This is an introduction to agile thinking as it is realized by organizations in the process of getting things done – specifically as it relates to information technology – and to serve as a foundation for additional articles to follow. For an alternative introduction to agile, see HBR’s Introduction to Agile Management. For a nicely rich discussion about mature agile organizations and the benefits they accrue, see the McKinsey Insight The five trademarks of agile organizations.
To what does the term agile refer? It is typically used as shorthand to mean agile methodology. In contrast, a waterfall methodology is a more traditional way of managing projects. Both types of methodologies provide prescriptions for specifying, building and delivering things of value in a (typically large) IT organization.
Waterfall methodologies recommend that each stage – and each stage only – be addressed at a time, namely:
- [G] ⇒ Gather (or document) All Requirements
- [B] ⇒ After [G] is complete, Breakdown All Requirements Into Tasks
- [D] ⇒ After [B] is complete, Develop or Execute All Tasks
- [T] ⇒ After [D] is complete, Test All Tasks to Ensure the Results Meet the Requirements
- [R] ⇒ After [T] is complete, Release Developed Items and Repair Any Problems as they are Discovered
Each stage of the waterfall is intended to be completed before moving onto the next stage. For complex projects, one full lifecycle (from the beginning stage [G] to the end stage [R] of a project) can take months or even years to complete.
In contrast agile methodologies are iterative and incremental in nature. They more closely support the way that we, as humans, think and perform in nearly all circumstances:
- Think about what’s needed – make assumptions, prioritize
- DO SOMETHING to validate your assumptions (build something, buy something, observe something in the real world)
- Refine your thinking based on what you just learned and reprioritize the things you want to do or achieve next, if necessary
Note that this type of learning cycle works for us whether we’re talking about buying a new toaster, building a shed, making a career change, or pondering almost any “process” in our lives.
We can portray a single agile lifecycle as follows.
…where the GBDTR activities have the same meaning as in the waterfall stages with the exception that agile methodologies are iterative in nature, so the term stages becomes irrelevant.
Note that our waterfall stages have now evolved under agile to become, simply, the work needed to provide clarity to product teams and their stakeholders:
- Clarity for the current lifecycle… In other words, “Did we get what we wanted?”
- Clarity for the lifecycle to follow… In other words, “Did we release it (remember: information technology is the overall context here), and if so, did it delight our customer?
→ If so, we might drop the remaining work and move on.
→ If not, what did the customer say would delight them?
…which highlights another important feature of agile development: Get feedback early and often.
Each agile lifecycle, or iteration, may last a few weeks at the most, meaning that more high priority work can be completed and delivered far faster than with waterfall methods.
Project Versus Product
If you’ve been paying attention, I speak of waterfall projects but agile products. What is the difference between projects and products?
In waterfall methodologies, the focus of work is on a project. According to the Project Management Institute a project is “… a temporary endeavor undertaken to create a unique product, service or result.” It has definite beginning and ending dates and its scope tends to be well defined.
A product is an asset that has value; for example, this could be an app, a process, a service, or any of a number of other things considered to have value and persistence, and which provides benefits to a market.
Agile Versus Waterfall
Generally speaking agile methodologies produce better results than waterfall methodologies. Here are just three differentiators.
- Agile methods focus on creating value, first and foremost.
- Agile methods mitigate risk. By delivering work in short bursts, problems can be discovered and dealt with far faster than is possible with waterfall methods.
- Waterfall methods discourage changes to requirements once they’ve been identified. This is because every change to requirements – after the [G] stage is complete – represents an additional cost to the project. Under agile, changes to requirements are celebrated, not avoided. The philosophy sounds something like this: “If requirements change before a feature is added to a product, this represents a costs savings – because the original requirements (later modified) were not built (the money wasn’t invested in building according to the original requirements).”
Comparing the waterfall lifecycle with the agile lifecycle, we see…
[G] ⟶ [B] ⟶ [D] ⟶ [T] ⟶ [R] ⇒ MATURE RESULTS (Waterfall)
…which is intended to show that agile methods provide much greater value at significantly lower risk to the organization, given the same amount of time overall. In the above, only one waterfall lifecycle is shown whereas several agile lifecycles are shown to be executed during the same time period.
Agile Value Statements
Let’s leave this introduction with some thoughts about how the architects of agile saw its advantages over waterfall. The Agile Manifesto does a good job of explaining this:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”
The items on the right hand side are still important, just as they are in waterfall. They are simply considered to be of lesser importance than the items on the left hand side.