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.

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
  • 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

0-To-Agile-In-3-5Years

Some of the main points:

• Agile, Lean, and other improvement concepts are holistic things, and applying them to a subset of your organization or value stream is likely to result in local optimization, and miss opportunities for far greater improvement and value
• The paradigm shift required is significant- amounting to a values change for individuals throughout the organization- from team members through executives.  Such a paradigm shift can take a long time- months, even years.
• There is not a model that can be used to perfectly plan your transition (if someone tries to sell you one, then I’d like to show you a bridge I am considering selling).  Understanding multiple models of change, and constantly adapting your strategy based on learning, will improve the success of your change effort.
• Coaching can help people learn, and is best when it is available real-time, in-context, so that the most important learning opportunities can be taken advantage of.
• It is easy to fall into the trap of focusing on practice and tools compliance, and neglect ‘the learning journey’ – where the real change has taken place as teams and individuals try different things, learn about what works and what doesn’t in their context, and try to change their context in ways that will result in greater emergence.   Neglecting principles and learning can result in the same practice standardization that is similar to a fundamental flaw in more traditional approaches.
• Don’t forget to examine and change existing rules when introducing new improvements!

Collaboration is great…

Collaboration helps teams accomplish things, and accomplish the right things.

Getting the right people together in a well-facilitated meeting can quickly move us through decisions to the right actions (see the reference to Jean Tabaka’s book at the end of this article, from which I paraphrased this).

…but collaboration is not everyone involved in everything

A common trap is to assume that collaboration is about everyone being involved in everything, and everyone having a say in everything.  Acting in such a way results in meetings overload, stifled decisionmaking, inefficiency, and other problems – probably the opposite of the effects of good collaboration.

Some Tips for Meetings (Organizers and Participants)

If you are planning a meeting, make it easy for invitees to attend and participate!

• Always create a simple purpose and agenda.  Here is a tool (from “Collaboration Explained,” by Jean Tabaka) you can use to come up with a brief agenda that will let people determine how important it is for them to attend, and how they need to prepare:
  • What is the purpose of the meeting?
  • What outcomes will support the purpose?
  • What questions will lead us to these outcomes?
  • How much time will we plan on spending answering these questions, and how?
• Ensure that you are inviting the right people and amount of people to be effective – people who can’t help enable decisions and outcomes, for example, might not be helpful to invite
• Use “To” and “CC” to help people understand who you think is mandatory and who is being invited “FYI”
• Do you need the full default 1 hour for your meeting?  Don’t accept the default unless you need it.  A shorter, time-boxed, more focused meeting might be easier to get the attendance you need
• Use time-boxing and facilitation tools during the meeting to make the best possible decisions and start action

If you are invited to a meeting, determine whether you really need to go, and why!

• Review the agenda.  If there is no agenda, ask for one!  (in one [perhaps extreme] experience, a team set the expectation that they would not attend meetings without an agenda )
• Some good reasons to go to a meeting:
  • You have something to contribute to the discussion/agenda (e.g. you are bringing expertise, or part of the decision making body. etc)
  • You have something to gain from the discussion/agenda/decision-making process itself  (warning- this alone may not be enough of a reason to be invited or to go)
  • The meeting is mandatory for you (hopefully for one of the above two reasons  - if not, isn’t the requirement to go an obstacle to be resolved?)
• If you don’t have good reasons to go to the meeting, don’t go! (well, maybe…)
  • Talk to the organizer to help with this decision
  • Ensure that if someone from your team is needed to represent, that at least one person does so.
  • Ask your Scrum Master (if you are on a scrum team) or Project Manager for help:
    • Share why you think you are not needed for this meeting
    • Ensure that if there is some kind of representation from your group needed, you find sufficient representation
    • Work with your SM/PM to determine the best approach that accomplishes everyone’s goals (including the organizer!)
    • Verify this with the meeting organizer

I think that the more people who go through this type of thought process, the more people will start more effectively planning meetings.

During the collaborative meeting

During collaborative meetings, use big, visible. organizing tools to facilitate effective collaboration, such as:

• A clear purpose, posted – reminds us of why we are here
• Ground rules – helps us work together effectively
• An effective parking lot – allows us to recognize topics that may be important, but perhaps independent of or not relevant to the purpose
• An action plan – build a list of actions to take during the meeting, not at the end, or after the meeting
• A communication plan – determine who needs to know about results of this meeting
• A decisions list – capture the decisions that were made during the meeting

