Thoughts on agile management

Steve Denning, one of the leading business thinkers pushing the business world to abandon the outdated idea of maximising shareholder value has published an interesting article on Forbes titled Why do managers hate agile?

That immediately made me think of my first experiences with agile as a board member of software and web startups shifting away from waterfall development to agile to improve productivity. On the one hand I was excited by the prospect of more efficient development and getting away from late delivery and poor quality software that I was used to, but on the other hand I struggled with the lack of predictability and commitment inherent in the agile process. As board members we needed to plan for the next round of fundraising, and that required knowing when product would be released and revenues could be expected to increase.

Reading Denning’s article I see that the trade off between predictability and productivity that I describe above is what companies everywhere are struggling with now agile as a methodology is being adopted across the enterprise and not just in development. Managers have generally been trained to deliver predictability and are generally held accountable for hitting their forecasts, making it hard for them to go down the agile route.

The good news for agile fans is that this battle is only going one way. As the world changes faster and faster the advantages of just-in-time agile methods and customer focus in generating quality output are getting greater and greater. Agile methods are also more attractive to the best employees.

That said, predictability is still important to shareholders and hence for companies looking to raise money to maximise growth. The net effect of this is to make the job of CEO and senior managers more difficult – they have to ‘manage’ self-organising teams and try to predict the output. That takes a high degree of trust and a thick skin to take the flack when things go wrong. Choosing shareholders who understand the trade-offs and can tell the difference between systemic poor performance and a blip will help.

  • Emanuele Di Saverio

    Uhm… first you say you want to get away form late delivery and poor quality,

    but then you miss the predictability you had (predictability to miss deliveries?)

    Don’t expect Agile to affect only the product “delivery”, or you’ll be stuck in this dichotomy forever.

    On one thing I agree with you: current economic models based around investment amortization and discounted cash flows are flawed, not in regard to Agile, but in regard to reality.

  • I find that enterprise clients in particular get trapped in promise-based product prioritization, where they promised internal or external stakeholders a release and thus prioritize it whether or not it’s still the right business priority. The same thing can happen with startups, so I think your advice about choosing shareholders is important.

    More broadly, agile doesn’t require uncertainty on dates. From an extreme programming perspective, you can either have a time-based release or a scope-based release, you just can’t have both. If you need to hit a date and things don’t go according to plan, you just need to be ready to cut some scope to hit the date. Releasing production software frequently should mean that less is riding on each release.

    Finally, I think organizations need to be more sparing with their date-based releases. If it’s in a contract or needs to be on a retail shelf, that’s a true date-based release. In other cases, I think people put specific dates on releases without a very strong reason, which results in the product and engineering teams spending a lot of time on estimating and re-estimating without a lot to show for it.

  • Hi Greg – the other case for date based releases relates to financing timetables. E.g. If I will be able to raise money at a higher valuation once I have released my iPhone app I need to know when it will be ready to make the assessment of whether it’s worth waiting.

    Thanks for a good comment.