Clash of Cultures

     I’ve had the opportunity to work in some interesting business environments in the last couple of years. What made them interesting was the partnerships of multiple organizations with different cultures striving towards common goals.  As an Enterprise Coach, it is part of my role to help these organizations navigate these cultural differences. These differences often exhibit themselves in obvious and sometimes mundane ways.

     In one instance, where Company A had hired Contractor B to deliver a program of projects, Company A was interested in transparency and the use of Big Visible Charts.  They believed that broadcasting the true state of affairs was a valuable communication mechanism and helped everyone understand not only our successes but where problems existed and thus where priorities could be found.  Management of Contractor B on the other hand was very concerned about displaying any information that could be construed as negative.  They were only interested in broadcasting positive news.  They feared that the broadcast of problems or perceived failures would be a drag on morale.

     Interestingly (and possibly related), these same organizations also had vastly different meeting cultures.  Company A was protective of their peoples’ time.  Meetings were scheduled only when required participants were available and there was rigour around responding to meeting invites in order to make the best use of everyone’s time.  Company B had a culture where meetings were scheduled regardless of whether required participants were already booked.  Further, people who were double or triple booked then selected the meeting they would attend in real-time.  This resulted in the meeting organizer never really knowing who would show up for the meeting until it occurred.

     These cultural difference have a marked effect on the ability of the companies to work together effectively.  So what to do?  Well, the first step is to identify the differences; accept that these differences are likely ingrained.  The second step is to refrain from trying to shift one company to the other’s culture; instead start the process of creating a new culture for the combined team.  The third step is to engage the team in a discussion of how best to address these differences for the good of the projects.  The fourth step is to establish working agreements in these areas, explicitly agreeing to review and adjust those working agreements as the team discovers new situations.  As with every working agreement, it’s important that everyone model the agreed upon behaviors and be willing to hold each other accountable to these agreements.

     While these kinds of cultural differences often occur between organizations, they also occur between different departments, groups, and teams within a single organization.  Can you recognize those differences within your organization?

Catalytic Poisoning; Coaches and Chemicals

As an agile coach, my purpose is to help people, teams, and organizations transform the way they think about their work and how they function as an organization. My role serves as a catalyst in these transformations, asking questions and inspiring clients to create their own new thinking. As with any change involving people, this does not happen overnight. These transitions can take several months to several years, and I’ve been considering how my coaching perspective is affected in these long term engagements. 

In considering this, I was reminded of another type of “catalyst” I learned about in school. In the world of chemical transformations, tiny amounts of a substance can be introduced to a reaction to increase the speed of a transformation and decrease the amount of energy required for the transformation to take place. These substances are called catalysts and they are usually unaffected by the chemical reaction taking place around them.

If you are a regular reader, you know I am a big fan of analogies from other aspects of life. This one was pretty clear to me when I happened upon it. When added to a new or already existing agile transformation, a coach’s mission is to increase the speed of a transformation and decrease the amount of overall energy required for the transformation.

However, catalysts (whether chemicals or coaches) can occasionally be inhibited, deactivated, or destroyed by secondary reactions.  Some secondary processes cover a catalyst in bi-products (see my previous post on Scaling) and inhibit the effect of the catalyst.  If that inhibiting effect is permanent, it is known as ‘poisoning’. It is important that coaches remain vigilant to recognize the risk of this, and prevent it.

During a long term engagement with a client, it is inevitable that relationships form, biases shift, and as a result, dysfunctional patterns can emerge.  As coaches we are trained to avoid these pitfalls, yet we are human. While my objectivity is often desired, it is my subjectivity that is often required in order to be an effective coach. I need to connect with people.  I need to understand them--- their fears, their motivations, their relationships with their teammates.  As time marches on, making these connections can occasionally draw me into situations where I risk losing my coaching stance and perspective.  Occasionally, my investment in the outcome of the work can become more important to me than the means to accomplish it.

In a recent example involving multiple teams, multiple companies, and multiple cultures over an 18 month period, my catalytic effect had deteriorated immensely to the risk of being poisoned.  My ability to affect the teams and organization through coaching was handicapped.  After recognizing this, I introduced a person to the transformation with different experience, different perspective, different history, and different relationships.  This had the two-fold effect of re-energizing the transformation---and opening space for another catalyst leader.  People and teams were able to better learn for themselves by being involved in new and meaningful conversations, and I too was encouraged by this new energy.  I’ve had some limited experience with paired coaching and this example has led me to believe there is likely tremendous value in utilizing that concept in large transformations.