Using tools like these during the entire meeting as opposed to after the meeting will help you finish with outcomes, a plan, decisions, and more – together!  Less cleanup work to do afterwards.

A good book

Much more guidance on these topics can be found in the book “Collaboration Explained: Facilitation Skills for Software Project Leaders” by Jean Tabaka (upon which much of this article is based). I highly recommend this book – it is full of great recommendations for effective collaboration, meeting planning and facilitation.  It also has good guidance for effective agile ceremonies- a separate topic we may explore is common anti-patterns in agile ceremonies.

I spoke about the topic of Agile and the Organization at the PMI’s Orange County chapter.  Attached are the presentation materials.

AgileAndOrg-PMIOC

Goldratt describes these things (not directly), and similar phenomenon (like failure of companies to get the real benefits from ERP, SAP, 6Sig, Lean, etc.) nicely:

Organizations make rules to deal with/operate in the presence of limitations.  By rules, I mean rules, processes, structures, and other arrangements and things (see the dictionary definition).

Technology (see the dictionary definition) improvements remove limitations.

For a change to truly take hold and succeed, the rules that were made to operate in the presence of the old limitations must be eliminated or changed, and new rules created to deal with new limitations

The concepts above (ERP, SAP, 6Sigma, Lean, and Agile) are technology improvements.

Specifically, Agile, as a technology improvement, removes limitations such as:

• the inability to deal with change
• the inability to deal with uncertainty

Make the Change Stick
For an Agile transition to be truly successful, all the rules that were created when the old limitations existed should be revisited.

1. Remove rules that are no longer useful – these tend to be the ones that were made specifically to address those old limitations
2. Identify the new limitations we have now (they’re out there…a separate article coming soon)
3. Create new rules to deal with these new limitations
4. Rinse and repeat when you find the next improvement

Examples of Rules that May Need Changing and/or Scrapping in Agile Transitions

• Functional Org Structures and Groups
• Documentation-focused processes and steps (this is a huge one…changing how we validate things to how we request things)
• Heavyweight software release processes
• Compliance processes
• HR-related rules – from career paths, to evaluation and compensation, and more

All of these rules that were made when older limitations existed, if they continue to be modus operandi, will sap away the ability to continuously improve and embody the change you are trying to make, leech away energy from your change agents, and eventually result in a transition that has been mediocre at best.  It is exactly this situation that makes it appealing to create a hybrid method – such as combining the UP with Agile.

Changing the rules – A transformation enabler

I do believe that there are other aspects of Agile transitions that are important to consider.  Changing the rules is a major one that is often neglected due to how difficult it is.  Any time you feel like customizing your agile process with something from your former processes, ask yourself if it is because you have found a rule that needs changing!

My opinion may be a bit controversial.

I believe that a coach is whatever she/he needs to be to help their teams get to the next level.  I believe that great coaches are also great leaders, though they are not formally in leadership roles with those they are coaching.

Some organizations are in such a state that they need someone to demonstrate leadership in order to even begin to understand what a leader does in their context, and in such a state that no one available is ready to step up.  In such places, no amount of Socratic questioning, facilitating, dialog, or other hands-off techniques will help them in a reasonable time.  In such places, I imagine those with more strict coach role definitions would declare “they are not ready for <improvement x>”.  I would take a different approach – I might temporarily take on a leadership role to demonstrate, and then hand off the role to a team member.

Important considerations when taking on a leadership role as a coach

When you do this, you are removing your coach hat, and putting on a borrowed leadership hat.  Set expectations clearly:

• this is a temporary, brief, time-boxed situation with specific goals including demonstration and mentoring
• a primary goal of this endeavor is to hand over the leadership role as quickly as possible to a team member
• a primary goal is to put the coach hat back on as soon as possible and to break dependencies on the coach as leader

If you are a coach, you may already be taking on leadership roles

Do you facilitate meetings early in an engagement, such as discovery workshops or other things?  You are acting in a leadership role already.  As I describe above, it is a time-boxed endeavor with pretty clear expectations.  But it is leadership.  The more explicit and accountable the leadership role you take on, the more slippery the slope becomes, but with careful expectations management and a clear plan for transitioning the role to a team member, teams can benefit from your experience and leadership.

Turn them away?

Some believe that the role of the coach is very explicit and that there are clear boundaries, and that some people just aren’t “ready to be helped”.  I don’t.  I believe that I “work on/with the person in front of me,”  in the middle of the problems they have, and that rules sometimes need to be bent to help them in the best way.  If they want to change, and improve, I will do whatever I need to help them.

