For example, the most recent class was very intense with the team asking me some really hard and crucial questions.  Then they dropped the bomb. “Hey Mike, you act like Scrum is a Silver Bullet.” Arghhh! I HATE THAT. I don’t know how many times people get that impression and how many times I have repeated the litany, “Scrum doesn’t solve anything it shows you what is happening in your organization”.  Well not this time. What jumped from my lips was “Scrum is Not a silver bullet, Scrum is a silver mirror!”.

The next day, one of the class members reported out that my ‘catch phrase’ had really worked.

Huh? The class was right behind me in asking for an explanation.

It seems he left the class last night and went back to work (we are such a bunch of OCD wonks) where is boss was talking about Scrum not being the Silver bullet he, the boss, had expected. Our teammate then popped the phrase “Scrum is Not a silver bullet, it is a silver mirror!”. This stopped the boss in his tracks as he realized that Scrum was just that, a high definition reflection of all the things that were actually going on. And if memory serves the attendee went on to say the conversation went from Scrum not meeting expectations to what was coming off the mirror.

The class, being a great one, started kicking this around. One of the comments emerged from someone saying “Talk to the hand” and became “talk to the silver mirror in my hand”.

Maybe a good ScrumMaster is a person who can have people talk to the mirror in their hand.

Thomas Crane, in his book “The Heart of Coaching” identified a model from an article in the November 1979 issue of the “Training and Development Journal”. Sadly, I could not find the original article, but I’ve adapted the diagram to communicate the model. If we think about change on two levels, we see that there are changes in behavior and ultimately changes in results. These two dimensions remain roughly proportional in a static system, as your behaviors impact your results. Things get really interesting once you try to change behaviors. We frequently see this done by sending people or a team to training. Indeed, the “Certified ScrumMaster” classes, are often this point of entry. Now we see that behavior changes, but once someone goes to apply this new behavior, the results are actually worse than when they were using the old behaviors. Many people are familiar with the idea of the “j-curve”, as we use a new practice for the first time, we’re actually quite clumsy and our outcomes are not as good as if we were using an old technique. For those of you who ski, when you first learn to parallel ski, it’s actually much harder to get down the mountain. In fact, when you ski an expert trail, you probably find yourself reverting back to the snow plow. It may be a less refined technique, but you’re effective with it. This is exactly what we see when people first learn and apply Agile practices.

Training with No Coaching

What we observe is that while one’s behavior change at first, they are immediately put back in their prior environment and begin to revert. Perhaps not everyone went to training or the boss doesn’t really care about Agile. As Weinberg observed, the cucumber eventually gets pickled. What’s really interesting as that at the same time, our poor change champion is not performing at a lower level as they try to use new practices. Thus, the “new” stuff actually feels worse than the “old” stuff they were trying to fix. We know some of this is a learning curve, but the observed behavior is that as one reverts back to the prior standard, results are actually getting better. Thus, one can settle at a level with slightly better behaviors and slightly better results, feeling like this is the proper place to be. David Douglas and Robin Dymand talk about a situation they call “we suck less” and I think this nicely summarizes how people can fall into that trap.

Training with Coaching

So how do we help people maintain, or even improve, their behaviors after a training class? Well it must be reinforced, and this is where coaching comes in. Having committed time and energy to learning a new way of doing things, people need ongoing support as they begin to apply them. No matter how good your training class, it will never be a substitute for the messy reality of the world in which we must all operate. Also, we need to remember that there are very real pressures that have driven us to our prior behaviors. We need to begin to apply counter pressures so that we don’t revert back to old habits. This second diagram shows the two dimensions, but now the team receives coaching after they complete training. The coaching helps reinforce practices so that they don’t abandon their behaviors as they move through the adoption curve. As results get demonstrably better, this can create a virtuous cycle where coaching can eventually ramp down and the team becomes self-sufficient, continuing to improve it’s own performance without any external support.

Like many things, this probably introduces more questions than it answers. How long is the right amount of time for coaching? What if the coach is hands on, or the team is supplemented with other experts to get through the adoption j-curve? Are there other ways to change the environment such that teams feel positive pressure to maintain behavior besides through a coach? These all probably merit further discussion, but let me leave it here for now. So I am curious, what are you experiences with rolling out Agile, or any type of change, initiatives? Is this model consistent with your experience?

Also, several people expressed some interest in local Agile groups so that they could learn more. I would point out three specific ones that have monthly meetings and support vibrant communities of both learners and practitioners:

• Agile Bazaar
• Agile Boston
• Nashua Scrum Club

“I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth.”

It struck me it was ‘the’ perfect story. It has a role, action that had to be taken, and a goal.  But most of all it had a very tangible, clear, and explicitly well defined definition of DONE – “returning him safely to the earth.” What a story!  What an Epic! What a way to get a nation – a world – to focus.   But it wasn’t a user story – it had this timeboxing clause,”before this decade is out,” that started the clock ticking.

I refer to it as a Focus Story. It serves as the transforming agent changing a poetic visiony user story into a ‘Mission Statement” and a Commander’s Intent”. With it in place, at the top of Product Vision, enough guide rails are in place to make reasonable initial roadmaps, release plans, prioritization criteria, and definitions of done.  But most of all we have a means to understand core values criteria “safely to the earth”.

We also have triggers to inform us when we are losing focus –  Meetings get longer, Done isn’t understood. Pieces don’t fit and the conventional mindset you have been struggling to win over sighs and goes back to its safe place of waiting for the fad to die.  When these show up it is time to revisit the focus story and build a bigger focus or wrap up what you are doing.  Otherwise you risk having “O”rings show up on your Columbia launch.  Nobody wants to be part of that type of bad day.

There really is a lot of say about this, and I intend to write more,  but for now I wanted to make my presentation available. It can be downloaded here: Agile Beyond Faster, Cheaper and Less Defects

Agile 2009: Mapping the Change Battlefied

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.

You can view the presentation here