If your development team or manufacturing team is considering moving to using Kanban vs. Agile Scrum, one of the biggest decisions is choosing the right agile development methods for the job. Let’s discuss the realities of implementing Kanban and some of the fundamentals that hold back both Kanban and Scrum implementations.

On paper, Kanban is certainly easier to kick-start from a change management perspective because you can leave current roles and processes largely intact; you just need to get commitment from the business to adhere to three basic principles:

1. Provide a high degree of visibility/transparency of the state of all work queued and in progress
2. Establish and respect WIP(work in progress) limits in the value flow
3. Commit to execution in a ‘pull-based’ manner from the prioritized work queue

Yeah, just get commitment and practice of these three things… Much easier said than done in my experience because they are frequently outside the circle of influence of those driving the change to implementing Kanban!

Usually it isn’t that the agile software teams are unable to execute under Scrum; the fundamental issue is that the business isn’t willing to accept a “pull-based” execution model (required for Kanban and Scrum).

Businesses continue to make irresponsible commitments to customers and investors. This only perpetuates crystal-ball thinking, fixed-date, fixed-scope and fixed-cost projects. It’s the classic sales-driven model we see all too often where the sales arm doesn’t respect the capability of its product development group to produce predictable value for the customer in a timely manner, and with an agreed-upon level of quality. After all, quality is a business decision.

This irresponsible action ends up causing organizations to be unpredictable in their delivery, have lower quality, and to burn out their teams. These outcomes in turn destroy brands, ruin company reputations on Wall Street, increase the percentage of each investor dollar serving up technical debt (in lieu of adding new value to products), and causes instability in the organization’s systems due to turnover.

Bottom line, if an organization can’t make the commitment to respect their product development system’s proven delivery capability at the current level, neither Kanban nor Scrum will provide predictability. But even in the face of this dysfunction, agile methodologies like Kanban and Scrum can still provide faster learning to teams, which allows them to test their assumptions faster and provide more value to their customers by delivering what they actually need.

In conclusion, I leave you with this advice: ignore the myths and hype about Kanban. Before you can make any decisions on the Kanban vs Scrum debate, you must first evaluate:

• Your organization’s product development and sales culture,
• The nature of the demand for service from product development,
• The competency of your organization to plan and execute change, and
• The degree to which you’re willing to face the truth

Only then can you choose the best agile software tool for the job.

Michael DePaoli Bio

Over his 26 years in IT, Michael DePaoli’s experienced has included serving in different
traditional roles in highly respected companies. The roles have included analyst, software
engineer, quality engineer, development manager, project manager, Director of Engineering,
VP of R&D, CTO and Consultant in companies, such as American Express, Sprint, Deloitte
Consulting, Sapient, Knowledgepoint, Adobe Systems, AOL, NetApp and VersionOne. Michael
works as an agile / lean coach and product consultant with the VersionOne services group.

Related posts:

1. Kanban aligns with Control Culture In my last post, I looked at how Agile Culture...
2. Kanban is Like an Oreo Cookie Kanban is like an Oreo Cookie: Dark Crunchy Control on...
3. Agile Fits Better in Some Company Cultures than Others At XPDays Benelux last November, Pascal Van Cauwenberghe told me...

Related posts brought to you by Yet Another Related Posts Plugin.

Dark Crunchy Control

In an earlier post, I wrote about how Kanban aligns with Control Culture and argued that for companies with Control Culture it will likely be a better approach than Scrum or XP. (Of course there are alternatives described in Ways to Make Progress with Culture Gaps.)

Needless to say I got a lot of flak over this. No one in our community wants to be associated with Control Culture. Agile has been pushing so hard against this for so long that people have an emotional response akin to when a Jedi Knight goes over to the Dark Side of the Force.

Nobody wants their baby called ugly. And linking to Control culture feels like just that.

OREO COOKIE to the rescue!

Yes, on the outside Kanban aligns with Control culture. It is made of dark, rigid, structured material. Looks like Control, tastes like control. Fits in with local culture and practices.

Sweet White Goodness

But wait! What’s this inside the cookie? The inside is a bright, soft, flexible material. Why this is all the Agile/Systems Thinking/Lean goodness!

These cookies are not just crunchy, they can filled with collaboration, cultivation and craftsmanship. OMG, Kanban is a Gateway Drug to Agile.

There are many documented cases of teams spontaneously collaborating, of learning, and of noticing problems and investing in technical practices. This has been my experience as well.

There is nothing wrong with starting from control as long as we never loose sight of our mission of helping companies and bringing joy to work.

Rejoice in the Differences!

So, from my perspective, calling Kanban Control on the outside is a huge complement and competitive advantage. Kanban allows many companies that could never undertake Scrum to use Kanban to make a positive difference.

Many thanks to various commentators (Paul Boos, Paul Beckford, Michael Spayd, and Sabine Canditt) and to Jeff Anderson for sparking this concept over lunch.

