In software development, the fundamental goal of change management is to ensure that modifications to the scope of work taken on by a team are addressed in an appropriate manner. Changes may include the addition of new requirements, modification of existing requirements, requests to fix defects, requests to assist other teams, and many other kinds of work. There are different strategies for managing change, some that make it very difficult for stakeholders to get the changes they want and some that make it very easy. There are, of course, advantages and disadvantages to all of these strategies, and no one strategy is best (regardless of the claims of proponents).
This article describes how to take a disciplined approach to choosing the strategy that is best suited for your team. I’ve adapted material from the book Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise, which I coauthored with Mark Lines of UPMentors. An interesting feature of the Disciplined Agile Delivery (DAD) process framework is that it is not prescriptive, but instead is goals-based. So instead of saying, “Here is the über-agile way to manage change,” you instead prefer a more mature approach of acknowledging that you need to manage change, that there are several ways to do so, that there are the trade-offs associated with each, and deciding when you would consider adopting each one. Granted, some people who prefer to be told what to do, but my experience is that the majority of IT professionals prefer the flexibility of having options.
The DAD process framework describes several common strategies that you may choose to adopt for managing change. These options include formal change management, Scrum’s product backlog strategy, work item stacks, work item pools, and no strategy at all. Let’s explore each of these strategies one at a time.
Formal Change Management
Formal change management? For an agile team? Blasphemy! But no, the DAD process framework recognizes that agile teams can find themselves in a very wide range of situations, from very simple to very complex. Therefore, you need to consider a range of options, including strategies from the traditional realm.
With a formal approach to change management, the work to be performed is typically defined in detail and agreed to early in the project; and any changes to that planned work are then managed throughout the lifecycle. In simple situations, the product owner will be responsible for considering and acting on change requests for requirements or defect reports; although at scale, a change control board (CCB) may exist and meet regularly (ideally, at least once an iteration) to manage any change requests. The team lead is typically responsible for making decisions pertaining to requests from other teams or personal requests. Part of deciding whether to accept a change may include analysis to determine the impact/cost of the change versus the priority and business value for the customer.
The potential advantages of a formal approach to change management on an agile project include its applicability to regulatory situations where formal change management is mandated. Past surveys in Dr. Dobb’s have found that roughly one-third of agile teams work in environments where one or more regulations apply. This approach also works well for environments where the requirements seldom change, although this proves to be very rare in practice given the hyper-competitiveness of today’s marketplace.
There are many disadvantages to formal change management. First, it motivates stakeholders to accept a big requirements up front (BRUF) an approach where detailed specifications are created and agreed to early in the project, thereby taking on all the disadvantages of BRUF (and there are many). Second, it can motivate onerous requirements traceability efforts to aid impact-analysis efforts for the CCB. Granted, it’s possible to largely automate traceability if you adopt an acceptance test-driven development (ATDD) approach and a tool that supports it. Third, formal change management can add significant overhead to the effort, particularly when requirements change often, increasing project cost and extending the delivery schedule. Fourth, formal change management often evolves into a change prevention strategy on the part of IT staff, something that is ethically questionable at best. Fifth, for small changes, the overhead of considering the change may be greater than the cost of actually implementing it in practice. This indicates that you need to consider adopting a change triage strategy as well, further complicating your process.
Scrum Product Backlog
A common agile approach to change management is Scrum’s product backlog strategy. A foundational concept in Scrum is that requirements, and optionally defect reports, should be managed as an ordered queue called a “product backlog.” The contents of the product backlog will vary to reflect evolving requirements, with the product owner responsible for prioritizing work on the backlog based on the business value of the work item. Just enough work to fit into the current iteration is taken off the top of the stack by the team at the start of each iteration as part of the iteration planning activity.
This approach has several potential advantages. First, it is simple to understand and implement. Second, because the team is working in priority order, it is always focusing on the highest business value at the time, thereby maximizing potential return on investment (ROI). Third, it is very easy for stakeholders to define new requirements and refocus existing ones.
There are also potential disadvantages. You will need an additional strategy to manage other work item types, work such as people assisting other teams or taking time to attend training classes. The product backlog must be groomed throughout the project lifecycle to maintain priority order, and that effort can become a significant overhead if the requirements change rapidly. It also requires a supporting strategy to address non-functional requirements (NFRs), something I discussed in Beyond Functional Requirements on Agile Projects. With a product backlog strategy, practitioners new to agile will often adopt an overly simplistic approach that focuses only on managing functional requirements. Finally, this approach requires a product owner who is capable of managing the backlog in a timely and efficient manner something that organizations new to agile often struggle with.
Work Item Stacks
Development does not occur in a vacuum. Potential defects and enhancement requests are often reported from operations and support teams working with existing versions of a solution or from independent test teams working in parallel. Because your team is likely one of many within an organizational ecosystem, you may receive requests to review the work of other teams, to collaborate with them to ensure that your solution works well with what they’re producing, and other similar requests. Individual team members will have personal requests to attend training classes, take vacations, attend conferences, and so on. All these work items should be managed and acted upon by your team accordingly via your change management strategy.
A work item stack, sometimes called a “work item queue,” is an extension to Scrum’s product backlog that includes all types of work items (requirements, defects, team collaboration requests, personal requests). Work items are prioritized based on a variety of considerations, including both stakeholder value (an extension of business value to address all stakeholder concerns, not just business ones) and team health considerations. Mature teams will take risk into consideration when prioritizing work. For example, to reduce technical risk, a DAD team will prove that their architectural strategy works by creating a working, end-to-end skeleton that implements several high-risk requirements.
There are several potential advantages to this approach. First, it includes the benefits of the Scrum product backlog described earlier. Second, it explicitly manages all work item types in a single, consistent manner and thereby simplifies the overall change management process. And, it provides an explicit strategy for addressing high-risk work early in a project thereby increasing the chance of project success
There are also some potential disadvantages with work item stacks. The most serious is that it increases the responsibilities of the product owner already a tough role to address team health and project risk considerations. Second, like product backlogs, the work item stack needs to be groomed throughout the project lifecycle, thus adding overhead. Third, it still requires a strategy to address non-functional requirements. Finally, although human considerations such as training and vacation should be addressed, they are often deprioritized by the product owner in favor of function-oriented work items such as new requirements and defects.
