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.

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.

(This post is part 1 of Agile Culture Series – see Reading Guide for more).

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.

This is a guest blog post co-written with Christine Neidhardt based on a session at Play4Agile conference on coaching with photos. The session was based on an experiment with the Points of You – Coaching Game (German link) to find ways to use the photo cards with a group or team. And we did.

Here is a photo of some of the cards scattered across the floor.

The one-on-one Coaching Game

The CoachingGame is used as a creative support material for coaches and offers a variety of possibilities to work with. We started with a public one-on-one coaching session to show one practical case how to use  the CoachingGame and we were lucky that we had a person volunteering. We selected between four topics the game is offering:

• Relationships
• Winning and Loosing
• Mindfulness
• History, Present, Future

We decided for History, Present, Future. In a fishbowl arrangement, the practice client selected an important question for the session and we asked: what happened in the past, what happens now, what is the potential. The client selected three photos that represented each of the topics.

The cards do offer a photo, a word and a symbol. There is a companion book that explains each of the photos and provide stories to deepen the examination of the topic and offer additional perspectives and insights. There are five types of symbols (way, act, be, problems, opportunities) to which each of the cards belongs. Information which gives additional orientation. This together with an explanation cloth to position the cards to the questions, makes it all very comfortable to work with.

Creating Team Games

After the Coaching demo we formed two working groups to figure out how to use these cards in a group or team. This was the goal of the session and we came up with some pretty cool results in just 15 minutes.

Photo Reflection Game

One group created the photo reflection. We selected the Play4agile conference as topic and asked us, what was the past, present and what is the potential in the future. Everybody selected up to three  cards. Everybody presented his cards to the group. The foto helped to explain and gave new ideas.

Past (first column): We as Coaches who love games realized we were often hold by old habits, felt alone with our ideas and had to endure through tough times in the day to day work.

Present (second column): The conference was the place to be at least authentic and to find people with the same mindset, where there occured many oppurtunities and creativity is in full bloom.

Future (third column): Putting the new games into action was one of our goals, as well as being open to all that is possible. All could happen. Lots of people from the conference would like to see games as a usual tool being used like techniques as Scrum. Some of the people found it possible that they would find their vocation in introducing games and the results of the conference in their daily work.

If we would have had more time, we could have gone deeper, could have agreed on some cards which would be the most important or we could have made as well the second part of the shared vision game.

The Shared Vision Game

The second group used the time to focus just on the last question: the future.

1. Select the topic. In our case it was our future expectations of the conference. It could be for your team or project.
2. Have everyone pick a card that resonates with them.
3. Confirm that everyone is comfortable with the other cards. Some people did not understand the card I picked and after explaining what it meant for me, they were OK with it. I even changed the photo by covering up part to make our shared understanding of the meaning clearer.
4. Create a statement that incorporates all of the ideas.

Our Shared Vision Statement

We somewhat unexpectedly created a powerful shared vision of our expectations of the conference.

What Can We Still Learn?

You see, there are unlimited possibilites and maybe we have now lots of more ideas how to work with these visual tools.

Why does this work?

Michael, as an NLP practitioner, is a big believer in the power of the unconscious mind. And photos tap right into our unconscious minds so we get to what is really important.

In the book How Customers Think, there is a great technique where customers bring in a photo that they feel relates to the product. When they explain the relationship they give very rich information about what is important and why. It’s a great book full of research on brains and decision-making.

The game with photos works the same way. We allow people’s unconscious to get in the game by selecting a photo. This is much deeper than just visual expression or writing on a sticky note.

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.

A critical predictor of success I have seen in Agile transitions is how people define reality.

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.

Agile failure is a sensitive topic but one that we as a community need to talk about in order to build a brighter future together. In this post, I will share some observations that came out of an informal session that took place over an extended coffee-break session at Play4Agile conference.

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)

Gerry Weinberg’s Secrets of Consulting is a well-recognized classic for anyone helping organizations and people. It is a delightfully written treasure trove of tips, tricks, and hard-won wisdom. My goal is to draw a mind-map of each book that I read, however, this book is too filled with gems of knowledge to compress into a single page.

What I have in today’s post is a series of mind-maps that cherry-pick the best bits. I include a lot of quotations from the book together with page numbers, so these may be used as a reading guide. (I’ll let you in on a secret: it’s actually for me to be able to look up the good bits quickly).

Consider your attitude as a Coach or Consultant

Client Relationship is Built on Trust

Understand You Client

Change is Harder than you Think

Coach the System and Beware the Fate of Consultants

Reality Check to Avoid Problems

Give away your Best Ideas and How to Price your Services

Hidden Agenda Game

Ironically, the one item that didn’t fit with any of the others is the Hidden Agenda Game (p.116). It is a simulation that helps people start seeing other people’s behaviours and intentions.

After reading Roger Brown’s post – Adventures in Accelerated Learning – I decided I had better read Sharon Bowman’s Training From the Back of the Room. The book has really helped me improve my training style and I look forward to taking Sharon’s training to get an immersive experience. I am writing about this now since I had a chance to put it into practice on my Kanban 101 training. In this post, I want to share the key concepts from the book.

