Cycles of Change: Agile, Waterfall and Continuous Improvement
When version 2 of A Guide to the Business Analysis Body of Knowledge® was released about five years ago, the Business Analysis Planning and Monitoring Knowledge Area discussed a spectrum of project types that range from plan driven to change driven.
Agile methodologies were not yet established, and were described as change driven. This was in stark contrast to traditional Waterfall projects.
Volunteers working on version 3 of BABOK® Guide – now undergoing a practitioners’ review and expert review — are using the Business Analysis Core Concept Model as a foundation. They found that approaches to controlled transformations of organizational systems had the same fundamental purpose: to manage the risks associated with the complexity of a change.
- For logistically complex changes, longer change cycles are established, with up-front planning to identify potential problems, establish risk management practices, and then to take considered action. This is particularly useful for big, well-defined needs, and high-risk situations. It is very hard to build a dam using Agile.
- For logistically simpler changes, rapid cycle times are established, with continual reprioritization to target short-term value delivery. This is particularly useful in unstable, dynamic situations. It is very hard to maintain a bridge using Waterfall.
This analysis led the team to generalize and refactor the spectrum of “change driven to plan driven” in BABOK® Guide version 3 The new text discusses three concepts: cycles, complexity, and formality.
Cycle durations describe the typical time frame for delivery of a solution to a stakeholder. This directly constrains many options for the business analyst, including the timing of business analysis work, which techniques may be used to perform business analysis tasks, the degree of formality possible, and the levels of complexity that can be addressed. The team found most changes deliver value in one of three ranges.
- Value Delivered in Days to Weeks: Continuous improvement and Agile are best known for operating with cycles of this duration, but many support or maintenance changes also have short cycles. While Agile is focused on delivering working code in very small increments, physical objects can also be built in this timeframe, particularly with the advent of 3D printers.
- Value Delivered in Weeks to Months: Iterative changes are common, especially as “phases” of a project. Phased projects have many small waterfalls, rather than one big one, and can be thought of as a program of many small projects.
- Value Delivered in Months to Years: Traditional waterfall is most appropriate for changes that are logistically complex. Some complexities result from having long timelines built into the change, as is found in highly regulated industries (such as financial services, power generation) or research (such as pharmaceuticals and aerospace engineering). In these cases, there may be no “minimum viable product” that can reasonably be treated as its own change.
The Complexity of a Situation can drive the cycle duration that is appropriate for a change. Factors that can increase the complexity of business analysis efforts include:
- number of stakeholders affected by the solution,
- number of stakeholders involved in making the change (change agents),
- number of organizational areas affected,
- number of systems affected,
- number of technologies or tools affected,
- amount and nature of risk, and
- uniqueness and uncertainty of requirements.
Agile approaches are most effective when the complexity in any single cycle is quite limited; there simply isn’t the time to communicate with a large number of stakeholders, or manage a large logistical effort. Agile tends to be more effective at making less complex changes, particularly when the situation is rapidly changing; course corrections are built into the short cycle time. Longer iterations increase the risk of irrelevance—but some changes take time to complete.
Agile approaches can be combined with longer cycles. For example, some aspects of a large, complex change may be developed using Agile approaches.
As the complexities increase there can be thresholds where the nature of the change transforms into something altogether different. This is a common experience in communications, where the nature of communication is fundamentally different at different scales; a message to hundreds of people cannot use the same tools as a message between two people.
The formality of business analysis work is also related to the duration and complexity of each change cycle. For a close-knit innovation team with six people doing everything in one room, requirements may be largely composed of diagrams on the walls, and pictures of those diagrams—but most situations demand more structure and consistency in the outputs from business analysis work. Templates, document repositories, and requirements management tools may all be used to increase the formality of the requirements. Approvals and commitments to act on requirements will be related to the formality of the requirements themselves.
In many cases, Agile development and Continuous Improvement work can be pursued with relatively informal requirements, and relatively informal approvals. Requirements still need to be complete—measurable, clear, traceable, and so on—and approvals must not be assumed.
Change Cycles and You
There are general principles for choosing the right cycle duration for a change:
- Given the complexities of the situation, minimise cycle duration and formality of outputs.
In other words, shorter cycles are more likely to deliver more value more quickly, unless they deliver no value at all.
Don’t forget to leave your comments below.