Archive for kanban

Book – An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture

I am very excited that I just published my free book - An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture on InfoQ. Agile change agents will find it valuable in helping companies succeed with Agile and avoiding failure.

About the Book

Struggling with Agile? Frustrated that people don’t really get it? Tired of fighting with organizational bureaucracy? Wondering how you could have been more successful? If so, then this book is for you!

The book provides a set of essential thinking tools for understanding Agile adoption and transformation: how they differ and what you need to know to know to avoid being another statistic in the widespread adoption failure. In particular, you will learn how to use culture to work more effectively with your organization.

It is called a survival guide since so many people have found the concepts to be invaluable in understanding their experiences when working with Agile.

This book includes:

  • Identification of causes of the widespread Agile adoption failure
  • A model for understanding Agile, Kanban, and Software Craftsmanship culture
  • An outline of key adoption and transformation approaches
  • A framework to help guide when to use these these approaches with your organization
  • Real-life case studies of what has worked and what hasn’t

Electronic Version is Free

You can get a PDF or ePub version of the book for free on InfoQ. Why free? My primary goal is to change the world of work, and by making it free I can best achieve this goal. Of course, I would be really happy if you bought multiple copies of the print edition to give to your friends and clients to help them succeed as well as support my work.

Thank You

“If I have seen further, it is by standing on the shoulders of giants.” – Isaac Newton

I would like to thank Henrik Kniberg who has contributed so much open source material to the Agile community and inspired me to write a free eBook to pay it forward. I also appreciate him taking the time to write one of the forewords.

I would like to thank the attendees of workshops with early incarnations of this material – XPToronto, SoCal Lean Kanban, Agile Tour Toronto, and Agile New England. Your comments, challenges and reflections have helped in immeasurable ways.

Thanks to all the people who read my blog posts throughout 2011 on this topic and provided valuable feedback.

A big thanks to Michael Spayd for first introducing me to the Schneider culture model and for conducting a survey of Agilistas.

For sure this work would not exist but for Mike Cottemeyer’s differentiation of adoption and transformation.

Thank you to the review team for feedback: Chris Williams, Irene Kuhn, Armond Mehrabian, Krishan Mathis, Bernie Jansen, Ed Willis, Eric Willeke, Karl Scotland, Sabine Canditt, Todd Charron, Bob Sarni. Olaf Lewitz in particular deserves distinction by providing an extraordinary quantity of valuable comments, questions and challenges.

I would like to thank those who directly contributed to this work as well as reviewing: Olivier Gourment for contributing a case study; Jeff Anderson, Olaf Lewitz, Jon Stahl, and Karl Scotland and Alexei Zheglov for sharing their challenges and alternate visions in the appendix.

I would also like to thank Alistair McKinnell, Jason Little, Declan Whelan for providing feedback on the Methods & Tools article that formed a chapter in this book and to John McFadyen and Dave Snowden for feedback on the Cynefin section.

I am very appreciative of Jurgen Appelo for taking time out of his busy schedule to write a foreword.

And of course a big shout out for my daughter Scarlett who provided original art with the jigsaw puzzle and butterfly transformation drawings.

Wow! Even a small book such as this benefits from so much help.

- Michael Sahota

 

Print Friendly

Comments (5)

Lean Startup? Use Kanban! Maybe Scrum

Just finished Lean Startup Machine this past weekend and would like to connect the dots between Lean Startup and Agile.

Lean Startup: How to Learn fast about Customers, their Problems and Solutions

Lean Startup is a powerful approach for learning quickly about who your customer is and what problems they have and what solutions they value. The diagram below illustrates how it follows the scientific method: hypothesis, experiment, conclusions. As an entrepreneur or Product Manager, you keep running the cycle until you find out who your customers are (what market demographic), what their burning problem is and what solutions people will pay for.

The whole point is to learn quickly to avoid building more products that no one really cares about.

The biggest challenge with Lean Startup is not that the approach doesn’t work, but that we as human beings are so conditioned to think about products and systems that it is difficult to let go and just explore customers and their problems. Validated learning about customers is not optional.

What about Agile?

Steve Blank’s second commandment in his Manifesto for Customer Development is: “Pair Customer Development with Agile Development”. But how to make sense of this?

Agile Pre-supposes Customers and Problems are known

Agile is mindset and approach that supports building great teams and great products. It pre-supposes that there is someone who knows what needs to be built:

  • In Extreme Programming this is the onsite Customer.
  • In Scrum this is the Product Owner.
So, it’s not about whether Lean Startup is better or worse than Agile, it is more a question of what kind of environment you are working in.
N.B. Agile extensions such as Innovation Games® provide amazing support for understanding customer problems as well as building great hypotheses.

Use Kanban for Most Startups

Kanban is a powerful toolkit that supports visualization of work and is a very lightweight Agile method. It is well-suited to startup environments characterized by uncertainty and quick feedback loops. It can be used to manage what hypothesis are in progress or are being tested with live clients via A/B testing. It is  really easy to get started with a wall and sticky notes or tooling if your team is distributed (e.g. Trello or LeanKit Kanban).

Consider Scrum for Large Projects

Sometimes the Minimum Viable Product (MVP) will require a substantial amount of work to complete. In this situation, where the customer, problem and solution have been validated, then it may make sense to take advantage of Scrum as a powerful team and product container to provide focus.

We Won Lean Startup Machine Toronto

My big take-aways from Lean Startup Machine are the learnings, but it was great to be part of the winning team.

Print Friendly

Leave a Comment

What’s the first Decision? Implementing Kanban vs Scrum

Guest post by Michael DePaoli

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.

Print Friendly

Comments (2)

Kanban is Like an Oreo Cookie

Kanban is like an Oreo Cookie: Dark Crunchy Control on the outside, but Sweet White Goodness (collaboration, cultivation and craftsmanship) on the inside!

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.

Print Friendly

Leave a Comment

Agile Fits Better in Some Company Cultures than Others

At XPDays Benelux last November, Pascal Van Cauwenberghe told me that his main focus is to stop companies from doing Agile. I didn’t get it then. I think I finally understand.

(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:

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.

Print Friendly

Comments (13)

Kanban aligns with Control Culture

In my last post, I looked at how Agile Culture is about Collaboration and Cultivation.

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.

Print Friendly

Comments (20)

Home Run with Kanban 101 Workshop

John Goodsen and I set out to deliver a great one day Kanban workshop as part of Agile Tour Toronto 2010 and we hit this one out of the park.

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

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

Connections – Table Talk (p.105)

  • In pairs (or triple), decide what is more important (rank/order them): (3 min)
    • Reducing multitasking
    • Smaller batches
    • Identifying bottlenecks
  • Share with class (3 min)

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

Closing of the Day

Evaluation – Where do you stand? (p 221)

  • How comfortable to you feel with the material? Stand where you are.
    • Ready to roll — On the way — Not quite yet
    • Take 3-5 minutes for pair/triad discussion.
  • Report back to larger group
Course Feedback forms – May we quote you? (p223)

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.

Print Friendly

Leave a Comment

What’s better than Kanban?

I was reading Freddy Balle’s book The Gold Mine: A Novel of Lean Turnaround and I read something that stopped me dead in my tracks. In the book, after months of transitioning a manufacturing plant to continuous flow using Kanban, the Lean sensei asks the innocent question:

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.)

Print Friendly

Leave a Comment

3 minute video on why Scrum and Kanban are both good

At Agile Coach Camp North Carolina, I had the opportunity to give a lightning talk on Kanban on my posts:

Here it is:

You may wish to check out the other lightning talks.

Print Friendly

Leave a Comment

Kanban is a Gateway Drug

For years I have preferred Scrum as a starting place rather than XP since it is easier to adopt. One of the patterns of Fearless Change is to take small steps. Scrum is a much smaller step than XP. That’s old news. Lot’s of folks like to start with XP, that’s OK by me.

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.

Print Friendly

Comments (8)