Long stand-ups. User stories that roll from sprint to sprint. Acceptance tests that fail almost immediately when passed to a tester. These are all symptoms of a flailing, toxic agile process.
I’ve had many years of experience with various flavors of agile. I’ve seen it work out well on large teams and I’ve seen it fail miserably on small ones. There has always been one common thread, when I’ve seen it fail. Every time it failed, it was because my team prescribed to a version that was poisonous and deadly.
This is the first post in a series that will discuss the symptoms and consequences of adhering to a toxic agile process.
Symptom One: Only the scrum master cares about what everyone is doing in the daily scrum.
This is one of the most fundamental problems of the daily scrum. Most agile training material recommends that you format the meeting with three basic questions:
- What did you do yesterday?
- What are you doing today?
- What’s blocking you?
Many teams hold to a belief that if they simply ask these three basic questions, their daily scrum is productive. However, this recipe in and of itself is ripe for turning the daily scrum into nothing more than a daily status meeting. You have successfully achieved this if the developers are disconnected and have no vested interest in what each other is doing.
Why are they disconnected from each other? They are disconnected because they are working in isolation. Each developer has his/her own story and these have no direct dependence on each other. As a result, the only thing blocking the developer is the daily status meeting that they must attend.
Managers love that each developer is working on a distinct problem. Parallel operations yield higher throughput, right? Yes, multitasking with multiple processors, high cohesion, and low coupling are both great for software architecture, but they aren’t good for your daily scrum. No developer is an island. Here are three reasons why I think you should proactively address this problem.
1. It Puts the Sprint and the Release At Risk
Working multiple unrelated stories at a time means that your development efforts are not laser focused. With the efforts spread thinner and more stories activated, there is a much higher probability that the end of the sprint will be reached with much less accomplished than desired.
It takes just one sprint to begin the snowball process of the backlog running away from you. The rollover from the first sprint must now be accomplished before what was originally prepared for the second sprint. Now the second sprint will have twice the rollover. This process is repeated until the last sprint of the release is reached and the product owner has discovered that there is no minimum viable product with which to go live.
2. It Creates the Threat of a Context Switch
Each developer is focusing on a different problem. This also means that each developer is working in a different context. When one developer is blocked, s/he will inevitably require the support from another developer. Once the question is posed, the unaware subject will drink from a cup of deadly poison which will automatically cut productivity in half.
3. It Opens the Door to Technical Debt
To mitigate disturbing another developer, or to simply ensure that the developer can continue to work in total isolation, s/he may attempt to solve a problem in a less than satisfactory manner. There is no dialogue regarding design or implementation of the low-level intricacies of the story. The developer may fallback to searching online in forums to solve a problem that someone else may readily know how to solve.
At a minimum, this will introduce technical debt. In reality, this could yield something much more costly – a security vulnerability. The reality of it is, the damage will be done before a word was ever spoken, before a peer review was ever performed, and before the test case was ever executed. The introduction of technical debt has slipped its way into your product, all the while the managers are applauding that developers are working on multiple stories in tandem.
What kind of problems do you have in your daily planning meetings? Are your colleagues engaged, or has your team fallen victim to a radioactive agile process?
