Saturday, January 22, 2011

Stress in Agile teams

People working in agile teams sometimes complain that stress levels are higher in agile projects. Now, we all know that it is not supposed to be so. After all, don't agile projects distribute work more evenly for the duration of the project? Aren't agile teams supposed to be self organized and responsible for signing up for an appropriate load of work in a sprint (can't even blame management now)?

Agile experts are quick to point out that the increased stress, if that's even true, is most likely the fault of the agile coach / scrum master. Don't blame the agile methodology, they say. But then, there have always been good managers and bad managers and there certainly are good agile coaches and bad agile coaches. In many teams, the managers have now become scrum masters or agile coaches. When the same team, under the same manager that was practicing waterfall or iterative development is now practicing agile and is complaining about additional stress, could there be some truth to the statement?

Let's examine possible reasons for the stress and potential ways to mitigate them.

The Daily stand-up: This is the heart of many agile processes. This is also a potential stress point. Think about it. Day after day, you are asked to give an account of yourself in front of others. What did you do since your last stand-up? What do you plan to do today? Like it or not, you are subjecting yourself to intense scrutiny. There's no place to run and no place to hide. You cannot help wondering what your team mates think of you. You cannot help comparing yourself to Joe who always seems to get more done in the same time.

How to mitigate it: 
Emphasize to the team that skills and experience vary between individuals. Some are more skilled and experienced than others and may even be earning substantially more. Therefore, it is natural that they will produce more. Do not compare yourself with the performance of others. Just do the best you can.

Commitment:
 In agile, as in life, it's the many small promises that we make that adds to the pressure. In an agile process, specifically in the daily stand-up, we are making promises everyday. We call them commitments. It's human nature to want to meet those commitments. We are essentially honest people and we want to live up to our promises. Until we fulfill that promise, it's hanging over our heads like the proverbial sword of Damocles. And if we fail to keep the promise, we feel guilty. Even, if it's not entirely our fault.

How to mitigate it: 
Don't not use the word "commit". Instead, say "try". Don't say "I commit to do X". Instead say, "I'll try to do X". It's a subtle but important difference. Notice how there's no promise to deliver? Does that mean you are going to work any less harder? No. Remember, we are honest people. Our teams trust us.And we will do what we can to complete X. 

But we did not commit.So there is no expectation tomorrow that it will be done.We'll sleep better and perhaps even make it home in time for dinner.

Estimates:
When teams or individuals estimate tasks, they are implicitly committing to the hours. When we commit, we take on stress.

How to mitigate it:
Do not ask for estimates. Instead, attempt to "right size" the tasks using techniques like T-Shirt sizing. Measure the time taken to complete the task from the time it is started. The task will start when it does and complete when it does. As the team gathers these metrics they will also become more adept at "right sizing" the tasks. The eventual outcome is a steady velocity for the team.  And since the team is not providing estimate that they have to commit to, the stress is also less.And when the team is less stressed, they produce more.

Conclusion
Agile processes introduce stress in many subtle ways. Some of these are an outcome of the high visibility and transparency of the methodology - the very techniques that make agile so successful. This stress is not introduced intentionally - rather it is an unintended side effect. Being aware that the stress is real and tangible can help us mitigate it.

Unless we acknowledge it, we cannot manage it.

2 comments:

Ian said...

This is one of the reasons that I like XP much more than Scrum (which sounds like what you're describing above). In XP, sustainable pace is a core principle - work your 8 hours a day, then go home and get some rest so you'll be operating at 100% the next day.

In order to make this work, fixed sprints are eliminated and more fluid iterations are used instead. Using your team's velocity, you can predict about how much work you can get done in the upcoming weeks, but the product owner can always add stories and move things around at any time (other than started stories of course). This is done with the understanding that adding more work now will push out future stories, which is basic common sense when you think about it.

I've found that when this is done right, it can lead to an incredibly low-stress environment for both the developers and the product owner. Devs get to go home on time and don't get burned out, there isn't any "committing" to anything other than working your hardest each day, and the product owner has the ultimate freedom in prioritizing and adjusting the backlog. Win-win if you ask me :)

I often say that Scrum is about screwing yourself over in small doses and XP is about embracing reality and making the best of it. If you can get buy-in from management to try it, I would recommend all agile teams take a look and consider it!

Wallis B said...

I disagree with your point about commitment. We found that until we stressed using the actual words "I commit to completing XYZ today" there was a much slower and less efficient work rate. As soon as the team really started to understand what commitment means, and delivering on it, we achieved a lot more and starting feeling good about it, which was much less stressful than under-delivering and not meeting the sprint goal.