Board Tyranny in Iterations and Flow

I was at an experience report at Agile 2016 last week, Scaling Without Frameworks-Ultimate Experience Report. One of the authors, Daniel Vacanti said this:

Flow focuses on unblocking work. Iterations (too often) focus on the person doing the work.

At the time, I did not know Daniel’s twitter handle. I now do. Sorry for not cc’ing you, Daniel.

Blankboard-1024x743

Possible Scrum Board. Your first column might say “Ready”

Here’s the issue. Iteration-based agile, such as Scrum, limits work in progress by managing the scope of work the team commits to in an iteration. Scrum does not say, “Please pair, swarm or mob to get the best throughput.”

When the team walks the board asking the traditional three questions, it can feel as if people point fingers at them. “Why aren’t you done with your work?” Or, “You’ve been working on that forever…” Neither of those questions/comments is helpful. In Manage It! I suggested iteration-based teams change the questions to:

  • What did you complete today?
  • What are you working on now?
  • What impediments do you have?

Dan and Prateek discussed the fiinger-pointing, blame, and inability to estimate properly as problems. The teams decided to move to flow-based agile.

kanban.iteration-1080x905

Possible Kanban board. You might have a first column, “Analysis”

In flow-based agile, the team creates a board of their flow and WIP (work in progress) limits. The visualization of the work and the WIP limits manage the scope of work for the team.

Often—and not all the time—the team learns to pair, swarm, or mob because of the WIP limits.

Iteration-based agile and flow-based agile both manage the team’s work in progress. Sometimes, iteration-based agile is more helpful because the iterations provide a natural cadence for demos and retrospectives.

Sometimes, flow-based agile is more helpful because the team can manage interruptions to the project-based work.

Neither is better in all cases. Both have their uses. I use personal kanban inside one-week iterations to manage my work and make sure I reflect on a regular basis. (I recommend this approach in Manage Your Job Search.)

In the experience report, Daniel and Prateek SIngh spoke about the problems they encountered with iteration-based agile. In iterations, the team focused on the person doing the work.  People took stories alone. The team had trouble estimating the work so that it would fit into one iteration. When the team moved to flow-based agile, the stories settled into a more normalized pattern. (Their report is so interesting. I suggest you read it. Page down to the attachment and read the paper.)

The tyranny was that the people in teams each took a story alone. One person was responsible for a story. That person might have several stories open. When they walked the board, it was about that one person’s progress. The team focused on the people, not on moving stories across the board.

When they moved to flow, they focused on moving stories across the board, not the person doing the stories. They moved from one person/one story to one team/a couple of stories. Huge change.

One of the people who read that tweet was concerned that it was an unfair comparison between bad iterations and good flow. What would bad flow look like?

I’ve seen bad flow look like waterfall: the team does analysis, architecture, design specs, functional specs, coding, testing in that order. No, that’s not agile. The team I’m thinking of had no WIP limits. The only good thing about their board was that they visualized the work. They did not have WIP limits. The architect laid down the law for every feature. The team felt as if they were straightjacketed. No fun in that team.

You can make agile work for you, regardless of whether you use iterations or kanban. You can also subvert agile regardless of what you use. It all depends on what you measure and what the management rewards. (Agile is a cultural change, not merely a project management framework.)

If you have fallen into the “everyone takes their own story” trap, consider a kanban board. If you have a  ton of work in progress, consider using iterations and WIP limits to see finished features more often. If you never retrospect as a team, consider using iterations to provide you a natural cadence for retrospectives.

As you think about how you use agile in your organization, know that there is no one right way for all teams. Each team needs the flexibility to design its own board and see how to manage the scope of work for a given time, and how to see the flow of finished features. I recommend you consider what iterations and flow will buy you.

Tags: , , , , ,
Previous/Next Posts
« »

2 Comments

  1. Lisa Crispin

    I think it’s more about how the team decides to work. My last team started out as a by-the-book Scrum team. We used a typical Scrum board (tho we added testing-related columns) where story swim lanes were organized from top to bottom by priority. As a team, we decided to always focus on completing one story at a time. Of course, with our small stories, usually one or max two pairs or solos could work in that part of the code at a time. However, the rest of the team took on other tasks as appropriate. For example, one person or pair might say, “Let’s get that database task done” or “I’ll do that testing task”.

    As a team of 3-4 programmers and 3-4 testers, we only worked on 2 or 3 stories at a time, but focus was always on “get that top story done” and when it was, we moved onto the next story. (Of course, “done’ meant all testing activities were also complete!)

    So I don’t think it matters what framework you choose. What matters more IMO is the team’s commitment to quality and what they will do to make sure they build it in and deliver value frequently.

    Reply
    • johanna

      Hi Lisa, yes! For me, it’s not only the team’s commitment to quality but how they create a board that helps them work.

      I love your example of “completing one story at a time.” For me, that’s the value agile provides. We can see working product, one story at a time.

      Thanks for commenting.

      Reply

Trackbacks/Pingbacks

  1. Five Blogs – 4 August 2016 – 5blogs - […] Board Tyranny in Iterations and Flow Written by: Johanna Rothman […]

Submit a Comment

Your email address will not be published. Required fields are marked *