If You Want To Stop Becoming More Agile, Start Focusing on Standards

Change is difficult.  Improving is difficult.   Many managers see improvement and change as temporary things that cause confusion and misdirection until a steady state is achieved and the improvement is completed. They approach change with a model of “unfreeze – change – refreeze”.  Only when things are frozen again – a standard established, a checklist and diagram provided – will workers know what to do, and will it be safe to “roll out” changes to others.

This way of thinking and approach to change may drastically limit the success of your journey to becoming an agile organization.

Some indications that your organization treats change as a temporary state to be controlled, and may need help moving to a more appropriate theory of change for today’s complex environment:

  • Establishing a standards board to cull “best practices” from a cherry-picked pilot team and/or from research to then “roll out” a new [“standard” agile] process to other teams (“surely only the pilot team was able to do something effective without a standard!”)
  • Preventing teams from improving until someone has determined the “best practices” that they can then implement (e.g. “you can’t introduce that practice until the centralized group has determined the best process™ and best tool™ for everyone to use!”)
  • Taking experiences of success from implementing a practice or improvement in one context (organization, project, situation) and dictating their use as standards in others contexts (“<practice x> worked with <SuperPilotTeam>, other teams must use <practice x> too!”)
  • Measures of transition success based on “adoption percentages”

A Reality Check for Most Organizations Considering (or in the middle of ) Transitions to Agile, Lean, etc.

If you can relate to this, the ship that is your agile initiative may be sinking.  Over time, the initial excitement generated by the introduction of agile principles may be crushed by your management and organization as they ignore the learning process your teams have gone through, and carve out standards to be applied to everyone.

Basically, you may have the appearance of agile, minus the agile part – the practices without the principle; the motions without the capability.

This is one of several causes of the phenomenon known as CrAgile (“Crappy Agile,” a.k.a. “Scrummerfall,” “Scrum-But,” etc.) – wherein an initial exciting introduction of new ways gradually reverts to old ways.

Young business team exhausted and over worked

The Learning Journey

Standards, when used as described above, don’t result in success of complex endeavors like product development efforts.  They result in begrudging compliance and, if you are lucky, successful following of steps as opposed to achievement of outcomes.  From years of coaching, consulting, and being a member of many successful and unsuccessful product development and change efforts, I have realized a few things about learning new ways, such as:

  • Each person and team proceeds on its own “learning journey” when trying new things (see diagram). The real learning is in understanding what things work (and don’t) in different situations, reflecting on these experiences to understand why they did or didn’t work, modifying and improving them to work, and continuing to expand their awareness to continuously determine better ways.
  • Standards and best practices, used wrongly, are an attempt to short cut this learning process.  Ironically, the short cut only cuts out the “learning” part, and results in blind adherence to practice, and rarely greater capability.


This diagram shows the learning journey of a team.  Over time, the team tries new practices and techniques.  They learn how things work, and how to customize practices and interactions in ways that work for them – in their environment, for their challenges.  The practices alone were not the reason for growing in capability, but rather trying the practices and learning about when and how to apply them.  The common management mistake is to assume that taking the practices that a high-performing team is using, and copying them to other teams, will result in the same improvement.

The Only “Best” Practice – Continuous Learning and Improvement

“There are no best practices, only better practices”

I don’t know where I first heard/read this quote, or who it came from (let me know and I’ll update this page- my searches yield many writings). What I do know is that the pursuit of “best practice” has a number of subtle problems:

  1. It implies that once these practices are found, improvement is done. This is consistent with the “unfreeze-change-refreeze” model of change associated with Kurt Lewin in the early 1900’s. This older model of change is often criticized for being too inflexible to deal with the overwhelming amount of change and disruption we face today.
  2. It mistakenly assumes that effectiveness of practices is context-independent (i.e. what works well in/for one situation, person, team, group, environment will work as well in other situations, persons, teams, groups, environments). Consider how much can be different about situations, people, teams, groups, and environments and it becomes easy to imagine how a “best” practice in one place may not even be a useful practice in another.
  3. It assumes that change is not constant.  More and more articles, books, and experience show that change is constant, and that organizations that will survive in the future must develop the capacity for continuous adaptation.


A Better Use of Standards and Best Practices

Reconsider how best practices are used in your organization.  Learn from lean thinking a different approach to improvement and standards.

  1. Change your focus on standards from that of arriving at “best practice” to constantly finding “better practice”.
  2. Shift the purpose of centralized groups from centers of governance to centers of enablement – helping to encourage teams to visit each other to learn about successful approaches
  3. Encourage the building of communities of practice wherein people from different teams and group can share experiences and learning.

Lean “Yokotenkai”

In the lean world, the concept of yoko tenkai (which I’ve read is poorly translated as something like “beside/to the side, expansion” – shortened to “yokoten”) is a process of sharing best practices from one part of the organization to others, and (as importantly) improving or expanding them constantly to meet the needs of the new context. There are two aspects of yokoten- both are necessary, and neither is sufficient on its own.

  1. The first is the “copying” of best practice to the side. This involves learning about discovered “best practices” from other parts of the organization.  A subtle (but critical) nuance is that these practices are not designed and dictated by some governing body- instead, the process of “copying” involves people sharing learning and observing practices in other groups as they are being used, in context.  It is a sideways proliferation of learned practices across the organization, fueled by observation of these practices where they are working.
  2. The second part is “expansion.” Practices are not to be blindly and arbitrarily applied to other parts of the organization.  Instead, the practices are modified and improved to suit the needs of each group and context.  The result is continuous improvement, fueling more sharing.  This results in continuous “better” practices.

When people from one team observe practices in use in another team, they are taking these practices, bringing them to their team, and will more likely customize these to work best on their team and “make it theirs,” with the goal of improvement.  Alternatively, when an authority tells a team to implement a practice, will do what they are told, with the goal of following the practice.

What can you do?

Here are some ways you can get started, today:

  • Discuss the role of standards in your organization.  Discuss yokoten and what it means to your group.  Research the Toyota Production System and other lean implementations.
  • If you are on a team, try to embody yokoten yourself!
    • reach out to other teams to learn how they’ve been successful/li>
    • bring back learnings to your team and improve/modify them to suit your context
    • share any improvements you make with those who helped you
  • If your organization is embarking on a large transformation in pursuit of organizational agility, and seems to be run in a manner similar to that discussed in the beginning of this article, seek expert guidance.

The following things may take a long time to instill in your organization – as they may need cultural change to be truly accepted:

Start shifting the role of centralized groups from designers and declarers of standards to enablers of yokoten

  • Ensure teams get the help they need to be successful
  • Be aware of learnings in various teams
  • Encourage teams to visit other teams that have been successful, and bring back learnings to their teams to improve
comments powered by Disqus