By Alan Atlas
Managing a Scrum team for the first time brings some unexpected challenges. Often, at least at our company, the lucky manager hasn’t received the same Scrum training as the ScrumMaster or the team. She hears a lot of vague things about letting the team manage itself, but doesn’t quite know what to expect, let alone how to properly manage a Scrum team. All she really knows is that she is responsible for the success of a team over which she has very little control and who are using a process she doesn’t really understand.
As the scrum process takes hold, it begins to do what we promise in training: it makes a lot of things visible that were not visible before. One common example of this phenomenon is the fine-grained list of tasks that the team is doing on a daily basis (the sprint backlog). Estimates for these tasks in ideal hours are a tantalizing target for managers who are used to creating success by actively controlling (managing) their people. These lists are often like candy to managers who have never before had such visibility into what their teams are doing on a daily basis. They latch onto this concrete artifact with its numbers and lists and immediately start to manage with it.
Many hard-charging managers become puzzled, scratching their heads in confusion and consternation as they try to apply waterfall-based thinking to the sprint backlog. They end up wondering how it is that they can’t make the estimated hours add up to the number of hours that the team has available during the sprint, even allowing for overhead. Worse, they start to wonder why the team appears to be committing to work that adds up to a paltry 30 percent or 40 percent of the total time available during the sprint.
“Five people for 30 days (22 work days) adds up to 110 possible person-days of work! That’s 880 hours! I only see 350 hours estimated on your backlog! This can’t be right. You’re being lazy or inefficient. This Scrum process is awful, and I’m going to get very involved to make sure we’re doing the right amount of work!”
This is something that I see fairly often as Scrum spreads throughout my large, successful Internet company. Does this happen at your company, too?
What is the thought process that got our new-to-agile manager so upset?
- Employees need to be supervised (command and control).
- Time spent is a good measure of work done because employees have already been told the correct thing to do.
- 100-percent-resource- (employee-) utilization is the goal in order to avoid “waste” and reduce costs.
- If utilization is low, it is because employees are not being controlled enough. They are getting away with being lazy.
- Therefore, I as a manager must make sure the team is spending every possible minute doing work. That’s the way to get the most software released!
By contrast, what would an experienced agile manager be thinking?
- The team is doing the most work possible in the time allowed.
- The team is concentrating on delivering value, defined by product backlog items, in priority order.
- The most useful measurement of team accomplishment is the delivery of product backlog items as working software, so that is what should be monitored. Time spent does not correlate with delivering value.
- Improving the team’s velocity requires removing organizational impediments that are revealed by Scrum (e.g., high operations load, high maintenance load, technical debt in legacy software, requirements churn and lack of definition, no continuous integration environment, poor employee retention, incorrect team size, incorrect people on the team).
- The goal of Scrum is not to achieve the highest resource utilization; it is to achieve the highest throughput of completed, deliverable value. Little’s Law, Goldratt’s Theory of Constraints, and the Lean principles of pull scheduling and working to capacity explain why Scrum can deliver on this goal. From these underlying principles, we realize that 100 percent utilization actually works against high productivity.
- I, as manager, care that the team produces the most value possible each sprint, therefore the best way for me to reinforce the team’s focus on improving velocity is by helping to remove impediments.
We already know what 100-percent-utilization of roads gives us: zero throughput (gridlock)! Why do we think it is different for a development team?
Concentrating on resource utilization sends a negative message to the team without improving anything except, well, resource utilization. It diverts energy and focus from the important thing, which is delivering value for customers. It takes away the single largest source of productivity we have available: the creativity and commitment of the team.
So what should our manager, who is perplexed because “the hours don’t add up” and suspicious that not enough work is getting done, do? The key is to stop thinking in terms of people spending more time doing more work and start thinking in terms of changing the tasks that the team is doing so that the time spent working contributes to value and not waste. This shift in mindset leads to a different set of possible actions for the manager:
- Concentrate on velocity as defined in Scrum: the amount of value completed each sprint. Watch for the velocity to increase every few sprints as a result of the improvements that you and the team make.
- Stop worrying about why the hours don’t add up. Start noticing instead that the team produces the working software they say they will at the end of every sprint.
- Challenge and inspire the team to improve velocity by changing the things that get in the way of building lots of good software. Ask about the impediments that have been raised in retrospectives and what has been done to remove them.
- Work with the team to address organizational impediments as they are identified in retrospectives. For example:
- Do you really need to have a meeting of the entire organization every week?
- Is the corporate QA group able to support your team in the most efficient way possible?
- Are outsiders randomizing your team by redirecting them during the sprint?
- Let the team self-organize to improve velocity. Ask them what changes they are making that will enable them to spend more time building software and less time doing unproductive work. For example:
- Did people spend a lot of time fixing broken builds that could have been spent delivering features?
- Were team members available to help one another when help was needed?
- Did the team swarm to complete features quickly, or to overcome difficult obstacles?
- Did people privately wrestle with problems rather than reaching out for help? Look for and review impediment backlogs.
Thinking in agile terms will lead the manager, and the team, to their shared goal of shipping the most, and highest value, software possible. The improvements to velocity that are achieved in this manner will be long lasting and sustainable.
The passage of time, in and of itself, signifies nothing. Don’t tyrannize your team with ideal hours. Time is enough of a tyrant as it is.
