Respond to change - Agile

When I first started doing Scrum I was focused on project delivery. As a software professional I wanted to find better ways of delivering customer value and Scrum made total sense to me.

But as I applied Scrum, I started to realize that Scrum isn’t actually about delivery; it is about change.

What is Agile Methodology …. here is a quick overview:

Agile is a group of methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile promotes adaptive planning, evolutionary development and delivery – a time-boxed iterative approach – and encourages rapid and flexible response to change.

Here, Agilists want to develop software which is both high-quality and high-value, and the easiest way to develop high-value software is to implement the highest priority requirements first. This enables them to maximize stakeholder ROI.

In short, agilists strive to truly manage change, not to prevent it.

Change control is a traditional project management process for managing change. In a traditional project change control typically consists of filling out a detailed change request form which includes attributes like detail of change, impact to the project, risks, mitigation's etc. It also needs approval of several people.

Traditional change control is at odds with Agile because it conflicts with the principle of “Responding to change over following a plan”.

Why there is any change request in Agile requirement?

• Product Owner missed a requirement. A stakeholder will be working with an existing system and realize that it's missing a feature.
• Product Owner identified a defect. A bug, or more importantly the need to address the bug, should also be considered a requirement.
• Product Owner realize they didn't understand their actual need. It's common to show a stakeholder your working system to date only to have them realize that what they asked for really isn't what they want after all. This is one reason why active stakeholder participation and short iterations are important to your success.
• The market place changes. Perhaps a competitor will release a new product which implements features that your product doesn't.
• Legislation changes. Perhaps new legislation requires new features, or changes to existing features, in your software.

How to consider any new change requirement in Scrum – Agile?

• One of the 12 agile principles say " Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage" . But Scrum suggests that we should freeze the requirements after the planning session as soon as team gives its commitment for the current sprint. After that any change coming should be treated as a new requirement and should follow the change management process

How Agile Change Management should occur in Scrum …

• Normal Conditions

All Scrum teams work on a product backlog which is owned by the Product Owner. The user stories are prioritized in the decreasing order of priority. So at any point of time the scrum team is always working on the highest priority item. The priority of an item is based on multiple factors including ROI, Business priority, technical dependency, risks associated with the story etc.

• Change Triggering Points

If there is a new story, of high priority, added during the execution of a sprint, change control board members will sit together and work on the updated product backlog to decide the user stories which are planned for the next sprint. Similarly, if during sprint review, the Product Owner feels that a story needs to be re-worked or changed due to inputs from stakeholders or market conditions, that particular story needs to be given a higher priority and the team picks up that story as a part of the next sprint depending on the available team capacity.

• Steps taken in the change implementation

1. Product owner raises a request to add/modify a requirement/story in the sprint backlog
2. Impact Analysis of the change by the team
3. Estimation by the team
4. Decision by the CCB to accept or reject the request
5. Look at the available capacity and resource utilization
6. If there is no capacity available, then some other user story should be dropped from the product backlog; best practice is to remove the user story that is not yet started by any of the team member. I would also suggest maintaining a change log at scrum master level per sprint. This change log should also be reported in the sprint status meeting after the sprint. And off course this is an item in the retrospective meeting.

Does Agile eliminates change management challenges?

• Change management challenges are not eliminated when using Agile methods. They may be necessitated by the external environment, not something within the development team. Agile provides a disciplined, streamlined way to manage them. Agile iterations provide working software earlier, enabling owners and users to recognize and address needed changes earlier. Change management in non-Agile environments assumes that changes come at the end of the development cycle and at most can be minor deviations from the original set of requirements.  However, in practice these changes are anything but minor. Agile methods give you a way of recognizing that change management is inevitable and the development methodology needs to facilitate its incorporation in a natural and non-intrusive way.

Conclusion

Change management has always been a challenge in software development, whether you use Agile methods or not. If changes are needed, in Agile-Scrum, they can be recognized earlier and interleaved with earlier iterations. This also provides a smooth way to also get development risks out of the way, earlier in the development cycle.

Rapid change management is the rationale for using Agile methods and can add significant value to resulting software as per corresponding market need.

Happy Learning ....