Parte 2: Duplicar la productividad mediante un liderazgo Scrumming

por Steve Daukas | Nov 13, 2017 | Blog

Read part one of Doubling Productivity by Scrumming Leadership

In part 2, Steve shares his success and details the deployment steps of this Scrum at Scale transformation.

My engagement with this particular division of the organization began shortly after a meeting at headquarters presenting to the technical leadership of the Fortune 100 corporation. That was in February. It was in April, after I had been working with this division for about 6 weeks (3, 2-week Sprints) when the velocity data and happiness metrics indicated that I had the information the leadership team needed to take things to the next level.

The leadership team had been very supportive of Scrum and were attending training and actively engaging in Sprint Reviews. They had proven themselves open to feedback coming from division-wide retrospectives. For example, at a leadership meeting, the GM stated “Since deploying Scrum, I have much better real-time visibility of what’s going on with key projects. I don’t always like what I see, but I know what’s going on!”

However, the leadership team had not yet run as a Scrum team themselves.

An early morning meeting with the head of R&D and the GM secured the support necessary for organizing the leadership team as a scrum team, complete with a Scrum Master from outside the executive organization. When I asked the GM if he and his team were ready to run as a Scrum Team, his reply was "yes, full steam ahead!"

This Leadership Scrum Team would host both the Executive Action Team (EAT) and the Executive Meta Scrum (EMS). They would work off of both a transformation backlog and a second backlog with stories representing the value they would deliver to their own staff and shareholders. The GM would be the Executive Product Owner for the EMS.

Of course, a transformation to authentic Scrum, or what Dr. Sutherland calls "Aggressive Scrum", doesn't take place overnight. It is a journey. However, that journey doesn't have to take years and organizations don't have to settle for a sub-optimized version of Scrum. This organization was able to define its vision for the transformation, and begin to pursue it in just a handful of Sprints.

The key to success was experimenting with scaling scrum across R&D, which necessarily involves the Quality and Manufacturing departments. These critical functions were integrated using 4 simple rules for scaling Scrum. Those simple rules, or ingredients, include: having a dedicated Scrum Master, Team, and Product Owner (in other words, actually doing Scrum at the team level), scaling the Scrum Master via the Scrum-of-Scrums, and scaling the Product Owner through the Meta Scrum. And, as we know from research concerning Complex Adaptive Systems, these simple rules allow for easy adaptation to the needs of a changing, complex organization.

Of course, we already had Scrum teams with Product Owners and Scrum Masters. And, those teams were coordinated through the Scrum@Scale "Scrum of Scrums" for the R&D organization with the Lab EAT being the focal point of the escalation of the various team's impediments. I had also initiated daily Meta Scrums immediately after the 15-minute Lab EAT so that we could determine how to best leverage the Scrum@Scale framework in its entirety for the whole organization, not just R&D. We tried a few different permutations and ended up with the arrangement below:

By running a daily Meta Scrum, we were able to inspect and adapt based on feedback and arrived at the best structure for the organization at that time. We decided to run the Meta Scrum twice a sprint anticipating an eventual once a sprint cadence. The structure of the Meta Scrum is depicted below:

Putting this together gives us the current Scrum@Scale picture:

This is asymmetrical in that impediments are still concentrated and escalated through the Lab EAT. This is a pragmatic practice until such time as leadership can scale Scrum across the entire organization.

In another few sprints, as the organization further refines how to scale Scrum based on the data being collected, we have an expectation that we will arrive at something closely approximating the following:

This desired end state is more fractal in that impediments and backlog associated with a particular deliverable (product, product line extension, component, etc.) are co-located within the Scrum-of-Scrums or Scrum-of-Scrum-of-Scrums that is responsible for that deliverable.

The leadership team has learned that a Scrum transformation isn't just following a recipe. Leaders actually have to commit to making Scrum their "day job" and endure the heat of the kitchen with their teams. They need to both work with and coach the rest of their organization on how to orchestrate their teams' individual dishes into one great dining experience.