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:
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.
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.