Knowing when you, as a catalyst, have been inhibited is one of the many coaching skills necessary to ensure that your clients’ transformations continue to evolve.  I suspect the risks increase more for in-house coaches rather than consultants, but I'd like to hear what you think.

Musical Scales

Having spent years playing in musical ensembles, I’ve recently considered the similarities between 'scaling' musical groups and other types of teams.  For the listener (the customer), the value in scaling musical groups is in the increased variety of instruments and their associated interactions and dynamics. But what is the experience of scaling like for the musicians?

The most personally rewarding musical ensembles I've played in were small groups of 2-4 people, where the interaction with each other was constant and immediate. We would sit together in a configuration that allowed us all to see each other without anyone having their back to the audience. It was important that we could make eye contact with each other, breathe together, and take cues from one another. The notation on the page is only the framework to create music.  The nuances within that framework and the interpretation of that framework are where the music lives.   It was a joyful experience to anticipate each other's timing and intonation based on our history and immediate body language. We respected each other's abilities, and reveled in our mates' individual contributions to an overall musical experience. All of this took practice, time, and passion.

As a member of a symphony orchestra (50-70 people), the situation changed significantly.  Once again we all played from the same score, had similar (but not identical) aural interactions, and our visual interactions were still limited by proximity to others.  We took cues from other players in our section and from the conductor. The orchestra's seating arrangement involved 'sections' of like instruments arranged in a semi-circle around the conductor.  If you were at the front of your section, you could take cues from people at the front of other sections.  If you were at the back of your section, you took cues from the people in front of and beside you.  The quality of the music produced was defined not only by the underlying score-- but the ability of the large group of musicians to be collectively in time, dynamically aligned, and in tune with that score.   The conductor was responsible for interpreting the score emotionally and showing the orchestra the timing/dynamics necessary to express that emotion.  A significant amount of time was spent keeping an eye on the conductor, especially when there were complex musical interactions.  The conductor faced the orchestra, back to the audience, and was the unifying force behind the music.  

I love watching and listening to people who are exceptional at their craft. The highlight of orchestral work for me was experiencing soloist performances against the backdrop of the rest of the orchestra. The soloist was the star of a moment, with the orchestra playing a supporting role. If we were in perfect unison  (intonation, timing, dynamics) the resulting effect was magnificent.

While the powerful music created by orchestras can be divine, I’m still drawn to creating music in duets, trios, and quartets.  Why?  I can only surmise that for me, it’s about the symbiotic and continuous exchange with people I trust and admire. The arrangement of a symphony  orchestra is strikingly similar to many traditional organizational structures.  Can you see how and why?  Do you see similarities to the way your department, division, or company functions?  What could you and those around you do differently to shift the experience closer to that of a quartet?  Let me know -  @snowdolphin



The E-Mail Iron Triangle

In traditional project management the axes of success are usually denoted as cost, scope, and schedule.  This is often known as the 'iron triangle' as it was once believed that if one thought about it long enough (and estimated accordingly), each of these 3 axes could be fixed.  These days most sane projects are executed with an understanding that, at most, 2 axes can be fixed. 

The farther that communication is removed from face-to-face interaction the less effective that communication is.  For numerous reasons, face-to-face is better than telephone; telephone is better than texting; texting is better than email.  Co-locate where possible!  Yet, due to geographical distribution of companies, their teams, and their customers the need for this type of communication is unavoidable.  The cost of that decrease in effectiveness is rarely taken into account at the project level.  Let's consider the concept of the 'iron triangle' in the context of the use and proliferation of email communication on projects:


As projects progress, people are involved in communicating via email at different frequencies and urgencies and for different purposes.  These email volumes (some portion of the scope of our work) are always underestimated and perhaps most puzzlingly, are not considered by some to be actual 'work'; they're considered something separate.  In the Creative Economy of knowledge work,  email is unfortunately a huge part of the work.  Solving problems requires collaboration and the exchange of ideas and if we choose to have these conversations asyncronously (for whatever reason) through email then we must accept that we are working at an often reduced velocity.  In order to maintain a level of thoughtfulness in engaging in these asyncronous conversations, we each have a volume threshold beyond which the quality and timeliness of our responses will suffer.