The visual note below is an example of an exercise I did when reading the book – “1 minute concept review”. It took me considerably longer than a minute, but now I have a clear picture of what the book is about. I knew some of this stuff when I was a teaching assistant in university where I was part of a program to help improve teaching skills. Sharon’s stuff is way more powerful.

The 4 C’s

1. Connections
2. Concepts
3. Concrete Practice
4. Conclusions

Sharon uses the 4 C’sas a way to think about training and to help learners engage with new information. The book contains links back to research on learning and neurology.

The reason I really like the book is that it is chock full of example exercises. These are easy to understand and apply. So it is theory + practice.

4MAT

The 4 C’s are a simplified model of the 4MAT system of learning that I learned a while back but found difficult to apply effectively. So if you are looking for a richer model consider this one.

What Sharon’s book brings to the table is a model that is easy to understand and apply. And great examples. So give it a read if you do any training.

Agile requires a lot of skills. Agile Coaching demands even more.

Each individual coach has specific talents, capabilities and passions. Similarly, superheroes have their special powers, areas of strength and weaknesses.

Sure the Thing can break down a door, but Mr. Fantastic can slip his arm under and open it without damage or noise. Of course, if “It’s clobberin’ time!” then maybe the Thing is the right superhero for that situation.

Superheroes work in challenging environments and often succeed by working with a team that has complementary talents. The same is true for Agile coaches – we can achieve more in a team with other coaches.

In this post, I want to touch on the skills needed for Agile coaching and how this relates to learning and working in coaching teams.

Skills needed for Agile

The Agile Skills Project is the best reference that I know of. It breaks Agile skills into 7 competence areas: Business Value, Collaboration, Confidence, Product, Self Improvement, Supportive Culture, Technical Excellence. Each competence area has lots of definition (see MindMap). Phew! There’s a lot to know.

I just finished my self-assessment (see below) and probably the biggest challenge for me is around how to rate myself around areas for which I am an expert, however, not currently practising (in last 30 days). So if you want to be strict, just shrink the figure – shape won’t change much.

Overall, I am not 100% happy with this model. On the other hand there is not better.

Agile Skills for Coaches

Agile coaches are a mix of consultant, trainer, and coach. I do not know of a list of skills, so I’ll take a stab at it below. The astute reader will be aware that each of these is a profession in its own right.

Consultant

• Systems Thinking
• Root cause analysis
• Client relationship management
• Consultative Selling
• Organizational Change Management
• Navigating politics

Trainer

• Participatory training – including Agile Games, Training from the back of the room
• Speaking skills
• Presentation software such as PowerPoint. Including graphics/photos/diagrams
• Lesson and content preparation

Coach

• Listening
• Effective Questions
• Giving feedback
• Group collaboration

• Retrospectives
• Personality models such as Myers Briggs
• Psychology models such as NLP (NeuroLingusticProgramming)

To quote Socrates – “The more you know, the more you realize you know nothing.”

Every Agile coach will have some areas of skills that they have capability and vast areas with limited skills. This is why it is best to work in teams. As well, all the usual reasons for pairing apply here too.

Coaching Circle – the Fantastic Four

Gerry Kirk created a coaching circle for some of us in Ontario to meet online weekly to share ideas, provide support, debug situations and learn together. Other participants are Declan Whelan and Jason Little (photo from Agile Coach Camp Waterloo). For me the sessions have highlighted that we come from different backgrounds and have different skills and interests. When working together, it is these very differences that add value and allow the sum to be much greater than the parts.

Gerry ran an open space workshop on this at Scrum Gathering in Orlando if you would like to learn more - Agile Coaching Circles aka How to avoid feeling isolated and unsupported as a coach [Open Space]

Post Script: Selena Delesie and Susan Davis recently joined the coaching circle. Bye bye, Fantastic Four. Hello, X-Men.

Pair Coaching and Coaching Teams

In 2009, I had the fortune of pair-training with Yves Hanoulle at Agile Tour Toronto. He introduced me to the concept of PairCoaching for which I am very grateful as it has profoundly influenced how I work. (For example, I had two pair-authored sessions at Agile 2010).

Earlier this year, I was on a coaching team with Alistair McKinnell and Jason Little. I learned a lot see different skills sets in action. Alistair is a world-class technical architect, consummate consultant and above all test-infected. Although he can do much more than this, he is a great technical coach -someone to sit with developers and testers to get in the trenches and show people how to do quality work. Although Jason knows some technical practices and has worked with Agile Management, he worked with team process (Scrum, Kanban) as well as team dynamics. Me? I love getting people to work together. On this engagement, I worked mostly at the team level and the organizational/inter-departmental level. We did a lot of pairing and the quality of our work was way higher.

I know some XP Coaches who think that all Agile coaches need to be developers in order to assist the team in technical practices. For me, it is more important that all relevant skills are manifested in a coaching team and not in a given coach.

So be a superhero and work in a coaching team. If you are a coach, work this in to your engagement model. If you are a client, ask for this and join the team as internal coach – you are welcome for sure.