This video is pretty long, but the best bits for me were in the first 12 minutes. Some great parts:

• Letter using Remember the Future for remembering why the student will have been wildly successful (3:43)
• You can give an “A” grade to anyone – to transform the relationship (4:25)
• “How Fascinating!” as a celebration of errors to maintain an available state (10:53)

Also, Benjamin Zander has a book with this title (haven’t read it yet).

No related posts.

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

A very practical and relevant question is: how does it fit in with Agile? If we are going to the bother of undergoing a transformation, let’s at least make sure we have the right ingredients.

I make the case that an effective transformation needs to bring elements from outside of these systems in order to be great.

First, let’s consider where Good to Great principles align with cultural analysis.

Schneider Model of Good to Great

The following analysis is based on the Schneider Culture Model.

We see that the clear focus is on Cultivation and Competence cultures.

Competence. Good to Great speaks of companies that seek to be the best in the world. They get the right people on the bus. And the wrong people off the bus. Hire the best and the rest will take care of itself. Companies such as Netflix have taken this to an extreme with amazing results. Built on the people is a culture of focus and discipline to be the best.

Cultivation. Good to Great companies have a vision of being the best in something and the passion to pursue it. A sustained commitment to the vision allows such companies to work relentless year by year to build towards success. There is also a strong sense of the need to develop people, perhaps in different roles.

One of the phrases I love most from the book is: “Confront the brutal facts … yet never loose faith.” The idea here is to make visible and deal with all problems – no matter how discouraging or painful – and keep faith that success will come eventually. Faith in success is the key ingredient that allows one to examine the really tough issues.

Level 5 leadership is about unassuming leaders who build great teams around them.

Why it Matters

Agile, even XP, is completely silent on competence as an important trait in company culture. In fact, this notion is at odds with singing kumbaya and holding hands. But as Ken Schwaber said, “If you have a crappy to team, at the end of a sprint, you will get an increment of crap.” And a lot of companies I see are filled with mediocrity. So, if we really want to help build great companies, we need to stretch beyond Agile. Yup, this means firing people. “The most common failure of great managers is not firing people soon enough.”

An even more interesting notion is that the quality of a transformation is limited by the leadership. So, who’s in charge and what they want to accomplish becomes really important. To quote one CTO who wanted the benefits of Agile but was not interested in personal change: “I didn’t hire you to give me feedback on how I treat my staff.”

So, it’s a great book and helps me see the larger business context.

Or Not?

Please check out some of the great comments below – like how some of these companies crashed and burned after the book was written.

Related posts:

1. How to Make Your Culture Work (Schneider) (This post is part 1 of Agile Culture Series –...
2. Agile is about Collaboration and Cultivation Culture What is Agile Culture? In an earlier post, I talked...
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.

In this post, we’ll review some common strategies for handling cultural mismatches.

The Big Pitcure

I almost posted this blog without a summary picture and I am glad I stopped myself. Once I made the drawing below, I saw there are two main strategies (adoption and transformation) and sub-strategies within them. This post will walk you through the options and when to use them.

Work with your Culture

This is the recommendation from Schneider’s book – How to make your Culture work: work with your culture; don’t fight it. I’ll outline some ways below.

#1 Build on Your Current Culture

The idea here is pick an approach that is compatible with the current culture of the organization.

One way I interpret the diagram on the right (see related article) is a prescription of what aspects of Agile/Lean to focus on based on company culture:

• Control Culture? –> Lead with Kanban
• Competence Culture –> Lead with Craftsmanship
• Collaboration or Cultivation Culture –> Lead with aspects of Agile that align with the organizations culture. e.g. Vision and Retrospectives for Cultivation Culture.

Kanban? But it’s not Agile!

Some really smart Agile folks think than Kanban is a sell-out: That it is a watered down, inferior form of Agile that doesn’t measure up. (I mostly disagree with this sentiment).

This reminds me of a story Craig Larman shared at a local user group meeting: “My favourite process is Unified Process. I do it in a very Agile way. But, I never recommend it to my clients since it is too easily interpreted as Waterfall and they won’t get the benefits. Instead I use an explicit Agile method. It’s not my preference, but I use it and it is better for my clients.” So, even if you like Scrum better, your client may thank you for helping them with Kanban.

So my view on the topic is that it doesn’t really matter which is better in some abstract sense. All that matters is what will help this client the most and make peoples lives better. See Kanban is a Gateway Drug for more thoughts on this topic.

#2 Work with Compatible Cultures

Consider the diagram to the right. It shows that although the easiest option is to work with the existing dominant culture (in this case Control) it is possible to explore adjacent cultures since these are more aligned. Choice of direction may be guided by what the secondary non-dominant culture of the organization is. The idea here is to work with the culture, and not go against  the grain.

#3 Create Adapters between Different Cultures

Another way to handle this problem of cultural mismatch is to create barriers between different cultures. The idea here is to create a firewall or facade that lets the different cultural groups function with little friction.

Israel Gat talks about creating a boundary object such as automated tests and technical debt measurements to avoid conflict between development (collaboration) and operations (control). For this, and more on ways that you can make your culture work see Israel Gat’s presentation and conference session.

Joseph Pelrine has a great video on InfoQ – Dealing with the Organizational Challenges of Agile where he talks through some models including using people as buffers (Scrum Master) to translate between internal team culture and the external culture of the team. This is an amazing video that goes into much more theoretical arguments well beyond culture, so consider watching the full one hour.

One successful pattern I have seen is for Agile teams to create Gantt charts to keep the PMO happy. In some companies, this is necessary waste. It brings no value to the organization, but it is currently required for the organization to function. Of course you could stick to your principles and refuse, however, you may find that when the organizational antibodies that attack, they are stronger than your management support. Or it’s not worth the fight at this time.

Change your Culture

OK, this is hard. Really hard. Culture is singularly persistent in organizations.

What about Visionary Leadership?

Conventional wisdom is that innovative companies with visionary leadership can also transform to Agile. This is why you will often hear Agile coaches say that you need strong management support. But is this true?

Some people might point to the success of a company like SalesForce.com as an example of how they were able to change their culture. On the other hand, in the article Six Common Mistakes that Salesforce didn’t make, it is stated that “The leadership saw the transformation not so much as a wholly new approach, but rather a return to the firm’s core values.” So, this would then not be an example.

I vaguely recall a similar story about getting back to the original culture with Yahoo, who also did and enterprise transition to Scrum.

If you have any case studies, please feel free to share via email or comments.

Welcome back, Kotter

No, I’m not talking about the TV show. I’m talking about the Kotter model of organizational change. It recognizes the eight stages that are seen in successful organizational change efforts.

Some coaches in the Agile community are aware of the Kotter model and a few are actively using it to help companies achieve an Agile mindset. I am not aware of any case studies where a company has undergone transformation to Agile using this model (but we don’t do a good job as a community collecting case studies so it is unclear how heavily to weight this).

So, if you are thinking about changing company culture, this is pretty much the only clear transition model available. And yes, if you are a coach, you do need to understand organizational development to do your job well. Sad, but true.

So what?

As a coach, you need to know what game you are playing. Are you helping management transform their organization or are you helping them adopt a culturally-fit approach? Hopefully, you are not rolling the dice with inspect and adapt.

Related posts:

1. Kanban aligns with Control Culture In my last post, I looked at how Agile Culture...
2. How to Make Your Culture Work (Schneider) (This post is part 1 of Agile Culture Series –...
3. Agile is about Collaboration and Cultivation Culture What is Agile Culture? In an earlier post, I talked...

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

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.

Related posts:

1. How to Make Your Culture Work (Schneider) (This post is part 1 of Agile Culture Series –...
2. Post-Chasm Agile Blues Agile has crossed the chasm and things are different over...
3. Shhh! Agile Failures (in the large) Agile failure is a sensitive topic but one that we...

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

I finally had time to read The Reengineering Alternative: A plan for making your current culture work by William Schneider. If you are at all concerned about successful Agile adoption, then this is a must-read.

Before reading the book, I already had a pretty good idea about it thanks to a private seminar with Michael Spayd and a conference session by Israel Gat – How we do things around here in order to succeed. But when reading the book, I crystallized my thinking about a whole number of disparate experiences and open questions.

In this post, I will cover the key concepts of the book. Analysis and connections to Agile will follow in subsequent posts.

Schneider Culture Model

In the diagram below, there are four cultures depicted – one in each quadrant. Each has a NAME, a “short quote”, a picture, and some words the characterize that quadrant. As you read through this, you may will get a sense of where your company is.

There are also two axis that indicate where the focus or an organization is:

1. Horizontal: People Oriented (Personal) vs. Company Oriented (Impersonal)
2. Vertical: Reality Oriented (Actuality) vs. Possibility Oriented

This provides an a way to see relationships between the cultures. For example, Control culture is more compatible with Collaboration or Competence cultures than with Cultivation culture.

Key points about culture

• Management guru Peter Drucker says “Culture … is singularly persistent … In fact, changing behaviour works only if it is based on the existing ‘culture’”
• No one culture type is better than another. The book details the strengths and weaknesses of each so check it out if you are curious to learn more.
• Depending on the type of work, one type of culture may be a better fit.
• Companies typically have a dominant culture with aspects from other cultures. This is fine as long as those aspects serve the dominant culture.
• Different departments or groups may have different cultures. (e.g. development vs. operations)
• Differences can lead to conflict.

How to make Culture work

The starting point for making culture work is understanding it. The book describes a survey you can give to staff (Example Survey from Book in Survey Monkey – N.B. You can’t see the results). The book suggests using this as a starting point for culture workshops with a diverse group of staff.

There are several suggestions for using cultural information to guide decision-making:

1. Evaluate key problems in the context of culture. Sometimes changes are needed to bring the culture into alignment with the core culture.
2. Sometimes the culture is too extreme (e.g. too much cultivation without any controls – or vice versa!), and elements from other cultures are needed to bring it back into balance.
3. Consider the possibility of creating creating interfaces/adapters/facades to support mismatches between departments or groups.

Well, that’s the book in a nutshell. More to follow on how this relates to Agile.

Related posts:

1. Shhh! Agile Failures (in the large) Agile failure is a sensitive topic but one that we...
2. Red Pill, Blue Pill & Ugly Transition Realities A critical predictor of success I have seen in Agile...
3. Post-Chasm Agile Blues Agile has crossed the chasm and things are different over...

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

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.

Related posts:

1. Shhh! Agile Failures (in the large) Agile failure is a sensitive topic but one that we...
2. 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.

Let’s face it, if you are running Scrum well, then there will be all sorts of ugly problems that pop out of the woodwork: decaying technical infrastructure, technical debt, people struggling with new roles, people no longer able to hide behind the fog of waterfall, and conflicts between groups.

Scrum is designed to make impediments visible. Management’s role is to act on these and remove them to support the team. Usually, these problems have been around for a while.

Consider the Matrix

What does the film The Matrix have to tell us about this situation?

Neo is Seeking

Neo is not satisfied with the status quo. He knows that something is wrong but is not sure what it is.

Morpheus is the Guide

Morpheus acts as a guide. He tells Neo that everything is not as it seems. Neo must decide if how badly he wants to know the truth.

Neo must choose

Morpheus gives Neo a choice:

• Red Pill: Learn the truth about and discover how deep the rabbit hole goes.
• Blue Pill: Remain in his current reality and wake up the next morning believing whatever he wishes.

What does have to do with Agile?

• The Matrix = Organizational Reality
• Neo = Transition Sponsor
• Morpheus = Agile Coach

When a client swallows the red pill, they choose to confront the red flags and problems. Just like the recommendation from one of my favourite management books - Good to Great. In this situation, it is possible to do what Michael Spayd call Strategic Agile. This is represents the fundamental shift in behaviours and values called for by Agile. It leads to a learning organization that is on the road to joy in work and high performance.

When a client swallows the blue pill, the we are in a Tactical Agile situation. In this case, it might be possible to find some local wins with morale, teamwork and productivity. It might also lead to organizational backlash that reverts Agile. Sadly, what frequently happens is that  the Agile champions and advocates who want to create a better company leave to find a place with a future.

My Stories

In every transition, I have seen red pill, blue pill situations. Some of them are minor decisions. Some are major like investment in repaying technical debt and investing in improving productivity.

At one company, the top 10 contributing staff built a value stream showing that a “5 day project” actually took 9 months to complete and the $5k revenue was offset by $25k of costs. More than half of the executives (CEO, CTO, VP Sales, VP Engineering, CFO) discounted the data. It was a blue pill moment.

At another company, we talked about the science of motivation, and they took the red pill. The yearly bonus went bye-bye. On the other hand they later took the blue pill on technical debt. Can’t win ‘em all.

One of the biggest problems I have seen is that the sponsor of the Agile transition is often the author of the problems. For example, the VP Engineering who was on watch when technical debt was piling up – it’s hard for him to get excited about sharing this problem with superiors and asking for patience while he fixes it.

If you are a coach, it’s your job to know where the boundaries are and help clients cross them when they are willing.

Your turn!

Next time you are working with someone, think about their reality and how they see the situation. Then find ways to share yours. At the end of the day, it is their choice.

The Video

Take a few minutes to watch this video clip from the movie. It’s fun and will help your brain remember this post.

Related posts:

1. Shhh! Agile Failures (in the large) Agile failure is a sensitive topic but one that we...

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

Survey Results

I ran a quick fist of five survey with first eight coaches and then with twelve as people. The question was:

“How many (percent) of your Agile transitions have been successful? Zero for none. Five for all.”

The results confirmed what I have suspected and experienced: a single one, lot’s of twos and threes, and one four. No zeros or fives.

It was noted that one problem with the survey is that Agile (Lean?) is a direction (dream of perfection) and not a destination.

Good news, Bad news

Consider the visual note below (start in the top left).

Agile in the small is fine

When probing about what was working and what wasn’t it became clear that agile in the small was working well. With single teams and smaller companies, people were pretty happy with the results. Even isolated teams at large companies seemed to find success when the teams wanted to go Agile. The principle that applies here is: Go where the energy is.

Agile in the large needs attention

Now that Agile has crossed the chasm and many more transitions are initiated by the early majority we are seeing more of “me too” Agile adoption. Some of the support found in earlier transitions are now missing:

1. Strong management support
2. Sense of urgency (Critical for Kotter model)
3. Notion that: failure is not an option

Case studies MIA

One key need of early majority is case studies. We as a community do not do a good job sharing success stories and an even worse job sharing failures. This makes it hard to learn and improve.

Agile in the Large

Craig Larman and Bas Vodde have written a great book - Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum – on how to make Agile work in the large. This is a good start and paints a clear vision for alternatives for making Agile work.

We also have Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising. This is nice, but not nearly enough to get to a playbook for Agile adoption.

I believe that we as a community need focus more attention on models, patterns and guides for Agile transition and adoption. Lot’s of open territory here.

It’s about people. Duh.

One of the challenges with Agile in the large is that many people really don’t care about Agile and don’t want to change. Yeah, this happens with small teams too, but I find it is manageable there. When dealing with hundreds and thousands of people the problem gets amplified.

I thank Christine Neidhardt for reminding me that organizational change is about people. The way to change an organization is one person at a time.

Addendum

Subsequent to publishing this, I found this great post that I strongly recommend: Agile’s Second Chasm (and how we fell in)

No related posts.

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

Starting with the top right and going clockwise, I’ll make a few comments…

There is no Agile toothfairy to make all the problems go away. A lot of companies only look to Agile when things are really broken. It took your company a long time to create the mess that it is in and it is going to take a while to get out of it. Agile will help and provides a direction and it is going to take hard work. Sorry.

When you have no automated tests in place, acceptance tests add much more value than unit tests. So, consider starting here before learning about JUnit, refactoring and working with Legacy Code.

TDD (Test Driven Design) is a huge technical contribution to the community that stands independent of Agile. It is an amazingly powerful design practice.

We were reminded that a flat org structure with a technical career ladder is essential in a well-functioning organization. It is important to keep your top technical people in technical roles.

Dave has seen the rise of what he calls blue collar programming. So many environments are filled with legacy code. Programmers have to sweat out meaningless design-dead code just to make things work.

No related posts.

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

For me organizational change is a hot topic since I keep running into it when adopting Agile practices.

Schneider Model for understanding Culture

Israel introduced the Schneider model for understanding company culture. The idea is to use survey questions to categorize the dominant culture into one of four categories (see below).

Many companies we work with are a control culture while Agile is all about Collaboration and Cultivation and (sadly) to a lesser extent about Competence.

You Can’t Change Culture

“Culture is singularly persistent” – Drucker. It is estimated that it can take 10 years for the culture to change in a large company.

Consider the chart in the middle of the diagram below. If we want to be successful in adopting Agile (or anything else) it is essential to focus on harmony with the existing culture. Pushing for different culture will lead to conflict.

Agile adoption leads to conflict

This is an observation rather than a pejorative. With the best intentions Agile will accidentally lead to conflict within the organization. The example given was of different cultural biases within different departments.

For example, Competence in Engineering and Control in Operations. In addition to differing departmental objectives, us vs. them thinking will also create tension. Israel talked about the Outmodel that describes perceptual bias that we create when we have limited information about a situation. The idea being that by design of our organization, there will be conflict between the groups and Agile adoption only makes this worse by perturbing the system.

One idea proposed by Israel is to create a boundary object between different groups. In the case of Development (Engineering) and Operations, one could use Technical debt as a way of measuring the quality of the code to satisfy ops that the code was production worthy. So a  boundary object that has a quantitative measure is very helpful. IMHO, there is much more than this required to ensure that code is production-worthy, but that’s another story.

What I learned about myself

In one exercise we broke into the four groups to explore the different cultures. I went to Control because I have struggled with a few organizations with this culture. What I discovered is that I personally have strong control tendencies. I also discovered that control can save a lot of time by decisive action. The trick is knowing when to apply it. I experimented with my workshop later in the conference and was happy to see that very strong direction around group logistics and exercise structure can make a session more coherent and valuable.

And now for something completely different

Clarke Ching shared a great 6 min animated video on organizational change by Eli Goldratt. It is related so, I’ll throw it in here…

No related posts.

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