Tag: Kanban

Posted on

WIP It Real Good

In his article “WIP It Real Good,” John Cutler examines the systemic challenges organizations face when attempting to reduce high levels of work-in-progress (WIP). He identifies common adaptations—such as excessive handoffs, reliance on shared resources, and a culture of saying “yes”—that, while initially beneficial, become entrenched obstacles to efficiency and focus. Cutler emphasizes that these issues are deeply rooted in organizational structures and mindsets, making change difficult. To address this, he proposes a series of reflective questions aimed at uncovering and challenging these ingrained practices, thereby fostering a more sustainable and effective workflow.

https://www.linkedin.com/pulse/wip-real-good-john-cutler-bhwlc

Posted on

Kanban Must Evolve in the Age of AI

In his article “Kanban Must Evolve in the Age of AI,” Jurgen Appelo argues that traditional Kanban boards, with their linear workflows, are inadequate for today’s AI-driven, nonlinear processes. Using examples from video editing, book publishing, and dining, he illustrates how modern workflows are complex and dynamic, defying simple sequential visualization. Appelo suggests that organizations should adopt flexible, AI-optimized systems that can handle the intricacies of contemporary value streams, moving beyond static boards to more adaptive, automated solutions.

https://substack.jurgenappelo.com/p/kanban-must-evolve-in-the-age-of

Posted on

Bye Bye Velocity. Hello Throughput.

As published by Louis-Philippe Carignan on Scrum.org

The Professional Scrum with Kanban (PSK) course has now been out for more than 6 months at Scrum.org. As one of the first few trainers who wanted to teach this course when it came out, I find that it is a great way to combine the Scrum framework with Kanban as a strategy to deliver value to your customer.

Out of the many topics that we talk about in this class, I’ve found that the use of throughput instead of velocity/capacity to be a positive change. I’ve taught the regular Professional Scrum Master (PSM) course for about 6 years now and when I get to the Sprint Planning slides, we usually extend the conversation around velocity and capacity. I pull up my complementary slide deck around relative estimation, poker planning, charts to track velocity and we spend an additional hour on this topic. I answer questions around the meaning of story points, how they should be understood, tracked and used in multi-team Agile project.

In the PSK class, this conversation is completely different. When I get to the Sprint Planning slides, I point out that the throughput history is used as an input to the Sprint Planning. With a few examples, I show how easy it can be to get from your electronic Agile tracking system (Ex: Jira) or on your physical Kanban board.

I then get a new set of questions from students which I find a lot more interesting. The conversation goes quickly around the variation in the size of the Product Backlog Items (PBIs) that are taken by the team at Sprint Planning. I can also tie it back to Little’s Law where limiting work in progress will increase throughput, thus helping students see throughput linked to limiting work in progress. There are very few questions around understanding throughput. Students find it is a metric that makes sense to the business compared to story points.

While our industry has talked about poker planning and story points since almost the beginning of agility in 2001, I think it is more than time that the conversation at Sprint Planning shifts to historical throughput instead of using velocity. Maybe one day in the software engineering museum, we can see a deck of poker planning cards next to a set of punch cards.