Over the past few years there’s been an interest in scaling agile to the enterprise.  The desire to scale agile seems to have intensified over the last year, in particular.  Almost without exception, every conference remotely related to software development and/or project management seems to have some presentation on the topic of scaling agile.  I believe this is being done with the best of intentions but, in my opinion, it misses the point on at least three levels.

First, almost all of the discussions I’ve heard, and most everything I read, refers to scaling aprocess.  I can understand why so many are looking at the process first—because it’s easier; well, until they actually start at which point they discover it’s not so simple after all.  One of the reasons they immediately encounter difficulty is that the enabling factor of scaling is not yet in place.  I know it may sound cliché at this point, but please recall the first line of the Agile Manifesto which states that we value “individuals and interactions over processes and tools.”  One of the primary reasons companies struggle so mightily with agile adoption, not simply with scaling, is because the enabling behavior and attitudes are either lacking or totally nonexistent.  They’ve either forgotten to consider individuals and their interactions, ignored them completely, or undervalued the importance of the human element.

Agile methods are based on empiricism, which implies adaptation based on observations.  In short, it is not a control mechanism—especially of people.  In fact, I’m beginning to strongly believe we should stop talking about scaling process entirely—at least for the time being; rather, focusing our attention on de-scaling process through the introduction of replicated Lean Startup models such as the one Spotify has adopted.  My colleague, Brian Watson, also discussed this premise in a blog post titled Agile Killed the Project Star.  If you’d like an introduction to the Lean Startup, the video below summarizes the concept .

Secondly, I fear that leaders genuinely desire the results agility promises (faster delivery, higher quality, improved morale, etc.) but do not want to first address their own behavior. They’re perfectly ready and able, but not truly willing. I constantly hear the lip service, but rarely witness the behavior demonstrated. The dissonance I see repeatedly is as follows:

Lip Service: I want teams to be self-organizing, self-sufficient, and deliver value quickly to the customer with high quality;

Behavior Demonstrated: I don’t want to let go of the control I’ve worked so hard for and hold dearly. I must be able to leverage my personal authority – otherwise, what value does my authority bring?

This is a dysfunctional and destructive attitude for your teams, your organization, and your shareholders. For an agile leader, the value of your authority is that you have power to remove organizational and bureaucratic barriers impeding the progress of teams—exercise your authority through servant leadership. It’s amazing the change you’ll see in others as a result of first changing yourself. Reread that sentence again and stop to let it firmly embed itself into your psyche. To put it another way, you do not deliver value; you enable value delivery. I wrote about this topic last year in a blog entry titled What’s Your Role: Umbrella or Funnel?

Finally, when people speak of scaling agile they are usually talking about IT or software development—the technologists. This is about so much more than software development. The agile values and principles offer a promise of a more innovative way of managing and working in a creative era than the hierarchical control mechanisms invented by Frederick Winslow Taylor used to manage Industrial era assembly line work. Unfortunately, this is still the predominant management technology used today.

To extract maximum organizational benefit, consider embracing agile throughout the entire value stream. I’m talking about adoption that begins at front-end sales all the way to back-end support and customer service. The only question is, are you willing to adopt the behaviors and attitudes (as an individual) necessary to enable this type of change?  I’ve created additional content beyond what’s in this blog if you’d like to further explore A Case for Building the Agile Company.

Join the Discussion

    • Dave Gunther

      Great post, Brian. It is interesting to think about how much easier agile would be if we all truly shared agile values, and behaved accordingly. But there wouldn’t be as much to talk about. 🙂

    • Michael Moore

      Awesome thought on scaling Agile, Brian. Do your principles or practices come first? This is a great question to ask regardless of what you do. Is it a chicken and egg scenario for you? If so, it’s likely you don’t value your principles enough.

    • Greg Luze

      Excellent post Brian. Definitely nails the issue with adapting Agile to the enterprise. The misguided attempts seem to end up simply building process silos to go with the organizational silos they were supposed to replace. No process or practice will ever compensate for fearful leadership that can’t let go.

    • Mark Manta

      Great post. Interesting to see how scaling can be in conflict with the Agile Manifest itself. Also, a great point o make is that a lot of managers have trouble letting go of authority. Not realizing by doing so they enable others, and my enabling others then go a long way towards achieving their results.

    • Mark Taylor

      Excellent post, Brian. I work with the product team members on the marketing, sales, business and finance side of Agile delivery programs. One of the ways I get managers to elevate their authority view is organize the bits and pieces of the product world into: features, product, product line, product portfolio and product and business road-map. Two engines drive these element on a daily basis: product life cycle management (PLM) and market conditions. In the age of I-know-what-I-want-and-I-want-it-now managers’ authority view needs to be focused on barrier elimination and horizon setting. When given examples of how frequently significant changes occur in the market (on average every 8.5 days) and how they can impact the PLM, managers see the priority need is to stay current and communicate continuously to the other product team members. Self-organized teams work with current information and a view of the horizon.

    • David Koontz

      Nice article, I’ll have to read the other referenced links. I’m unsure of how one “scales a value”. but I think I understand your meaning – I think you mean to amplify the behaviors that result from the values – to scale the outcome of people holding those values and living / behaving consistent with the value system of Agile.

      I’m adding this article to my growing list of writings on the topic of scaling Scrum/Agile at:

    4 + 6 =