Extreme Measures

• Shorten iterations to force priority
• SME can only help others complete tasks
• Require 40% stories 100% done at midpoint
• Revert/discard work over three weeks old
• Random weekly team roster to force closure
• Stir pairs twice daily
• Eliminate individual tasks

Sometimes one has to take some extreme measures to help a team over the hump in their agile transition. It is hard to adjust work habits without having a work environment that depends on new behaviors. These extreme measures may stick, or may be training wheels for extreme programming.

Shorten Iterations
Shorten iterations to force priority. Cause the Customer role to pick fewer things to do, more often. This also should force developers to reach closure on cases more quickly. If the team is used to letting things lag and stack up for some future day, shortening the iteration can help them get into the habit of finishing things more quickly and taking on less work.

SME Has No Tasks
SME can only help others complete tasks. This rule forces collective code ownership. If a subject matter expert is not allowed to "do his own work" then he/she must do it through other people. This means more people with their hands in the same code, and also means a higher "truck number" for the team.

40 At The 50
Require 40% stories 100% done at midpoint if the team is still trying to assign work to individuals. If work is split up to individuals, it is normal that much of the work completes (if it completes) on the last day of the iteration. If the team is expected to organize around completing stories every day or two, then they have to work together in a new way. Normally tracking velocity will take care of the problem, since having 100% of the work 90% done means a velocity of zero. In the cases where velocity is not motivation enough, you may need to enforce the "fourty by the fifty" (40% completely done by the 50% mark of the iteration) rule.

Destroy Unfinished Work
Revert/discard work over three weeks old. Nothing proves sincerity like throwing work away. If you roll up your sleeves and delete some of the old tasks that have been pecked at over the course of weeks or months but never completed, it actually helps your team focus on the things that *really* need to be done, which improves your velocity. Incomplete work product is defined in Lean processes as "waste". If it were really all that important, it would have been driven to completion. It's trash. Take it out.

Random Roster
Randomize the team roster weekly to force closure of stories. Divide the team in half. Perhaps have half of them fix bugs while the other half works on new features. In most non-agile teams, people are used to having work slop over the edges of the iteration, and so they claim "done" when they're not really "done done". So randomize the teams. Now nobody can count on having next week to finish up the work they've committed to this week.

In addition, moving from team to team means that they will have the opportunity/obligation to work on parts of the system that are unfamiliar to them. This motivates the cleaning of ugly code and the shoring up of weak tests. It costs velocity, but improves truck number and code.

It is uncomfortable to live with change and uncertainty this way, but it will push people to rely on tests for features they don't know and ensure the tests pass pass before they hand off the code to a peer.

Stir Pairs
Stir pairs twice daily if you find people migrating to "pair marriages". You want to avoid having the same people partner up over and over. Things go stale that way, and people tend to partner with people at their own skill level rather than learning from people who are more skilled and sharing the burden of teaching those less skilled. If the partners are stirred occasionally, there is no undue burden and no hiding.

No Individual Tasks
Eliminate individual tasks by requiring that all production code have two sets of eyes at a minimum. Require pairing and TDD for all code. If this sounds extreme to you, you haven't been working in a shop that truly practices the XP style. This is actually part of the original process, and has been taught as-given for quite a long time now.

I don't generally advocate heavy-handed measures, but sometimes you have to create a system that teaches the practices you want people to learn... if only as a temporary measure.