How Does The Agile Manifesto Address Planning

Considered by Agilists to be the Bible of all things Agile, the Agile Manifesto is a document that outlines four key values and 12 principles that its authors believe should guide an Agile project. Originally called the Manifesto for Agile Software Development, this document was created by 17 of the most forward-thinking software developers at the time, during a meeting at a ski resort in Utah in February 2001. As they combined work with a holiday, they created history in the world of project management—and Agile was born!  

In this blog, we’ll talk about how the Agile Manifesto approaches planning and change management, allowing teams to implement evolving requirements throughout the project journey. 

Difference Between Traditional and Agile Approaches To Change

Traditional project management methodologies   have always frowned upon any changes that occur during the progress of the project. They follow rigid change management procedures, including legal contracts around change and strict budget policies, that ward off change as much as possible. However, what usually happened with such inflexible approaches, especially in projects that lasted several years, was that the product did not meet the needs of the end-users. Quite often their requirements had changed in the meanwhile and these changes were not considered at all.

This is where Agile project management came in, disrupting the traditional approach to change management with the Agile Manifesto. "Responding to change over following a plan," is the fourth core value of Agile, and addresses the need to be able to respond to and factor in change. 

Agile projects differ from traditional projects in that they can accommodate change in a systematic manner. In a world where requirements keep evolving and industry needs are volatile to say the least, Agility is a very important prerequisite for success. This was the core reasoning behind the formulation of the Agile Manifesto, and the authors of this innovative philosophy recognized the need to break away from tradition and embrace innovation.

What Does the Agile Manifesto Have To Say About Planning?

Agile is not a framework but a philosophy and mindset. The Manifesto offers a broad overview of the values and principles at the heart of an Agile mindset, without being a How-to Guide that details out processes on how to complete a project. Strictly speaking, the Manifesto does not talk about project planning, but it does strongly emphasize the importance of planning. The fourth value outlined in the Manifesto talks about “Responding to change over following a plan.”

What this means is that Agile recognizes that change is a valuable tool in the arsenal of project managers, as it adds immense value to great products. Planning is indeed important, but not as important as the team’s ability to respond to change. Using the principles in the Manifesto, teams can respond quickly to change, and develop products that have current industry relevance and that people want to use. 

As such, an Agile project plan should be a living document that is modified to accommodate change as required by emergent market conditions.

Change in Agile: The Gamechanger

In any Agile project, the team should have the ability to not only respond to but also welcome change. This capability of Agile teams is a gamechanger that differentiates an Agile project from a traditional one. The Agile mindset is flexible, and every single practice and process has the capability of continuous adaptation built into it.

In fact, as the world today is so volatile, we could even claim that a project without change has a much higher chance of failing. If we lack the ability to change course and make new decisions in our everyday lives, we would find ourselves failing in the simplest of tasks. In a VUCA world, change is indeed the only constant and runs through all that we do.

How Does Scrum Factor in ‘Change’?

Scrum, the most popular Agile framework, understands the importance of change in the current market. As change cannot be ignored, the best way to deal with it is to embrace it wholeheartedly and adapt to suit the change. This principle is an inherent part of the Scrum framework, and it follows the key principle from the Agile Manifesto “Responding to change over following a plan,” in its entirety. 

By adapting to change, Scrum aligns itself with the needs of the market and gains competitive advantage as a result. Scrum project management is approached in an iterative, adaptive manner and does not follow a previously prescribed plan. Scrum enables rapid product development through short iterative cycles called sprints. This is why it is very well suited to projects where the requirements are not fully defined upfront, and changing requirements need to be incorporated into the product in subsequent sprints. 

Scrum proves to be the most useful approach for projects with: 

• Requirements that are not fully understood 
• Requirements that are not completely defined 
• Volatile markets 
• Long-term uncertainties and risks 

In all these cases, by using the Scrum framework, teams can easily adapt to the change and roll out high value products that are relevant to end user ends. The team follows Scrum principles and processes, working with complete transparency, inspection, and adaptation to achieve valuable business outcomes. 

Some of the ways in which Scrum factors in change are: 

• The entire product backlog can be modified and re-ordered to keep in line with evolving scenarios. 
• Any degree of change can be accommodated in between two sprints, but not within the sprint itself. By keeping sprints shorter in duration, more changes can be accommodated. 
• Scrum feedback cycles such as reviews and retrospectives allow for frequent inspection, after which the team can change course to align with the feedback given. The stakeholders and end users are in constant touch with the way the project is unfolding and will therefore not be faced with nasty surprises at the end of the project (as would be the case in a traditional project). 
• Scrum allows Change Requests, with a process in place for approving and managing changes. Small changes are usually approved by the Product Owner, while larger changes might need to get higher level approval, such as from stakeholders or senior management. 
• During Epic development, and while the Product Backlog is ordered and groomed, user stories around these change requests are written, and the items are added to the Product Backlog. 

Conclusion 

While the flexibility and iterative nature of Agile projects might seem to make the project journey unpredictable, the reality is that change in Agile is very predictable and manageable, and results in greater project stability with better outcomes. Any change is considered as a chance to add more value to the product, instead of being viewed as an impediment to progress. This is where Agile enhances value, paving the way for superior products that create customer delight.