Related posts:

1. Kanban aligns with Control Culture In my last post, I looked at how Agile Culture...
2. Agile Fits Better in Some Company Cultures than Others At XPDays Benelux last November, Pascal Van Cauwenberghe told me...
3. Agile Culture, Adoption, & Transformation Reading Guide This is a reading guide to the series that explores...

Related posts brought to you by Yet Another Related Posts Plugin.

(Note: Post used to be named “Problems with Agile? Check your Culture!”)

Agile (and Kanban) from the perspective of Culture

Rather than seeing Agile as universally great (aka silver bullet), I see it as a tool or philosophy that fits better in some company cultures than others.

Consider the following diagram illustrating how Agile, Kanban, and Craftsmanship principles align with various cultures. If, for example, you are working with a competence culture, then a good starting place is to focus on software craftsmanship and help them get really good at building quality software. Similarly, Kanban for control cultures and Agile for collaboration and cultivation cultures.

For this to make any sense, it would be advisable for you to check out the four related posts on culture:

1. How to Make Your Culture Work (Schneider Model)
2. Agile is about Collaboration and Cultivation Culture
3. Kanban aligns with Control Culture
4. Software Craftsmanship promotes Competence Culture

(Seriously, go read them now. They are pretty short and have great diagrams).

Rock my World

For me this is pretty profound. Cultural analysis provides me a tool for understanding clients and helping them where they are right now.

When a client contacts me as a coach, it is because they want help. What they think they need is a better process to help them with their problems. They do not want to change their company culture – they just want results. Well, depending on their company culture Agile may fit or it may not. Perhaps this is why many of us are experiencing the Post-Chasm Agile Blues.

A lot of my clients ask for Scrum and I am actively working on helping them understand where they are and where Scrum will take them. This is part of stepping away from one-size-fits-all. Scrum isn’t a good idea for every company.  That should be obvious, but true believers may want to burn me at the stake.

What this means is that we may need to act more like a consultant than an Agile Coach. Some people have already been doing this to greater or lesser extents. A good example is David Hussman, who shares his thoughts on Coaching and Producing Value.

Empirical data that Culture is the Problem

Courtesy of VersionOne, I would like to share a snippet of the results of their 2010 Agile Survey. Thank you, VersionOne! (The image below is copyright VersionOne and is reproduced without permission).

Note that:

• The #1 problem (51%) is cultural change
• The #2 problem (40%) is resistance to change

Maybe it’s time we start paying attention to Culture!

Cargo Cult and Being Agile

There is the famous line from Ken Schwaber about 75% of companies not getting the expected benefits from Scrum that they expect. Why?

Scrum is a disruptive, transforming technology and most companies don’t want to be disrupted or have some Agile consultant tell them how they need to change their core culture to succeed. (But we don’t actually tell them, we just create lots of conflict and may even create a mess). So what is the result? Lot’s of Cargo Cult behaviour where people Do Scrum (or worse Scrum, But) without Living Scrum or Being Agile.

What do I mean by be Agile? Fortunately, some great minds in our community have written on this topic, so you can go read their stuff:

• Tobias Mayer has written about how Scrum is much more about changing the way we think than it is a process. For example, two good posts on this are The People’s Scrum and Scrum: An New Way of Thinking. I think what he is getting at is the essence of being Agile.
• Bob Hartman has a great presentation on this topic – Doing Agile isn’t the same as being Agile.
• Mike Cottmeyer wrote a series of great posts on how companies are adopting Agile, not transforming to Agile.

Post-Agile? Agile-AND?

What I am saying aligns with the concept of becoming Post-Agile. If it means using tools beyond Agile, then I am there and so are most people practicing Agile.

I like the term Agile-AND. I still like and use Agile. AND I use other tools and approaches depending on the situation.

We as a community need to get better at communicating when and where to use Agile and more importantly when not to.

Related posts:

1. Agile is about Collaboration and Cultivation Culture What is Agile Culture? In an earlier post, I talked...
2. Kanban aligns with Control Culture In my last post, I looked at how Agile Culture...
3. Software Craftsmanship promotes Competence Culture The rise of anemic Scrum was noted to dismay among...

Related posts brought to you by Yet Another Related Posts Plugin.

Today, I am likely to ruffle a lot of feathers by observing that Kanban aligns well with control culture. So, if you are a consultant or coach, this is good news since Agile plays badly to companies that have a control culture. I view todays post as a refinement of my earlier post – Scrum or Kanban? Yes! – where I argued that some situations are a better fit for Kanban vs. Scrum.

What is Kanban?

I am choosing a recent and very insightful post by David Anderson – The Principles of the Kanban Method as the basis for my analysis. David is arguable the leader of the Kanban/Software school with his book, very active mailing list and Lean Software and Systems Consortium.

