Courage can’t be taught, I’m told.  It can be learned though.

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 facilitating 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 embarassing mistake and helping the teams realize the benefit of sharing mistakes/learnings.  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.

I recently created a simple Theme Prioritization Scoring Spreadsheet.  I use this as part of the Certified Scrum Product Owner class that I conduct.

BigVisible Theme Prioritization Scoring Workshop - CSPO Class

Feel free to download and use.  It currently does not weight the relative benefit of implementing a feature (epic, theme or user story) nor the penalty of not implementing though adding the weighting capability is simple enough.

If you are interested in taking an public scrum class with me, check out training.bigvisible.com

Regards,
Giora Morein

Coaching has some really important benefits in helping organizations adopt Agile methods, Lean, <insert process improvement of your choice here>.  This is especially true in large, complex organizations with deeply-traditional cultures that seem resistant to change.

Are you considering a coach?

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

Fire! Read, 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.

I apologize for the delay in posting this presentation. Here is the third, and final presentation we offered at the Mass Bay Professional day on May 2nd. Presented by Giora Morein, it is focused on the challenges an organization faces as they try to grow an Agile initiative beyond a single team.

You can view the presentation here

This Saturday, Giora and I were invited to speak at the Massachusetts Bay PMI Chapter’s professional day. Thanks to everyone who contributed to a great dialog about Agile and project management. I have included the two of the presentations we went through and hopefully we’ll have the 3rd one out shortly.

This Friday I had the opportunity to speak at the Southern New England Chapter of the PMI. I would like to thank the chapter for the invitation and everyone attending my session for the lively discussion. I have posted the slides for any who may be interested.

There is a lot going around about success in Scrum these days.  Talks on ScrumButt,(or ScrumBut); long threads about how long it takes; presentations on what is involved.  Yet I wonder how these folks can talk this way.  In my humble opinion to declare that you are successful at being Agile or doing Scrum is to admit that you don’t grasp the essence of Agility.
Maybe I am wrong, after all I put my pants on just like everyone else and just like them I periodically forget to zip up.  Could be one of us has that problem.
So to be transparent, What I have been teaching, coaching, leading, and doing the past 10 years is getting people to stop thinking about this as a goal to attain and to start accepting that it is a way of getting things done, better each time.
Is this a copout in that I never have to say my teams FAILED?  Nope.  It means that if you did good today, you were better than you were yesterday and now you have to do something else to be successful tomorrow. Lots of days you don’t get there but you do learn what doesn’t work. So if I understand the ScrumButters’ metrics, most of what I do is fail, but then again I have tomorrow to change things and get better than I was.

Here is what I measure. more »