Kanban standup with no blockers/stoppers

Question

In a kanban project, a daily standup meeting must be help to discuss the stoppers (blockers) in the project. However, some of the developers are asking if, in days in which no stoppers are present at all, we should still have the meeting. Should we skip the meeting or have it to discuss just the overall progress?

Answer 1

Identifying blocked work isn't the only thing that can or should be done in a daily standup. It's a good opportunity for the team members to align on what everyone is planning to do, if someone will need help from someone else, and how to best get one step closer to achieving the desired outcomes.

Since you're using Kanban, you're probably using flow metrics like cycle time and throughput, have work-in-progress limits, and track work item age. If you have cycle time SLAs, you can use work item age to see if anything is progressing slower than expected and understand why, even if it's not necessarily blocked at the point in time. You can get ahead of potential problems.

Since a daily standup is short, I don't see a reason to skip one. Instead, I'd focus on making sure you're getting the most out of that time by looking at all the relevant data and getting the team on the same page.

Answer 2

"Daily Stand-Ups" Aren't Required

Kanban is a pull-queue methodology that uses a board to visualize status. While your team may have borrowed the practice of daily stand-ups from XP or Scrum, there is no requirement in "kanban" to hold one at all, ever. The only teaming requirement is kaizen, which is to practice continuous process improvement. This is more akin to Scrum's Sprint Retrospective than to its Daily Scrum event.

Re-Examine Your Process

Essentially, you're asking the wrong question. If your physical or digitial kanban is accurately reflecting status and performing its function as an effective information radiator, where is the requirement for a daily stand-up coming from? It's clearly not the team, so it's being imposed from outside the team; this is generally an implementation problem.

Most of all, you should ask the team how they want to coordinate their work. Again, while not defined by kanban-the-tool or kanban-the-practice, empowering the team to self-organize around the work is a central tenet of agility, and should be your primary source of information. If the team is successfully meeting its working agreements with the organization, then how the team does it doesn't really matter. If it's not, then kaizen should be routinely employed until the team is able to either meet its agreements or adjust the working agreements to reflect reality. Either outcome is acceptable from a process perspective.