Scrum The Toyota Way

Toyota Connected uses Scrum combined with the Toyota Production System to deliver Lean Production, enabling teams to deliver rapid PDCA cycles. Scrum of Scrums, Meta Scrum, and the chief product owner, are some of the approaches used to scale Scrum for multiple teams and products. Agility is not the goal. It’s a result, an outcome. 

Nigel Thurlow, chief of Agile at Toyota Connected, will talk about “Scrum The Toyota Way” at eXperience Agile 2018. This conference will be held in Lisbon, Portugal, on October 1 - 2.

InfoQ will be covering eXperience Agile with Q&As, summaries, and articles. This year’s conference theme, “Improving Through People,” is described below:

Discover the latest cutting-edge Agile practices by top industry leaders from around the world. eXperience Agile is more than just another Agile conference. This is an event that will highlight the most revolutionary applications of Agile being used today.

InfoQ interviewed Thurlow about how the DNA of Toyota connects to Scrum and agile, the challenges that Toyota Connected is dealing with, how they apply agile and what they have learned, the role of the product owner, how the C Suite fits into the agile world, and how Scrum and agile relate to the Toyota Production System and Lean Production. 

InfoQ: What’s the DNA of Toyota and how does that connect to Scrum and agile?

Nigel Thurlow: Everybody at Toyota understands the customer-first promise and the founding principles of TPS and the Toyota Way. When we discuss the value of embracing new technology and the digital world, we always have our DNA giving us the reasons why we need to do it: our customers. 

Customer First was first coined in 1946 by the first president of Toyota Motor Sales Japan, Shotaro Kamiya, and is the principle of considering the need and desires of the customer when determining direction and strategy.  Simply stated, it’s delivering the highest quality, in the shortest lead time, for the lowest cost.

Scrum is a framework to enable teams to deliver rapid PDCA cycles, where value is prioritized for the customer, and non value added work is eliminated.  It’s important to note that Scrum does not make you lean, and being lean does not mean you are doing great Scrum.

Agility is a result or outcome, and is not the goal.  Scrum is one way to help achieve that, in fact it’s the best way to codify PDCA I’ve worked with.  Everyone knows what PDCA is, but no one actually knows how long a PDCA cycle should last for.  What we are trying to do with Scrum is shorten that cycle.  The cycle to inspect customer feedback (check) and to adapt to that feedback (act).  I sometimes refer to this as PDIA, Plan, Do, Inspect, Adapt.

Just as Scrum does not make you Lean, being Lean does not mean you are Agile.  You can be Lean without being Agile, and you can be Agile without being Lean. They are different, yet very complementary concepts. We want to be Lean, delivering the flow of value the most efficient way possible, but we also want to be Agile by being able to respond rapidly to changes in customer or market demand, or responding to unknown events quickly.

InfoQ: What are the challenges that Toyota Connected is dealing with?

Thurlow: Toyota Connected (TC) was established as an agile startup to help Toyota respond rapidly to the changing connected-car technology space. We are not just talking about self-aware cars, but about providing a wide array of connected services to vehicle owners to serve their mobility needs. That’s the vision of Toyota’s President, Akio Toyoda, which we try to execute by leveraging the digital tools at our disposal -- from Artificial Intelligence to the Internet of Things -- enabling us to build the future of connected vehicle technologies.

We are working in an ever-fast changing world where time to market is no longer measured in years, but often in months, and soon even shorter durations.  As the ability to upgrade cars in real-time becomes an everyday occurrence, as well as the increasing levels of live data vehicles are now able to stream, we have to be able to deliver the benefits and capabilities our customers seek.  Whether that’s helping an insurance company set rates through accurate and meaningful driver scoring, or being able to correct an operational problem with an over the air update, to creating mobility options like the Hui car-sharing service in Honolulu in partnership with Servco Pacific Inc, and to integrating Amazon’s Alexa into Toyota vehicles and studying advancements in data science and AI. 

InfoQ: How does Toyota Connected apply agile?

Thurlow: We practice and teach Toyota Production System (Lean) and Toyota Way principles, but we are also an agile company by design. TC was setup to behave like a startup, but with the stability and funding of a global corporation. We create an office environment for great engineering and technical excellence, that allows teams to thrive in a creative and open way.  

Our small (typically five to six people) collaborative teams sit very closely together in open-space offices, with obeya rooms, visual management and andon displays all around them. Whilst we use electronic tools, we teach and encourage visual management to enable transparency and openness and to enable real-time discussions at the gemba with leadership and key stakeholders. 

We are focused on creating flow efficiency through eliminating bottlenecks and impediments to deliver value faster to the customer.  This involves studying multi-team science, something we have partnered with the University of North Texas to study, and conducting many experiments to define the repeatable patterns in many contexts to enable agility across the organization.  We are currently working on a number of scholarly white papers for publication in the coming months to share this learning with the agile world.  

A example of Multi Team Systems is Scrum of Scrums and Meta Scrum.  We define these as behavioral patterns, and it is through observing them we can identify what works and what struggles.  We can then experiment by adjusting the process and see the effect on the behavior.  As we refine these team interactions, we iterate and document them as patterns, both positive and negative.

