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”.
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.
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.
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.
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.
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 ….