Case Study

Toyota: Leveraging Existing Communication Paths

“[Scrum@Scale] forces us to look at the real issues and talk about what is going on.”
– A Toyota Scrum Master

Case Study Snapshot

Trainer Name: Dave Slaten
Organization: Toyota
Industry: Automotive
Org Size: Large
Date: 2016-17
Website: Scrum Inc.

We reused their existing structure to build something new and better. This was more efficient and easier for them to accept.  

Summary

Change under any circumstance can be difficult. All the more so when it is dictated by a strict “one size fits all” architecture that demands adherence to a plan that may or may not work for the organization in question.

This is why Scrum@Scale lacks the rigid architecture demanded by other scaling methods.  Instead, Scrum@Scale relies on a lightweight framework which can be superimposed over an organization’s existing events, meetings and communication pathways. These meetings then evolve from what they were, largely status reports, into what they should be, ways to efficiently run scrum teams in order to maximize key metrics like productivity and team happiness.

LAUNCHING AN EAT

Toyota has invested more than $7 billion in their Georgetown, Kentucky manufacturing plant. It is now the company’s largest manufacturing facility on the planet. In 2017, Toyota wanted to transform their information systems group, which supports the plant, using Scrum@Scale techniques.

And I had experience doing just that. In fact, this was the second wave of just such a transition. We had already trained 50 to 60 people in earlier in California. So both Scrum Inc and Toyota knew the first step to take – create an Executive Action Team (EAT).

So we launched an EAT with the key goal of removing impediments which the Scrum Teams could not deal with on their own. That’s when I heard something a little surprising. “Nobody is bringing us any impediments.”

FIGHTING A CULTURE OF FEAR

A system without impediments would be something to see. So we immediately began to examine this claim. What we found instead was not perfection, but rather a system where individuals were afraid to speak up.

It was easy to see why. Many of the Scrum Masters and team members were contractors and not full-time staff. Their employment status provided a disincentive to speak up. When impediments were raised some were publicly rejected as “something you should be able to sort out yourselves.” Still, other impediments would be placed in the doing column of EAT’s Scrum Board and there they would stay for several sprints. Eventually, and sometimes inexplicably, they would move to the done column, or simply disappear altogether.

None of this built trust or showed transparency in the system. A lot needed to be changed. And not just with the EAT.

Many Scrum@Scale implementations efficiently coordinate the work of multiple Scrum Teams by focusing them on a single product. But this division of Toyota required a different approach.

They were responsible for fulfilling a series of relatively small requests of many customers. So the model for its delivery system was the opposite – one team: many products.

Complicating the situation was a pre-existing series of meetings which management left in place. Rather than add to the meeting overhead, we decided to evolve these meetings into what they should be; Scrum@Scale.

We asked, “Where do you currently talk about your project level impediments?” Two meetings quickly surfaced.

THE WALL CHART

The first meeting was a 90-minute long status report known as ‘The Wall Chart’ meeting. This is where project managers would answer the standard questions of what are your accomplishments, risks, etc.

This product management template had been used for decades, so changing it overnight was not readily accepted by the management. So we started taking small, incremental steps of change. The first iteration was to remove the Gantt chart and replace it with a Burndown chart. This way management could stop guessing at the future and start planning for it using empirical data.

Then we were able to show the Scrum Masters and Product Owners how the information on their Scrum Boards would feed this changing ‘Wall Chart’ meeting.

Organically, this meeting evolved from a 90-minute long status report to a 45 minute long Scrum of Scrums. The focus shifted as well. Now fixing project level impediments was the goal. And the organizational impediments which could not be fixed at this level were passed up the loop, eventually reaching the EAT.

We had built a Scrum master loop on top of their existing platforms all while cutting the meeting time in half.

SCRUM@SCALE SATURATION

We found the second key meeting by asking a simple but important question, “where do you decide the highest priority project for the company?” This would lead us to the Product Owner side of the equation.

Toyota had one event called ‘The Investment Council’. This is where stakeholders decided what was the most valuable thing for the manufacturing group to work on at any given time.

It met just once a month and clearly represented a one-directional communication flow. That needed to change.

So, we built two additional events on top of their existing ‘Investment Council’ meeting to fill in the Product Ownership loop.

This allowed Toyota to continuously answer key questions about market conditions and technology. And it fostered better communication by turning a one-way channel into a true feedback loop.

In essence, we showed them the key missing pieces of the Scrum at Scale puzzle based on what they were already doing.

RESULTS

The flexibility of Scrum at Scale allowed Toyota to change at a sustainable and organic rate. We reused their existing structure to build something new and better.  This was more efficient and easier to accept.

And the changes have stuck.

Project impediments are now largely dealt with on the team level. Those which do reach the Scrum of Scrums are resolved in a more direct manner. Product Owners are able to prioritize backlogs with a clear understanding of the business value goals of the group. And Scrum Masters tell us the teams are re-engaged for a simple reason; things are getting done.  

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from the Scrum@Scale team.

You have Successfully Subscribed!