Scrum@Scale is a framework developed by Jeff Sutherland to enable networks of Scrum teams operating consistently with the Scrum Guide to creatively deliver products of the highest possible value. It differs from other frameworks in that it is less prescriptive on the structure and practices required and focuses more on the organizing principle of using scale-free networks of teams and the component-based structure of the framework.
The Scrum@Scale Guide defines and describes the framework: http://www.scrumatscale.com/scrum-at-scale-guide/
Why a scale-free network?
Most organizations are hierarchical, with authority centered at the top, and many levels resulting in long decision cycles and frequent status updates to keep leadership informed. This structure reduces agility and responsiveness, as well as, reducing the autonomy of the workforce and therefore engagement of the teams delivering value.
Scrum@Scale organizes via networks of teams, each with full autonomy within their scope, interacting with each other as needed to deliver value quickly. Authority is distributed via the Scrum guidelines. Product Owners at all levels have the authority over the content of their area aligned through the Product Owner Cycle. Scrum Masters are the owners of the process and work together to improve flow and effectiveness of the organization. The Development teams have authority over delivery. The Scrum Guides states “No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality”. This authority distribution model enables agility and engagement. It also allows the growth of agility to expand organically based on the needs and desires of the people in the organization.
In a scale free network, a small number of nodes contribute heavily to connectivity. These nodes are called hubs. In Scrum@Scale, the hubs are the Executive Action Team (EAT) and the Executive Meta Scrum (EMS). These teams provide the vision, alignment, and process improvement focus of the organization. Content and delivery are executed by the Scrum teams in the network that connect to each other as needed to achieve value delivery. Scale-free networks tend to promote high speed transfer of information or energy. Their hubs, EAT and EMS, have a combination of high global connectivity with highly developed local clustering. Consequently, there is a rapid synchronization of distant nodes.
A scale-free network is “robust”. It can still operate with a random removal of a few nodes or teams. But, the failure of a hub can fragment the system into a number of smaller islands, causing connectivity failure. Thus it is essential that a strong EAT and EMS are in place. Without them, delivery is fragmented and potentially not aligned with corporate priorities.
Scale-free networks are “self similar”. Any part of the network is similar to the whole network. This allows clusters of teams to align on a product delivery or product line alignment without the need for “top nodes” needing to get involved in the details.
Why a component architecture?
Many frameworks are very prescriptive with many parts that need to be implemented at the same time. Scrum@Scale’s component architecture allows organizations to execute a transformation strategy that suits them. They can start with the weakest and most impactful components and then move onto others when they are ready.
The second advantage of the component architecture is in how each component is defined. They are not prescriptive practices that must be followed to the letter to work, but rather a set of goals that the component must achieve with the expected inputs and outputs. This allows lots of flexibility in how an organization may choose to implement the practices within the component. As an example. the Team-Level Process does not specifically require Scrum! Although Scrum is strongly recommended, its definition states that the team process must achieve the goals of maximizing the flow of completed and quality tested work; increase performance of the team over time; operate in a way that is sustainable and enriching for the team; and to accelerate the customer feedback loop. Teams doing complex work like product development, well-run Scrum accomplishes these goals. Teams doing complicated work with standard repeatable steps can use other methods and achieve the same results. As long as the goals are achieved, the component is satisfied.
Want to learn more?
Contact us for consulting, coaching or to attend one of our classes. You can visit http://www.scrumatscale.com/ to read the guide, review case studies, or find a class close to you.
Comments are closed.