- Waterfall Versus Agile
- An "Agile" Experiment
- Differences Between Agile, Lean, Six Sigma, PMP, and Other Methodologies
- Agile Is NOT for You ...
- Marketability of Scrum Certification and Consistency of Employment
- Certify THIS ...
- Getting the Most Value from Gatherings, Conferences, and Other Events
- I'm Certified--So, NOW What?
- Goodbye, My Friend
- Closing
This chapter is from the book
This chapter is from the book
This chapter is from the book
Differences Between Agile, Lean, Six Sigma, PMP, and Other Methodologies
This is a great question that has frequently been repeated in my classes in various forms. In other words, it comes up even if the class participants do not always ask about all of these methodologies listed, sometimes including Scrum, software development lifecycle (SDLC), and others. I think it’s important to first clearly define the difference between a methodology and a framework before we begin to look at these approaches and others.
A methodology is a system of methods, tools, and practices that explicitly outline phases and what must be done in a procedural manner. A framework, on the other hand, loosely defines practices and patterns, but allows for customization and flexibility in the implementation of these practices and patterns.
As we have discussed under the question “Waterfall vs. Agile,” Agile itself is neither a methodology nor a framework. Rather, Agile is a collection of values and principles that represent a philosophy and a way of thinking about value delivery. Because the authors of the Agile Manifesto were pioneers of their day who were advancing their own practices in software product development, Agile is a sum-total representation of many different approaches, not the other way around. I view Agile as a way to define the unity of purpose between Scrum, eXtreme Programming, Kanban, Adaptive Software Development, Rapid Application Development, etc.—somewhat like an umbrella term to describe all that is common among these practices in terms of their beliefs and the spirit of what they are trying to accomplish.
Agile shares with Lean the idea of delivering value by reducing the amount of waste. In some ways, Lean and Agile can be virtually the same thing. However, Lean has some very specific defining elements, such as the five principles:
Identify value
Map value stream
Create flow
Establish pull
Pursue perfection
Along the way, Lean identifies seven wastes that can exist in any manufacturing process, regardless of the type of manufacturing:
Transport
Inventory
Motion
Waiting
Overproduction
Overprocessing
Defects
We then look for ways to avoid or reduce these wastes while also considering the theory of constraints around external dependencies; that is, we build systems around the issues that we cannot control and then seek to optimize system performance instead of local performance, which does not increase overall throughput.
Thus, it isn’t a question of “Scrum or ...” or “XP or ...” These approaches are not 100 percent mutually exclusive of each other. In fact, many of the practices overlap and those that do not are complementary and compatible to a large degree.
Six Sigma (or 6σ) is a collection of practices and tools, albeit much more focused on improvements via measurement and metrics than on organic feedback loops. At the core of Six Sigma is the overall Lean goal of reducing waste and maximizing value.
However, because of the emphasis on quantitative vs. qualitative measures, many Agile proponents feel that Six Sigma is too heavyweight (and even a bit misguided in its application). Six Sigma can provide justification for changes and improvements for industries that are subject to very stringent regulatory compliance requirements.
For software systems that do not have a great risk or threat to human life or general welfare, improvements to performance and fitness of purpose are more effectively driven by customer interaction than an examination of metrics.
Kanban is framework that raises the transparency of work flowing through a workflow (system) by tracking the states of the work from beginning to completion. The key feature with Kanban is that each of these workflow states has a “work in progress” (WIP) limit, which transforms the entire workflow into a pull system instead of a push system. With a push system, it is possible for work to be continually sent downstream in the workflow in spite of a bottleneck or overflow condition. With a pull system, additional work cannot progress through the workflow until there is an opening in the next workflow state downstream. The only exception is an expedite queue, which allows violation of WIP limits in those rare instances when there is work that is critical in nature.
Kanban can be used in concert with Scrum with a degree of success, especially when Development Teams are focusing on establishing a consistent flow of features that meet the Definition of Done and are continuously deployed rather than batched into Shippable Product Increments. The Scrum aspect comes into play in order to take advantage of the improvement mechanisms (aka feedback loops) provided by Scrum Ceremonies (aka Activities). For instance, the team would select a regular interval to reflect on its own growth and maturity and to discuss ways of improving how they work together as a team. This is the Scrum notion of a Sprint Retrospective. They would also regularly reflect on the product itself to ensure that it is meeting customer and stakeholder expectations. This is the notion of a Scrum Sprint Review.
eXtreme Programming involves engineering practices and less formality around roles than does Scrum. Some of these practices include continuous integration, test-driven development, pair programming, the use of acceptance criteria, refactoring, collective code ownership, etc.
There are other sets of practices such as Rapid Application Development, Dynamic Systems Development Method (DSDM), and Crystal Clear, which have all lent their influence and inspiration as inputs to the Agile Manifesto. Even some aspects of Rational Unified Process (RUP), vis-à-vis “The New, New Product Development Game” (Takeuchi and Nonaka, 1986) and some parts of traditional project management have arguably had influence on Agile. That is, project management is not specifically mentioned anywhere, but the activities of “managing projects” happen inherently and as needed throughout the various practices of Agile.
More important than any of this is the need for organizations to establish cultures that embrace change, learning, compassion, responsible growth, curiosity, experimentation, play, margin (à la Andy Stanley in Take It to the Limit) as a definition of sustainable pace, and other key dynamics that improve the quality of life for customers, workers, and the world at large. Organizations that embrace learning and promote the free exchange of ideas without fear of negative consequence excel in creating innovative products that delight their customers.
According to Steve Denning in his book Radical Management the ONLY thing that matters is the pursuit of customer delight, which can be accomplished through the practice of continuous innovation. Denning concludes that focus on profits, costs, and shareholder value does not produce the desired result of increased profits. If we focus on delivering products that delight the customer in every way, profits will naturally follow.