The cost of 'keeping up' with the ever increasing volumes of email usually results in:

  • a decline in the quality / timeliness of the work,
  • an increase in the stress of the people involved,
  • the realization that the work needs to be subdivided and additional people involved, or
  • the realization that less people need to be involved in the work

As email volumes increase unhindered, the cost can only increase.


As email volume increases, the ability to respond meaningfully in a timely manner decreases.  This leads to people trying to multi-task by responding to emails amidst other communication mechanisms like meetings/ teleconferences. This in turn reduces the quality of at least one and likely all of those communication mechanisms.  Often an illusion of responding in a timely manner only creates churn due to incomplete answers or incompletely thought through responses.  People need time to communicate effectively.


So if scope increases beyond a threshold, cost and/or schedule will increase.  Most people have exceeded their threshold. That threshold can only be avoided by taking a hard loo at working communication agreements, communication conventions, and individual systems tailored to each person's working style.  Until these true costs are effectively considered on projects, the E-Mail Iron Triangle will remain fixed along all three axes and people, teams and organizations will continue to suffer the consequences.

How can you tell if your threshold for email has been exceeded?  Some symptoms are:

  • feeling the need to respond to email while doing something else
  • having to respond to an email multiple times because you didn't give it the time it deserved initially
  • hearing yourself say on any given day "I haven't caught up to my emails from yesterday yet"
  • feeling like you may have missed an email, but you're not sure because you have so many (unread or read) cluttering your inbox.

If you've experienced these symptoms,  you, your team, and your organization probably need to examine which two axes of the email iron triangle you want to anchor and which you're prepared to let float.

The Satir Interaction Model and Hand Reading in Poker.

Essentially the Satir model involves processing of communication via several steps: Intake, Meaning, Significance and Response. Teaching yourself to be disciplined about progressing through these steps helps greatly with minimizing miscommunication. The idea is that whenever you receive information (e.g. someone engages you in conversation) that you ask yourself the following questions before responding:

  • What did I just see and/or hear (sometimes, smell, taste, touch)?
    • The facts.
  • What does it mean?
    • Possible interpretations based on context.
  • How did it make me feel?
    • Significance based on my mindset
  • How should I respond?

Poker is a game of communication; telling a story based on the movement of chips in relation to the exposure of community cards.  Perhaps the Satir model is useful in reading opponents' hands in a NLHE tournament, street by street. Here's a pre-flop example:

  • What did I just see (action)?
    • A player with the table chip lead opened to 2.5x from middle position and there is a short-stacked player in the big blind with 8 big blinds remaining.  The action folds to me in the small blind.
  • What could it mean (ranges)?
    • What ranges of hands could these facts represent? Based on previous hands shown down and activity, the raiser is likely to have any: suited connector 89+, pair 22+, or A10+.  The big blind may be prone to shove all of their chips in the middle as a re-raise with any suited ace, any pair, or hands as weak as J10s
  • What is the significance to me (what are my reasonable options)?
    • I'm in the small blind with AQs and 40BB. I'm willing to call a shove from the big blind with this hand but I'll need to exercise some cautioun against the raiser. The raiser must know that the big blind is likely to shove and therefore he's either willing to fold to a shove or is willing to call a shove.  I could re-raise in hopes of isolating the big blind but I would risk playing out of position against the raiser regardless of the raiser's actions.  I could simply call the raise (potentially inducing a shove from the big blind), see what the big blind does, how the original raiser reacts and re-evaluate.
  • Based on all that, what should my response be?
    • I choose to re-raise to 6x.

On further streets, of course, the answer to the first question is additive and ideally the answer to the second question becomes more refined.

Are your opponents analyzing your responses this way?

What a game!

Agile Education