Another example is the idea of creating a SoSM (Scrum of Scrums Master) and making them accountable for the release of the joint team's effort.  We find that this creates a command and control leadership style, as we now have a single person ‘telling’ the teams to deliver.  This dampens the collaboration between teams as they are now being measured and held accountable by a proxy manager.

We recognize that simply making a group of people use Scrum does not create a great team, and when we involve multiple teams we find the challenges are amplified.  Changing behaviors and teaching team skills is essential.  

Cynefin enables us to understand complex adaptive systems, and teams are indeed complex with many unpredictable behaviors.  It’s important to understand that it is task interdependence that determines if you need a team, and not people in a reporting structure who are necessarily a team, despite what the organization chart might say.  If individuals need to work consistently with other individuals to deliver something, then we consider them interdependent and we form a team, irrespective of reporting lines.  Those people work interdependently, adaptively and dynamically towards a shared & valued goal. 

Studying the work of David Snowden with the professors at UNT, we are starting to define behavioral markers that teams can self identify against and then self correct against, together with close coaching and support from the team’s Scrum Master.

We are defining what agility means to Toyota as a global corporation. We have taken a lot of industry knowledge and we are giving back to the community by trying to find synergies between TPS/Lean and the agile world. We have recently launched a public offering called Scrum the Toyota Way, for example, and after successful beta tests we are now planning a wider public availability of this training.  We continue to learn new things and evolve as our understanding of this world deepens.

InfoQ: What have you learned?

Thurlow: We have learned that agility is hard, really hard. There is also no such thing as an agile transformation.  You fundamentally have to change your operating model, and undertake an organizational transformation to achieve the agility you desire.  Scrum is but one item in the toolbox to help you do this. You also need a sense of urgency. If the C Suite don’t see a compelling reason to change, chances are you’ll actually make things worse by messing with the current condition, and the resistance to change will be overwhelming, with no mandate to actually achieve that change.

I’ve also realized that not everyone needs to be agile!  If you’re shipping concrete slabs you probably don’t need to do that in two-week sprints, as the need to change rapidly is not there.  Sure, Scrum will give you a planning cadence, but Scrum was intended to work in complex domains and with complex systems.  These are areas where a linear approach and fixed thinking are not effective.  

If you are working in a domain that is fixed and varies little, then agility may not be as important as being Lean.  Optimizing the efficiency of product flow may be much more beneficial.  If however, you are working in a fast changing ever evolving market, then agility is crucial.  Remember, you can be lean and not agile, and you can be agile and not lean. I’d suggest that agility plus lean is a winning combination.  You could say that Agility is delivering the right thing, and Lean is delivering the thing right.

InfoQ: How successful is Scrum for you?

Thurlow: If you are a one team one product startup, Scrum is very simple to apply, and very effective.  If you put a group of highly talented individuals together in a room and provide the motivation and the challenge, they’ll create great things.  Scrum is highly effective at shortening the PDCA cycle and delivering rapid results, by enabling rapid response to change, a key agile tenet.

Scale that to one team with many products and the product backlog becomes a team backlog. Prioritization now becomes much more challenging as many stakeholders vie for the number one spot.  Making that team backlog visible to leadership is critical to enable real-time discussion and prioritization.  And when I say visible, I mean on a physical board across a giant wall or a series of whiteboards stitched together.  This is precisely what we are doing at Toyota Connected.

Scale that to many teams on the same product, and certain patterns become useful; patterns to enable higher level backlog and product management.  It’s here we start to use Meta Scrum for the management of backlog, as well as Scrum of Scrums for the management of delivery across multiple interdependent teams.  The coordination of multiple dependencies between teams and products is amplified and so the need to find pragmatic techniques to coordinate that collaboration is essential.

When you scale that to many teams on many products, the complexity scales exponentially.  Now throw in numerous dependencies, and constraints, whether that’s multiple partners or vendors, or built in constraints within a global corporation, and agility becomes far more complex to achieve.  The concepts are the same, the tools are the same, but the context alters everything.  This is where organizational design and the operating model have to change and evolve.  

We have clearly recognized that there is no one-size-fits-all scaling framework. Frameworks are context agnostic, but at scale context is everything.  Patterns, techniques, experiments, and empowered teamwork are all essential, but there is no silver bullet, not yet anyway.

InfoQ: How crucial is the role of product owner?

Thurlow: The product owner role is critical to the success of a Scrum team, but is also the most challenging to get right.  The Scrum Guide notion of the team doing the heavy lifting on creating the backlog is not workable in practice at scale. Developers do not always possess the skills or desire to be the owners of a product backlog, even if the PO is still accountable.  Being able to sell and market a product, as well as do the business analysis side of the role requires certain disciplines that are not plentiful in highly technical engineers, nor is it the best use of their skills and talents.  If that role does exist or evolves within the team, then the team effectively become a product owner anyway.  Of course, this depends on the way you define Product Ownership, and the bigger picture of Product Management.

