Nokia Networks (Comparing Two LeSS Huge Adoptions)
Will Your Second LeSS Adoption be Easier?
Your company has successfully adopted Large Scale Scrum (LeSS) for one product. Results are promising and you want to have more products adopting LeSS. You might think it will be easy for the second product – you just cherry-pick some key contributors from the first product and ask them to do the job. They have the experience of the first successful adoption and they will transform the next product in a blink of an eye. Unfortunately, my experience tells transforming the second product might be harder than transforming the first one.
My first LeSS adoption was in Nokia Networks, now NSN. (This was not Nokia Devices that made mobile phones; this was and is a networking and telecommunications equipment company). It started with small-scale Scrum pilots in 2005, initiated with help from the internal “Flexible Company” group that included Bas Vodde as a key internal scaling-Scrum coach, and Craig Larman as the external coach for LeSS. We went for organization-wide LeSS adoption in 2007, with Bas as primary LeSS coach and member of the leadership team, and some support from Craig. We had around 500 people in two R&D sites developing the first product. Product used a quite “by the book” LeSS Huge setup (Requirement Areas, Area Product Owners, Feature Teams, etc). After some initial hiccups, the new setup turned out to be successful – changing plans was way more easy and the organization got rid of quite a lot of activities and tools which were seen wasteful. Many up-front specification documents were trashed, detailed requirements were replaced with tests, hour reporting tool was replaced by generated reports from product backlogs (reports were needed because of different taxations in many countries for new product development and maintenance work), etc. The first product also got rid of extra managers and coordinators (subproject managers, project managers, fault coordinators, etc).
I have been in the second product for three years now. I am one of the people who were cherry- picked to transform the second product. The head of the first product had moved to lead the second product already earlier on.
Transforming the second product begun top-down. The head of the product told he wants to use scrum and to go to feature teams in order to shorten cycle times and make planning more flexible. People coming from the first product had learned that an almost to by-the-book LeSS Huge setup was the way to go. Just setting that up should be simple. But it really is not. The organization is resisting! We have some progress but it is broad and shallow instead of deeply adopting practices of lean and agile development. Many things look agile but when you dig deeper, you often find old roles renamed into scrummish roles, ‘testing sprints’, teams without a common goal, even ‘feature teams’ without product-level test environments.
Only the head of the product, I and some handful of other people have seen LeSS Huge work in the first product. Especially, in the leadership team, only the head of the product has seen LeSS Huge work. Other members of the leadership team are currently leading either some component organization or organization responsible for some development ‘phase’ . It is natural for them to try to keep the status quo because e.g. feature teams would break their organization. To make it more challenging, the second product has more than 4 times the people and the development sites the first product had. People with product level knowledge are rare in the second product compared to the first one.
In the first product, we got the leadership team quite well aligned in where we want to go and how. This was done by
- Leadership team members participating to small scale scrum pilots in either Product Owner or Scrum Master roles.
- Having a professional LeSS coach (Bas Vodde) as a leadership team member.
- Everyone in the leadership team participating Scrum Master training.
- Open email discussion among leadership team members and other people keen on contributing to the transformation.
Not all members of the leadership team in the first product were LeSS believers. Bottom line is that there were some and these people helped to create common understanding on what steps the organization should take next. The first product also invested quite a lot into organizational and team coaching in lower levels during the pilots. Adoption was deeper and impediments were removed – e.g. a unit test tool was written for an in-house programming language. The first product learned a lot about its capabilities during the pilots and these were respected (e.g. in scope of Definition of Done) when we went for full product LeSS.
In the second product, we have not said aloud that adoption will be easier than in the first product. But when I reflect back, it seems we are unconciously believing so. We are pushing the organization to adopt a setup which used to be successful in the first product. It seems we should stop this and dig up the good learnings of transforming the first product. We need to start working more iteratively in transformation (perhaps creating a parallel feature team organization), be more transparent in where we really are and have more open discussion on how to get forward and solve the impediments.
Published material from Nokia:
- 2012 - Scan Agile Conference - Creating Continuous Improvement Culture
- 2011 - History of the Nokia Test
- 2010 - Greenfield Product Development Case: Flexi Network Gateway - Ran Nyman, Ismo Aro, Roland Wagner
- 2009 - Oredev Conference - Agile Adoption at Enterprise Level - Petri Haapio
- 2008 - JAOO Conference - NokiaSiemens and Agile Development - Petri Haapio
- 2007 - JAOO Conference - Stories from the Flexible Company - Bas Vodde
- 2006 - Euromico Conference - Nokia Networks and Agile Development - Bas Vodde