Walk the Board
Teams retrospect often, but not every day. On the other hand, team members do need to connect with each other and see their work on a frequent, if not a daily, basis. And unless everyone mobs on all the work, the team needs to understand what everyone is doing, and especially if any work is stuck.
In the past, the team may have met once a week (or more often) to have a serial status meeting. Agile approaches save us from serial status meetings, which waste everyone’s time. Instead, the team can walk the board—the board your team created back in Make Your Own Board. That’s how the team learns what everyone is doing and if any work is stuck.
Note the project manager or the Scrum master or whomever is a nominal lead does not necessarily lead the board-walking. Walking the board is a team responsibility. It’s not the responsibility of any specific leader, although it might be convenient for someone to lead the board-walking activity. Consider asking a different person every day to lead the activity of walking the board. Or establish in the team’s working agreements how the team will walk the board.
When the team walks the board, it doesn’t have a serial status meeting. If team members start to blame another person for the state of something on the board, any team member can object to that blame.
We Walk the Board as a Team
by Javier, Tester
Javier
When we first started our version of agile, we had a dev board and a testing board. You can imagine how well that worked. After our first retrospective, we decided to merge our boards. We decided to visualize our flow with a kanban board.
We learn a ton about our WIP when we walk the board as a team. The first iteration of our joint board, we realized we needed buffer columns. The developers were too "fast" for the testers. We also realized we needed a UI column because we don’t have a UI person on our team. We decided to calculate our delay so we now have a req for a UI person on our team.
We update our board. We don’t have serial status meetings. No one blames anyone for doing or not doing work. Our board makes our work transparent, whether we like it or not.
The board is for the team. The board represents the state of the team. If the team doesn’t like what the board looks like, it can change the board by changing the team’s process. When someone in a leadership position or a title-based authority position decides on a board for a team, the team might abdicate its responsibility for changing its process.
Regardless of your approach (iteration or flow) consider asking the team to start in the column just before the Done column and ask this question: “What do we need to move this to Done?” The reason you start at the column closest to the Done column is that the team creates its flow, a pull-based approach to work. You can’t pull from the Ready column until you finish work in the right-most column and work left, to the front of the board. When you use WIP limits for a kanban board, you encourage the team to collaborate.
Even if your team uses iterations, consider asking, “What do we need to move this to Done?” Too many iteration-based teams fall into the Trap: Everyone Takes His or Her Own Story, or Trap: Experts Take Their Own Stories. The question changes the conversation from “how much work can we start” to “how much work can we finish.”
Once you have a board, the team uses it by managing work in progress and finishing work. Many teams use standups to understand what’s on the board. Boards help everyone see if a team is falling into any traps of not finishing work or having too much work in progress.
