Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

              I.  Individuals & Interactions OVER Processes & Tools

             II.  Working software OVER Comprehensive documentation

            III.  Customer collaboration OVER Contract negotiation

            IV.  Responding to change OVER Following a plan

While items on the right are important, we value the items on the left more

This manifesto with its 12 Principles and 4 Values is at the core of all Agile Practices and techniques

What does this Manifesto mean?

Individuals & Interactions over Process & Tools | As we have discussed before, the process of software delivery has been a highly regulated one with practices to ensure that what is being built is first designed perfectly. Processes and tools that supported this approach were also designed to track the artefacts through its life cycle enabling monitoring them as they moved from one person or department to the next. Thereby reducing people's interactions and conversations. Agile believes that when the various stakeholders involved in designing, building and delivering the software collaborate closely, the completeness of the deliverables, its alignment to the expected outcomes and hence the speed is positively impacted. This is what drives the first line of the Manifesto – Individuals & Interactions need to be supported by the right process & tools. The latter are not meant to replace the former, but to enable them

Working Software over Comprehensive Documentation | In the waterfall approach it is believed that to build software you first need to comprehensively document everything that needs to be known and anticipated upfront, so that there are no “surprises” later. This upfront analysis and sign-offs, take up roughly 50-60 percent of the project time. To finally be left with less than half the time to develop, test and deploy the actual software that would bring in value to both the business and its customers. This means that the maximum time that should be spent on building the software to drive real value is now being spent on analysis, planning and perfecting the two. The focus should be on maximising the time that the team has to actually build, test and deploy the software as that would be unlocking the real value. Hence Working Software is more valuable than the surrounding documentation and other artefacts. Documentations and design should support and enable the speed and completeness of delivery rather than take time away from it. Living Specifications using BDD are far more supportive of a responsive software than the reams of document we otherwise create but are hard to read and comprehend.

Customer collaboration over contract negotiation | In the waterfall approach, the modus operandi is to ensure that all that is known, understood and required are documented and signed off before any work starts on them. This becomes a binding contract to which business is held up to where any change to the same would need to go through a change management board. This is an attempt to avoid any changes to the software being developed. This worked well in the early days of software delivery where making any change was very expensive. This is not the case today and moreover, this goes against the grain of the market forces today where neither the customer nor the business might have a clear idea of what would work and what would not. Hence the emphasis has moved over time towards focus on outcomes and teams working closely to rapidly ideate, create and deploy the software. The feedback helps the organisation tweak the idea, till the needed results are achieved. This is succinctly captured in the 3rd line of the manifesto

Responding to Change over following a Plan | Planning has been and continues to be a big part of the software delivery process. A well thought through plan is half the battle won they used to say and maybe it is. Plans are good and are needed, but a good plan is one that adapts to reality and responds to change enabling us to effectively reach our goals, despite the many distractions and hurdles. This is what builds and drives the ability to respond to change. This does not mean there is no planning but predictive approach to planning is replaced by an adaptive approach. The focus switches from following a plan to planning to deliver

‍

Next : Agile Values