Agile Software Development

There are not that many people who like micromanagement. No surprise that the fear of day to day micromanagement scares some people off the agile processes. That is not the only way agile processes can look micromanaging. All the agile processes employ the idea of iterative and incremental planning on pretty much every possible level. Scrum Product Owners can change the project priorities every 14-30 days, in Extreme Programming, the usual iteration length is just one week. Naturally the possibility for the rapid shifts in the priorities can make it difficult for the team to design and build a good architecture and work at a full possible speed.

Development team productivity

The sad or not so sad truth is that agile methods are not aimed at maximizing the development team productivity. It is one of the welcome side effects that can happen, but that is not the grand goal. One can even say that the agile doesn't care about the development team productivity at all (you anyway cannot measure it properly). What agile is focused on is the speed of the business value realization. It is the team productivity towards the current understanding of the business value is what matters. Whatever fast the one could move it doesn't matter if doesn't want where he wants to go. Extra team speed that they could have if the goals were more fixed, just doesn't count in the end if it was not the real goal.

Lousy requirement management

So, is agile invented for helping the lousy requirement managers to get at least something useful for the customer at a cost of the developers' time, headache and inability to see really long forward? You might call it this way, indeed. Agilists though prefer thinking that capturing the actual customer requirements upfront is impossible whatever good analysts you've got and even if you manage to capture requirements reasonably well, the real customer goals and/or market situation can easily change during the course of development (think what iPhone did to the phone buyers expectations). The need for agile comes from the poor predictability of the real world, not from the hordes of poor managers existence.

The Agile balance

Agile methods seek balance between the need not to distract developers every day and the need to adapt to the changing world complexity. In a way that is micromanagement, but in a strictly limited manner. A team always has at least an iteration to go without interruptions and a good product owner always tries to make it clear which requirements are most likely to be changed. Naturally, if your you have to satisfy the frequent changes of the customer and market desires, you might have to learn the evolutionary requirements, evolutionary design, test-driven development, continuous integration and other good old agile engineering practices.

Your experience

Does it make sense in your environment? Is there a way to both make developers happy about their software and satisfy the always changing customer requirements?