John Deere

Fixing Misconceptions When Scaling: Introducing LeSS

John Deere is a leading agriculture-products company that has faced long and challenging development cycles with quality problems after implementing a process for regularly delivering software within a “release train” scaling approach two years before my arrival. The following main challenges drove the need for changing the set-up:

• Missed delivery dates
• Quality problems
• Missing trust and product ownership
  
  
  
  

When I started coaching four teams, located at the same site, it was obvious to see that there was a need to change several misconceptions. In introducing Large-Scale Scrum (LeSS), this involved related scaling aspects and organisational impacts; the prior incorrect belief was that “scaling agile” would not have to impact the existing organizational structure and manager positions.

Large, multi-site, and offshore elements were other aspects within this product development context, but are outside the scope of this article.

The following sections summarize how various “experiments” and guides in LeSS helped to fix misconceptions. Most of the following points thatwere applied are found in the 600 experiments described in the 2008 and 2010 LeSS books by Craig Larman and Bas Vodde.

Managers (and Others) Starting to Learn, Help, and Teach

After my arrival as a coach, managers started working on an impediment backlog and service.

Managers were educated in lean leadership, and also taught their teams lean thinking.

Senior developers were very helpful at this moment, as they were encouraged to (and did) bring in new techniques, and more important, a new mindset to their teams. This was really helpful.

And Scrum Masters and managers were educated formally in LeSS. A three-day offsite to join a session with Craig Larman was not only helpful, moreover it was an icebreaker for many further steps.

Functional Reorganisation

After the LeSS workshop with Craig, it was clear that organizational restructring was needed, and deep organizational changes were done. This included all team members reporting under one person, and the creation of new cross-functional teams.

Environment, Communication, Collaboration

On a communication level, visual management with physical boards, build monitors, and a “PSPI roadmap” was installed next to the senior manager.

There was a relocation of team spaces to truly co-located teams, and this helped to work efficiently on features together.

As former testers within the new cross-functional teams learnt to write automated Cucumber tests, development became acceptance test-driven and Product Backlog refinements got filled with important questions about testing acceptance criterias. Discussions became result-driven!

Scrum Masters stopped represented Teams in Scrum-of-Scrums meetings. Instead, teams experimented with different methods in direct communication and coordination without intemediate managers or Scrum Masters.

Step by step, the state of common Sprint shared by all teams and of the product development became visible and transparent.

Collaboration and Coordination

Collaboration was easily realized and naturally propelled by co-location of teams for planning, joint design workshops, and pairing workstations.

Dependencies were discussed in planning sessions with impact- and story mapping. As dependencies were finally seen and understood as introducing variability and delay from the viewpoint of the overall system delivery, teams started to reduce them.

Product Owner and Product Backlog

We introduced one overall (real) Product Owner with one Product Backlog, and some other “fake product owners” to help teams and the overall Product Owner to create a high-quality Product Backlog.

Summary

Agile practices and the LeSS framework helped this group to solve common misconceptions. Teams were able to give a useable realistic forecast for the next release and deliver in time and quality. Within half a year, the teams were able to plan and forecast delivery dates reliably upfront. Massive quality problems were fixed and teams became focussed. And it wasn’t just the teams: great managers, Scrum Masters, and Teams together were responsible for improving this System. All of them inspected and adapted their behaviours and supported experiments to learn from.

Learnings

First, a warning: After experimenting with Scrum in large-scale groups for more than 8 years now, I want to emphasize Craig and Bas’s advice when they introduce LeSS: Don’t do or believe your need to do large, multisite, or offshore development. Instead, focus on creating great products with a small number of extroardinary multi-skilled developers who are co-located, in touch with customers, and with a strong business-thinking Product Owner.

But if there is no way to avoid scaling, then try LeSS. It works. Without any compromises to regular Scrum. And ask yourself again and again, why it’s useful for your product not to follow one of the more than 600 practices, which Bass and Craig collected for you.