I like to move fast. I like having the “first mover advantage”. I don’t believe that my team needs to be smarter than yours or better at what we do (though those attributes certainly help). If we can simply move faster, we’ll have the advantage and we’ll be more likely to succeed.
Regrettably, I work with many software managers who don’t see things that way. They believe that success depends upon staying in control. They want all activities to be planned, documented and approved. I get it, but that attitude builds a major barrier.
All that planning, documenting and approving takes time — lots of time. I’ve seen software development projects requiring less than a month of building and testing — that’s 3-4 weeks of writing code and thoroughly testing it. Yet, 6-8 additional weeks are spent planning, prioritizing, documenting, reviewing and approving. So a 3-4 week project takes 9-12 weeks!
You can’t lock down the team and still be agile.
Yeah, I know. I’m exaggerating a bit. We need a few days of planning and documenting even within agile development projects. So my 3-4 weeks is probably more like 4-5 weeks — fine. It’s still about half of the total calendar time actually expended.
I’ll also point out that not all of that 6-8 weeks of administrivia is work time. A significant portion of it is spent waiting — waiting for meetings, waiting for reviews, waiting for approvals, and waiting some more.
Warning: While your big enterprise is waiting, your small competitors are gaining first mover advantage. You may release a better software system but it could be too little, too late. You end up doing the right thing at the wrong time.
You might think that the solution lies in agile software development but it doesn’t — not really. The solution lies in your mindset, your behavior. Software development teams need guidance not controls. They need to be led not directed.
If you put your software developers in lockdown, you’ll spend vast amounts of time managing the lockdown and little time delivering results. If you give the software developers some direction and running room, you’ll spend more time evaluating results and little time issuing directives.
Will mistakes happen? Of course, they will. But the mistakes are more likely to be small, easy to spot and recoverable. The team will come out way ahead of where it would have been with a heavy handed approach. Big design up front often results in big mistakes at end.
Here are a few tips for releasing control and offering guidance instead.
- Keep deliverable cycles short. (Team deliverables should be no more than 4 weeks though I prefer 1-2 weeks. Individual deliverables should be no more than 5 days and 1-2 days is better).
- Use whatever metrics you like to track activities over time but mix them up. (Metrics are notoriously easy to game. Once people learn the system, they also learn how to use it to their advantage. Mix up your metrics.)
- Trash the long, fancy document templates. Reward people who can get to the point and convey an idea quickly.
- Offer samples. If there’s a document, code snippet, diagram, etc. that you really like, display it as a guideline and let the team try to improve upon it.
- Set high quality standards and don’t compromise. Set firm deadlines and hold them. Reduce scope to hit target dates and/or budget constraints.
Let the deliverables and the results drive the team’s progress. They’ll get more done in less time with better quality.