Scrumban is a name coined by Corey Ladas, for what happens when what you do now is Scrum and you apply Kanban. I stress again the cautions of Chapter 13: Kanban does not mean recklessly throwing out all of your Agile discipline; rather it’s a transformative process that takes time, thought, care, and collaboration.
This progression is typical…
This blog post explores how your org design decisions impact organisation productivity and what signals might help you to understand if your teams are aligned to purpose. In my work across large-scale software development organisations I’ve observed a number of different ways that teams are commonly structured and organised…
We’re at chapter 15 of Kanban from the Inside, on economic approaches to flow. This excerpt expands on the third of three principles of Real Options as identified by Chris Matts and Olav Maassen: Options have value, options expire, never commit early unless you know why.
I really enjoyed writing this chapter! My goal was to illustrate the extent to which things can look radically different and yet share the same underlying principles and philosophy. The excerpt below comes after a description of a production line at Toyota; the “TPS” of the chapter title is the Toyota Production System.
We’re often asked, “Is Kanban Agile?” To anyone who understands Kanban as the start with what you do now method, that’s a slightly odd question, but still, it deserves a respectful response.
When “Agile” is used as an adjective like that, it’s worth drilling down a bit to find out what’s really meant by the question.
Like many Kanban trainers, I like to reference POOGI and the Five Focusing Steps when I teach Kanban. I particularly remember one class in which a small company’s entire middle management layer was in attendance. It dawned on us that if the company had a constraint (and surely it must), it had to be represented by one of those managers in the room.
Earlier chapters have made it clear that the Kanban Method leaves room for interpretation. This is a strength. It is articulated sufficiently clearly for a community to rally around it, yet it is applied with sufficient diversity that its community continues to learn, to develop lower-level practices, and to share experiences. It is satisfying to observe that the Kanban community itself demonstrates in some measure all five of Senge’s characteristics of the Learning Organization.
Does Kanban in some neutral way just create the conditions for change, or does it come with its own biases? Do the method, its practitioners, and their host organizations need direction—in the form, perhaps, of an external true north (Chapter 14, Lean)—or will they steer themselves? As a community, we’ve considered these questions several times.
The ninth in a roughly weekly series of short excerpts from my book, Kanban from the Inside. We’ve reached the penultimate chapter of Part I (Kanban through its values) and the last of the nine values.
In this cheat sheet you’ll find 20 useful metrics commonly used by software development teams which can be used to improve their effectiveness. It has been written with the backdrop of two previous articles I’ve written (In the pursuit of effectiveness and Kanban’s Geological Record) which will give you further context to get the most from the cheat sheet.
