Agile has many qualities that developers enjoy, not the least of which is the lack of a possibility of that "death march" described above. Another developer-friendly concept is that agile allows developers to be involved in the requirements gathering and estimating, ensuring a level of investment and ownership not usually possible in waterfall development.
But perhaps the most important agile quality that most developers enjoy is the sense of autonomy they have day-to-day. They attend the daily scrum and then are free to work on their code with no one looking over their shoulder.
To be fair, this is the default action and adult behavior and code quality are assumed. However, if a developer is struggling, it is always possible to manage by exception under agile methodologies without negatively affecting the time line or quality of the overall team, sprint or release.
Use the next release
While "Next Release" is associated with software that comes from honest-to-goodness software companies, it is an integral part of agile development. If you choose to ignore the "Next Release" and pull everything forward into the current release, you are ignoring a key part of the methodology.
Using the "Next Release" means that, by signing up for an agile development methodology, you are prepared to take one or more features from the product backlog of the current release, which are (hopefully) the lowest priority and have been overcome by the events of the current release, no matter the reason, and move them to the product backlog of the "Next Release".
At many large companies, the concept of "Next Release" is completely at odds with complex processes around procurement, bids/proposals and budgetary planning. We will address that in Part 2. For the purposes of Part 1 - the "Next Release" is assumed to be already bought and paid for.
An agile example
Since agile projects are time-boxed, it is easy to propagate the effects of today's development efforts throughout the life of the current project.
Sign up for MIS Asia eNewsletters.