Stress and rhythm - both musical terms, but both also part of software developers’ everyday lives.

Sometimes I hear from a team or individual that the stress of achieving sprint or iteration deliveries every one or two weeks is turning them off the whole idea of agile development. This is a sign that something is wrong, and is an indication that (as often happens) one aspect of agile practice is being emphasised at the expense of several others. Programming is design (all the way down), design is a creative activity, and it’s well established that the experience of stress is completely at odds with the states of mind associated with creativity. (Caveats, in case you’re yelling at this point. One - there’s a difference between stress and challenge, and sometimes too little challenge can be more stressful than too much; Two - yes, there will always be the occasional pathological case, an individual who is able to be genuinely creative under pressure, who maybe even - as a consequence of their own particular psychology - needs the pressure. I’m not convinced this is healthy, and I’m looking at what I hope is a more general case here).

A key agile practice which gets forgotten in the enthusiasm for short iterations is “sustainable pace”. A team must be able to iterate over the product backlog, again and again. To get any handle on how fast a team is consuming its backlog, you need to be able to measure and compare this over several iterations. If every iteration feels like an impossible deadline, a team can get into a horrible cycle of anxiety (at the end of an iteration) followed by a crash (fatigue and depression in the first part of the next). How can we avoid this?

First, let’s think about terminology. Scrum bears some for the blame for this, by calling iterations “sprints”. If I’m working towards a 6-month release, I’m not sure I want to hear that I’m going to have to sprint for 26 weeks… What we’re aiming for here is rhythm: the easy, efficient rhythm that (for example) a long-distance runner or swimmer falls into, that lets them cover mile after mile of a marathon.

Second, the iteration practice, like all of the team practices in agile development, creates pressures in several directions. One of these is is into a team’s development practice - you simply cannot continue developing as if you have to plan, architect, design, code, test BIG STUFF in the way that you might have been used to. The best antidote I know to this thinking is the radical inversion implied by TDD - a succession of tiny tiny goals which means that completing things is not an activity that’s deferred to a frantic last few days of an iteration (this is how iterations turn into “mini-waterfalls”) but something that’s happening all the time - not just task by task, or day by day, but minute by minute.

One circumstance that gives rise to iteration stress is consistently having too few, too large backlog items. If you only ever try to deliver two or three big items per iteration, and only ever achieve one out of the three, it’s no surprise that a team ends up feeling stressed and demoralised. The key phrase here is “consistently”. If this happens in one iteration, and if a team is working through issues effectively in iteration retrospectives, the team itself should apply the pressure to build the next iteration backlog from smaller items. (Though occasionally it’s actually useful to have fewer, larger items in a sprint - if you need to spread knowledge and generate the conditions for effective collaboration, for example).

A common cause for discord between developers and their organisations is the feeling - in management teams - that project teams “lack urgency”. Sometimes management teams try to generate this urgency by requesting or imposing deadlines that are admitted to be heroic or barely achievable. We’ve all seen schedules where there is no buffer, no slack, and a set of features that absolutely must be implemented in the next release which is promised for the next quarter. We can’t afford agile iteration goals to be thought of in this way - so if you or your team feel this way, stop. Think. Do something about it. And if you’re responsible at an organisational, program or product level, and you think your developers aren’t exhibiting the symptoms of pathological stress that you might associate with commitment, please try to think back to how you felt when you last did some truly creative work, and sympathise with your architects, developers and testers who are turning the fragile stuff of imagination into valuable features and products.