The Case of the Time Tyrant

Don't Play Whodunit with Ideal Hours

13 February 2008

Alan Atlas
Mad Parrot Consulting, LLC

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.

Article Rating

Current rating: 0 (0 ratings)

Comments

Eivind Hagen, CSM, 2/14/2008 12:48:50 AM
I like your contrasted ways of dealing with this. I'd also suggest that using story-point estimates can eliminate this problem altogether, since story-points are unit-less by definition. No manager can say how many hours equals 1 story-point (unless you give them a clue) and the velocity becomes simply the sum of the story-points completed for a particular sprint. A crafty manager might try to reverse-engineer the hours / story-point, but then you can counter him/her saying that a story point is a deliberately 'rough' estimate, and if you use the common set of modified Fibonacci sequence to them (1, 2, 3, 5, 8, 13, 20, etc.) then you are deliberately making those estimates immune to 'accurate' reverse engineering. It's simply not enough to work out any kind of reliable formula, and this should bring the managers mind around to the thinking that it's delivered value that matters, not trying to make 100% 'accurate' estimate (an oxymoron anyway).

-Eivind
Jeffrey Whelan, CSM, 2/14/2008 10:53:31 AM
I'm dealing with that now, with a member of my team and not a manager. I will dig into new functionality and sometimes my 'ideal hours' exceed the time allowed for the task. That is perceived as me not pulling my weight - but the job gets done, I update my times and move on to the next task. This person has decided to get our manager involved. So, in spite of the goal, to deliver working software at the end of the sprint, having it working as expected with maybe a little technical debt ...we are seen as failing because we did not do the heavy documentation of everything we worked on.
Dave Bales, CSC,CSP,CSM, 2/15/2008 4:07:23 AM
I recently started using scrum with one of my teams and they also had puzzled looks when the total number of ideal hours exceeded the amount of time expected in a regular working week. But they took it on trust with the story points, which were alien to them at first, and now after three sprints the velocity history is beginning to take effect. They now solely estimate their commitment on story points and take into account the velocity that they have achieved over the past sprints. I still have to educate my managers and peers when they walk past and check out our white board littered with post-it notes and numbers of hours remaining, but they quickly get it once I show them the velocity graph and the history of story points achieved in each sprint. P.S. I did start off with a linear 1-10 rating, but I became a little disapointed when it came to consistency of estimates and the appreciation of the magnitude of higher rating stories. After trying the fibonacci sequence though, this all changed with real mental decisions being made between what constitutes the difference between an 8, a 13 and a 20.
Mark Summers, CST,CSC,CSP,CSM,CSPO, 2/27/2008 11:24:15 AM
There is also the affect it has on the team, having time associated with tasks. When one team I worked with went over to Scrum, they started to panic as they ran out of time on tasks and started to compromise on quality. It turned out that team members had been blamed so many times for not completing work in line with a plan and were used to cutting corners to fit into the schedule. What we decided to do in this case was do away with estimating time on tasks; tasks are either done or not done, 1 or 0. This allowed the team to focus on quality.
What they accepted into the sprint was entirely based on the velocity, derived from the story point estimation. You still get a burn down this way its just number of tasks remaining rather than number of hours; need to make sure teams break down tasks sufficiently for this to be meaningful. This also takes away the temptation for managers to hold the team to ransom about how many hours work they are getting through and thus makes it easier to educate management to look at how much value is being added.
Mike Collins, CSM, 8/7/2009 4:55:42 PM
I agree in principle with most of the article but in my experience, the task estimates will usually be more or less in line with reality. When the task estimates are adding up to less than half of the available time, it is a red flag that either something is wrong with the estimates or the team has too many impediments. In either case it would be good to address this in the retrospective context.

The article also says...
"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 is a good sentiment but also completely irrelevant in this context because the value of a task does not correlate to its time estimate or to its estimation error.

You must Login or Signup to comment.