Kanban is mostly aligned with Control Culture

The cultural model used in the analysis below is based on the work of William Schneider. If you are not familiar with it, I suggest you check out my summary of his book. The terms I am using have a very precise meaning, so please refer to this for additional context.

As you can see the main focus is about Control. Control cultures live and breathe policies and process. Kanban has this in spades. Control culture is also about creating a clear and orderly structure for managing the company which is exactly what Kanban is about.

Control cultures focus on the company/system (vs. people) and current state (vs. future state). This is a good description for the starting place for Kanban.

What is really interesting from a cultural analysis perspective is the principle: Improve collaboratively using models and scientific method. These two concepts really don’t mix, so how can this work? According to Schneider, other cultural elements can be present as long as they support the core culture. So having some people focus is fine as long as it supports controlling the work.

The notion of evolutionary or controlled change can also be compatible with a control culture if it is used to maintain the existing organizational structure and hierarchy.

Wait a minute, Kanban is Agile, isn’t it?

Mike Burrow’s made a very influential post: Learning together: Kanban and the Twelve Principles of Agile Software. In it he argues that Kanban satisfies each of the Agile Principles. Now that I am studying this from the perspective of culture, I see that this is in fact not the case or perhaps only weakly the case.

Agile and Kanban for sure share a common community, and many practices may be cross-adopted, however, they are fundamentally promoting different perspectives. Agile is first about people and Kanban is first about the system. Yes, people are important in Kanban too, but this is secondary to the system.

So is Kanban Agile? I used to think so. I don’t any more.

Addendum

This is an update to this post where I need to clarify a few things:

1. I love Kanban and think it is great. We need more of it in the world.
2. I am not saying people who use Kanban are control freaks or prefer command and control. What I am saying is that if your client has a control culture, then Kanban is a good thing to talk to them about (vs. Scrum).
3. I am not saying Kanban is incompatible with Agile. I am saying that they are complementary perspectives.

So What?

You may be burning with curiosity about what the implications of this are. Stay tuned for upcoming posts.

Related posts:

