Jump to content

  • Log in with Facebook Log in with Twitter Log In with Google      Sign In   
  • Create Account

Shopping Cart

Your cart is empty right now

Scrum at Scale Part 1

- - - - - (0 customer reviews)


Scrum Inc.'s Alex Brown and Jeff Sutherland present an object-oriented model for scaling Scrum across the entire business enterprise. The modular object oriented architecture means the overall system to function together using different specific solutions for each module, which allows this approach to work successfully across a much broader range of contexts than other “tightly coupled” solutions. This course will cover:
  • the full case for a modular vs. deterministic model of scaled Scrum
  • the overall vision for a modular scaled Scrum that spans the Team, Program/Product/Business Unit, and Enterprise levels
  • specific examples of different successful practices
You will not leave this course with a cookie-cutter answer for large-scale Scrum implementations. Instead, it will fundamentally change the way you think about agile processes within your organization and will equip you to lead a thoughtful exploration of what the organization really needs from scaling Scrum.

When Jeff and Ken originally developed the Scrum framework, they deliberately ensured that each element of the framework could function independently and adapt to a variety of situations. Our Scrum at Scale framework borrows from the same principles to create loosely coupled modules. These modules act as the skeleton to which the muscle of different practices is connected, which enables the iterative implementation of agile practices by refining the highest priority modules(s) first. The approach reflects what we have learned over the last decade about large-scale agile implementations: the process is different for each organization, and top-to-bottom “big bang” implementations are the exception, not the rule.

Each module is defined by “goals” (what needs to be accomplished) “inputs” (information from another part of the organization) and “outputs” (what the module produces). The details of how these defining inputs and outputs are fulfilled is left up to the implementing team. For example, the Release Management module serves to ensure a consistent flow of valuable finished product to customers. It integrates the work of different teams into one seamless product and to provides a high quality customer experience through capturing and communicating feedback on the product & process. To accomplish these goals it has four outputs and three inputs:

Posted Image

The release module team is empowered to decide how it can best process the inputs and produce the outputs. And if the team is using Scrum, we can expect it to iteratively improve the internal process of the module. Below are three different ways we’ve seen the Release Management module configured:

Milestone Based

•Release is based on a pre-defined feature set

•Often driven by a set target delivery date

•Larger clusters of functionality delivered at once

•Product is not released until all required features are available

Release Train

•Product is released to customers on a pre-determined cadence (e.g. quarterly)

•Features that are ready in time for the release are included, otherwise they wait for the next release

Independent Releases

•Release management team decides when enough incremental value has been created to merit the overhead of a release

•As new independent functionality is judged “ready” it is released directly to customers

•Releases can happen multiple times a day

For a full presentation of the Scrum at Scale framework, join Alex and Jeff for the live online course on July 23rd.
Live broadcast: Wednesday, July 23rd, at 11:00 EDT
Length: 1 hour

All of Scrum Inc.'s online courses are eligible for Project Management Institute PDUs and Scrum Alliance SEUs.