Episode 1/10 of Demystifying top 10 Agile & Scrum Myths
Embark on a journey of Agile enlightenment! Unveil the curtain on common misconceptions that often shroud the world of Agile and Scrum. Whether you’re a seasoned professional or new to the Agile landscape, this series is your passport to clarity.
Have you ever found yourself having to defend the need for documentation? Have you ever been told not to document because it’s not agile? Or have you perhaps been on the other hand and pushing for no documentation because it goes against the agile manifesto? Well, then this article is for you!
Let’s directly dive into the root cause of this first myth, which can be found by misinterpreting and potentially even abusing the agile manifesto, followed by clear situations in which more documentation improves agile delivery.
1. “Working Software over Comprehensive Documentation”
Agile values working software as the primary measure of progress. The focus is on delivering functional, valuable software to users. Continuous delivery can however be hindered by a lack of documentation or a lack of quality.
Mind the knowledge gap
How to recognise it?
New team members struggle to onboard quickly and have a high reliance on tribal knowledge. Or the team struggles to recover from key individuals leaving the team.
Why is this bad?
Expect your more senior developers to get burdened with training newcomers over and over, draining their energy that could have been used towards development.
The energy drain is something most developers will eventually want to move away from and can cause to want to step away from the development team. Be extra wary of people who try to hoard knowledge and are reluctant to share it. Knowledge is power, and some people crave it to build their individual value, and in doing so, they actually hurt your team’s value proposition.
Not intervening here can lead to two things:
- We all keep passing on the information over the years.
Anybody who has played the ‘Telephone game’ can tell you the hilarious outcomes you’ll get for just trying to pass through a single sentence to multiple people. Imagine doing this in a complex environment, and all of a sudden, this approach just doesn’t make sense anymore as your main means of knowledge transfer.
2. We train newcomers by having them read the codebase.
Without proper documentation, that’s hardly going to be effective and a huge time, money and motivation sink each and every time.
Coding boy-scouts will always try to attempt to leave behind an environment more clean than they found it, but you can imagine a ‘teach by reading undocumented code’ culture does not foster such a thing and can persist well beyond the initial founding father’s departure of a product.
Such a culture will encourage a patchwork type of working, which will introduce technical debt at an alarmingly rapid pace. And just in case you’d like to solve this by adding more developers to the team, expect increasingly diminishing returns.
Maintenance maze
How to recognise it?
Grooming sessions focus increasingly on what ‘could happen’; more spikes are introduced to analyse upfront, and the number of bugs increases.
Why is this bad?
As code bases grow, complexity grows. This directly means that as a code base grows, the value of and need for comprehensive documentation grows. A vital realisation should quickly set in:
What sufficed in the past as the minimum viable documentation may not suffice as a standard in the future.
If not tackled correctly, brace yourselves, because bugs will surely be coming at a very rapid pace and will cause both the perceived stability and value of your product to decline.
A common mistake is to focus on the symptom rather than the root cause. This increases the number of spikes and upfront analysis, which is all effort that doesn’t directly deliver valuable software. By following this approach without updating your documentation, you’ll be stuck in a downward spiral of having to mitigate more risks, conduct more upfront analysis, and risk bringing your team to a near-complete standstill.
Try to update your documentation standards and include them firmly in your DoD at this stage, or at the very least, include them in the acceptance criteria for the spikes and analysis. It may feel like going a step back, but it’ll propel you forward long-term.
Communication breakdowns
How to recognise it?
Frequent unclarity about goals and vision, or working agreements.
Why is this bad?
Misalignment on goals and visions can cause quite a mess, take away from focus, and with it lowers predictability, delivery and continuity.
Do your teams behave like chickens in a pen at the start of the sprint? When the shot is fired to start the sprint, everybody is busy, and you’ll spend the rest of the sprint bringing them back together again.
Or do your teams behave like a bicycle racing team? Heading towards the same goal collectively, manoeuvring obstacles with a shared goal of reaching the finish healthy and effectively?
If the first situation is allowed to fester, this situation of chaos will cause an increasing number of conflicting goals and a lack of trust. Also, your team will be unable to manage stakeholder demands and will lose buy-in from stakeholders.
Without a foundation of trust within your team, it will be nearly impossible to drive positive change, and you will have allowed your team to descend back to the storming phase.
In situations like those above, creating transparency on the vision and goals that you as a team are going for can create a talking point to increase alignment, stakeholder buy, and overall collaboration, and in doing so, value creation in the form of valuable working software.
Talk with your product owners about the product vision, product goals, and sprint goals. If you get stuck on any of those levels, it’s an important indicator that there’s a deeper problem that needs to be solved.
2. Responding to Change over Following a Plan:
Agile embraces change, even late in the development process. This principle can lead to a reluctance to create extensive documentation upfront, as requirements are expected to evolve throughout the project.
This part of the article is fairly short and simplistic. It’s indeed a waste of time to create extensive documentation up front in agile product development.
Be mindful however, that as time goes on with your product development, more and more clarity should also come on how your product works, how it ties in to the product goals, and the product vision. Focusing on a minimum viable documentation agreement will be important (more on that in Chapter 4)
3. Customer Collaboration over Contract Negotiation:
Agile emphasises continuous collaboration with customers and stakeholders. This ongoing dialogue is seen as a more effective means of understanding and refining requirements compared to relying solely on static documentation.
Expectation roulette
How to recognise it?
Frequent unclarity about goals and vision or working agreements.
Why is this bad?
Misunderstandings in working agreements open up doors for conflicts. If your conflicts keep occurring, they are paired with fuzzy agreements and diverging expectations.
It can be very much like Russian roulette, where you’ll spin the revolver with six chambers and two bullets. 66.7% of the time you’ll come out alive, and the other times, not so much. You will however have to identify the loaded situations and come up with a proper strategy before they blow up your team’s dynamic.
Conflicts come with a lot of energy, you can and should defuse the situation to prevent further escalation obviously. An important follow-up should be to thank everybody for their engagement and energy and channel it to optimised collaboration and agreements.
These newly found lessons should most definitely be documented and put on paper. The process of doing so in the right manner with a clear outcome takes the fluff out of the discussion, and the clarity objectively in the documentation. While most of the value of the documentation lies in the memory of what was said and felt and the alignment it brings, the sheer fact that documentation exists means that future conflicts can be killed more easily, or better yet, prevented completely, and will focus everybody’s energy and focus back on the actual software delivery in a constructive manner.
Please note that these agreements do not hold indefinitely, and if somebody thinks we should really revisit them, you can and probably really should. In this way, the agreement can help spark and structure a conversation based on a common understanding, which keeps it relevant. The document in itself is an enabler for higher alignment and never a goal in itself.
4. Individuals and Interactions over Processes and Tools:
Agile values communication and collaboration between team members. The emphasis is on face-to-face communication, which is considered more effective than relying on documentation for conveying information.
Howitzer duck hunting
How to recognise it?
Documentation is actually limiting interaction within your team; nobody wants to update the documentation; documentation is all over the place.
Why is this bad?
Documentation that is not enabling interaction means documentation adrift, which will over time become a shipwreck.
Are you familiar with organisations where documents that haven’t been updated in a year or less get put in an ‘archive’ folder, or does documentation get shared with a disclaimer of ‘The information may be somewhat outdated here and there, it’s quite old’? Well you’re in luck, because this chapter should speak to you.
Focus is of the essence here; less documentation can definitely be more valuable than more documentation. Set up a strategy regarding documentation:
- Where do we share documentation as a team most effectively?
This sounds very menial, but you’d be surprised at how many channels can be used simultaneously with all the best intentions, which can impede proper documentation management. Reducing channels means less loss of communication, being able to update information or request feedback continuously, and keeping an overview.
2. What is a good tool that fits our needs in documentation?
This is a point that people can really learn from each other. You’ll find that depending on your product or process affinities, there’s a whole bunch of tools out there, but you should provide focus.
I still think fondly of the days I would be puzzling out processes with BPMN2 and printing them out on an A2 format with all the exceptions, impacts on the flow, decision moments, and triggers within the right actor swim lanes, while distinguishing between data and process flows, system actions, notifications, and… Did I lose you yet? Well, good, because that’s exactly what can happen if you let one guy loose on a hobby project that is overkill for its purpose and cannot be maintained by somebody else. The only solution a well-intentioned victim of this has is to completely rebuild and scrap most of it. (Consider this an unofficial apology to some older colleagues.) So think of why the information is needed, how to present and document it, and what tool can be used effectively.
3. Which processes or product characteristics are most valuable to document for the team?
It’s important to establish minimum viable documentation, to make explicit what documentation deserves active maintenance and could even be incorporated into your DoD.
This should be a short list, and that is perfectly fine. Ensure the important information is up to date, so that people consuming it can be informed efficiently with reliable information. If there is a need to increase this list, then it’s an agreement that can be taken up with the team, so that means that interactions with individuals are foundational to meaningful documentation.
Wrap up: No documentation = working agile?
Not quite; documentation can unlock value creation by creating focus to do the right things at the right time. They can be the grease in your continuous improvement process, functioning as central talking points that evolve as your development team grows. They can increase the satisfaction of all stakeholders. And probably a lot more things…
Please note that I wrote down ‘can’ in the above sentences and not ‘will’. That’s because like everything, you’ll have to be smart about using it. Nobody goes duck hunting with a Howitzer, and you should not use more documentation to fix all problems.
Having said that, the above article does prove with concrete examples how documentation can help with being more agile-focused and getting more valuable features delivered in a timely fashion, and disproving the beginning statement of:
Agile software development means no documentation