1. Agile is about Collaboration and Cultivation Culture What is Agile Culture? In an earlier post, I talked...
2. How to Make Your Culture Work (Schneider) (This post is part 1 of Agile Culture Series –...
3. Red Pill, Blue Pill & Ugly Transition Realities A critical predictor of success I have seen in Agile...

Related posts brought to you by Yet Another Related Posts Plugin.

What People had to Say about the Training

• “Engaging, Practical, Fundamental I liked the flow from concepts to games/practice; moved quickly; teamwork/collaborative learning.” – Alex Zeldin, Manager Planning and Business Solutions
• “Wicked, Awesome, Cool I liked the games and the Q&A session at the end.” – Trevor Ramoutar, Project Manager
• “Interactive, Informative, Practical A very lively workshop – you could feel the experience the trainers have! Thanks a lot.” – Hedi Buchner, ScrumMaster and coach.

Recipe for Success

• Two coaches who have different experiences, points of view and are ready to experiment (See: Agile Coaches are like Superheroes)
• A strong desire to apply Training from the Back of the Room (See: Thought you were a good trainer? Guess Again!)
• A group of motivated learners

How I trained from the back of the room and loved it

If you are unfamiliar with this book, please check out my book review and mindmaps.

Below are the exercises we use from the book. Most of what we used was from Connections and Conclusions. We played lot’s of games for concrete practice. We had limited use of slides (see bottom of page) to illustrate concepts. My overall take is that we covered less and did it with much higher quality.

Introduction

Connections – “PostIt/What’s in it for me?” (p.99)

• Hand draw poster with “What’s in it for me?”
• As people arrive, have them write WIIFM on PostIts with their Name.

Connections – “Think then Ink” (p.98) + Knowledge line

• “Think about what you already know about this topic.  Write three facts on an index card.
• Form a line from most to least knowledgable about Kanban/Agile to least.
• Share your facts on index card with your neighbours.
• In a line from least to most, everyone can share one thing with the class

Lean: Waste & Value Stream Mapping

Connections – Card Carousel (p.106) – 2 minutes

• Pass around cards with topics written on them: Value Stream Mapping, Muri, Mura, Muda, Value, Toyota Production System, Waste

Oops – forgot to integrate cards when reviewing material.

Idea – Would have been good to have people make notes during waste discussion of what they have seen in their workplace and then make a top 10 list.

Flow Basics

Conclusions – same exercise as at the beginning. Wow, what great discussion. People really remember this part.

Closing of the Day

Get Kanban Game

The whole workshop was organized around playing Russell Healy’s GetKanban Game in the afternoon. The morning was all about layering in basic lean concepts followed by a quick intro to Kanban – just enough to play the game. Afterwards, we covered various topics through parking lot (Q&A).

I give the game a thumbs up and will definitely use it again. One important note that John and I clued into is that the game presupposes that people understand breaking work into small batches/tickets and limiting work in process. That’s why we played several games in the morning to establish the basics of flow. See slides for specifics.

Slides

Eating our own dog food

Yes, John and I eat our own dog food. We used Kanban to visualize the work we needed to do to prepare for the workshop. Below is a snapshot of our Kanban board we created in google docs. See Henrik Kniberg’s sample.

Thanks

John and I would like to thank everyone who shared material with us to prepare our slides – notablly Henrik Kniberg, Mary Poppendieck and Jon Stahl.

I would also like to thank Russell Healy for discussions on rule variants of the Kanban Game.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Question: What is better than Kanban?

To answer this, one must think of the purpose of a Kanban card. In manufacturing, a Kanban card is a replenishment indicator for a particular part or assembly. In software, we use Kanban to represent a piece of work such as an MMF or user story. Either way, a Kanban card represents WIP (work in process). More Kanban cards means more WIP.

What’s our goal? To increase throughput and reduce latency while minimizing operating expense. Reducing WIP is very helpful. Would be great if we could reduce our WIP as far as possible. How to do that? One-piece flow. So we reduce Kanban cards to zero.

Answer: No Kanban!

If there is no Kanban and you are very Lean, then you have single-piece flow. The holy grail of Lean process. This is what Arlo Belshee and Jim Shore attempted to explained in their LSSC10 session Enough Kanban! Use XP for Single-piece flow. (Please check it out if you haven’t seen it before.) I say attempted because I didn’t get it – I needed to read the above question and answer for the pin to drop.

So what? If you are in an environment where you can do Scrum or XP, then go do so! If not, then Kanban is great place to start. Or finish – in the case of an elite Scrum/XP team that doesn’t need iterations as training wheels.

Kanban in Context

I love Kanban – it is a great tool. One thing that I keep in mind is that Kanban is only a small part of the Lean context in which it lives. Kenji Hiranabe has a great article on InfoQ on this - Kanban Applied to Software Development: from Agile to Lean Please check out Figure 11 TPS Concept Structure: it illustrates that Kanban is just one part of the Lean system of thinking. Of course, it is a great starting place for learning it.

(Aside: I almost had a blog post without images or drawings. Then I decided I needed to do something – anything to make my point more vivid. Please excuse my primitive drawing skills.)

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

• Scrum or Kanban? YES! and
• Kanban is a Gateway Drug

Here it is:

You may wish to check out the other lightning talks.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Probably a good thing to clarify at the start is that Kanban is part of the Agile family of processes.

Kanban is easier to adopt than Scrum

Way easier. Like almost trivial. Let’s see: no process change, no role change, no change in team structure. Just make the work visible. Wow! There is so much value in just making the work visible. Lot’s of little problems can be fixed and voila – productivity and cycle time gains.

Kanban uses Kaizen = Continuous Improvement

Kaizen is about continuous improvement. Define a standard process and then start improving. Take smalls steps. Get everyone involved. Kanban is a standardized process flow that starts with the existing process.

In the graph of performance vs time on the left, kaizen will result in improvements that will asymptotically approach the limit within that paradigm.

As teams mature, they may go beyond this into the place where Scrum/XP start…

Scrum/XP is Kaikaku = Radical Overhaul

Kaikaku is discontinuous improvement. It is about a revolution in the way things are done. It is also called Breakthrough Kaizen.

Can anyone say Scrum or eXtreme Programming? It changes work groups, job titles, roles, and project basics. For contexts where Scrum is a good fit, it is a high-value, high-cost game-changing move. James Shore has a great post on Kaizen and Kaikaku where he argues that this is a better starting place if you want a high-performance team.

What does this look like in terms of performance? See graph below. It looks like Virginia Satir’s Change Model.

In the Lean world, companies use both kaizen and kaikaku depending on circumstances as they are complementary approaches.

Why a gateway drug?

The gateway drug theory states that softer drugs (Kanban) can lead to harder drugs (Scrum, XP). This is a great metaphor because this theory has been proven as well as dis-proven. To quote David Anderson “we are only beginning to understand the differences between Scrum and Kanban”.

Do I believe in the the theory? I’m not sure that I care – as long as people are working to improve their work environments at a pace that works for them, that is good enough for me. For me, any Agile is good –  it does not need to be one particular style.

Let’s face it – lot’s of organizations are ready for a radical overhaul. For companies like these, Kanban is a great place to start. Getting off the sofa and going for a marathon may not be a good idea. For some it may be better to start by jogging around the block.

Other Perspectives

David Anderson has a contemporaneous post (go read it, it’s good) supporting the notion that Kanban is primarily focussed on continuous evolution until the organization has enough maturity for more radical changes.

Ken Schwaber is continuing the drum beat that Scrum is the one true path.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.