Recently, I was working on an introductory presentation about Kanban. A “thorough” Google search revealed how drawn out and convoluted many Kanban explanations can be. Was there one true answer I was missing? Something nice and succinct like, say, a tweet on twitter?
Acting on this and laziness, I decided to pose the following question to twitter:
I was so surprised by the number of great responses that I’ve decided to compile and share them with you here:
giff24:#kanban 130 chrctrs? PLS!!! I dnt hve time or patience 2 rd that much
erwilleke:#kanban combines systems thinking with a work-limited pull system to allow rapid maturation of teams and delivery of software.
davenicolette:#kanban “What 100-130 characters would you use to describe Kanban?” I’d use the cast of _Who Framed Roger Rabbit?_
knoxgourmet: Kanban is Scrum without the mess, no sprint planning, no midrange planning, no MSG headache.
kjscotland: Map the value stream, visualize, limit WIP & establish cadence. Reduce WIP to improve flow of value and individual fulfillment
agilemanager: #kanban visualize flow & limit WIP to encourage evolutionary change towards a lean outcome & high maturity culture
Sprezzatura: First establish your value stream. Next limit your work in progress. Then visualize & learn from your workflow. #kanban
most_alive: . #kanban: value flows, post-its move, step,step,step, workers unite
neontapir: Kanban uses visual signals to track and optimize work delivery through key stages in its lifecycle.
I like the commonalities around value, visualization, limited WIP, pull systems, cadence, and flow. This tells me that Kanban is speaking a common and useful language to a lot of us. And, its value can be articulated in a tweet.
But my quest goes on!
I encourage you to add to this list by submitting your own 130 character Kanban definition either as a comment to this post or as a tweet to me (@jeantabaka and use #kanban in your answer.)
In April, I’m attending the Lean SSC conference in Atlanta. There will be a lot of discussion about Kanban. I’ll personally carry all comments and tweets to the conference for inclusion in the discussion. If you’re able to attend, let’s stretch the envelope and go beyond 130 characters on Kanban.
I know what you are thinking with the title of this post – I am drinking the Kool-Aid. Just bear with me for a minute. Back in 2002, when I started working on Rally, it was originally known as F4 Technologies. It was known as F4 because I did not want to work on anything that did not have the potential impact of a Factor of Four, for example a 4X increase in productivity or effectiveness. There are two reasons for this:
According to Paul Hawken in Natural Capitalism, we need a 4X productivity increase in the use of natural resources to get to a sustainable place with the current population in the world. Chapter 7 of that book helped form the core purpose and mantra of Rally – “Muda, Service and Flow.”
Now seven years into Rally, we have the proof that teams – including large and distributed teams – can be 4 to 10X more productive by following Lean principles and effectively implementing Agile development. Like the story of “Good to Great” from Jim Collins, you can’t leap here, but you can put yourself on that path by adopting a continuous improvement approach like Agile. If you do that, you can be a “great” software development organization that dominates your market and is 10X better than the good ones. Great organizations that dominate in their industry also have the knowledge and resources to change world, a la Google.org, the Salesforce.com Foundation and or through my favorite the Entrepreneur’s Foundation.
If you are working toward this, I believe you increase your business value by 4 to 10 times. I am going to make the case with the help of ROI models from David Anderson. (BTW, I love his book – it does a great job explaining the simple physics of Agile.)
From Chapter 2 - David Anderson's "Agile Management for Software Engineering"
This is a very simple model of software process. David shows more complex ones that model all the loop backs of large shipping software, but let’s work with this one. So, the rough equations to calculate the business benefit of the process are the following:
Net Profit = Throughput – Operating Expense
ROI = Net Profit / Investment
In the following four pages, I am going to look at how this equation plays out for four different scenarios:
Beginning Agile team in Flow benefiting from the 25% productivity savings of an Agile teams in the same study
Intermediate Agile team in Pull with incremental releases of value
Advanced team in Innovate that cuts time-to-market in 1/2 to end early after delivering 50% of the work but 80%the value
What you will see in this hypothetical modeling exercise is the true power of Agile to dramatically impact the software development teams in the organization. For a deeper understanding of what I mean by Flow, Pull and Innovate, please Jean and I’s white paper on moving to Program Pull.
Here is the summary:
Good waterfall team – ROI – 0.8
Beginning Agile team in Flow – ROI – 1.4 (1.6 factor better than good waterfall team)
Intermediate Agile team in Pull – ROI – 2.6 (3.2 factor better than good waterfall team)
Advanced Agile team in Innovate – ROI – 6.3 (7.7 factor better than good waterfall team)
Factor or Four or better – that is why there is such a rush towards Agile development. Of course, you can’t have your cake and eat it too. Moving up this maturity curve takes long-term dedication to increasing discipline and agility across the entire organization, but there are dramatic benefits if you can get on the continuous improvement path and stay there.
RallyDev.com
