[Click for full size]
I’ve been using Kanban at the enterprise level as a way to engage executive leadership visually to see an entire PMO project portfolio (and I’m sharing a story about this at AgileDC in October for my Scaling Product Ownership talk). What has come up through these assessment sessions has been very interesting to say the least. Now, applying Kanban to bug remediation and defect resolution processes is somewhat straightforward. What if we look at how software development really works?
Kanban, a system based off of manufacturing inputs and outputs, doesn’t say much about re-queuing things. What I mean is, we look at Kanban, work in progress limits, etc etc, and see the card go through the line. Then it’s done.
In the software development world we have reusable processes, we have repeatable steps, and we have recycled stories. Kanban doesn’t really address the whole re-queuing thing.
So the thought in my mind is: “So let’s talk about versioning.”
“You can always create a new version of the repeatable card, story, or step.”
But this doesn’t seem to sit well with me. I’m not so sure I’m convinced.
So what happens when you need to send that repeatable story through the line… several times, or even greater, what about an entire multi-story process?
Tell me I’m missing something… and yes, I have several books on the subject (like Kanban: Successful Evolutionary Change for Your Technology Business by David J. Anderson)… so don’t flame me too hard. Hell, I even use kanban at home.
If you’re a real Kanban/Lean Manufacturing NINJA you should get:
Yes. It’s from 1982 and you can buy it for 1 CENT on Amazon.com + $9000 for shipping… I keed I keed!
So tell me, what’s goin’ on here? Am I taking it too literally?