Various scaling approaches attempt to remedy this through various means, but we have come to realize that we need a clear product owner in that role, and that while the role is singularly accountable, the role of product ownership is an activity that involves many people.  A single team concept does not scale without adaptation and without immense discipline, and such discipline is hard to achieve in a large corporation.

Through the study of the product owner role, we have realized that we needed to codify the actual work of creating the backlog.  Afterall, we need the backlog for the team to work on, and for the team to refine. Therefore we created an activity called Product Backlog Development.

Product Backlog Development is the act of creating Product Backlog Items. This is an ongoing process in which the Product Owner together with any required stakeholders create Product Backlog Items. Required stakeholders may include; Customers, Subject Matter Experts, System Users, Business Representatives and support from any group necessary to help the Product Owner develop backlog items. During Product Backlog Development the product vision, strategy and roadmap are created, reviewed and revised. Product Backlog Development occurs every Sprint.

It may seem simple, and probably others would argue not needed as the Scrum Guide defines this anyway, albeit less explicitly, but what we have found is that it does not define it well enough, so we simply did.

We do of course promote and enable open and effective communication between the teams and the actual customers, but often we found that the product owner being actively engaged is more effective day-to-day, especially where we have time zones, language, and technological limitations.  We also use the chief product owner concept when we have many teams working on the same product.  The chief product owner enables effective communication between many teams and a customer, as well as working with other product owners to ensure everyone is aligned and focused on the highest priorities.

InfoQ: How does the C Suite fit into the agile world? 

Thurlow: Executive and senior leadership engagement is key once you start to scale the number of products, or the number of teams. At Toyota Connected we scale the role of product owner to the executive level and we conduct an Executive Meta Scrum monthly to review enterprise progress, ensure alignment to vision and strategy, and to make critical prioritization decisions.  

We also have an Executive Action Team (EAT) where the same senior executives meet frequently to review impediments (blocking issues) and self assign them for resolution.  This means the EAT behaves like a Scrum team, pulling impediments from a backlog and executing work to resolve them.  In larger more complex multi vendor or multi affiliate product delivery, we may also have an intermediate Leadership Action Team (LAT) to resolve impediments or to take more rapid action before it is escalated to the EAT.

If you don’t have this engagement, you will find the ability to change direction or priority quickly is diminished, and with it your agility and perhaps your competitiveness.

Executive engagement is also needed to tackle the silos that exist in large companies and organizations. It’s a challenge to eliminate the silos that evolve and protect their existence. This makes value stream design long and painful, and as Peter Drucker once said, “any innovation in a corporation will stimulate the corporate immune system to create antibodies that destroy it.” To truly transform an organization we must optimize the system for the flow of value, and this means looking at the whole system, and changing the whole system, if that is what is needed. 

We must stop doing agile and start enabling flow and shortening the feedback loops.  Then we will become agile.

InfoQ: Toyota is known for the Toyota Production System and Lean Production. How does Scrum and agile relate to this?

Thurlow: Scrum, the predominant agile framework, was based on the Toyota Production System (what many refer to as lean, a term coined by the authors of the book, “The Machine that Changed the World,” the first major publication on how Toyota manufactures products) and, as I was recently told by Ken Schwaber, on DuPont’s influence to adopt an empirical planning approach.  In fact, Scrum is simply an empirical planning approach, with rapid feedback loops built in to enable certain behavioral characteristics in a team.  It is PDCA codified with time boxed steps. 

How long should planning, doing, checking and acting last? And what is actually happening in each of these phases? Scrum codified this, providing discipline around PDCA.

TPS/Lean is the gold standard for lean product development.  Codifying PDCA using Scrum is providing a mechanism through which we can improve our responsiveness to change, and to constantly inspect and adapt the value we are delivering to our customers.

However, agile isn’t saving lean and lean isn’t saving agile; the agile movement is enabling companies that are already lean or may wish to be lean to make decisions faster. We are using frameworks like Scrum and tools coming out of the Toyota Production System to enable business agility, thus developing the ability to respond more quickly to market trends. “Agility is not the goal. It’s a result or an outcome”. 

InfoQ: If InfoQ readers want to learn more about Scrum The Toyota Way, where can they go?

Thurlow: Right now we are testing a number of public classes. We have just held two beta classes and will be holding two more public classes, one in Portlandand one in Dallas.  We are also sponsoring Agile Camp. The event in Dallas is in final preparation and will soon be announced on various social media platforms by Agile Camp.

We also offer a 100% discount for our military veterans and serving members of law enforcement so they can attend and learn new skills for re-entry into the jobs market and help them serve the public more effectively.  

About the Interviewee

Nigel Thurlow is an Organizational Theorist, Continuous Improvement Leader, Agile and Scrum Expert, and The Chief of Agile at Toyota Connected. He is an internationally recognized industry expert on Lean and Agile approaches and is leveraging the power of The Toyota Production System and The Toyota Way to enhance and develop Agility in Lean Product Development.