This is a reading guide to the series that explores corporate culture and how that has a direct impact (sometimes very negative) on efforts towards Agile adoption and transformation. It is a must-read for every Agile Change Agent. The role of Kanban is quite distinct and is discussed throughout.

Below is a quick synopsis of each post in the series on Organizational Culture, Adoption and Transformation so you it’s easy to find the most relevant content for you and start with what interests you most.

Best Summary

• 1 Hour Video explanation (and slides) of Culture; adoption/transformation meta-framework – If you really want to understand, I encourage you to watch the video. Don’t have time – just scan the presentation slides. Agile New England, Dec. 2011
• How to Make Your Culture Work with Agile, Kanban & Software Craftsmanship – Method and Tools Article, Dec. 2011
• eBook – In progress. Drop me a note if you want to be a reviewer.

Juicy Conclusions

Read about why it matters to you:

• Agile Fits Better in Some Company Cultures than Others – Agile is a great way of thinking about software development but that doesn’t mean it fits in with all company cultures. Ditto for Kanban.
• Agile – The Good, the Bad and the Ugly – Links cultural issues central to challenges faced with Agile Adoption and Transition. What you need to know as a change agent.

Change Agent’s Toolkit

Read this to expand your toolkit:

• A Tour of Agile Adoption and Transformation Models – Review of Agile Adoption and Transformation models. What tools people in the community are using and where they are effective.
• Ways to Make Progress with Culture Gaps – Different ways for coaches to make progress with Agile when it doesn’t fit with the culture.
• Agile – The Good, the Bad and the Ugly – See final section – “The Good”

Reading Order from Beginning to End

If you want to understand the logic in linear order, start here:

1. How to Make Your Culture Work (Schneider) – Explanation of Schneider culture model that is used as a base for the analysis and provides a framework for discourse.
2. Agile is about Collaboration and Cultivation Culture – Analysis of Agile/Scrum core values and associated culture.
3. Kanban aligns with Control Culture – Analysis of Kanban cultural bias.
4. Software Craftsmanship promotes Competence Culture – Analysis of Craftsmanship cultural bias.
5. Agile Fits Better in Some Company Cultures than Others – Juicy conclusions that points to a different way for coaches to approach and engage with clients.
6. A Tour of Agile Adoption and Transformation Models – Review of Agile Adoption and Transformation models. What tools people in the community are using and where they are effective.
7. Ways to Make Progress with Culture Gaps – Different ways for coaches to make progress with Agile when it doesn’t fit with the culture.
8. Agile – The Good, the Bad and the Ugly – Links cultural issues central to challenges faced with Agile Adoption and Transition. See also slides.

Post-Script

Here are some more bits and pieces around culture:

• DOI? Cultural Shotgun – Culture analysis of the Declaration of Interdependence
• Culture of “Good To Great” Companies and Why it Matters – Why competence matters.
• Workshop Results on Culture - Walk-through of workshop results supporting cultural claims.

In light of Agile adoption failures and awareness of cultural challenges, the purpose of this post is to review current models that are applied to adopting Agile and transforming with Agile at organizations. Worthy background reading is Mike Cottmeyer’s post on Untangling Adoption and Transformation.

It is worth noting that there is no widespread agreement about how to undertake agile adoption.

A Tour of Adoption and Transformation Models

Below a number of models for Agile adoption and organizational transformation are shown.

The horizontal scale shows on the one hand techniques aimed at adopting practices while at the other we have wholesale organizational change or transformation. I am increasingly thinking that for many situations, adoption is not sufficient and transformation is required but not wanted.

Models above the line are not specific to Agile, while those below the line come from an Agile context.

What follows is a short overview of each model or approach.

Becoming Agile in an Imperfect World

Smith and Sidky’s book – Becoming Agile in an Imperfect World – provides a lot of practical advice on adopting Agile. They begin with the premise that many companies are not ready for Agile along a variety of dimensions: Tools, Culture, Project Management, Software Process and Physical Environment. They advocate becoming as Agile as possible given the current environmental limitations and most important needs. Although they recognize that Agile represents a shift in thinking, they support an incremental practices-oriented adoption. Some might characterize this as Doing Agile rather than Being Agile.

Containers, Differences and Exchanges

The CDE (Containers, Differences, Exchanges) model provides a way to understand the context of a team or group and highlights ways of effecting change. For example, a team is a very powerful container for organizing staff. So is the physical environment. Esther Derby has a good post and presentation/video on Shifting Organizational Patterns. CDE is also discussed in Succeeding with Agile (p. 221-227).

Fearless Change

Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising provides lots of great techniques and tips for adopting new ideas within an organization. The image at the right shows the different patterns (click for hi-res version). I have used these patterns and they are very helpful for adopting new ideas. I have included them on the adoption end of the scale as they are not about organizational transformation although they can support it.

Inspect and Adapt with Enterprise Transition Team

In The Enterprise and Scrum Ken Schwaber outlines his view of how to transition an organization to Scrum:

1. Create an Enterprise Transition Team – a Scrum team responsible for the transition of the organization to Scrum.
2. Apply Scrum to an enterprise backlog of transition items.
3. Inspect and adapt to success.

Although there are a number of caveats – Scrum requires a new Enterprise Culture and huge effort to execute – the book is light on specifics.

Another example of this approach is written by Schwaber, Leffingwell and Smits: A CIO’s Playbook for Adopting the Scrum Method of Achieving Software Agility.

To my knowledge, this is the most commonly applied pattern within the community.

ADAPT

ADAPT is Mike Cohn’s model for adoption of Scrum:

• Awareness that the current process is not delivering acceptable results.
• Desire to adopt Scrum as a way to address current problems.
• Ability to succeed with Scrum.
• Promotion of Scrum through sharing experiences so that we remember and others can see our successes.
• Transfer of the implications of using Scrum throughout the company.

This feels like a light-weight version of the Kotter Model (below) for organizational change so I have placed it further along the scale towards transformation. See Chapter 2 of Mike Cohn’s Succeeding with Agile or presentation for further details.

Cynefin Framework

The Cynefin is a decision-making framework that recognizes the causal differences that exist between system types and proposes new approaches to decision-making in complex social environments. Some argue that the Cynefin model (Snowden) can be used for Agile adoption. Others use it as an analysis model to create a shared understanding of the type of environment so that the most appropriate approach can be selected. For example, for complex environments, cause and effect are so closely linked that an adaptive approach to change is appropriate.

Here is a short video explanation of the Cynefin model as well as a presentation on why it matters. i.e. the case for Complex Adaptive Systems.

The implications for Agile adoption/transformation is clear – many organizational environments are complex and adoption approach needs to reflect this. In this case, we will not know what actions will lead to the desired result. We can only take one and sense the result. This state implies less clarity than one would have with an Enterprise transition backlog.

Kotter Model for Organizational Change

Truly transforming an organization requires consistent sustained energy over a long period of time. Kotter outlines the 8 steps that need to happen in sequence to establish real and lasting change. These have been observed in a variety of companies over the last 20 years:

1. Establish a Sense of Urgency
2. Forming a powerful Guiding Coalition
3. Creating a Vision
4. Communicating the Vision
5. Empowering Others to Act on the Vision
6. Planning for and Creating Short-Term Wins
7. Consolidating Improvements and Producing Still More Change
8. Institutionalizing New Approaches

The model is simple, yet powerful and challenging. For example, the criteria put forth for a sense of urgency is that “75% of management genuinely believe that the status quo is unacceptable”. Another key aspect is that it is not possible to make real progress unless each step is completed in order.

To learn more please see: short article or Leading Change book. Also, Olivier Lafontan has Card Decks for Implementing Kotter (very cool) if you are interested in using this model.

Marshall Model of Organisational Evolution

At the very extreme edge of transformation, the Marshall Model defines a paradigm for organization evolution and growth. It can be viewed as an organizational maturity model where effectiveness increases with maturity. It reminds me of Spiral Dynamics Model that posits a theory of human development.

Conclusions

There are a lot of different ideas floating around of how to adopt and transform to Agile. The models presented here, together with your client’s situation, puts you in a better place to choose a suitable model to help them find success. Perhaps even asking yourself the question “Am I adopting Agile or transforming to Agile?” may help you find a happier path or terminate a painful one.

What’s Missing?

I am sure that you (the reader) have a story to tell about an approach to Agile Adoption or Organizational Transformation through Agile. Please comment and share.

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:

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

The rise of anemic Scrum was noted to dismay among the Agile community and in particular by “Uncle Bob” Martin who coined the fifth Agile manifesto value of Craftsmanship over Crap(Execution). This gave rise to the much needed community of Software Craftsmanship.

Looking at an earlier post - Agile is about Collaboration and Cultivation Culture – it is clear that the Agile community was not addressing the Competence Culture. And we as a community of software professionals do need to pay attention to competence and technical excellence for long term sustainability. Uncle Bob recently wrote a good article on this topic – The Land that Scrum Forgot.

Cultural View of the Manifesto for Software Craftsmanship

The diagram below relates parts of the craftsmanship manifesto to cultures identified in the Schneider cultural model.

Not surprisingly, there is a big focus on Competence Culture. This culture is focussed achieving success by being the best. And craftsmanship is about being the best software developers possible.

The value of productive partnerships stands alone. I am curious as to what purpose this supports as it is not directly related to writing quality software. I am wondering whether:

• this exists as a bridge to the Agile community?
• is related to the strong XP practice of pairing?
• is intended to appeal to the need for mentorship?

So what?

Craftsmanship needs to exist to make sure that the technical practices promoted by XP don’t get lost in fluffy bunny Agile culture. Things like: refactor mercilessly, do the simplest thing that could possibly work, TDD, ATDD, continuous integration, continuous deployment, shared code ownership, clean code, etc.

The existence of a separate movement to support competence culture that exists outside of the Agile, supports the assessment of Agile culture as focussed on Collaboration and Cultivation.

Caveats

I think that Craftsmanship is a good thing. I also believe it is complementary to Agile.

This is post is about understanding how Craftsmanship fits with Agile and company culture.

What is Agile Culture? In an earlier post, I talked about Schneider’s model for understanding culture – How to make your culture work. (Hint: this post will make more sense if you read the earlier post.)

What do we discover about Agile culture when we apply the Schneider model? How does this inform us about approaching Agile adoption or transformation?

Michael Spayd has done the community a great service by undertaking a culture survey of Agilistas. The results are very striking: it shows that the two dominant cultures are collaboration and cultivation, with competence a distant third and control barely even on the map. So one can say clearly, Agile is all about the people. Interestingly, the survey included Scrum, XP, as well as Lean-Kanban folks. So thanks, Michael!

What does the Agile Manifesto and Principles informs us about Cultural?

I took a look at all the values and principles and plotted the ones that show a cultural bias on the following chart:

The chart illustrates  the same finding as Michael Spayd’s survey – Agile is all about the people. It is aligned with a company cultures of collaboration or cultivation.

An Explanation Please!

Some of you may be curious as to how I arrived at my result.

For each value or principle, I analyzed how well it was aligned with each of the cultures. If there was a strong affinity, I associated it with that culture. For example, Customer Collaboration was very easy since it has the word collaboration in it and identifies success through people working together.

Some items seemed to be orthogonal to culture. For example, working software, didn’t really seem to suggest one culture over another. Well, it may weakly suggest competence culture, but only a bit.

Other items were a best guess based on my current understanding. It would be great to have a workshop to see if we can come up with an even better model.

I could go through each item and argue why I placed or chose to omit it. But that’s pretty boring and wouldn’t really change the result much.

So, there you have it: Agile is about people!

So what?

Consider for a moment what happens when foreign cultural elements are injected into an organization. Well, it’s like the human body: unless the body can be fooled into accepting the foreign tissue, it will be rejected.

More on what this means for Agile adoption and transformation in upcoming posts.

Agile has crossed the chasm and things are different over here. Really different. And not so good.

It feels like we have landed at Dieppe (Canadian/British Military WW2 Failure). The bad news is that there is significant failure successfully adopting Agile. The good news is that we can recognize it and learn from it.

Technology Adoption and The Chasm

Michael Moore’s crossing the chasm introduces the notion of phases in technology adoption.

Consider the diagram below:

