Burndown charts are one of the most common artifacts of an Agile software development environment. As a tool to provide insight for management into the state of a project, burndowns are useful and easy to understand. As a tool to motivate developers, they are counter-productive and often abused. The information contained in a burndown chart should be largely irrelevant to the day-to-day work of a developer.
Let's consider a scenario: assume you have a team of developers who are skilled, intrinsically motivated (i.e. enjoy their work), and focused on delivering the highest priority features as defined by the product owner. Now assume the burndown chart displays a slope indicating that the project is behind schedule. What is a developer supposed to do with that information? What actions or behavior is he or she supposed to alter based on that knowledge? Let's consider his or her options:
(1) Cut corners to go faster. This is obviously short-sighted. By omitting critical work such as testing and code re-factoring we are creating a code base that is full of defects and unsustainable.
(2) Work more hours. Again, this is short-sighted and self-defeating. Without proper work/life balance, developers become unmotivated, unfocused and burnt out. Lower productivity and turnover more than offsets any short-term benefits. There is a finite amount of productive focus one has available in a given day. Like a baseball pitcher who must rest his arm between games in order to maintain his performance for the whole season, so must a developer make time to recharge his mind. Although we use the term "sprint" in scrum teams, most development projects are more like marathons; it is critical to maintain a sustainable pace. Another unintended consequence of developers pressured to work extra hours is inflated, unreliable forecasts as developers pad future estimates.
(3) Work faster (a.k.a. work harder). This is a common idea, but I'm not sure how you do that. Type faster maybe?
Burndown charts, along with a host of other metrics, are useful for gaining insight into the state of a project and the effectiveness of the team's processes such as forecasting, but there seems to be no real benefit and a potential cost to using burndown charts in an effort to spur developer performance.
Diving deeper into the underlying issue - the idea of trying to put psychological pressure on your developers seems wrong-headed and counterproductive (whether it's shoving a burndown chart in their faces or some other tactic). These strategies actually result in the opposite effect of what is intended. People under pressure don't do their best work. Looking to sports psychology as an example - to play at your highest level, top coaches, trainers, and athletes know that it is critical to block out everything except the immediate task at hand. Top tennis players don't allow themselves to think about the point that was just lost, or how far behind they are. He or she just immediately returns to focus on the mechanics of the next serve. Mediocre coaches scream at their players during the game about poor performance. The best coaches encourage their players just to "keep blocking and tackling", staying in the moment, and following the system they've practiced.
What do we mean by pressure? It's really another word for fear. What happens when you're afraid? Fear causes the brain to produce fight or flight hormones that suppress the higher order functions of the brain (the kind of functions you might need to develop software). This also creates cognitive noise - thoughts that distract and compete with the task we are trying to perform (such as writing quality software). Ideally, you don't want your developers thinking about anything other than taking the next highest priority feature and working it through to a quality outcome, and then grabbing the next highest priority feature and doing it again.
One final thought - another unintended consequence of creating a pressure-cooker environment for developers is that it undermines teamwork. Studies have shown that if you put rats in a cage and create a stressful situation, such as random electric shocks, they will begin attacking each other as their fight or flight hormones boil over. Similarly, people in a stressful situation start spending more of their energies venting their frustrations at each other and even trying to preemptively assign blame rather than working together to achieve the goal.
Let's consider a scenario: assume you have a team of developers who are skilled, intrinsically motivated (i.e. enjoy their work), and focused on delivering the highest priority features as defined by the product owner. Now assume the burndown chart displays a slope indicating that the project is behind schedule. What is a developer supposed to do with that information? What actions or behavior is he or she supposed to alter based on that knowledge? Let's consider his or her options:
(1) Cut corners to go faster. This is obviously short-sighted. By omitting critical work such as testing and code re-factoring we are creating a code base that is full of defects and unsustainable.
(2) Work more hours. Again, this is short-sighted and self-defeating. Without proper work/life balance, developers become unmotivated, unfocused and burnt out. Lower productivity and turnover more than offsets any short-term benefits. There is a finite amount of productive focus one has available in a given day. Like a baseball pitcher who must rest his arm between games in order to maintain his performance for the whole season, so must a developer make time to recharge his mind. Although we use the term "sprint" in scrum teams, most development projects are more like marathons; it is critical to maintain a sustainable pace. Another unintended consequence of developers pressured to work extra hours is inflated, unreliable forecasts as developers pad future estimates.
(3) Work faster (a.k.a. work harder). This is a common idea, but I'm not sure how you do that. Type faster maybe?
Burndown charts, along with a host of other metrics, are useful for gaining insight into the state of a project and the effectiveness of the team's processes such as forecasting, but there seems to be no real benefit and a potential cost to using burndown charts in an effort to spur developer performance.
Diving deeper into the underlying issue - the idea of trying to put psychological pressure on your developers seems wrong-headed and counterproductive (whether it's shoving a burndown chart in their faces or some other tactic). These strategies actually result in the opposite effect of what is intended. People under pressure don't do their best work. Looking to sports psychology as an example - to play at your highest level, top coaches, trainers, and athletes know that it is critical to block out everything except the immediate task at hand. Top tennis players don't allow themselves to think about the point that was just lost, or how far behind they are. He or she just immediately returns to focus on the mechanics of the next serve. Mediocre coaches scream at their players during the game about poor performance. The best coaches encourage their players just to "keep blocking and tackling", staying in the moment, and following the system they've practiced.
What do we mean by pressure? It's really another word for fear. What happens when you're afraid? Fear causes the brain to produce fight or flight hormones that suppress the higher order functions of the brain (the kind of functions you might need to develop software). This also creates cognitive noise - thoughts that distract and compete with the task we are trying to perform (such as writing quality software). Ideally, you don't want your developers thinking about anything other than taking the next highest priority feature and working it through to a quality outcome, and then grabbing the next highest priority feature and doing it again.
One final thought - another unintended consequence of creating a pressure-cooker environment for developers is that it undermines teamwork. Studies have shown that if you put rats in a cage and create a stressful situation, such as random electric shocks, they will begin attacking each other as their fight or flight hormones boil over. Similarly, people in a stressful situation start spending more of their energies venting their frustrations at each other and even trying to preemptively assign blame rather than working together to achieve the goal.
Hi Joel--thanks for your further thoughts here. While I believe that the situation that you describe above is likely common, you are missing two other options that I espouse for my teams, and prefer over those that you've mentioned.
ReplyDelete1. Discuss wasteful things that are occurring in the sprint and eliminate doing them. Pet projects and dictates from outside the team are obvious examples.
2. Discuss doing less in terms of a story that may be taking longer than planned, but maintain very high quality. User stories are "placeholders for conversations" and should be negotiable all the way through, as long as they're meeting basic acceptance criteria.
3. Drop work for the current sprint. Yes, we actually do this! However, I ask that teams are always working on the highest priority work and limiting work in process (somewhat like Kanban). We plan on 80% completion at the sprint and release level, so this is almost never a problem.
The burndown chart is a great way of getting daily information when applied in the above context. Of course, you can also go with a burn-up chart in terms of story points and that will give you even more valuable information.
Thanks again for sharing!
@multicastmatt
Chad, thanks for these insightful thoughts. Having experienced the good, bad, and ugly of metrics in software development and more specifically burndown charts, I typically encourage teams to look at burndown charts as they look at stories - a conversation starter.
ReplyDeleteIf the burndown chart shows we're behind, that's a conversation. Someone should ask the question: "the chart says we may be behind. Are we?" if the burndown shows we may be ahead, that's another conversation. "The chart says we're ahead of schedule. Are we?" Until the team confirms to me that we are ahead and behind, I'm not making an inference solely out of a chart.
Why is this important? Because in Agile we want to be focused on delivering customer value, and we also want our engineers to understand and drive towards that value. Because of that, they might make day to day decisions that are geared towards achieving that value but may not reflect well in a daily progress chart. Removing the flexibility to make day to day adjustments because we want precise predictability will backfire, not only in lower morale due to the feeling of failure induced by the chart but also in bad habits, such as cutting corners, introducing technical debt, writing fewer tests, inflating estimates, etc.