Scrum@Scale is a framework for scaling Scrum invented by Jeff Sutherland. Scrum was created to help a single team deliver products in a complex environment. Scrum@Scale is for multiple teams to collaboratively deliver products in a complex environment. It is designed to create agility for an entire enterprise. Its primary use is to coordinate the efforts of multiple Scrum teams in delivering complex products and services. The flexibility of the framework allows it to be used in multiple ways.
Three ways that I have found the framework useful is as an execution model for delivery, as an assessment tool, and for transformation guidance.
Execution Model
Using Scrum@Scale as an execution model is its main purpose. Collections of teams that need to collaborate to create a product increment form a dynamic network of stable teams known as a Scrum of Scrums. The Product Owners of those teams form a Product Owner Team led by a Chief Product Owner and execute the PO Cycle for the SoS and representatives of the teams hold a Scaled Daily Scrum to coordinate shared work and to remove impediments. Those impediments that cannot be removed by the SoS are escalated by the Scrum of Scrums Master to leadership or the Executive Action Team (EAT) to remove.
Teams may use practices like Scaled Sprint Planning to establish a shared Sprint Goal for the SoS and manage dependencies. They can hold a single Sprint Review to inspect the work product increment produced by the SoS. They may even hold a Sprint Retrospective for the SoS to share learnings and improve as a network of teams.
Organizational priorities are handled by the Executive Metascrum (EMS) where the Chief Product Owners meet with stakeholders to set these priorities that are then communicated through the network to signal organizational intent and gain alignment.
Business agility emerges when these structures and rules are followed.
Assessment Tool
The components of Scrum@Scale are descriptions of the capabilities needed to successfully deliver products using multiple teams. Each component describes its goals leaving the actual implementation open to what might work in your particular organization.
Given that, no matter what scaling method you use today, you can use Scrum@Scale to assess where you are currently and use the Scrum@Scale patterns and practices to improve them. For example, the Release Planning component’s goals are: forecast delivery of key features and capabilities, communicate delivery expectations to stakeholders, update prioritization, as needed. Say you are doing SAFe®, you can assess your Roadmap and PI planning to determine if the goals are being met. If not, you have something to work on improving.
I use the “heat map” exercise from the training where you bring people involved in your agile implementation into a workshop. You should include team members, leaders, facilitators, product folks, and stakeholders to get a 360° view of the current state of agility. The workshop will go through each component plus 3 “mega-issues” (Prioritization, Working Product Every Sprint, and Organization Refactoring) and ask everyone to assess using these symbols on post-it notes:
Each participant places them on the wall in their own column to create a map like this one:
From this map, the participants can choose where to focus their improvement energy.
Transformation Guidance
Scrum@Scale also guides organizations during their transformation. The EAT is formed with authorized individuals to own the transformation backlog. They execute the Organizational Change effort by creating the sense of urgency, transformation vision, and communicating that vision to everyone in the organization so that appropriate structural, process, and policy changes can be enacted to create business agility. Working with a Agile Practice Team who owns the Scrum and Coaching competency in the organization, they periodically hold the assessment workshop described earlier to populate and prioritize the transformation backlog and empirically improve the organization. These items may include changes to the Product Development Process, HR policies around performance management, finance policies around budgeting and purchasing, and processes around portfolio management. As these transformation backlog items get executed, new Scrum teams, consisting of people across the organization, can be formed to make the organizational changes needed to improve business agility.
Conclusion
There are several alternative frameworks available today. Some are very prescriptive and heavy weight, others only address the product deliver problem with no mention of organizational agility. Scrum@Scale is a powerful framework that addresses both whole organizational transformation and product delivery using many teams. It is less prescriptive on specific practices and enables dynamic network of teams to increase business agility. I encourage you use it to enhance any agile method you’re using, be it LeSS, Nexus, SAFe, DAD or a custom version of your own by using its assessment tools, transformation framework, and practices from the execution model.
Join me at our next Scrum@Scale Certified Practitioner course coming soon. You can register here: http://www.freestandingagility.com/training/certified-scrumatscale-practitioner/
Comments are closed.