As a community, we have experienced a lot of success working with Innovators, Early Adpoters. Here we are working with visionaries that have a high tolerance for change and provide strong management support.

The problem is that we are now working with the Early Majority. The recent announcement of PMI certification is pretty strong evidence of entering the early majority.

So what’s the problem? “75% or organizations do not get the benefits they expect.” – Ken Schwaber. These are pragmatists. Their goals are to avoid risk and change as little as possible. They want to buy some off-the-shelf Agile so they can get the benefits, with the least effort. They have heard good things about Agile and want the Agile Tooth Fairy to come in wave a magic wand.

Agile is not an out-of-the-box solution. I don’t there will ever be one, but we can build more around Agile to change the world of work.

We all have a pretty good idea (more or less) what Agile is. The problem is that the whole product is only partly defined by our community. For example, tools that do not scale to Enterprise needs. Some level of agreement about when to use Agile and when not to. Sorry, that I can’t paint a clear picture of what the whole product looks – still figuring this out. (If you have one, let me know).

There are for sure many talented coaches who have something that approaches whole product thinking. We need to do better communicating and growing our ideas around this or we will fail as a community.

External Related Blog Posts

• Agile’s Second Chasm (and how we fell in)
• Agile is Here to Stay… Now What?
• Agile @ 10 Years – Elephants in the Room

Epilog (Apr. 12, 2011)

I am thinking more and more that Agile is so tightly bundled with modern management culture that this is less about the whole product and more about organization evolution.

Just had my first article posted to Scrum Alliance website. (Click link to check it out). I originally wrote this 9 months ago to support my Certified Scrum Coach application, but that process finished first.

Here is the abstract:

Scrum contains a set of practices distinct from XP that are intended to enhance project safety. The Scrum framework is simple and intentionally incomplete. Scrum expects that teams will add in practices that are relevant to their specific context. For example, there is wide recognition within the Scrum community that XP engineering practices need to be added to Scrum to create sustainable software projects. So, Scrum and XP together is a good starting point.

At XPDays Benelux I was fortunate to accidentally attended Agile Community Vision with StrategicPlay by Olaf Lewitz and Yves Hanoulle. If you are curious how you can use Lego to achieve strategic results, read on.

Ideal Team Member

One of the exercises was for each participant to build an identical turtle from a kit using instructions. We were told that the turtle represented an ideal member of a team and ask to add one part that represented what we thought was important. In my case, I picked a flower (see photo on right). For me the flower stands for individualism that is needed to have a strong team. I am sad I did not video record my explanation or take notes since I can’t re-access the profound insight I had when created my model.

You can also see all the turtles that the group created in the photo below. Even though some us picked the same Lego piece to add, the location and narration of the meanings were quite different. So, in this case you really need to hear the debrief to understand the meaning.

Agile Community Vision

The next exercise was for each of us to build our vision of the Agile Community using a large collection of Lego without talking. After building, we took turns debriefing. You can see the different models that people created below. Mine is the one in the foreground with a tall antenna and bridges to other communities. As I went through the exercise, I found that I was learning things about myself. This can be a very revealing exercise.

Check out a very short video where I explain my model.

Shared Agile Community Vision

In the next exercise we built a shared vision that incorporated ideas from the individually created models. As we did this we clarified and enriched our metaphors. It was a very interesting social/team exercise to work through the ideas.

There was only one rule to guide us: everyone had to feel comfortable with the model. If there was a part that did not work for them, we were to remove it.

Here is a short video where we took turns explaining parts of the model:

Wow! Agile Games Day Workshop! What a great way to end Agile Tour Toronto! Here’s what people had to say about Gino Marckx and my workshop:

• “Fun, Energizing, Informative I liked adjustments during the day to our plan – nice! Facilitators checked in to see where group was at (all day – during games too)” – Alistair McKinnell, Agile Coach
• “Engaging, Fun, Self-discovery High energy personalities in delivery; not sitting all day and mixing the groups up” – Colin Bowern, Technology Coach and Solutions Architect
• “Fun, Engaging, Educational I liked the split from play to how to facilitate; the mixture of games and game lengths; the flexibility to adapt to the needs of the group” – Sarah, Coach
• “Engaging, Fun, Insightful I liked talking about different roles; it was laid back and fun; good energy and inspiring. – Nick Faulkner, Team Lead
• “Fun, Insightful, Amazing We adjusted as we moved through the day and we took longer where there was value” – Alex Aitken, Consultant

