In a previous blog post, I discussed how sprint planning can help put the team in position to effectively swarm on tasks.  If building software is like playing golf, sprint planning is akin to assessing playing conditions, determining yardage, selecting a club, and setting up to hit the ball.  While the golfer has a few minutes to do all of these things, the act of actually swinging the club and hitting the ball allows little time for conscious thought or strategic decision-making. The player often acts based on habit and what feels right.

The same is true for task execution during a sprint. With the challenge and pressure of the sprint timebox, team members who are new to agile often revert to pre-agile habits. Signs include:

– Team members or (gasp) the ScrumMaster pre-assigning tasks to specific team members at the beginning of the sprint

– Team members only working on tasks that fit squarely within their skillset

– Each developer taking a user story to work on by themselves

Pre-assigning tasks:

No ScrumMaster worth their salt would assign tasks to team members as it is would be a violation of them principle of team self-organization.  Oh – not to mention totally disempowering the team as well.  Team members, on the other hand, may be tempted to pre-assign tasks. Having completed a sprint plan, they may proceed to divide up the sprint work and then head off in their separate directions to take care of their assignments.  This creates a couple of problems.

• Having too many user stories in progress (think WIP) at the same time. This creates bandwidth issues for the customer, who is charged with participating in conversations about each story, writing acceptance tests for each story, and testing each story. Worst case, it can put the team in the position of having 80% of 100% of the stories done at the end of the sprint, which delivers zero value to the customer.
• Promoting individual team member ownership of user stories rather than whole-team ownership.  This ownership can possibly impact others’ commitment to jump in to help out on the story, but more importantly it makes it harder for others to get up to speed to understand the story and the technical implementation if they were not involved in the conversations with the customers or any of the coding.

A pattern that minimizes work in process and maximizes team ownership is to not pre-assign tasks.  As team members finish a task, they look for the next available task to work on, even if it is for a story that someone else has started.

Working on tasks only within skillset:

We all know by now that Scrum prescribes three roles: Product Owner, Scrum Master, and Team Member. Putting aside discussions about whether the Product Owner or Scrum Master is a member of the team, the key point is that there is one Team Member role.  There are not separate roles for Web Developer, Data Base Developer, Data Architect, DBA, QA, etc. Properly constituted agile teams consist of specialized generalists with t-shaped skills. But skills are only part of the equation.  Desire for team success is paramount.  This means that a DBA is willing to help with QA testing in order to help meet the sprint commitment.

Developers who prefer to work on stories by themselves:

Sometimes Scrum Masters or functional managers have to make a hard assessment of whether team members prefer to work mostly by themselves. Not to be confused with introverts, some people gravitate toward coding because it allows them to delve deeply into the intellectual challenge of piecing together great code.  Before agile, so many buffers existed between developers and customers that loners could be valuable contributors to project teams as long as the team lead or systems analyst could be relay information to/from the customer and those developers.  These same types of developers struggle in the highly-collaborative world of agile teams.

Reflections:

• Resist the temptation to pre-assign tasks at the start of a sprint. Strive to minimize WIP and maximize whole-team ownership of stories.
• A culture that values team success rather than individual achievement is key.
• Not all individuals are a good fit for agile teams.