Antipattern of the Month: Cloned Avatar

Stepping back from the task board, you view your handiwork and allow yourself a satisfied smile. After democratically putting the choice of avatars to the team, each of them decided on a "South Park" cartoon character. Ever the diligent servant-leader, you printed out a sheet - in color no less - with all of the cartoon choices they had made. You cut them out carefully into avatars 2 or 3 inches square and went the extra mile by laminating them. Just in time for the Daily Scrum to begin!

The team gathers around the board and starts to form their plan for the day. They also seem pleased by these smart new avatars, but it soon becomes evident that they aren’t quite clear on how to use them. One person wonders aloud: “why do we only get one avatar each?” Another, seemingly in pursuit of a remedy for that very concern, moves to the board and places his own avatar so that it spans two items of work-in-progress. Momentarily stunned into silence, you watch aghast as a third team member summarizes his plans to complete a user story that day, while placing his avatar over an item in the Sprint Backlog so as to “book” it in advance.

Looking on the bright side, however, you can see that the introduction of avatars was a wise move. It's provided transparency over team behaviors and exposed the team's flawed understanding of Scrum and of what it means to collaborate in an agile fashion. It's highlighted “coaching opportunities” which have lurked unseen until they were blown to the surface by Cartman, Kenny, and Stan.

The attempted “booking” of work in advance illustrates one of these team misunderstandings. An avatar is supposed to personify the individual who is actioning work which is actually in progress. It should show at a glance that an item is indeed being worked on and by whom. By definition, an item which is still in a backlog is not yet being actively worked on by anyone, and hence the placing of an avatar over such an item is nonsensical. Furthermore, trying to “book” an item in advance removes the opportunity for another team members to perform that work, should they be in a position to do so earlier. Only once a team member completes an item, and is indeed available, should the next item be brought into play. Even then the choice of task ought to be made in accordance with the team’s plan, and not because he or she would simply prefer to do that work. Also, a conscientious team member should first try to help other team members complete tasks which are currently in progress, before looking to the backlog for new work to begin. In Agile practice, there are no kudos for starting to do something. The only value lies in completing work, and in thereby making a valuable increment ready for delivery.

If a team member wants more than one avatar for themselves, then that may expose yet another problem. An elementary operating principle of Lean and Agile practice is that work-in-progress should be deliberately limited. By constraining the number of tasks that the team allows itself to perform at any one time, the work which is currently in-hand is more likely to be completed sooner, and value is more likely to be delivered earlier. Moreover, that work may be completed to a higher standard of quality since the team can afford it a greater degree of focus. In theory, the most efficient way a team can function is to limit its work-in-progress to exactly one item, a pattern known as Single Piece Flow. In practice that is rarely achieved and can sometimes be sub-optimal, as team members can impede and block each other if their joint focus becomes too narrow. By limiting each member to no more than one avatar, the team can assert that its work-in-progress limit ought not to exceed the number of team members.

A common variation of this anti-pattern occurs when a team member tries to "span" two or more items of work with their avatar. This implies that they are working on two things at a time when at the very most they should be focused on one thing only, so as to pay it due care and attention. WIP limits can, of course, end up being broken by such behavior. However, it's possible that another problem lies behind it, such as a dependency between items whereby INVEST criteria have been compromised. It should be possible for each discrete piece of work to be actioned independently of all others. Each team member may then reasonably be expected to work on no more than one thing at a time. Note, however, that it is acceptable, and indeed commendable, for two or more team members to collaborate on the same piece of work. The clear grouping of avatars upon rapidly expedited items can be expected to bring joy to a Scrum Master's heart.

Cloned Avatar is Antipattern of the Month at agilepatterns.org

Cloned Avatar

Intent: Increase the Work In Progress beyond 1 item per team member.

Proverbs: You can’t be in two places at once; good and quickly seldom meet.

Also Known As: Split Avatar

Motivation: If development team members are given unclear priorities in a high-pressure environment, they can be tempted to start development on an item without first completing the work they have in progress. They can then claim to those exerting the pressure that work is underway.

Structure: A Development Team member accepts a backlog item on behalf of the team, and thereby brings it into Work In Progress. His or her avatar is placed on the item to show that responsibility has been taken for its progression. Before the item is complete, another enqueued item is taken off the backlog and brought into progress. The team member then either places a duplicate avatar on the work (cloned avatar) or spans both items with a single avatar (split avatar).

Applicability: Avatar cloning or splitting is common where product ownership is poor. A good product owner establishes clear priorities. Pull will be exerted on work that is currently in progress rather than unstarted work. As such, team members will neither be expected nor encouraged to break WIP limits.

Consequences: When team members clone or split their avatars they are typically breaking WIP limits. Each team member should only have one avatar and as such the team WIP limit should be no greater than the number of team members. Exceeding the WIP limit leads to an increase in batch sizes, reduced throughput, and an increased depreciation of work partially completed.

Implementation: It is common to find an avatar straddling two or more items in progress on a Scrum or Kanban board, or for items to be placed in proximity to one avatar so as to imply simultaneous progression (split avatar). Some teams normalize this dysfunction by mistakenly allowing team members more than one avatar (cloned avatar).

See Also: Information Radiator