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.

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.

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

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.

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.

I attended Israel Gat‘s session with this title at Agile 2010. I was already familiar with some of the concepts based on a private seminar given to my coaching circle by Michael Spayd.

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…

Lyssa Adkins ran a very practical session at DeepAgile that shared several tools for team formation or for tuning up existing teams. She often uses these right at the project start since team members may know very little about one another – even if they have been working together for years. Here is a run-through of three of the exercises.

Constellation – Understanding each other through motion

I love this exercise. It provides the team members as well as the coach important information about everyone on the team. It is called constellation since everyone arranges themselves around an object on the floor (in our case a roll of tape) depending how they feel about a statement such as “I like getting results”.  People align their bodies with the statement: standing beside the object signifies strong agreement while standing far away to signifies strong disagreement. It is very powerful since people are engaging their whole bodies. To learn more, there is a full write-up on Lyssa’s blog.

Journeyline – sharing our pasts

In Journeyline, each participant draws a timeline of their life with peaks, valleys and major life events. In turn, each person describes their Journeyline to the team. Team members listen and note skills or talents (on sticky notes) that stand out. These are then posted at the bottom of the Journeyline and reviewed as a team. This approach is about figuring out who the person is and what special perspectives they bring to move the project forward. When we did this, it helped the demo subject feel more positive about their talents. Nice.

Marketplace – sharing our talents

In marketplace we pretend we are a vendor in an open-air market place and decide what wares we have to sell. What are our special skills and talents that pertain to this project? We even get to create a banner to attract people. Under the table are things that are true for us, but may not directly relate to the project. The debrief is the same as Journeyline. Usually a coach will use one or the other (in the training session half of us did marketplace and half did Journeyine).

Below is my marketplace as an Agile coach.

(This is part of a series on DeepAgile 2010 Games Weekend).