Charles Suscheck
Member for
18 years 6 monthsDr. Charles Suscheck is a nationally recognized agile leader who specializes in agile software development adoption at the enterprise level. He is one of the few scrum.org trainers certified to teach the entire Scrum.org cirriculum. With over 25 years of professional experience, Dr. Suscheck has held positions of Process Architect, Director of Research, Principle Consultant, Professor, and Professional Trainer at some of the most recognized companies in America. He has spoken at national and international conferences such as Agile 200X, OOPSLA, and ECOOP on topics related to agile project management and is a frequent author in industry and academia. Dr. Suscheck has over 30 publications to his credit.
All Articles by Charles Suscheck
All Stories by Charles Suscheck
|
Product Owner, Product Manager, or Project Owner?If you really want to get the benefit of Scrum, you have to make the mind shift to product ownership, not project management or project ownership. The product owner role is often thought of as being a requirements specifier, when in fact a good product owner is a value maximizer, and a great product owner is a product maximizer. |
|
Using the Definition of Done to Promote Continuous Improvement The definition of done is much more than just a checklist for completeness—it can be a mechanism for determining where your product increment can be more complete by the end of your sprint. By using a discussion board with quadrants where you can sort sprint items, you can challenge yourself to see whether a task could be moved earlier in the lifecycle. |
| Identifying and Improving Bad User StoriesA written user story is a very short narrative—a sentence or two—describing some small piece of functionality that has business value. User stories are intended to foster collaboration and communication, but writing these short narratives poorly can negate agile’s flexibility. Charles Suscheck and Andrew Fuqua explain some common failure patterns that will help you focus on the right role, value, and business functionality when writing stories. | |
|
The Problems with Overachievers on Agile Teams Using an amusing medieval tale with a modern twist, Andrew Fuqua and Charles Suscheck tackle the dilemma of dealing with problematic overachievers in your agile team. |
| Defining Requirement Types: Traditional vs. Use Cases vs. User StoriesIf you have recently transitioned to an agile team, you may have questions about the differences between user stories and use cases, especially how they differ from tradition requirements writing. In this article, Charles Suscheck defines each of these requirements types and uses a running example to illustrate how they differ in a real-world setting. | |
| A Productivity Comparison of Kanban and Scrum Charles Suscheck compares the levels of productivity of Scrum and Kanban through a hands-on experiment that he and his team personally participated in. Learn the upsides and warnings about each practice to help you decide what might work best for you and your team on your next project. |
|
| From Red Tape to No Tape: Organizational Misalignment with Agile Values Charles Suscheck writes that if you’re in an organization that has signs of post-industrial orientation, now is a good time to take a fresh look at your organization’s underlying (and often oblique) belief system. |
|
| From Red Tape to No Tape: Maximizing Agile in Your Organization Companies using agile development must recognize that they won’t reap the benefits of agile without the correct organizational philosophy. Companies often don’t even realize that they are following a path that can limit agile adoption. Here, Charles Suscheck describes two organizational philosophies—one that is adverse to successful agile adoption and one that facilitates the agile processes. |
|
| Why Agile Development Teams Need Business AnalystsUnfortunately for the business analyst (BA), much of the literature regarding agile development focuses on the perspective of the developer, largely ignoring the role of the business analyst. BAs play a key role capturing requirements on large, software-intensive projects. Teams are co-located where programmers and their "customers" interact directly as a means of eliciting requirements. Organizations that are moving toward agile development may wonder if a has a role in agile software development. The answer, as addressed by this paper, is a resounding "Yes." |