In the two previous articles in the Change Management Series, we focused on the conventional “waterfall” approach to change.
In this article, we look at Agile Change Management.
“Much of the strategic change toolkit took shape in the 1990s and evolved to support the people dimensions of change for Waterfall projects, often comprising of rigid change strategies and communication plans, stakeholder analysis and impact assessments and a commoditized, perfunctory approach to change.This approach simply doesn’t work in an Agile environment.” 1
Table of content:
- 1. Agile is not like Conventional
- 2. Agile
- 3. The Beginning
- 4. How do we change
Agile is not like Conventional
In what might be referred to as conventional project approaches, attempts to quantify the scope of the project are undertaken in the beginning.This understanding of the scope of the project allows for estimating the cost, and duration for the project, however not all project objectives are so clearly delineated. A bridge, for example, is clear. The bridge spans across some area carries a defined amount of traffic, and the thing we must do to accomplish this objective is known and has been, with some exceptions. The Galloping Gertie bridge excepted.
2
Agile
In agile, we recognize we do not know everything we need to know. This requires a significant amount of discovery both technical and understanding the customer’s objectives. Doing the work will answer these unknowns. The Agile approach is frequently used in developing software products. Since we may not have a great deal of detail from the customer or perhaps technical, we cannot have a fixed scope at the beginning. Because we will learn throughout the effort, we cannot learn first then estimate the scope and duration. Discussions with a friend and colleague suggest that this lack of customer clarity of objective or scope does not only apply to software products. Even industrial systems have ambiguity and with ambiguity, conventional approaches, fixed scope, can be messy. To proceed, let’s start with some definitions.
Product Backlog
The highest level, least details, of scope is the product backlog. This is a list of features or attributes the product is to have. This will be a prioritized list, with the most imminent, or most desired attributes getting the most attention to evoke expectations. Once these things are known to a sufficient degree, these items will fodder for the sprint backlog for work.
Sprint Backlog
The sprint is the time where the work is to accomplish the objectives are performed. The sprint is usually between 2-4 weeks in duration, an 80 to 160-hour window. The highest priority items from the product backlog are decomposed into specific actions for the sprint. Once the sprint duration is filled, no more time in the window available for work, the sprint backlog is populated.The work must fit within the sprint window.
Unlike waterfall, we do not require to connect the entire scope of the project to estimates of cost and duration. Agile focuses on smaller work scope (incremental and iterative) and teams are always in communication with stakeholders. Rather than plan the entirety of the scope and cost, we will work from a list of desired features, the product backlog. Periodically, we will take the prioritized items off the product backlog and decompose what will be required to deliver that product backlog item during the sprint. In effect, no more work is added once the sprint is underway. There can be more than one sprint, if the product backlog still has content, and there is more budget for the work, the sprints can continue. There will be not changes once a sprint is underway.
The Beginning
We can see that rather than the scope being hard or fixed. The scope is not “fixed” until work is in the sprint backlog. The change process starts at the beginning of the execution.The product backlog can and is expected to change. There is no change mechanism required as the change in the product backlog does not impact the execution to deliver. Once work taken into the sprint, there are no changes.The scope is only fixed during the sprint. The product backlog changes and is updated as things are learned along the way. The duration of the fixed scope is so short, that changes or adjustment to the scope are seldom required and when it is, the sprint is terminated. Documentation is critical.
Agile change management is based on trusting communication. This is accomplished through frequent and open engagement of the stakeholders. Where conventional projects are delivered complete on a specific date, Agile projects are delivered in phases or stages. This allows for user feedback to create changes as the project progresses.
How do we change?
Change Management in an Agile Environment can be handled as the team, including the client and all stakeholders, decide. The team can establish guidelines such as Minimum Viable Product (MVP) or Minimal Viable Change (MVC).3 The changes still will need to be articulated and perhaps documented via the product backlog.
Just like conventional review and change meetings/sessions should produce documentation. Different from conventional, the documentation is usually a summary of the changes. And rather than investigating cost impact, a ballpark amount is presented. The approval process has more focus on the change approval than a cost approved. If the proposed changes fit the MVP and/or MVC, no matter the cost, they will be included.
1 Agile Change – Lessons from the front line | Deloitte Australia | Technology services
2 Graphic is from Rick Edwards
3 Agile Change – Lessons from the front line | Deloitte Australia | Technology services