Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Many software development shops have adopted the practice of “crunch time” right before a delivery. One of the big reasons is that the development team is on the hook to deliver a fixed set of features in the next delivery and management uses overtime and extra pressure to attempt forcing in the last few features. While some shops have used this tactic successfully, Agile takes a different approach.
Agile Practice 8.1 – No Overtime
Agile practitioners acknowledge that if you work too many long hours you get two bad results. First, you make mistakes if you are to worn out. Software development is a mentally taxing job and developers are going to need to clear their heads every once in a while. An overworked developer will often fall into what I call “mental block”. When I have been working on a particularly hard problem and struggling to figure out why my code is not working the way I want it to I just get up and take a break. Sometimes I head to the local coffee shop, sometimes I read the local news. The point is to do something that makes me not think about the problem for a short while. Then, when I come back I look at the problem with a fresh new angle. I can’t tell you how many times this has resulted in a problem I have spent an hour working on being resolved in five minutes.
“Mental Block” is a very real problem for software developers and pushing your team to long hours will make it much worse. Don’t let your team work too many overtime hours and make sure that they are getting the breaks they need. A thirty minute break can save you sixty minutes of time wasted in “mental block”. And, a sixty hour work week is likely to be filled with twenty hours of “mental block”.
Agile Practice 8.2 – Right-Sizing Your Team
Agile teams are meant to be cross-functional. That means that designers, developers, testers, and others are all together in the team. A common problem that I see when working with teams adopting agile is that they don’t have the right mix. They struggle with getting their product features implemented because they have backlogs of tasking and they feel like they aren’t working as fast as they should be. The root cause of this is often unrealistic expectations and the solution is to find the “sustainable pace” that the team can work at all the time.
I suggest that what you should do is track your team’s ability to complete tasks. I use a Kanban board for this. I track how many user stories my product owner can write each week on average. I track how many user stories my developers can implement each week on average. And, I track how many user stories my testers can test each week on average. If my product owner can write 6 per week, my developers can implement 1 per week, and my testers can test 3 per week, then my team should be one product owner, 6 developers, and 2 testers. This will give me a steady flow of completed user stories with minimal bottlenecks in the system. But, of course, none of us lives in a perfect world.
Suppose you only have four developers and one tester? This means you will overwhelm your developers with stories they can’t implement. The result of this may be a backlog of requirements piling up and become a drag on the overall system. Or worse still, it can mean the developers start to “cut corners” to try keeping up and the product quality suffers. It also means that the development team will overwhelm the lone tester with similar results. The tester may get buried in work or they may start “passing” things because they don’t really have time to test them.
My suggestion is to slow your product owner down to four stories per week. This means the development team can keep up. The lone tester will still be overwhelmed because he can only test three stories per week. The solution is to take your now under-utilized product owner and get them to test the one extra story. If you optimize the flow of value through the system then you take all the friction out of the development and you get a sustainable, predictable, and reliable product team.
