The Agile journey is such an adventure – exciting, exhilarating, and profoundly successful. That is, until the sh*t hits the fan...
and stakeholders retreat to perceived safety in old practices whose ineffectiveness they so recently sought to escape: big design up front, over-specification, phase-gates, command-and-control micro-management, time-tracking, and detailed status reporting. These are their go-to strategies in a crisis, and you are more likely to face one the earlier your organization and product are in an Agile transformation.
Sometimes the crisis comes when team progress is blocked by systemic/cultural incompatibilities with Agile practices. But there are other more mundane causes:
- Requirements need to change dramatically mid-project
- Unanticipated work emerges or technical debt accumulates
- Staff turns over
- Significant technical problems arise
A crisis disrupt a team's flow, but a truly Agile team will adapt and regain momentum quickly. Unfortunately, even the most effective Agile team will be undermined if a stakeholder-ordered retreat interferes with Agile's ability to self-heal.
Here are some ways you can prevent that from happening:
- Establish a track record of frequent successful customer deliveries. Frequent means every two weeks at the most. Force your organization to learn how to do this as soon as possible. When a crisis hits, stakeholders are much less likely to circle the wagons if they've seen you consistently delivering value.
- Forecast defensively. Research shows that most technology projects require 2 to 4 times as much effort as anticipated, regardless of how much analysis is done up front or how far into the project you are (!). So don't box yourself in. Endure the pain of justifying and qualifying your forecast up front – it is realistic and it reflects a level of confidence not a certainty. Technology development has no certainties.
- Provide a transparent and frictionless progress-tracking artifact that is compatible with Agile principles. When increased scrutiny comes, the first thing stakeholders will start to inspect is your progress. Use of a ranged release burndown chart is good, re-estimating all backlog stories every two weeks is not. Counting hours spent, hours remaining, etc is definitely not. We are not capable of understanding creative work well enough to expect a linear yardstick to accurately measure progress.
These practices can keep your Agile project from going off the rails. But as you can see, they force into stakeholder conversations the fact that you are doing creative work. At some fundamental level, resistance to that fact is the root of most of our difficulties with Agile transformations.
By applying these practices to your projects, you can often keep the flames down long enough for the magic of frequent delivery and market feedback to take hold. And over time (though possibly a longer time than you'd like) you can eventually cure your stakeholders of their dependency on reflexive habits that no longer work.
Patience is definitely a virtue. You can cultivate yours by remembering that, for others, their Agile transformation is a creative project for which you are a stakeholder. Try to resist the temptation to circle your own wagons!
