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.

Techniques for Agile Project Managers - This presentation has some introductory content and then discusses some of the key practices needed to help a team self organize and be effective.

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?

Within the large organization, I can appreciate the desire. Indeed, there certainly are some benefits around transparency, consistency and institutional knowledge to be had when we get everyone to agree to a standard. This is a careful balancing act, as the benefits may prove elusive and the risk is very real. First with transparency, while working code is the best indicator of progress, as teams grow into the hundreds, that can become too much “product” for an executive to effectively review and understand. This closely dovetails with consistency, where teams need to have common understandings of how to exchange stories, what “done” really means, and even what technical standards they will follow.

Technical standards can be quite pernicious, as enterprise licensing agreements, technology stacks and other architectural decisions can place very real requirements on how teams operate. We do like to think of each team as a trailblazer, but at some point, if you have three web development teams, one chooses ASP.NET, one chooses Java and the third chooses PHP, it doesn’t take an expert to see there is wasted energy. Lastly we come to the idea of institutional knowledge. As a consultant I can certainly appreciate that companies have a desire to “do it on their own” and apply hard earned lessons in one project to future ones.

It is not that these are invalid desires or that some benefit can’t be reached from standardizing, or as I’ve been calling it “institutionalizing” a Scrum implementation. Rather, it’sthat we need to understand the cost of each decision we make and weight it against the benefit. I think back to one of my earliest experiences in project management. An aspiring PMP, I was kicking off a project and I took out my PMBOK to find out what tools I could use to charter and initiate a project. From analyzing stakeholders to managing risk, I’m pretty sure if there was a checklist or template, I used it. At the time I didn’t understand exactly how each one applied, so I compensated by using every single one. Surely, this is not Agile, nor how one would advocate something like the PMBOK be used. I took a list of possible tools and considered them a mandatory set of things to do. Just like that, a supporting resource became a requirement and my project was about following lists rather than delivering value.

I see a similar challenge if an organization begins to offer too many guidelines. So what is the right limit for acceptance criteria in a story? Well, in my case, I took a 3×5 note card and figured out how many sentences I could fit on one side. This brought me to the recommendation of 7, but does it mean if I only have 2 that my story is wrong? Of course not. A better measure would if it clearly articulates what the story needs to do, is agreed upon by the team and they can commit to do it in a sprint. Then again, even user stories are not explicitly part of Scrum, so are we now mandating that all project requirements be formatted in this construct? Just because something makes sense in one domain, doesn’t mean it should be applied elsewhere.

Indeed, using a framework for empirical feedback like Scrum provides one with infinite ability to inspect & adapt. Of course, a common challenge with standardization is that, we have two groups of people: one group who is defining the standard and a second group who is trying to use it. Thus we have one group using the process and getting feedback, but a different team is supposed to make adaptations to the process, but is not experiencing that feedback directly. This is the paradox I alluded to before. In order to get a large organization to use a highly flexible & adaptive process, we must take away some of that flexibility by taking decisions out of the hands of individual teams and delegating them to centralized committees. When this is done, does the value proposition remain intact? How do we go about confronting making consistent & transparent Scrum throughout a very large organization without fundamentally undermining the nature of this framework?

I know many people have talked about this topic and I will certainly have more to say about it, but for now I think the key is to figure out how to standardize on the principles and keep maximum flexibility, but I can see this blog post is already too long so let me leave it with that until I continue this thought later. I’d love to hear your thoughts in the meantime.

Agile 2009: Mapping the Change Battlefied

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.