An example

A team is the first in its organization (a very large organization) to try scrum.  The team is 1 of four working on a large project.  No one on any of the four teams has any experience with scrum, and the culture until now was one of multi-tasking, multiple bosses (“I have five bosses, Bob, five”), and fear of rocking boats/exposing information.  There is little clear leadership.

An approach that worked really well in this situation in multiple organizations for me was to take on a leadership role for a time-boxed period, with the explicit goals of transferring the role to a team member as quickly as possible.  Taking on a scrum master role for a few sprints allowed me – someone with little need to fear breaking with tradition – to facilitate decisions, challenge rules, expose elephants, and more.  Team members saw that all of these things resulted in more success, and a natural scrum master emerged and took on the role, allowing me to focus on pure coaching.

As more teams started trying scrum, there was a new leadership gap – at the program level.  I took on the uber scrum master role – again for a brief time with explicit goals to transfer the role to someone on the team as soon as possible.  The results were repeated – this time at the program level – and the results were teams that functioned effectively as an agile program.

Taking on these roles was a risk…it is a slippery slope to start upon to take on accountable leadership roles.  However, in some places, drastic learning must take place, and in such places, arriving at some answers via questioning and facilitation would take unreasonable amounts of time.  In such places, demonstration and mentoring can be combined with coaching to turn lights on.  More on this topic in my coaching courage post.

What do you think?  I’d love to continue this discussion

I wasn’t taught it…but I did learn it.

One day long ago my professional career seemed torn asunder by an organizational change.  At that time, I believed that all I had worked for was no longer firm ground on which to base my next successes (that is the way it seemed, anyway).

“It is only after we’ve lost everything that we’re free to do anything” – Tyler Durden

I use that quote way too often.  My perception at the time was that I had lost everything.  There was a new regime moving in.  My colleagues resigned themselves to stagnation while the new leaders arrived and established their top-down plans.  This seemed really familiar to me…

“Meet the new boss…same as the old boss…” – The Who

Not wanting to have to repeat the last 2+ years, I chose a different approach.  I started just doing.  Taking on stuff that needed doing, defining my role myself (I helped my managers find the titles that fit later).  Questioning things and providing good alternatives.  Turns out everyone else was questioning the same things, but no one was doing anything about them…one reason is because they perceived that they had a lot to lose.

I’ve learned many things about courage over the years…here are two:

1) Everyone has some amount of courage bottled inside them.  It just doesn’t come out, for many seemingly-good reasons – the obstacles to learning courage.

Why does having nothing make it easy to find courage?  Perceiving that we may lose something or be punished if we act courageously and make a mistake is an obstacle in the way of courageous behavior.  The “easy,” less risky path is almost always the one that everyone takes – not bucking the trend, ignoring the elephant, not calling out an improvement opportunity, not making waves or rocking boats.  “My boss got promoted by not doing these things, should I not behave the same?”  Groupthink and peer pressure make being courageous difficult too.

2) Once someone realizes that good things happen from courageous acts, it becomes far easier for others to be more courageous.

Eli Goldratt, in “Beyond the Goal,” describes a psychological experiment done on Harvard MBA students – strong personalities who would likely be future business leaders (my apologies in case I am getting the details slightly wrong).  A group of these students are shown three very different lines on a card – a short line, a medium length line, and a long line.  They are then showed a second card, on which a line is drawn that is very clearly the same length as one of the three lines (let’s say it is as long as line #2 for clarity).  They are all asked “which line on card 1 is this line most like?”  Though the answer is clearly #2, all of the participants except one have been prepped to answer “line #1″ – the wrong answer.  The final participant, who has not been prepped, chooses “line #1″ – the obviously wrong answer – 90% of the time the test is conducted!

The experiment continues…this time, one of the prepped participants answers correctly – “line #2!”  When one participant bucks the trend (described as “one ray of light”,) 75% of the test subjects also stick to what they believe the correct answer is rather than conforming.

(Note: I can not find the original source for this experiment- please contact me if you can!)

What can we do to help us choose the harder path/path less traveled?

I believe that the things that prevent people from being courageous are obstacles to success.  We – as leaders, coaches, scrum masters – are here to remove obstacles from our teams’ way.  Assuming courage is a success factor for projects (which I do, especially on Agile projects), how can we encourage it?

We can’t teach courage, but we can certainly remove the obstacles that prevent people from acting with courage

1) Create the “one ray of light” that will break the conformity trend.  Demonstrate courage the first time.  Leading by example as a coach or scrum master, you can show a team that courage is desirable.    Some very simple examples that have worked for me include:

• Admit to a mistake very publicly and proudly.  I’ve found making very public a mistake of mine and its impacts results in others sharing their own more, and taking more accountability – it breaks the ice for others to realize that mistakes are part of learning.  This is the easiest way to start changing a team culture from one of introversion to one of collaboration and teamwork
• Escalate a particularly uncomfortable team obstacle to leadership and facilitate its resolution.  This can be really effective if the obstacle is one that team members believe is not going to be resolved.  That overwhelming release/migration process that no one wants to call out, for example, or some other set of rules that the teams just feel are just “the way it is” and that they have no hope of improving

2) Encourage courageous acts.  When you see them, point them out.   Discuss as a team how courage resulted in good things (for example, talking about an “elephant in the room” helped us have a great group discussion that resulted in starting to consider addressing the big issue that was previously being ignored).  Make courageous acts infectious.  Use informal awards (I’ve seen “Zena” and similar awards used informally for such things).  Help a team member champion an idea that may not be popular or an easy sell.

As a coach, scrum master, or other leader, do whatever you can to create an environment that rewards courage.  Sometimes this means leading by example to be the “one ray of light” illuminating an elephant.  Sometimes this means admitting to an embarrassing mistake and helping the teams realize the benefit of sharing mistakes/learning.  And sometimes this is simply helping a team member be courageous themselves.  Whichever, I see coaching courage – removing the obstacles to learning courage – as a constant role of servant leaders.

Are you considering a coach?

If you aren’t, are your organization and projects at risk?

Fire! Ready, Aim…
Many organizations, thinking that they can’t afford or don’t want to invest in coaching or training, read a book and some articles, and tell their teams that they are now doing Agile.

I have never seen a team get great benefits from Agile in this way.  When I am coaching, and I hear other teams that aren’t being coached say “we’re doing Agile,” I raise an eyebrow (in my mind anyway), and find out if I can spend some time with them to see what they are doing.  Without fail, these teams are doing “Scrum but,” “CrAgile,” “Scrummerfall,” or some other thing that only resembles an Agile method minimal ways.   There are many articles on these topics.

How might coaches be engaged?
I’ve heard that some people use the analogy of a Soccer Team to make the point about what a coach is and how coaches might be engaged:

Wing It
Consider a soccer team.  You could read about soccer in various books and other references, and then attempt to play.  Chances are, though you may learn some of the basic rules, your team will not perform that well without great luck.

The Clinic
You could have this team go through a 1-week soccer clinic to improve their abilities.  They will probably learn some new tricks, maybe a bit of strategy if you’re lucky.  But rarely will such a brief improvement effort result in drastic, long-term improvement as a team.

The Ramp-Up and Check-In
Now consider the same team if they had involvement from the expert who held the clinic for 3-4 months.  The coach could provide the same techniques and training, and apply them to real situations as the teams go through them.  This is FAR more powerful learning – it is contextual, it is about the team and its real challenges.  They can follow guidance as they are working and incorporate it into the way they do things.  The coach can also keep an eye on things that are nearly impossible to observe in the clinic- team dynamics, organizational obstacles, and more – and help any time they find a need.  The team’s game can really improve.  If you have a good coach, the team actually may even get to the point where it is able to improve on its own- perhaps the team members have watched the coach and adopted his/her techniques to observe and question and find improvements.  After a few months of working together, the coach can scale down her/his involvement, perhaps to the point where she/he is called in as needed and to perform periodic check-ins and assessments.

Though this is a far more powerful model, it may not sufficient – for all large/complex/business-critical projects that cost lots of money.  These projects and programs are the “pro” league of the project portfolio, and any opportunity to mitigate risk should be considered.  There may be argument that it is not even sufficient for smaller projects and programs, because much of the value a coach could add happens real-time, as the project is going through its iterations, as challenges arise (unexpectedly).  Depending on how infrequently your teams have help available, they may not be getting the help when they need it most.

The Embedded (the “pro” league of product development?)
Sports teams expected to perform at any professional level follow a different model of coaching – they have coaches and experts that stay around all the time.  The level at which they are expected to perform  makes the cost of great coaches and trainers a good investment.  The risk of not having a coach far outweighs the cost.  How does this compare to your projects?