The current 'standard' education system in North America stems from recommendations made in 1892 by the 'Committee of 10', a group of 10 educators headed by the then President of Harvard, Charles Eliot. The recommendations this group made were born of their times, only two decades after the Second Industrial Revolution. The recommendations were heavily influenced by the desire to measure and maximize human performance in a manner similar to that of Taylorism on the manufacturing floor. For instance, the length of any lesson was suggested to be between 52-57 mins as that was the optimal length of time that a worker on the factory floor could reliably perform a mundane task. The goal of the 'education' system was to process as many children as possible in an effecient manner. According to Sharon Friesen:

"Taylor and Thorndike’s models of schooling also defined teacher effectiveness. Relationships between teachers and students were seen as secondary to the importance of teachers managing the class by stressing punctuality, obedience and time on task and delivering information in a timely, efficient manner according to a prescribed schedule established far beyond the classroom. Learning goals were standardized, simple and invariant."

This model might have been effective if all children were created identically, but of course we now know that people learn via different mechanisms (visually, audibly, experientially etc) and can't be treated as a known input to a prescribed process in order to generate a prescribed outcome.

Educators on the forefront of their field, like Sharon, have long understood the need to transform education into a two-way conversation between teachers and students. This transformation does not preclude the need for struggle, hard work, and determination. It simply places emphasis on ensuring that those efforts are directed through consideration of many factors including the particular learning bias of each child and the appropriate environment and level of collaboration suitable for the desired pedagogical outcomes. This can only be arrived at using a mindset of experimentation and 'inspect and adapt' rather than a prescribed 'one-size-fits-all' approach.

At the elementary school that my kids go to, the school council has started an initiative to transform the existing school library into a Learning Commons; a flexible physical and virtual environment where teachers and students collaborate, experiment, and engage in critical thinking on their own and with others. The very nature of education and learning is changing and a key person necessary to help kickstart the change is often a Teacher/Librarian who acts like an Agile Coach; helping the students AND teachers discover new ways of learning, collaborating, and solving problems in an environment and at a pace suitable for the children.


Applying the Dreyfus Learning Model to Focus Your Coaching Approach.


Over the past five years, Jaron Lambert (@jaronlambert) and I have helped several companies and dozens of teams transition to agile product development processes.  In working with the myriad of teams and people, we've learned that the best way for us to help people learn agile principles and techniques is to use the Dreyfus Skills Acquisition Model.  This model employs the usage of non-situational rules for novice practitioners.  The adherence to these rules promotes the transition to an advanced stage of learning by providing the student with a foundation for recognizing patterns and principles for application in new situations.  We've discovered (as the model predicts) that skipping this stage of learning can lead to problems absorbing and implementing the philosophies and principles of the agile manifesto.  To that end, Jaron and I have collated a set of rules we have found useful in working with Novice teams.  This is a living collation and we'd be very happy to hear what other coaches and ScrumMasters (or others) think does and does not help their teams' learning process.

Jaron and I will be speaking about the 5 stages of learning that teams traverse (not just Novice) according to the Dreyfus model as they learn agile concepts and philosophies.


  • Co-locate where ever possible, set up your teamʼs space for optimal teamwork.
  • Maximize face-to-face communication; minimize email communication within the team.
  • Minimize distractions. Remove or minimize anything that distracts the team from finishing the work that they committed to (i.e. completing all the Stories in the iteration plan). Inform the Program/Project Manager of any distractions that canʼt be removed directly.


  • The Product Manager is the “messenger of the market” and articulates why we should spend time/money on any development. Product Managers describe what the market needs in a Market Requirements Document (M.R.D) and are responsible for describing those needs in User Stories.
  • Product Managers set the business priority and help define acceptance criteria during iteration planning, answer questions from the team during the iteration, and accept stories before the end of the iteration.
  • Program/Project Managers (Scrum Masters) shepherd the process. They provide the Product Manager with all currently available information so that the Product Manager can make informed and timely decisions. Program/Project Managers answer process questions from the team.
  • Program/Project Managers facilitate removal of any/all roadblocks for the team, ensuring that someone on the team is responsible for any roadblock and keeping track of unresolved roadblocks.
  • All other team members are responsible for delivery: reliably delivering quality software solutions (i.e. implementing stories).
  • All other team members provide the Product Manager with solution options (alternative ways to implement solutions to stories) with associated costs.

Release Planning

  • Review the MRD to ensure that the entire team has an understanding of the goals of the release (i.e. Problems, the users who have them, and the situations under which they have them)
  • Write stories using the template: “As a {persona} I want to be able to {do something} so that {some goal is achieved}”, See “Writing Stories”, Chapter 2 from User Stories Applied by Mike Cohn.
  • Size all the stories in the backlog using a modified Fibonacci sequence (0,0.5,1,2,3,5,8,13,20,40,100). The size of a story represents the overall complexity, difficulty, and effort to complete the story.
  • Add up the story sizes to get the total story points in the release.

Backlog Grooming

  • Product Manager grooms the Release Backlog for their product. They keep it organized and prioritized, and add or remove stories so the Release Backlog always describes expectations for the release.
  • Team Members are responsible for sizing the stories in the release backlog, and breaking stories from the Product Manager into smaller stories that deliver value within an iteration (see “Twenty Ways to Split Stories”,

Iteration Planning

  • The Product Manager decides priorities for the team to work on in the next iteration. Team selects the stories they can complete within the iteration and decides how they work on the tasks during the iteration.
  • Only plan to work on sized stories.
  • Only plan to work on stories with agreed upon acceptance criteria (discuss and agree on the criteria, and document it during the planning). Team breaks each story into tasks and clearly defined acceptance criteria.
  • Agree on the definition of ʻdoneʼ for the team (update it whenever necessary).
  • Agree on ʻRules of Engagementʼ (update them whenever necessary).

Iteration/Sprint Execution

  • The teamʼs priority of work:
  • Keep the build/install working and testable (getting a brokenbuild/ install, and getting broken automated tests working, is always top priority).
  • Keep existing functionality working (fixing defects with functionality that worked before the current iteration is #2 priority).
  • Keep the functionality being built this iteration working (fixing defects on this iterationʼs stories is #3 priority)
  • Build out current stories (implementing new functionality is #4 priority)
  • Philosophies to continually keep in mind:
    • The fewer stories in progress the better (3 things shippable and 2 things unstarted is better than 5 things ʻalmost doneʼ).
  • The fewer tasks in progress thebetter.
  • Donʼt work on anything unless youʼve already agreed with your team mates how it will be tested and how you will know if youʼve been successful.
  • Donʼt add a new story to the current iteration mid-iteration (unless every other story is complete).
  • Donʼt split a story mid-iteration. Teams need to consistently complete the stories they committed to and establish a velocity. While they are gaining experience doing that, they will learn better habits faster by recognizing 0 points for incomplete stories and reflecting on how to better deliver on the iteration plan.

Daily Standup

  • Each member of the team updates the other team members on progress against the stories they are working on:
  • What did you accomplish yesterday (since the last standup)?
  • What do you plan to accomplish today (before the next staandup)?
  • What is getting in your way?
  • What is your latest estimate of how much time is left on your current task(s)?
  • Only people with work assigned in the iteration should speak.
  • Topics outside these questions should be addressed outside the Daily Standup.
  • Does the plan need to change as a result of the above? If so, change it now!
  • If anyone doesnʼt have enough to do today, decide what they will do at the standup.
  • All members of the team watch for “bad smells” in their scrums, and mention any apparent infractions. All members of the team work together to remove “bad smells” from their daily scrums.


  • Demonstrate only what the team accomplished (i.e. Stories the Product Manager has already accepted).
  • Record any issues, bugs, or enhancements that come up (and assign them or add them to the backlog after the demo).
  • Product Manager accepts (or decides not to accept) any remaining stories.
  • Avoid troubleshooting, discussing solutions, brainstorming ideas, exploring functionality, or anything else that takes away from clearly demonstrating the work that was completed this iteration.


  • What was the teamʼs velocity this iteration? Has the team established a consistent velocity? If so, what is it? If not, what is preventing the team from establishing a constant velocity?
  • What did we say weʼd improve / stop doing last retrospective? Did we?
  • Each member of the team has a chance to say (focus on the process, not the people):
  • What went well / what should we keep doing?
  • What could be improved / what should we stop doing / what is holding us back?
  • Team identifies the most important item(s) or issue(s) to focus on next iteration (1 or 2 items / issues is enough).
  • Change or add to “Rules of Engagement”?
  • Modify the teamʼs definition of “Done”?