Hans Samios' Personal Lean-Agile Knowledge Base

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== How is Work Assigned During an Iteration (Sprint)? ======

> Sometime old habits and thinking die hard.

One of the fundamental tenants of Scrum and Agile is that the people who are doing the work are in the best position to make decisions about that work. This differs from a more traditional management approach which says that an outside expert can make better decisions about doing work than the people that are doing the work. The traditional approach is a left over from "[[http://en.wikipedia.org/wiki/Scientific_management|scientific management]]" (or Taylor-ism) a theory of optimizing labor effort which was developed in the 1910's. With scientific management an expert in work process would design a work process based by breaking down each and every task to its simplest constituent, one that required very little training and could be done over and over again by a relatively uneducated workforce. The management expert would then optimize each of these work bits by observing the way it actually worked, timing the process steps and changing the process as a result of what was seen. This approach made sense in the 1900's when companies like Ford were trying to figure out how to mass produce cars using labor that was relatively uneducated (most of the available people were people that moved in from farms to the city) and when you really could slice the jobs down into small repeatable jobs.

There was a time when we managed software in a similar way, or at least we'd try to. We'd try to break down jobs into small pieces and then assign that work to people for action. In extreme cases we tried to even predict what those tasks were going to be months or even years in advance. And sometimes you still hear of "management" thinking this is the best way to organize work. But while the approach might make sense for a simple, focused job, it does not make sense for software development (or any other knowledge management job, for that matter). You probably understand this intuitively yourself. Remember the time when the manager told you to do something, or do it in a particular way and you absolutely knew that it made no sense for you to do the job (eg because of other jobs you had) or in that way.

With Scrum we say the team is "self-managed". This means we (or perhaps more accurately, the Product Owner) decides "what" we want (in terms of goals and requirements) and we leave it up to the team to decide "how" they are going to meet the goal. Most teams do not (pre-)assign stories. During the Daily Scrum meeting, as each team member talks about her work, they select the work that will help the team meet the goal of the Iteration (Sprint). This usually means picking up work on the highest priority story since this maximizes the value delivered and the reduces the risk of meeting the goal of the Iteration (Sprint). It also helps broaden the team members understanding of the work as while they may not be the expert in the area represented by the task, they will learn something as they do the work. In general it is good to have these more flexible team members as it creates a team which is better able to deal with any requirement thrown at them, increasing the overall value of the team.

There are times when it does not make sense to pick work on the highest priority story, but again, she is the best person to figure this out as she has the context of all the other work going on and the overall goals of the Iteration (Sprint). The Daily Scrum also offers a forum for other team members to participate in the discussion of what's next. This works provided no-one falls back on old behaviors and tries to assign work to another team member.

By working this way, we get a number of benefits:

  * Teams assume responsibility for commitments they make because they know they are the only ones responsible for the work. If someone tells you what to do, and it turns out to be wrong, then its hard to feel like it is your issue.
  * Teams have a tendency to swarm more on work which increases cross-fertilization and learning while at the same time reducing work-in-progress (WIP) which increases throughput and decreases risk (if you don't understand why, play the [[http://www.scrum-breakfast.com/2010/03/scrum-value-simulation.html|Penny Game]] or variations). When non-team members assign work there is a tendency to focus on "who is best for the job" and "how do make sure everyone is busy" which does not lead to learning or the best method of execution.
  * Teams improve how they work more rapidly because they take responsibility for how they work. If someone tells you what to do, then there really is no reason to engage much in improving the work of the team.

A lot folks who read this will already know this and so this seems a pretty simple post. My reason for saying all this is that even with the best intentions in the world, we still find people who for whatever reason have fallen back on the old ways of thinking and work. This is a reminder of why we talk about self-management approaches with Scrum and Agile.

{{tag>FirstSprint FAQ Assignment BlogEntry}}