One of the key and often very much underestimated assets of working in agile teams, whether working on products or projects, is the idea of sustainable pace. In my view, sustainable pace targets at making sure that, even under time pressure, which is not rare in software development, the team remains it’s cool. For those of you who have been part of agile teams, you will have noticed that achieving sustainable pace is not always easy.
In traditional, waterfall-oriented projects big trouble usually isn’t discovered until late in the project. Especially when project phases have deadlines that were outlined at the start of the project. When earlier phases take more time than expected, there is less time than originally planned for building and testing the functionality. I’ve seen projects where developers were working nights and even weekends to get the code out on time. Essential activities such as unit testing are skipped to make the deadlines, and new developers are added to the team, resulting in temporary lowered productivity (remember Brooke’s Law?). And even worse, testing quite often gets totally jammed, when the testing phase is shortened from a couple of months to a few weeks, just to make the final deadline. Worst case: I witnessed a project where field beds were installed on site, so developers and testers did not have to commute, but could literally stay at their workspace to get the project done. So much for sustainable pace.
By setting sustainable pace as an essential value, agile teams are attempting to move away from these horrible experiences. Basically, we use the mechanism of sprints that have a well-defined start and end, to achieve this sustainable pace. At the start of a sprint the team defines how much effort the next backlog items (usually user stories) will require, and only plan to do so much work as the team can handle. When estimated and planned well, the team should be able to deliver what is discussed during the next two or four week sprint. What most teams do to achieve a proper estimate is to break the backlog items into smaller items (usually called tasks) that can be handled by individuals from the team. Next the team estimates the amount of effort required for doing the task. In hours. Then these hours are added up and matched against the number of available hours during the upcoming sprint. Sounds like a decent and easy to implement procedure, right?
However, it’s not as easy as it looks. I’ve witnessed many teams who weren’t able to deliver what they agreed on at the start of their sprint. One of these teams even has a name for sprints that don’t end “right”. They refer to them as red sprints, where, you could guess, they refer to green sprints if they actually make the self-opposed deadline. When I first talked with this team they’ve had six red sprints in a row. Go figure. The team was legging behind more and more, and had been doing overtime for four of these six sprints. Motivation dropped. To me this sounds more as burn-out then burn-down.
No sustainable pace
There’s a number of reasons why such red sprints occur:
- Deadlines, deadlines. First of all, instead of having a deadline per phase, as in traditional projects, teams now face a plethora of self-opposed deadlines, each of which is hard to make. Even though I realize sprints put some desired pressure on teams, the deadlines sprints seem to oppose potentially cause too much stress on the people in the team.
- Threat. Estimation in hours is threating to those who create the estimate. You have to feel quite confident with your estimates. In practice, estimation in hours is a tough challenge.
- Ten percent. Because of this, similar to traditional projects, teams take a lot of time breaking down backlog items into tasks and in estimating the effort it will take to realize these tasks. Just to feel confident. Such break-down is usually quite complex, as especially with user stories, there is no standardized way of splitting them up. Basically, it’s different with every story. I’ve literally seen teams taking a full day, on a two week sprint cycle. That is over ten percent of their total working time.
- The unexpected. And it gets worse. What happens if something unexpected occurs? Think of changing requirements, technical issues, or something as ordinary as a server that cannot be reached. Well, the effect is very similar as to waterfall projects, albeit smaller. Executing next tasks gets delayed or even postponed, resulting in not meeting the sprint’s deadlines. A next red sprint.
- Parkinson’s Law. Last but not least, even if a team is able to estimate quite accurately, you could wonder whether implementing the individual tasks exactly makes up for the time available. In most cases it will not, resulting in some slack. Usually having some slack is good, but remember that Parkinson’s Law will kick in: the work at hand will fill the time available. In sprints this results in a lower pace than estimated, because more time is spent then required in implementing the sprint’s tasks.
- Cutting on quality. Last but not least, what happens if the teams gets in a squeeze. The teams still needs to finalize some tasks, but don’t have enough time to do that. This is where quality goes done, as teams often decide to skip some of the work necessary for the implementation of their tasks.
All of this can attribute to having multiple sprints color red. An having no sustainable pace either.
From sprints to iterations
So back to the drawing board. The question is: do teams have an alternative if the “standard” sprint procedure fails? I strongly believe they do, after having worked with many teams that moved away from “traditional” sprints. Let me illustrate this.
As it is very hard to plan the exact amount of work even for a two or four week period, and still be able to round off all this work before this period finishes, why not move to a backlog item oriented approach? Where the realization of individual backlog items becomes more important than having green sprints or red sprints. Where it is less important to exactly have your backlog items done within the scope of a single sprint. Where work on a backlog item simply continuous during the next sprint, if it isn’t done yet. Or even moved back to the backlog, when they appear unclear. So how would this work better?
In bullet points:
- No break down. As it is less important to know exactly if your backlog items will fit your sprint, there is less need for breaking down backlog items in tasks.
- Follow the life cycle. Even better, in my experience most backlog items follow a similar life cycle when being realized. In software development this usually reflects in activities such as analysis, design, test design, build, developer test, test and accept – at least in my projects. Tracking this backlog item life cycle is easier than creating individual tasks such as “Build X”, “Write unit tests for X” or “Test X”. Saves a lot of work, and more over it allows you to optimize your work in progress much better (think Kanban) than just tracking “To Do”, “In Progress” and “Done”. My teams often visualize the backlog item life cycle using www.speedbird9.com or other tools.
- Hours don’t matter. Also, there is no need anymore for estimating tasks in hours. Just having a point scale that expresses the size or complexity of your backlog items will do. Knowing the average amount of points that a team realizes during a sprint is enough to plan the next sprint. You simply choose the amount of backlog items that matches the average number of points, and you’re on the road again. Thus, planning the next sprints is done in half an hour, instead of half a day.
- No mini-deadlines. This is the main points. If you are able to implement these guidelines, you can move away from the continuous pressure of having to run the 100 meters dash every sprint. You don’t have to be Usain Bolt anymore, but rather can work in a sustainable pace.
This is where sprints become iterations (again).
This post was published in SDN Magazine in The Netherlands, and in The Agile Record in Germany, Switzerland and Austria.
Very nice read. A lot of it resonates.
Personally, I tend to value those 10% because I don’t view them as a net loss. I guess that depends on the way the team works together during that break-down phase…