Does Agile mean no more planning or documentation?
At iLean we have been passionate about Agile for a very long time already, and it is our mission to help as many people as possible discover the many advantages Agile can bring. Unfortunately, a few persistent misconceptions about Agile are restricting people’s openness to give Agile a chance. That is why we want to take you along through the second episode of our “Agile Misconception Series.”
In this second episode of our series, we will touch upon the sentiment that “Agile means no planning or documentation”. We really beg to differ, and here is why.
Where is this misconception coming from?
Agile teams require a certain amount of independence and autonomy, enabling them to do what needs to be done to achieve their shared goals. Originally that often meant that Agile teams needed to rebel against the traditional plan-driven approaches, with fixed rules and plans that give the impression that everything can be controlled. The Agile movement was a counterreaction to this traditional approach and focused more on the ability to adapt.
But whereas people may have perceived this counterreaction as stepping away from planning, the Agile angle is not to be against planning or documentation but the realization that everything should not revolve around planning itself.
Agile manifesto
The development of the Agile movement, where like-minded independent thinkers united to create a more considerable positive impact with their principles, eventually culminated in the Manifesto for Agile software development in 2001, the Agile Manifesto in short.
Although this manifest was crafted with the best of intentions, its 4 values seem to have unconsciously encouraged some ongoing misconceptions about Agile.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The Agile Manifesto is often misread and misunderstood. It is important to interpret it with a certain degree of nuance in mind. And often, it is also used as an excuse because people don’t always like to write documentation, draft up contracts, or follow fixed plans.
But the four values of the Agile Manifesto are in fact preceded by an important instruction:
“That is, while there is value in the items on the right, we value the items on the left more.”
Agile working is not against planning or documentation, it is not a matter of good versus bad. It is about a shift in focus: success depends on the way of working together and the capacity to adapt. The right part of the manifesto (documentation, tools, processes, planning, …) needs to facilitate the left side (instead of being a goal on its own).
Individuals and interactions over processes and tools
A good example of a well-balanced left and right side of the manifesto is when tools are helpful, where they help shift the focus to the group rather than on the individual, and they help to stimulate interactions between individuals. For example, a tool like Jira or Azure devops can be great if it helps people collaborate on shared goals and talk around shared planning. But when they are used to isolate people, the whole point of tools that are helpful is moot. For example, members of an organization that only communicate over Slack whilst they are sitting close to each other, tools only used to push your finished work onto the next person without any common goal in mind, …
It is definitely worth the effort to contemplate the level of helpfulness of the tools, processes, … in your organization.
Working software over comprehensive documentation
The opinions on whether or not to document are very divided. And yet again, it is not a black-or-white situation. Agile is not against documentation, on the contrary, documentation is seen as a means to help solve problems, it is part of the overall quality.
It is actually a negotiable part of the collaboration with (internal) customers, rather than a tick in the box. It is important to determine what is needed, how much, and for what purpose. But again, the documentation should not be the goal, it should be a helpful tool to facilitate collaboration. A fully documented wiki page that no one reads is less valuable than one single line of self-explanatory code.
Customer collaboration over contract negotiation
This item of the Agile Manifesto does not imply stepping away from contracts, it is encouraging to shift focus, to use a different approach.
Whereas in the rather traditional contracts, there is a more punitive focus, stipulating penalties and what to do in case something goes wrong, the focus in Agile contracts is more reconciliatory, stipulating:
- agreements on how to achieve results together and in a positive, healthy manner
- guarantees for better ways to work together
- ways how feedback can be continuously integrated in the process
Responding to change over following a plan
Long-term planning set in stone is not compatible with our VUKA world. There is a need for a certain degree of adaptability, but that does not mean there is no need for planning at all.
Agile working does not equal no planning!
Agile is all about planning that enables long-term goal setting but where there is a possibility for change along the process.
It entails an iterative, incremental way of working, with smaller, achievable short-term goals. An evaluation at the end of this short-term goal will allow for the identification and implementation of changes (where necessary) to work towards the long-term goal.
Scrum can be an ideal tool in this context, and it will allow for the incorporation of what was learned into the next steps of the plan!
Agile in a more general context
The Agile Manifesto needs to be seen in its time and context. It does have its origins in software and IT and the terminology used is also software related. Just like Scrum had to break free from its stigma that it is a framework only suitable for software development, the Agile Manifesto deserves to be read with the same evolution in mind.
Fortunately, there is a clear evolution ongoing, and the Agile Manifesto in practice is getting more and more rooted in a more general context with a broader terminology.
“Working software over comprehensive documentation” is more and more changing into “working solutions over comprehensive documentation”, “Customer collaboration over contract negotiation” is evolving towards “stakeholder collaboration over contract negotiation,” and
“Responding to change over following a plan” has rather become “responding to feedback over following a plan”.
Conclusion
Despite the perception that Agile equals throwing all plans and documentation out of the window, we can assure you that it is not.
Agile is not against planning or documentation, it is all about using those tools to improve collaboration and to achieve goals, rather than focusing on planning, tools, or documentation in itself. It is about creating the right amount of documentation and planning to support the team in effectively working together, while also embracing a sufficient amount of adaptability to change.
We hope we have countered some of the misconceptions about planning and Agile working, and we hope you will tune in to our next episode of the Misconception Series, where we will dig deeper into the misconception that ‘the scrum master is the same as a project manager”.
Stay tuned!
