Finally, success!
Imagine this scenario: your development team has never been able to keep up with customer demand. Or quality was never good enough. Or your users felt that you never really built what they needed.
But, you’re working hard to improve your team. You’ve read the white book, the green book, the purple book… Your bookcase is full with agile books of all colours of the rainbow. You’re solving problem after problem by applying the agile advice.
Your team’s velocity climbs steadily up. Team morale goes up. Your customers are getting happier after each release. You feel you can almost implement your customer’s requirements in real time.
This could be your finest hour. This could be your worst nightmare.
What could possibly go wrong?
Your team is the bottleneck, the constraint. You elevate the constraint by improving the way the development team works. What happens next?
The bottleneck shifts.
Before you know it, your customer can’t give you new stories or write acceptance tests fast enough to keep you supplied with work. You won’t notice it at first, as you chew away the backlog your customer has built up. By the time you notice, your team is starved of work.
Before you know it, your customer can’t handle the flood of new features that you unleash in every release. It didn’t matter before that software distribution wasn’t very fast or that training wasn’t effective. The users didn’t notice that a release was skipped as there were few features per release anyway. The users could learn those few features per release on their own.
You are no longer the bottleneck. Someone else is. And then all hell breaks loose.
Surfacing old problems
As long as the development team was the bottleneck, other teams’ problems didn’t surface. They had no motivation to improve. But now, the spotlight is on them. And they don’t like it. You might even be blamed for causing those problems.
Now that your development team has some spare capacity, the Theory of Constraints tells us you should subordinate to the new constraint, by helping the new bottleneck. But, then you’re faced with two new problems:
- The new bottleneck team probably doesn’t want to be helped. Please do not inflict help on someone who has not asked for it.
- You’re operating out of your knowledge zone. The XP book won’t help you solve sales problems. The Scrum book won’t help you solve customer support problems.
Preparing for failure
If you’re lucky, you aren’t successful yet. You can take action now to avoid or mitigate the problem in the future. Start preparing for the worst now, because you know you will be successful if you keep on doing that agile stuff.
What can you do?
- Try to detect candidate bottlenecks before they arise. Subordinate some of your team’s time to help the bottleneck in waiting to elevate it’s performance. For example, to avoid the problems described above, I like to dedicate someone from the team to follow up a whole release, from stories to production, subordinating to whoever is involved. Once a release nears production, someone else starts working on the next release. Keep the team working at full capacity. Keep the bottleneck under your control.
- Learn a bit more about the other teams’ work. You’re going to need that knowledge to understand their bottleneck and to help them. Stop reading those agile books. Read a book on sales, on marketing, on operations or even on accounting (I can recommend a great book on accounting). You might not need it, the bottleneck might shift elsewhere, but it’s never too late to start working on a more well-rounded education.
- When I said “the XP book won’t help you solve…“, that wasn’t exactly true. The practices aren’t that applicable outside of development work (except for pairing, which seems applicable to most creative work). But the principles have helped me solve problems in areas I didn’t know anything about.
Communication, courage, simplicity, feedback and respect, it’s not just for IT.
Just do it
You know it makes sense. It could happen to you too. Where does your bottleneck want to go today?
