“Sustainable development, able to maintain a constant pace”, the fifth principle of Agile. Sustainability makes this sound a bit hippy right? Wrong!
Sustainability here relates to conducting development in a professional, consistent and therefore measurable / repeatable way. Any development team has a velocity at which they can cut code, the trick is to understand this and plan enough work in short bursts that can realistically be achieved. Meaning they are capable of achieving consistent results over and over again.
In waterfall projects I have seen developers overloaded on particular projects. This does work for one maybe two project cycles but eventually the developers either burn out or leave the organisation.
A much more sensible approach is to have short sprints, with manageable amounts of effort and clear targets.
KEEPING IT FUN! Strangely fun is a key concept in maintaining a constant pace, developers who are enjoying what they are doing are more likely to want to keep doing it. Commonsense, you’d have thought. But so often the developers are given unrealistic targets and pushed to breaking point. Whilst being given little or not recognition. Doing this has an adverse effect on the happiness of the team but also quality and ultimately costs are impacted.
The first step in planning any sprint should be to work out the man days available. Even if the sprint durations stay fixed the development days available will alter. Developers will take holidays, be sick or have other commitments outside of the project. You can only start to fill your bucket once you know how much water it can hold!
Another important concept is historic performance. If the team has on average delivered three new features in each sprint for the past 6 months, you can’t suddenly expect them to deliver a sprint with ten! Understanding the work rate of the developers over a period of time is essential to creating sensible achievable plans.
Also listen to your development team, allow them to tell you the art of the possible. Targets agreed in his manner are much more likely to succeed. Firstly as the developers will give far more accurate “guesses” than a Project Manager but also importantly their ownership of the estimates is essential.
Like most things Agile related, nothing about this principle is rocket science. But it does take real leadership to resit the temptation to revert back to saying yes to everything and overloading the development team.