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.
Sarah: “Walter, I just want to check in with you following the team demonstration and see how you are doing with the new Agile approach”
Walter: “Sarah the results were thrilling for the customer and the team. Everyone seemed engaged and the dialogue was very healthy. I see it, but it does not make sense. We are moving features through the team faster, but I had to do this with dedicated resources. I am sure this is costing me more.” Sarah: “Walter, this is totally normal. You are seeing the difference between single tasking and multi-tasking as well as optimizing the whole versus a certain roles or steps. We can do a little model to show you that this Agile approach is better, faster and cheaper.” Walter: “Well that would be very good because it is very counter-intuitive to me and all my management tools and tricks seem to run at odds with this approach.”
Sarah: “Great observation, Walter! As you told me earlier, you tend to focus on fully allocating engineers. In Agile we focus on increasing the throughput of value by optimizing the whole flow through all roles.”
Walter: “Right now I just want to stay out of the way, because I do not know how to help.”
Sarah: “Walter, let’s spend some time to get you comfortable with the impacts of batching, queuing and task switching. Once you see the math, we can talk about how to serve the team by proactively clearing impediments to smooth flow and taking some savings to invest more in them. The team will love you for this commitment.”
What benefits will you see when teams are in Flow?
As we described in “What so Great about Flow?“, we think of attaining Flow as the first step in our recommended approach to enterprise Agile adoption. For this step, we focus groups on adopting agile by the book by team; thus the impact from Flow is only incremental and isolated to the specific team. However, this does not mean the results of this effort are not noticeable and infectious.
Foremost, groups that attain Flow make changes on the way to becoming a team. When given space and dedicated members and short time box, new agile teams take three key steps:
First the collection of individual contributors comes together to plan a limited portion of their own work.
Second they set norms and limits that lead to common commitment to deliver working, tested increment.
Finally, they open their increment up to feedback and open themselves and their process up to feedback, introspection and adjustments for continuous improvement.
The benefits seen from doing this are many:
A team is forming and that makes work more fun and easier for them to manage
Work-in-process is getting reduced by focusing the work on a small increment of functionality
Testing is coming forward in the process and quality is beginning to become a team issue
Hand-offs and delays are declining by dedicating a cross-functional team to working on one thing at a time
Feedback loops are shortening in the demonstration and review process helping to prioritize the next step
Typically these benefits take one to three iterations to manifest themselves and translate into incremental productivity increases of 15%, 25% faster cycles and a reduction in downstream defects (See the Agile Impact report for more details of business improvements from Agile). Most of these teams are reporting the benefits of flow. Teams in Flow settle into a predicable pattern of delivery. They are not perfect, but you can count on them and estimate based on their historical velocity. We look for these metrics to know if a team is in the state of Flow including:
a rate of 90% or greater of Story Acceptance per Iteration on an iteration over iteration basis
an average of zero net, new Defects added to Defect list across iterations
A reduction in 1/2 of the amount of stories that are in-process across iterations
A continuous build success rate of 90% or greater for the team’s isolated code base
In general, they are starting to do things in a more lean and less wasteful way. By working together on a small batch of work with a clear definition of done, it allows the team to focus and reduce the task switching. To understand why multi-tasking and task switching do not work, you should read this post from Mark McGuinness at Lateral Action or check out Tom Demarco’sbook “Slack” and specifically pages 16-21.
However, the most important benefit is the positive feedback from the team members with regard to forming a team and working in this intuitive and social approach. It is this positive feeling that propels teams to move past Flow and into Pull. Congratulations if you have the continuous improvement snowball beginning to roll downhill at your organization. Building the trust and capabilities of the team is the most effective path to more value delivery. (See “The Scrum Picture is wrong” and the comment/link about the Lean Journey from Jason Yip.)
If your team does not find this benefit, it is clear that there is a fundamental issue that needs to be resolved. This is a great time to bring in an outside coach to help the team retrospect and give them space to form. In these situations, it is easy overlook the fact that teams need to go through the process of of forming, norming, storming as they reach toward performing. Remember this is a journey and you can not go there without building the team.
Walter: “So Sarah, I am trying to get started with this Agile stuff.” Sarah: “Great, I am here to help. What have you done so far?”
Walter: “Well, I get that we deliver something every two weeks. Agile makes us hyper-productive. And to do that, my job is to make sure everyone is busy all the time, right? We’ll get the most features if I get people to sign up for the maximum amount of work at the start of the two weeks. This is easy!”
Sarah: “Hmm, I think we better take a step back. You may be misunderstanding something about productivity. Have you ever heard about Slack or Done or Flow?”
Walter: “You mean like Slackers who just blow off work? Sure! And done means its coded, right? And Flow must have something to do with how you hide under the radar to get away with slacking how much you code. Gee, this Agile stuff doesn’t sound very productive after all!”
Sarah: “Well, Walter, I think we need to have a long talk. Coffee or martinis? Pick your poison.”
So What’s so great about Flow?
Walter is stumbling on how to get his teams started with Agile. He holds the notion that it is HIS job to make sure everyone is fully allocated, super-productive. And for him, productivity is measured in lots of features coded.
Sarah has some great advice here guided by the Lean principle of Flow. Productivity is not about filling our plates to maximum capacity during planning meetings. Rather, we encourage team members to build in “slack” in their commitments. They seek Flow of value delivery versus 100% allocation. That is: “Of our total time at work in this 2 weeks, we really only have this much time available (e.g. X hours). And because we need to allow room for discovering what we can’t know, we are only going to sign up for and commit to this much (e.g. 80% of X) work.” As for “done”, a team commits to a certain, attainable level of doneness that includes more than code: testing, documentation, code review, acceptance, etc.
When teams pull these two fundamental Agile practices together, they are invoking the Lean Principle of Flow as guidance.
This is important to understand. Agile teams paying attention to Flow do not bloat estimates in order to manage uncertainty. Nor do they use bloated estimates to artificially create 100% allocation within a timebox. Rather, teams give their most accurate estimates for the work. These estimates include what work it will take to adhere to their definition of “done”. Embedding slack in team capacity absorbs the uncertainty and doubt incumbent in new work. And, at the end of the timebox, a team truly committed to Flow checks in on how it delivered value. It then inspects and adapts how it can continue this smooth value delivery.
Sarah, gets this. New Agile teams that concentrate on Flow before moving to other rigors create a sturdy foundation for continuous improvement.
To be clear, here is what we mean by Flow.
A team commits to only taking on as much work as they can deliver consistently over time. Think of Flow as the work that can smoothly move through a pipe that delivers value to customers. If we fill the pipe to 100% capacity (as Walter is eager to do), we create at the very least turbulence. At its worst, value delivery stops entirely. When Flow becomes this turbulent, work becomes sloppy and quality suffers.
So how can you tell if your team has embraced Flow?
There are a few basic tell-tale practices you should see. Teams in Flow:
Are empowered and collaborative in decision making
Don’t over commit to what they can deliver
Declare a definition of “done” for how they make commitments to value delivery
Use a time-boxed rhythm with slack for high-quality product delivery
Engage in inspection and adaption practices that amplify their learning about team agreements, process and their definition of “done”
Most importantly, teams in Flow have a smooth reliable rhythm of delivery. They can be seen making and meeting their iteration commitments and thus have a stable iterative and incremental process. This is the key first stepping stone to Agile adoption.
Sarah will stick with Walter and his team in their adoption of these Agile practices of Flow. She’ll check in with them for a couple of iterations to help them inspect and adapt while adhering to Flow. Sarah knows there are tons of quick wins to find when teams move to true Flow. And she’ll be there to guide Walter and his team even when the roadblocks to those wins seem insurmountable.
About the Author: Jean Tabakais a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by emailor RSS.
I’ve written previously about my allergic reaction to process maturity models for Agile development. Based on 5 years of empirical feedback being a part of or watching what succeeds versus falls back, I do not believe there is a “cookbook” for Agile adoption. Of course, the question then becomes:
If there is no cookbook, then what is the best approach to succeed with my Agile adoption?
Enter the crib sheet for Flow-Pull-Innovate, which is a guidepost for the key transitions in Agile organizations based on proven bottom-up success. Because the hurdles and challenges are unique for each organization and code base, this is not a prescriptive approach. It’s a framework to thinking about how to approach Agile adoption incrementally and iteratively and is essential to establishing quick wins that create a virtuous cycle of success to keep the ball rolling.
The three phases of Agile maturity are based on work by Jim Womack in his book Lean Thinking. However, Jean and I thought it was appropriate to substitute “Innovate” for “Perfect” in Agile organizations. In IT/high-tech, it seems more about continuous innovation than the ultimate pursuit to “resource” efficiency.
Getting Over the Hump - Critical Step #3
Over the past 5 years, our focus at Rally has been getting our customer’s successful at Step 3, which we call Multi-Team Program Pull. (See our whitepaper on Leaning IT and moving to Program Pull.)
We focused on this step because at Program Pull, whole software products or major IT systems come to market typically 50% faster, according to the QSMA studies included in the Agile Impact Report. However, in this tough market and with mainstream Agile adoption, more and more organizations are adopting Agile at scale, making it important to light the path beyond Program Pull and into Organizational Pull and Organizational Innovate.
What do you think of the crib sheet for Flow-Pull-Innovate? Do you agree with the key metrics? Are these failure signs you’ve experienced? Would your organization be willing to stand behind items in the commitment needed column?
Back in 2007, Jean and I developed an evolutionary model of Agile adoption for teams and organizations seeking the benefits of “scaling software agility.” We presented talks on this at the Agile 2007 and Agile 2008 conferences. We call it Flow-Pull-Innovate based on the Toyota Lean principles of Flow-Pull-Perfect.
Productivity gains in Agile development teams come conceptually from eliminating waste. Just getting to the first step of Agile maturity can lead to 10 to 20% productivity increases. We want you to be successful taking the first step, and there is a ton of opportunity in most software development shops. According to Tom and Mary Poppendieck, most software development organizations are only spending 6% of their time doing value-added tasks. The other time is wasted in these categories:
Partially done work (coding features that get removed from release)
Extra processes (elaborating requirements that do not get built)
Extra features (features that are rarely used – more on this in another post)
Waiting (requirements, designs, feedback, builds, other teams, larger organization, customer)
Motion (walking over to interrupt folks for a build or status)
Defect (internal or external)
Agile works to systematically address these wastes as you mature. In our white paper on moving to Program Pull, Jean and I characterize the steps, roadblocks and benefits found at each step in the Flow-Pull-Innovate maturation process.
On the move to Flow, we find that teams can increase their productivity working as a dedicated team on a single project for a two-week iteration cycle. The reduction in waiting, motion, task switching and partially done work can be dramatic based on your level of multi-tasking. We even find some teams in Flow reduce their extra features, partially done work and defects, but those productivity gains tend to be more associated with the move to Agile Pull.
According to the QSM Associates study of Agile development teams, you can expect to save 16% (the green dots on the graph). Of course the teams that worked with Rally’s products and services achieved on average 25% productivity gains (the red dots on the graph).
(The graph on the right from QSMA shows a white line of the average productivity of different sized projects in their 7,500+ project database. Between the blue dotted lines is the area 1 standard deviation from the norm. You can see only one Agile project was less productive that the average and 7 Agile projects of the total 29 were outside 1 standard deviation. Thus 1/4 of these Agile projects were in the top 16% of all projects ever benchmarked by QSMA – see Michael Mah’s blog for more discussion – OptimalFriction)
Of course, you cannot have your cake and eat it at the same time. That is, you cannot just start running two-week iterations and become 20% more productive overnight, but with a combination of services and Agile project management solutions, you can attain these results in months. That is why we recommend a two-pronged approach to cutting costs with Agile and Rally offers a Guarenteed Succes program that combines our world class services and application in a discounted bundle for new and existing customers. Get started by getting your teams to Flow and the savings can come fast.
RallyDev.com
