Recognize Visualization Traps

Not every team gets its board right the very first time. And defining a board that works for your team might be even more difficult if your team encounters these traps:

• Management mandates your boards.
• Every person takes his or her own story.
• Waterfall masquerades as kanban.
• The team works in iterations of waterfalls.

You have options for managing these traps.

Trap: Management Mandates Your Boards

Your management says, “Do Scrum!” or “Do Kanban!” Your management has an idea of what it wants to see for your board and your output.

Don’t fight with your management—at least, not yet. Instead, use the project frame that they request. If they request Scrum, use two-week iterations.

Use the board you want. If you have a ton of interruptions, use a kanban board to make that work visible. Use the board to measure cumulative flow and cycle time. I would not even bother measuring velocity. With all those interruptions, cycle time and cumulative flow are better predictors of your capacity. See ​Cumulative Flow Shows Where the Work Is​, and ​Cycle Time Shows How Long Work Takes​, for information about these measurements.

Trap: Everyone Takes His or Her Own Story

Sometimes when teams are new to an iteration-based agile approach, they fall into the trap of dividing the work by the number of people. “We’ll each take our own story. We’ll make tons of progress.” Or someone, such as a manager or product owner, asks or demands that everyone takes his or her own story. (When people demand that experts work on “their” stories, it’s the ​Trap: Experts Take Their Own Stories​.)

It sounds like it should work. If we divide up the work, we can get done faster, right?

Well, no. Knowledge work is interdependent work and requires learning. That means we need other people to deliver a feature and we will learn as we deliver. I have yet to see one-person features. Every feature requires at least a person who creates the feature and a person who checks the feature. Most features I see require more people.

If you have noticed this trap, consider these options:

• Move to a kanban board and create WIP limits. This will help everyone see where the work is and if the team has bottlenecks.

• Ask the team to ​Swarm on the Work​, or ​Mob on the Work​, on every single feature. When people work together, they will finish the features faster.

• At a minimum, ask the team members to pair on every single story.

Maybe you can see more options for your team. The team will make much more progress when people collaborate on stories than when each person takes his or her own story.

Trap: Waterfall Masquerades as Kanban

Just because you have a kanban board does not mean you are agile.

I’ve seen at least two kinds of flow that were not agile at all. In one, the team used a waterfall approach and its board had these headings: Analysis, Architecture, Design Specs, Functional Specs, Coding, and Testing, in that order.

Those headings might be okay, but here’s how they worked: The “product owner” supplied a large document full of functional and nonfunctional requirements. The product owner then put all those requirements into the Analysis column. The requirements were not in the form of stories with acceptance criteria. The architect developed an architecture based on those requirements and handed off work to the senior developer. The senior developer wrote design specs and many functional specs. The other developers finally joined the project and wrote their functional specs. Finally, the developers wrote code that tested their earlier assumptions. The testers joined the team just in time to start working on requirements in the testing column. They had code and documentation to use to guide their testing. Except the documentation didn’t match the code.

The team had a tremendous amount of WIP, lots of up-front documentation that didn’t reflect the final reality, and little collaboration.

Its flow was not agile. And because the team had no WIP limits, it didn’t use any of the agile or lean principles to collaborate and finish work. The board itself is not bad. If the team collaborates on everything, uses WIP limits, and eliminates up-front documentation, this kind of a board might work to help a team move to an agile approach.

I’ve also seen a team where the architect was outside the team and told the team how to do the work. That team had these columns on the board: Receive Specs, Coding, Testing, and Rework. Yes, the board actually had a Rework column. That’s because that team’s experience was like many other teams’: its up-front design was often wrong.

Both of these teams felt as if they were wearing straitjackets. No one had any fun.

I can’t guarantee agile projects are fun. However, as the team defines its own workflow and its work, many agile teams appear to have more fun more often.

Trap: You Have Iterations of Waterfalls

Some people who start with an iteration-based agile approach have a two-week iteration that looks like this:

• Day 1: Commit to work. Start development.

• Days 2-6: Continue development. The testers are bored because they have nothing to do yet.

• Days 7-10: Test and send back work to developers.

• Day 10: Realize the team didn’t finish half of what it committed to finishing. Or the developers “finished” but the testers didn’t.

The team doesn’t finish the work it thought it could. Often, the team discovers (or, worse, the testers discover) that the developers created a number of defects along with the feature. And sometimes the team doesn’t realize that it let defects escape into the next iteration. The team has a ton of WIP during the iteration that might be invisible to the team.

The real problem is that the team doesn’t take the responsibility to complete the work. Instead of a collaborative approach to starting and completing work, the team uses a waterfall approach inside iterations. Maybe you have board tyranny, as discussed in ​Beware of Board Tyranny​.

You don’t have to work this way. You have at least these options: ​Swarm on the Work​, or ​Mob on the Work​; use a kanban board and measure your WIP; or make your iterations half the duration of what they were.

The way to see if your team is doing this is to use a kanban board. See ​Kanban Boards Show Team Flow and Bottlenecks​. Make sure the team re-creates its flow on the board. Once the team sees its flow, consider asking it to create WIP limits, so people can see what they start and when.

If the team uses iterations, it can still use kanban to see the flow of work. However, it might be time to reduce the iteration duration to see what’s going on. In ​Keep Your Iteration Duration Short​, I said to make your iterations short enough that if you had to throw away everything you had done, you could. If your iteration is four weeks, divide it by two and use a two-week iteration. If your iteration is two weeks, make it a one-week iteration.

When the team halves the time, it puts pressure on itself to commit to less work. When the team commits to fewer features in less time, it reduces the batch size. That has the effect of increasing throughput.

If you are already using one-week iterations, consider this question: What would you have to do to get one feature done? Maybe the problem is your feature (story) size.