Agile Coaches Can’t Scale (08 July 2014)

WARNING!  This blog post will probably offend most Agile and Scrum purists.  Also, as with all of our other blog posts, these thoughts are ours and don’t necessarily reflect those of the Knowit Group, PMI, Scrum Alliance, Agile Alliance, etc.

Arthur Shopenhauer, a 19th Century German Philosopher (nicknamed “obstinate” by his detractors), once said,  “All truth goes through 3 stages. First, it is ridiculed. Second, it is violently opposed. And third, it is accepted as self-evident.”

But, with those disclaimers, the time has come for transparency for some of the challenges companies are facing when trying to Scale Agile.  One assumption many companies have made is:  if Agile Coaches helped us become successful at the team level, then it follows that they should be able to help us scale Agile to the Enterprise level.  That assumption may be, and is usually is, in our experience, wrong.  This is true even for companies that have started out and remain Agile.

Just because an Entrepreneurial start-up has been successfully using Agile from its beginning does not exempt it from basic business principles that apply to scaling all successful businesses.  

As companies grow, suddenly what worked when they had five teams no longer works with 100 teams.  This is especially true from a governance perspective.  It’s fairly easy to manage Tribes, Guilds, Scrum of Scrums, etc. when a company is small.  To assume that you can successfully scale start-up culture and processes to the Enterprise level is naive and potentially fatal.

At some point in time the Tribes need to become a Nation.

To do that, you need to have effective and focused Agile Governance for the Enterprise.  If we were allowed to look behind the curtain of many Agile start-ups, we suspect that we would find a different picture that what is reported in the media.  It reminds us of law 20 from the book “The 22 Immutable Laws of Marketing” (by Al Ries and Jack Trout, 1993) which had this to say about what you read in the news:

20. The Law of Hype: The situation is often the opposite of the way it appears in the press.

No Agile start-up will ever publicly admit, particularly if they are publicly traded, that they are having troubles scaling Agile as they grow into more mature and larger organizations.  As we pointed out in our last blog post, one of the primary issues that Agile start-ups face as they grow is that they are now dealing with a completely different kind of professional stakeholder who speaks an entirely different language and has a completely different set of expectations. In many circles we call these stakeholders “Executives:”

Languages of Leadership and Management

The language difference between Management and Executive leadership usually comes as a shock for the Agile and Scrum purists.  They assume that success communicating at the management and team level should automatically translate into success communicating with the Executive level without any accommodation for the tribal differences.  They also firmly believe that the same tools and methodologies used at the team level will work at the Executive level.  We have observed that trying to force feed Scrum to traditional Executives generally ends badly.

It takes an Agile professional who possesses a high level of business acumen and maturity to be able to speak the Executive’s language.  It is even better if you can find an Agile professional who has been part of that tribe, i.e. one with Executive experience. Anyone who has worked at the C-level has already learned, and acknowledged, that a pragmatic, methodology agnostic approach is a more successful way of working.  By the way, the Agile and Scrum purist’s “force feeding” mindset (that Scrum / Agile can only be done one way, regardless of its audience) strikes us as unusual, especially from a group of people that pride themselves on quickly adjusting and adapting to reality.

Up to this point, some of the people reading this blog post will already be responding with ridicule and disdain. Others may even be responding in violent opposition to what we’re saying (and are already flaming us in the comments section below).  But our intent is to try and explain what we have found to be self-evident when successfully Scaling Agile to the Enterprise.  So, before getting all riled up and shooting the messengers, please follow our observations all the way through to their final conclusion.

When talking about Agile coaching, or team facilitation, it’s appropriate to be aware that almost all Agile literature and training is targeted at the individual and team level.  This doesn’t make it bad, but it also doesn’t make it effective when trying to execute Agile in the Executive suite.

What this means in practice is that a majority of Agile Coaches can’t scale and probably shouldn’t.

Yes, we know it’s not fair or accurate to lump all Agile Coaches together (as we stated in our last blog post on Enterprise Governance for Agile) since some Agile Coaches actually have the experience, education and skill to be able to scale Agile.  The rest of this post is about why the above quote is true for the vast majority of Agile Coaches with which we have come in contact.  It seems that many of the Agile Coaches themselves have missed a key point from title of the Agile Manifesto:

Manifesto for Agile Software Development” 

