One of the risks of iterative development is that the pace becomes too fast for everyone to sustain. In this post I discuss why I think this is a risk and some things I’ve tried, or considered, to deal with it.
Giving a team the time to do a good job is essential. I wouldn’t expect to hear too many arguments to the contrary. Setting unreasonable deadlines will lead to bad results, technical debt, unhappy developers and failure. A post about that would be a little boring, so just take it as read that any deadlines should be sensible. There are other problems with sustainability that I’ve experienced, however.
Pretty much all of the Agile work I’ve done has been in teams that use sprints or something like them. I really like the way that this style of working positively encourages teams to ignore everything beyond what is being delivered in the next few weeks. The effects of this include
- keeping everyone focused, because timescales are short
- time limiting overrunning tasks, and
- giving the team a SMART goal to work towards
However, a risk I’ve noticed (it’s something I am prone to) is for people working on the project to go too fast. Iterations become a vicious cycle (see what I did there?) – plan a lot, do a lot, plan some more, do some more, etc. This isn’t necessarily a conscious thing, I’ve read elsewhere the parable of the mean manager who overfills every sprint and turns sprint retrospectives into blaming sessions, demanding to know why everyone didn’t finish what they promised, and so on. This isn’t that, this is just the growing fatigue of people who enjoy what they do and never have a slow day. Avoiding this situation is the point of this post.
But first, why? Agile’s principle of people over process means that you should never mindlessly follow any of your processes, and often the processes themselves will be lightweight enough that you can’t just mindlessly follow them. For example, in a sprint planning session there is no guarantee that all of the issues going into the sprint are really ready; if one isn’t and you mindlessly add it to the sprint, you create problems down the line. Instead, you need to be switched on every time, ready to detect when you don’t understand something or you have doubts. That takes effort and will leave you exhausted. If you work at that kind of rate all of the time, I believe you will eventually make mistakes and/or burn yourself out.
So how to slow down?
I ran a team once where I noticed that we were all working very hard with no end in sight. I started to make sure we underfilled the sprints, so that most sprints we would complete everything planned with a day or two to go. I would then give the developers the opportunity to work on other things for the few remaining days – always related to the product but not things on the critical path. The sorts of things we did included refactoring, making the build process better, building tools for ourselves, investigating a new technology, and so on.
In that team, this approach was fantastically successful. However, I can see that there are situations where you really want to schedule everything you do (because all of the things I just mentioned are actually really important and shouldn’t just be things you get around to when you haven’t got anything else to do!)
Defining days off
I’ve been thinking lately about completing sprints and then taking a day or two before starting the next one. This time could then be used for the non-project stuff you do. For example, my current employer allows 10% innovation time and you could spend a day every couple of weeks doing that; you could also do some training and tidy up your todo list ready for the next sprint.
The only problem I can imagine with this is that I know a lot of developers who would get bored. They’d be writing a ton of code anyway, whether they were in a sprint or not!
Hands up, I’ve never run a Kanban project so I might be wrong here. It looks to me, though, like developers pulling issues in to work on them from a long todo list, without any sprint planning or deadlines, would be forced to go slower. With no deadline, there’s no benefit to rushing. You really have no excuse for hurrying, particularly if it can be demonstrated (as I believe it can) that this will lead to mistakes being made.
I suspect, however, that some of this is down to personalities. Some people would see that completing an issue merely means going to pick up the next most important thing and would be happy to treat the todo list as a list without end. Some people, on the other hand, would see that list as debt and would be unable to rest until they had finished everything. Some would compete with others for how many issues they had completed.
This is more of a personal thing than a team thing, but one way to ensure that you don’t burn yourself out at work is to have some kids. Kids are very difficult to ignore and you often need to leave work on time to do stuff for them. They force a change in priorities that means part of your day is always spent not thinking about work. I’ve found it helpful in forcing me to do something else with my day. However, I’ve also found there’s not a lot of time for lying around recharging for the next work day!