Scrum Scaled for Large Projects and Organizational Initiatives

Jeff Sutherland and I have helped hundreds of organizations scale their projects, enable their entire product development, and thread Scrum through their organizations. For sure, none of them were easy, and each had its own unique challenges. Each had its own structure, culture, goals and strategies, challenges, current practices and infrastructure, domains of competence, existing software, and people.

We assert that only a systematic, emergent, managed initiative to scale succeeds. Every initiative to scale is unique. Nobody knows what your organization needs to scale Scrum. And, nobody knows what your organization will look like as you scale.

To get a good feel for what scaling Scrum feels like, I refer you to Eliyahu Goldratt’s “The Goal” (or any of his later books), or Gene Kim and Kevin Behr’s “The Phoenix Project.” You will see the difficulty of teasing through symptoms to root causes, the effort to find solutions, and the possibility that solutions have undesirable side affects.

Lately, we have watched with amusement and then growing concern as the methodologists have rolled megaprocesses they assert are the silver-bullets to scaling. Although they look familiar, the familiarity is only skin-deep. As anticipated, these cookie-cutter approaches fizzled out within months of being deployed.

Scaling scrum requires concerted effort by an organization. The leaders should start thinking about answering these questions:

• How often does the work have to be released?
• What techniques are going to be used to integrate work to that frequency?
• What will be done to measure and manage the work and its integration?
• What overhead is being absorbed to achieve this integration and delivery?
• Are the cost and benefits of delivery frequency balanced by value returned?
• How is the cost going to be systematically reduced?

Based on experience, we have created frameworks that provide the sinew from which scaling can proceed. Based on your current unique situation, you can progressively scale the Scrum artifacts, integration and communication techniques, domains of competence, team formation and structure, release management, practices and tools for automating them, and so forth onto them.

Jeff and I cannot be everywhere, so we’ve had our teams at Scrum.org and ScrumInc develop several workshops to help you get going, to use the framework systematically and effectively.

For me, Scrum.org is conducting two-day workshops that will have development leads and managers build out the framework to fit their specific situation and needs. These workshops are for people who will do the scaling, results-oriented workshops, not overviews. At the workshop, they will learn how to extend a single Scrum to large projects and organizational initiatives. The first workshop is in Boston on December 4-5, and the second in Amsterdam (Delft) on December 11-12. Others will be announced during December.

If you want to successfully scale your organization’s use of Scrum, based on your own needs, experiences, and goals, we look forward to meeting with you.

26 thoughts on “Scrum Scaled for Large Projects and Organizational Initiatives

  1. It is great to see that a formal sessions starting on scaling from scrum.org. I am hoping that soon scaling framework as well will be out.

  2. Pingback: Scaling Scrum - The Agile Product Report

  3. Certainly peaking my curiosity Ken:). I love the suspense:). I hope to make one of these workshops as I want to hear and see more. Curious about the lens and comparison / contrasts with models from LeSS(Larman/Vodde), Spotify/kniberg, SAFe, Mike Cottemeyer, Mike Cohn, and you/Jeff from some years ago . Suspecting more in common with your own scaling approach (which I though needed more meat on the bone), Cohn and Larman/Vodde(LeSS), and less in common with SAFe? I am a great fan but I didn’t buy into the Enterprise and Scrum as I thought change was a missing trick, a field in itself. Also curious whether you and Jeff added some tricks from Change Leadership, Change Evolution, and Viral Change™. The scaling models, Cohn aside, seem to lack that, and even then seems too light even for lightweight methods.

    • All of the popular things are there along with metrics, value and software. What is unique is focusing on the technical and professional elements of the infrastructure and the actual engineering of software, from once a month to 8x per day. At its guts this is technical and engineering.

  4. The mapping of responsibility to need trips up efforts, but not nearly as badly as control of artifacts. The end of the Sprint comes, and there are four or five versions of the same thing, they don’t integrate, and the time for integration was at the start of the Sprint. We’re going to ensure that people know how they are going to scale all of the Scrum artifacts to suit their situation, so scaling is possible.

  5. This convergence towards inspective and adaptive methods of agile transformation is to be applauded, as deep organizatonal change cannot be templated. It must be ordered and managed empirically.

    My concern is that the relative positioning of Scrum at Scale with initiatives such Agility Path and EBMgt is unclear. I agree that you and Jeff “can’t be everwhere” and this…with SAFe having already gained traction in the boardroom…is why it is now so important to establish a coherent narrative.

  6. Reblogged this on Technology One Unplugged. and commented:
    Ken Schwaber’s point of view on scaling Scrum. With a smile I’ve read Ken’s comment: “Lately, we have watched with amusement and then growing concern as the methodologists have rolled megaprocesses they assert are the silver-bullets to scaling.”

    Growing concern, I must concur. As well, I experience how organisations are struggling and seeking how to scale scrum. Recently, Gunther presented the issue at #atbru (Agile tour Brussels) in his talk “Empirical management explored”.

    My observations:
    * Organisations not yet able to decently organize Scrum at team level, should not embark on a journey to scale Scrum beyond that team level.
    * If such organisations do attempt to scale Scrum, they will scale dysfunctions.
    * Organisations still stuck in the classic management paradigm are steer-less seeking to get product creation organised in an incremental and iterative way, still mixing it with many waterfall practices (predictive long-term project planning, absurd guesstimates, lack of transparency, …). On the way, they end up with a self-defined framework; mixing it all up.

    The bottom line is:
    * Invest wisely to get organized to transform your teams to Scrum
    * Invest wisely to maximize Scrum at team level, and next with multiple teams, and next with multiple products > this subsequent growing approach is the sound approach to scale
    * Live and breathe the Scrum Stance and agile values
    > Invest in people and teams
    > Manage and plan based upon real metrics and evidence
    > Focus on business value

  7. Hi Ken,

    I love the way you strive to get this industry out of the grips of waterfall and the forces that entangle it.

    I’m working with a company with 1000+ SW designers. We having been working SCRUM in name only with a few teams. The company now opens up for other ways of working and I want to warm management up using SCRUM at scale. It’s an endeavor with which I want to loose the suffix ‘in name only’ and get the famous ’empowerment’ and passion back into the organisation. I want to flatten the organisation, get less formal roles, improve collaboration and shared responsibilities. Make work more fun and as a consequence get higher productivity and quality.

    At this scale something extra is needed. Looking at ideas like SAFe, DAD, Agility Path, LeSS and even Water-SCRUM-Fall, I wonder what is the right approach. I read your opinion about SAFe. How would you say the other ideas compare?

    • LeSS from Bas Vodde and Craig Larman shares Jeff and my approach … we build on Scrum as is and provide practices, techniques and the structure for actually scaling. The biggest complaint about DAD and SAFe is that they add overhead but don’t tell you how to scale.
      Ken

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s