Do you have a project on which you are spending  millions each year?   That sounds like a risky endeavor, considering project success rates over time (See any popular project success rates research etc).  Having a coach on board or accessible at all times can help your team deal with the infinite number of challenges that it may run in to.   Are you an executive that has “shelved” a multi-year, multi-million dollar project?  This is about you.

The bulk of the coaching value-add is probably not in specific things like Agile practices and techniques, but in other, less concrete things – like dealing with situations that aren’t covered in the books, maintaining focus despite difficult situations, mentoring leaders in the team, facilitating brainstorming, guiding team members in problem analysis, and helping to identify goals for continuous improvement.  If your coach is effective, teams will make measurable improvements every iteration- much more consistently than without one.

Effective coaches are rare, and they don’t come cheap (if you find one that does, start asking around for references ).  But they are a force multiplier, and a massive risk mitigation technique.  The cost of this level of risk mitigation pales in comparison to the benefits  – in continuous team improvement, in mentoring of future leaders, and in the pursuit of organizational agility.

An example…(We have many…)
You may be doing a great job of allowing your teams to follow the guidance they’ve been given and execute Agile very well.  Great job!   Product owner (PO) of project X, one of the highest-budgeted projects in your organization, realizes that a feature set that was originally deemed extremely important has been exposed as a nice-to-have,  or maybe not really necessary at all (a very common situation on well-executed Agile projects).  What should the PO do?

Clearly, the PO should talk to the stakeholders and let them know that we could save $400k on the development of this feature set that we would have otherwise spent.  Is it that clear?  Is YOUR organization ready to handle this situation?  Would the project be deemed a success and the fact that it was ended early be treated as a win, or would the message be that it was ‘canceled’?  What would happen to the project team if they were done early?   Would your organization be able to get this high-performing team a new project that actually has critical importance, or would they be disbanded?  Would your organization be able to re-allocate those funds to the next most critical endeavor?  In many organizations I know of, there are many reasons why a PO in such a position might not choose to terminate the project early (would it be uncertain to the PO what they would move on to?).  These are organizations that have not taken Agile and Lean to the enterprise level.

A coach provides an objective, guiding voice.  Any coach worth his or her salt would help the PO and stakeholders realize the opportunity and the reasons why the opportunity might be tough to take advantage of.  They could then help the right decision to be made, and help the organization improve so that it will be better able to handle this situation in the future – by exposing this “organizational obstacle” to agility and helping the organization resolve it.  If there were a coach in the aforementioned situation, would that have saved the organization $400k in poorly-spent development costs and earned them $___ in benefits from the more important efforts that those funds could be devoted to (which otherwise would be opportunity costs)?

There are many things to consider when you are deciding about hiring a coach.  It’s not all about Agile, training, and practices.  It is about success and risk management, and about prevention of the common phenomenon of less-than-sucessful Agile implementations.

Are you considering a coach?

If you aren’t, are you putting your organization and projects at risk?

Play a game of pick-up
Many organizations, thinking that they can’t afford or don’t want to invest in coaching or training, read a book and some articles, and tell their teams that they are now doing Agile.  A few daily meetings later, an Agile project is born (well…something is born…).

I have rarely seen a team get great benefits from Agile in this way (except for when these teams already had heavy experience with XP and Scrum on successful projects).  When I am coaching and hear other teams that aren’t being coached say “we’re doing Agile,” I raise an eyebrow (in my mind at least), and try to spend some time with them to see what they are doing.  Without fail, these teams are doing “Scrum but,” “CrAgile,” or some other thing that only resembles an Agile method in minimal ways.  You might find that teams that do this actually are hiding information more than they did in the past (though the opposite should be true), by simply telling stakeholders and outside parties “leave us alone – we are doing Agile.”

See articles about these topics as well as “Scrum Tests” for a quick sniff-test that can be done in minutes (though not a substitute for more in-depth assessment, it can point out a CrAgile implementation quickly).

How might coaches be engaged?
I’ve heard that some experts (including Ken Schwaber, co-creator of Scrum), uses the analogy of a Soccer Team to make the point about what a coach is and how coaches might be engaged (my take on this analogy):

The Clinic
Consider a soccer team.  You could have this team go through a 1-week soccer clinic to improve their abilities.  Chances are, they will learn some new tricks, maybe a bit of strategy if you’re lucky.  But rarely will such a brief improvement effort result in drastic, long-term improvement as a team.