By definition, “Agile,” as described (and limited) by the Manifesto, is only for software development.  It was not originally intended for the entire organization.  That doesn’t mean that Agile’s Values and Attitudes cannot be used in other areas.  But, it does mean that the signers of the Manifesto understood the constraints of software development in context and relationship to the rest of the Enterprise.  There are examples of organizations that use Scrum and Agile for the entire enterprise:, F-Secure, etc.  However, the number of organizations that are struggling to scale Scrum and Agile far exceed the examples of those who have succeeded.

Most Agile Coaches and ScrumMasters are all about working with and facilitating teams (and individuals) with the goal of getting the teams to become high-performing.  This is part of what makes Agile and Scrum so effective.  And, Agile Coaches are taught to “lead” (train, coach and mentor) from the back of the room, as they should.

For example, Lyssa Adkins book, “Coaching Agile Teams,” has entire chapters on the coach as a mentor, facilitator, teacher, problem-solver, conflict navigator and collaboration conductor.  Another example is Sharon Bowman’s “Training from the Back of the Room,” which is the required course and book for anyone seriously considering becoming a CST (Certified Scrum Trainer).

These courses and books are both focused on training individuals and teams, not executives.

It has been our observation, however, when working at the Senior Manager, Executive and Board levels, it is an absolute requirement that a project, program and/or portfolio leader has Executive-level “room presence.”  Most of the Agile Coaches that we have observed in action don’t possess the room presence required to effectively communicate to and interact with Executive leadership.  This should not come as a surprise since they’ve actually been trained to do the opposite (to lead from the back of the room).

Assuming that all of the above statements are true, and even if an Agile coach has Executive level experience and/or “room presence,” we have witnessed a deeper, more fundamental problem within the Agile community that is blocker to effective scaling.  The following quote from a well-known Agile Coach captures the essence of this problem:

Management is the source of all Evil in the world.”  

Let’s be a little blunt here:  this is only true in the land of Dilbert.  Every organization has a pointy-haired boss lurking in the org chart.  However healthy, mature and growing Enterprises do not hold or share this errant belief.  Further, Agile and Scrum “purists” with this attitude have not done themselves (or the Agile Community at large) any favors by blaming all Agile transformation, transition and governance difficulties on the management and leadership of the Enterprise.

This is biting the hand that feeds you and also does not end well.  Worse, it blocks the ability of the organization to migrate to an Agile culture and many times kills the transformation effort.

Why is that?  It’s because, as we pointed out above, the language of Enterprise leadership is different than the language of management, Agile or otherwise.  I (Andrew) have a perfect example of this from last November when I had the opportunity to attend meeting for an Agile consulting company (that has both Agile Coaches and Agile Management Consultants).

The most fascinating, passionate discussion I’ve witnessed, so far, in my Agile journey, erupted during the course of this meeting.  As we shared in the quote above, one of the Agile Coaches had a complete meltdown during the meeting and literally blamed “ALL Evil in the entire world on ALL management consultants, managers and executives.”  Extreme? Yes. Unusual? Not so much.

Agile Coaches tend to ferociously fight to “keep a space for Agile and Scrum” (as they have been taught to do).  However, the most fascinating and rewarding part of the meeting was when the CEO of the company challenged and rebuked the riled-up Agile Coach with the following response in front of all of the other Agilists and Management Consultants in the room:

Frank*, by definition, if we are doing Agile consulting with the management of a company, then we are “Agile” management consultants.

*Note:  name changed to protect identity of the Agile Coach.  

The crimson-faced Agile coach sat down and the meeting continued.

Later in the same meeting, on a flip-chart, the President of the company had drawn a matrix with each of their products and services that they offered their clients.  The horizontal swim lanes were sorted by Portfolio, Program and Product, Project and Team and Individual Team Member levels; and, the vertical swim lanes were a categorization of their products and services.  ALL of their “Agile” products and services were aimed primarily at the Project, Team and Individual levels.

However, at the Program, Portfolio and Executive levels they had little or no product offerings.  No surprise there, either.  The “Agile” offering from almost all companies at the Executive level is fairly thin.

Why is that?  Because Agile has been aimed at optimizing the team (and by extension, individual).  I went up to the flip chart and drew two boxes around his Product / Service offering matrix that looked like the following:

Typical Agile Product Offering

A hush fell over the room as the idea of of the two languages sunk in and as they understood that Agile, for the most part, had ignored the leadership and governance levels.

Agile purists, like the Agile Coach above, have done a superb job of alienating almost everyone from the middle management level on up through the Executive team.  Worse, that particular coach wore it as a badge of honor that executives refused to meet with him; or, in the cases where they did, they never invited him back to another leadership meeting, ever.  This is because Agile purists speak a language that is foreign to the pragmatic leadership of the organization and because they have a value-set that is not aligned with the Executive level.  It is possible to preserve a “space for Agile and Scrum” without being offensive, arrogant and demeaning.

If at the team level 80% of all project management is communication, then working with the higher levels of an organization is 100%.  If Agile Coaches view Senior Management, etc., as the source of all evil, then that unprofessional attitude will be communicated loud and clear to those Stakeholders.  That is not a good thing.  It is truly a very unproductive anti-pattern.

People seem to have forgotten a well-know version of the golden rule:

He who has the gold, rules…

Everyone working on an Agile or Scrum project is accountable for the budget entrusted to the team.  If the team is not self-funded, then they are not truly self-governed.  If they’re not paying their salaries out of their own pockets, then they are financially accountable to the company and Executives that are.

Their mission is to deliver an increment of value to the Product Owner who is the voice of the Customer.

Sitting around in a circle, holding hands and singing “Kumbaya” just isn’t going to get a team very far with a group of jaded, “show-me-the-money” investors, Board Members and/or Executives.

So far we’ve looked at the “new” Golden Rule, the different languages used by Executives and Managers, the training Agile Coaches receive along with some aberrant attitudes and values that don’t win any friends with Executives and Upper Management, etc.

As we mentioned earlier, some Agilists have actually started to understand some aspects of successful scaling.  For example, at the Scrum Gathering Las Vegas (SGLAS 2013) I (Andrew) had the privilege to participate in a workshop facilitated by Lyssa Adkins and Michael Spayd on the Windows on Transformation: Four Pathways to Grow a More Agile Enterprise (the “I, We, It and It’s” 4-box applied to Scrum and Agile).  The model Lyssa and Michael used does a good job outlining the “who?” and the “what?” when scaling Agile to the Enterprise-level:

Windows on Transformation

There are additional items that they addressed in all four areas above, but those didn’t really give a crisp understanding of “how” to implement in each of the 4 areas.

While on the surface it would make sense and appear that teams should be able to organically scale using “team” Agile (from the “We” quadrant), the reality for most companies, even for those that started out Agile, it is quite the opposite.  There are organizational dynamics that “team” Agile is not equipped to manage … nor should it try.  See our recent blog post on “Agile Can’t Scale: Fact or Myth” for more on that.

Assuming that Team Agile, facilitated by Agile Coaches, will automatically translate to the Enterprise level has been a painful experience for many companies.  It’s not a question of Agile Coaches being able to understand the idea or principles of scaling.  It’s a question of battle scars, skill and demonstrated previous success in scaling Agile.  The universe of people that have “been there, done that” is rather small.  That is why a methodology agnostic Business Agile framework, like the UVF, is absolutely crucial for creating an organizational culture that facilitates Agile in all quadrants:

Windows UVF Aligns Implements All 4


The UVF works, and is powerful, because it continuously and iteratively communicates and focuses the “Vision” in all four areas and keeps it aligned at the Team level while you implement Business Agile.  The UVF is a simple, effective way to break through organization language barriers and get everyone on the same page.

But, frameworks don’t implement themselves.  And, there are no silver bullets.

Implementing Scaled Agile requires skilled people that know how and when to use the right tool for the right situation. During the past 2 decades, we have found that the Business Agile UVF with the VSPT, 4D and 4R Models will focus your organization to optimize all four areas, the “I, We, It and Its” that all Enterprise Agile must address.

Agile Coaches that only have a software development background usually do not have anywhere near the education, business experience and/or skills at the Executive level to deliver what is needed.  Hoping your Agile Coaches, using an organic “team” Agile approach, will get you to Enterprise “scaled Agile” simply won’t cut it.

You cannot scale an Enterprise from the bottom up only.  You scale from the top and bottom, simultaneously, using Vision.

1 comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: