Alcatel Lucent

Adopting LeSS in a Multi-site Product Group

During 2010 & 2011, while working at Alcatel-Lucent, I was asked to help out one of their product groups that was located across three continents, building network equipment for use worldwide. The group was struggling with, among other things, increasing product complexity as it became more feature-rich, and also needed to support previous versions, and increasingly aggressive marketing dates.

The combination of factors strongly suggest something exploratory and iterative, such as Scrum at scale, as a way of “buying information” and leveraging feedback from the market early and often.

The distributed nature of the people wasn’t unusual, but in Scrum terms this was going to be well over ten teams. Time to learn better ways to scale scrum. In 2010 we brought in Craig Larman, who worked with the management team, Scrum Masters, coaches and teams to explain how to apply Large-Scale Scrum (LeSS). For all these teams, we introduced a single common Product Backlog, one Product Owner, a common Sprint and delivery, and so forth. The transparency and coordination shot up, and as you might expect, knowing the truth rather than asking people to make hopeful predictions regarding deliveries raised a lot of eyebrows. Management came to appreciate the transparency once they learned how to manage in this new environment. All the things they need are present, just in different forms and places.

One of our business people stepped up to fill the void and became an exemplary Product Owner, making tough priority calls around features and managing expectations with the stakeholders. She really resonated with the role once she settled in. Because half the teams were on the opposite side of the globe from the Product Owner, she had a single local proxy Product Owner at each other site to be physically present with the teams. The Product Owner & the proxies worked very closely to make sure they were always in sync, and the product delivery came together very nicely.

Later, in the name of cost savings, all the work was shifted to Asia and the other two locations were disbanded. At least one of the teams had normed and was arguably high-performing, and instead of breaking up to seek new jobs as individuals, they shopped themselves as a team, and found another product to work on, recognizing that they were stronger and more valuable together than separately. They had learned how to learn.

I have been applying LeSS on every product I have been associated with since, as it has become clear to me how to make this work. In particular, I believe one of the key ah-ha moments for teams working at scale is when they realize how to slice the work so it retains an end-to-end aspect, which immediately ameliorates the vast majority of the dependency issues that people seem to stumble on.