Mistake #1 – Too many games

It all started a week before when participants met online to play the Innovation Games® Buy A Feature game to select what games we would play. Gino Marckx and I provided a menu of 20+ games. The prices? We use the number of minutes for a session. It was a public game, so feel free to check out our results or run your own games.

The first mistake was that we had too high a budget when playing Buy A Feature. I had worked out the approximate number of minutes and decided to budget 30% of the time so we would be a little under the total time. Problem was I forgot to change the default from 40% so we ended up with too many minutes.

How would you recover?

Gino and I used dot voting to prioritize the games selected so that we would play the most important ones first. Here is what we came up with. (Note: no votes for team games since we did this right at the start before the voting). The games are listed from top to bottom based on “ROI” (dots/time).

Mistake #2 – Budgeted times off by 40%

As the day progressed, it became clear that the time budgets we had allocated were too low. Way too low.

How do we know this? Well, having just finished a Kanban workshop, I created a control chart to track actual time in comparison to budget time. See photo below.

Root causes?

1. When we were having valuable debriefs we kept going, rather than keep to our timebox.
2. After each game was finished, we had a game facilitation discussion to talk about when you might play the game, setup needed, tips and tricks, etc. People found this very valuable.
3. The games are tiring and people needed more breaks than planned.
4. The two big games – Business Value Game (BVG) and Yellow Brick Road really benefit from having 2 hours instead of 1.5 hours. This is consistent with my earlier playings of BVG.
5. Some of the games we were less familiar with.

The Games We Played

Here is a quick review of the games we played and when to use them. The full list of games is here.

Team Formation and Energizing

Constellations (30 min) is used to share team perspectives around values and beliefs. The information allows team members to help each other through challenge areas and provide hooks to talk about problems. We also played Tribes as a warmup but don’t have a description for this.

MarketPlace (60+ min) is used to inform team members about skills help by one another. This helps on many levels. First, you know where people are coming from. Second, you learn what skills and capabilities they bring to the project. Third, you may notice other things about them that can help the project succeed. Fourth, appreciating skills creates a powerful connection between the team members.

Play these games with all team members when you start working with them.

Product Backlog Management

Business Value Game (90+ min) helps players understand different views of value and think about the challenges of modeling business value. In particular it gets players to think about how to keep customers happy and balance technical improvements with feature delivery. It also hammers home the importance of reviewing acceptance criteria. Play this game with Product Managers/Owners and everyone involved in backlog prioritization.

Emergent Design

Marshmallow Challenge (45 min) helps players understand the benefits of incremental and evolutionary design. Teams that balance planning with experiments and learning about the problem domain do a lot better than teams that do a lot of upfront planning and no learning. Play this game to shift away from Big Design Up Front. This is suitable for all team members and especially important for Product Managers/Owners and Architects/Designers.

Developing Coaching Skills

Yellow Brick Road: Fresh Insights through peer coaching (90+ min) allows people to develop their coaching and observation skills so that they can help one another. A side effect of the game is that people can solve real problems. This is a good game to play with ScrumMasters, internal coaches and managers.

Value of working in small batches

Penny Game (30 min) is a fast and effective demonstration of how customer responsiveness can be improved through delivery of work in small batch sizes. It also highlights the importance of identifying organizational impediments to productivity and selecting high priority stories first to maximize ROI. I like to play the game when introducing teams to Agile and Lean/Kanban – especially to motivate user stories vs. big requirements.

Concurrent Projects delay delivery

Name Game (10 min) shows how delivering to multiple client projects at a time will give the perception of responsiveness but will lengthen delivery times. Great game to play with managers, project managers and Product Managers/Owners.

Multi-tasking reduces effectiveness

Multi-tasking (10 min) is a quick pen and paper exercise that illustrates how multi-tasking reduces the effectiveness for an individual. Play it with managers and team members that think working on multiple projects or multiple tasks is a good idea.

Some photos from our day of play

Business Value Game

Marshmallow Challenge and Marketplace

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