The Ramp-Up and Check-In
Now consider the same team if they had involvement from the expert who held the clinic for 3-4 months.  The coach could provide the same techniques and training, and apply them to real situations as the teams go through them.  This is FAR more powerful learning – it is contextual, it is about the team and its real challenges.  They can follow guidance as they are working and incorporate it into the way they do things.  The coach can also keep an eye on things that are nearly impossible to observe in the clinic- team dynamics, organizational obstacles, and more – and help any time they find a need.  The team’s game can really improve.

If you have a good coach, the team actually may even get to the point where it is able to improve on its own- perhaps the team members have watched the coach and adopted his/her techniques to observe and question and find improvements.  After a few months of working together, the coach can scale down her/his involvement, perhaps to the point where she/he is called in as needed and to perform periodic check-ins and assessments.  The duration

Though this is a far more powerful model, it may not be the ideal for all large, complex, business-critical projects that cost lots of money.  These projects and programs are the “pro” league of the project portfolio, and any opportunity to mitigate risk should be considered.

The Embedded (the “pro” league of product development?)
Sports teams expected to perform at any professional level follow a different model of coaching – they have coaches and experts that stay around all the time.  The level at which they are expected to perform  makes the cost of great coaches and trainers a good investment.  The risk mitigated and value generated by a coach far outweighs the cost.  How does this compare to your projects?

Do you have a project on which you are spending  millions each year?   That sounds like a risky endeavor, considering project success rates over time (See Chaos report, or ask around at most large companies).  Having a coach on board or accessible at all times can help your team deal with the infinite number of challenges that it may run in to.   Are you an executive that has “shelved” a multi-year, multi-million dollar project?  This is about you.

The bulk of the coaching value-add is probably not in specific things like Agile practices and techniques, but in other, less concrete things – like:

• dealing with situations that aren’t covered in the books
• maintaining focus despite difficult situations
• mentoring leaders in the team
• facilitating brainstorming
• guiding team members in problem analysis
• championing and effecting continuous improvement despite any challenge
• identifying organizational obstacles and helping the organization overcome them

If your coach is effective, teams will make measurable improvements every iteration- much more consistently than without one, and the coach will be less necessary every day (at least in the ways they were needed originally).

Effective coaches are rare, and they don’t come cheap (if you find one that does, start asking around for references ).  But they are a force multiplier, and a massive risk mitigation technique.  The cost of this level of risk mitigation pales in comparison to the benefits  – in continuous team improvement, in mentoring of future leaders, and in the pursuit of organizational agility.

An example…(We have many…)
You may be doing a great job of allowing your teams to follow the guidance they’ve been given and execute Agile very well.  Great job!   Product owner (PO) of project X, one of the highest-budgeted projects in your organization, realizes that a feature set that was originally deemed extremely important has been exposed as a nice-to-have,  or maybe not really necessary at all (a very common situation on well-executed Agile projects).  What should the PO do?

The PO probably should talk to the stakeholders and let them know that we could save $400k on the development of this feature set that we would have otherwise spent.  Is it that clear?  Is YOUR organization ready to handle this situation?  Would the project be deemed a success and the fact that it was ended early be treated as a win, or would the message be that it was ‘canceled’?  What would happen to the project team if they were done early?   Would your organization be able to get this high-performing team a new project that actually has critical importance, or would they be disbanded?  Would your organization be able to re-allocate those funds to the next most critical endeavor?  In many organizations I know of, there are many reasons why a PO in such a position might not choose to terminate the project early (would it be uncertain to the PO what they would move on to?).  These are organizations that have not taken Agile and Lean to the enterprise level.

A coach provides an objective, guiding voice.  Any coach worth his or her salt would help the PO and stakeholders realize the opportunity and the reasons why the opportunity might be tough to take advantage of.  They could then help the right decision to be made, and help the organization improve so that it will be better able to handle this situation in the future – by exposing this “organizational obstacle” to agility and helping the organization resolve it.  If there were a coach in the aforementioned situation, would that have saved the organization $400k in poorly-spent development costs and earned them $___ in benefits from the more important efforts that those funds could be devoted to (which otherwise would be opportunity costs)?

There are many things to consider when you are deciding about hiring a coach.  It’s not all about Agile, training, and practices.  It is about success, risk management, and organizational agility – and it may be worth considering as a critical success factor on important projects.