Many new-to-agile teams use some form of iteration-based agile approach. Often, in the form of Scrum. Back in Time You Spend in Agile Meetings (near the bottom of the post), I enumerated all the possible meetings.
I suggested the team review its WIP limits and think about limiting the WIP for the entire team. When the team reduces its WIP, the team might be able to reduce the number of meetings.
I mentioned how you could integrate the demo work into an iteration if you create a column for the demo. I had a great picture in my mind. Unfortunately, the mind-meld function with you, my readers, isn’t working.
Here’s a picture of how you might create a kanban with a Demo state, just before the Done column.
Notice this team has WIP limits on every column except the Done column. Here’s how you walk this board:
- Start at the column just before Done, the Demo column. Ask the team, “What do we need to do to demo this card, to move it to Done?”
- Once the team answers that question, the team moves to System Test. Again, the question is, “What do we need to do to move this work to Demo, to help move it from System Test?”
- Continue for all the cards in progress on the board. The Develop and Dev-Done columns are full. The team can’t pull any work off Discuss Story until they somehow move work from Dev-Done into System Test and move work from Develop and Unit Test into Dev-Done.
When a team uses kanban, they start from the right-most column, clearing work. Then, they can pull from the next-left column.
I’ve seen several benefits of using a Demo column before the Done column:
- Too many teams have part-time product owners. The PO needs to be an integral part of the team and needs to participate in any board-walking meeting. If the PO can’t make the meeting, that is an impediment some servant leader needs to address. This Demo column on your board clarifies that impediment.
- When teams have trouble clarifying Done at various levels, the Demo column might help them see what’s really done or not done.
That combination of WIP limits and pulling instead of larger-batch planning/pushing, often helps teams limit their meetings.
Here’s another board where you can see how a team could integrate the releasing step into their board.
After Demo, they have a Release column. (This only works if you have a product that is SaaS.)
Again, because this is a kanban board, you always start at the right-most column and see what you can pull, to get to Done and manage the team’s WIP.
You can use iterations and use a kanban board. I explain how you might do this in Create Your Successful Agile Project.
Every team needs their own board. Here and in the book, you can see prototype boards. I fully expect you to change the board to meet your needs. If you have a code review step, maybe you need a column for code review. That column might be before Dev-Done in the board above. (And, remember, if you pair, swarm, or mob, you have built-in code review.)
Columns are cheap. Visualizing your work is priceless.
Too many long meetings is an agile “smell.” Consider changing your board and consciously thinking about the flow of work rather than pushing work to the team.
You can reduce the meetings you have if you visualize your work with a board that makes sense for you now. And, changes as your team changes its flow.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Visualize Work to Reduce Agile Meetings Opinions expressed by Java Code Geeks contributors are their own. |
