This article was originally published on InfoQ on July 15, 2015, by Ran Nyman. It has been archived here for preservation.

---

Introduction

At the end of 2007, Nokia Siemens Networks (now Nokia Networks) faced significant challenges developing a high-capacity network gateway from scratch. Two fundamental risks existed: the technology was entirely new to the organization, and commercial use cases remained undefined at project start. The organization selected the Large-Scale Scrum (LeSS) framework to address these uncertainties.

During development, the team pivoted from broadband to 2G/3G and LTE mobile network gateways based on market demand. Both hardware and software platforms were immature, requiring the team to work with non-standard equipment and manufacturer SDKs initially.

Organization and Growth

Starting Phase

Adopting LeSS proved challenging. The primary obstacle involved convincing stakeholders that feature teams outperformed component teams for reducing cycle time and increasing flexibility. The organization formed long-lived, cross-functional, cross-component feature teams responsible for completing end-to-end customer features.

Initial teams came from two distinct backgrounds: one with genuine Scrum experience and one from traditional waterfall development that had unsuccessfully attempted Scrum adoption through superficial rebranding without structural change.

The team-formation approach mixed members from both backgrounds. When developers resisted feature teams citing quality concerns, an agile coach asked about code quality in their previous component-based structure. The honest answer—”a mess”—convinced them to try the new approach. Team formation took under one hour.

Initially, out-of-line managers served as ScrumMasters, but after several sprints, managers acknowledged their unsuitability for the role. Team members assumed ScrumMaster responsibilities while managers transitioned to miscellaneous support functions.

Initial LeSS with Two Teams

Two teams conducted joint Sprint Planning 1 and 2 sessions in the same room, facilitating collaboration on architecture and dependency resolution. Each team maintained separate Sprint Backlogs using visual wall-based management—a simple tool that persisted as the organization scaled.

Product Backlog Refinement initially occurred informally during sprints as an ongoing activity. Since technology remained unclear, refinement consumed significant time. However, teams refined independently and attempted selling solutions to each other rather than collaborating, creating unnecessary conflicts.

Eventually, individual team refinement sessions with the Product Owner replaced this approach. In retrospect, the organization should have implemented overall refinement sessions earlier, as recommended in LeSS literature.

One overall Sprint Review included both teams, followed by individual team retrospectives and a common Overall Retrospective for cross-team improvements.

Growing the First Wave

Adding two more teams (reaching four total) introduced complications. One transferred team refused to adopt new testing tools and resisted unit testing, producing no done work for several sprints. The resistance stemmed partly from insufficient training and explanation of iterative development rationale. Importantly, new teams needed influence over working methods to feel ownership of practices.

The organization preserved long-lived feature teams rather than reorganizing existing ones.

Customer documentation personnel began working directly with teams during sprints, eliminating overhead from remote coordination.

Sprint Planning 1 included all team members rather than representatives, facilitating necessary coordination. Team-level Sprint Planning 2 meetings occurred together in one large room to encourage collaboration.

The single Sprint Review with six teams occurred in an open area near team spaces, with each team presenting completed work. Marketing and support personnel participated, enabling incorporation of support functionality from early stages.

The Overall Retrospective struggled with productivity, primarily because managers lacked genuine commitment to executing improvements. Creating an improvement service where managers collaborated on team-identified improvements would have helped, as recommended in LeSS, but managers remained insufficiently engaged.

Growing the Second Wave

Adding teams at a second site presented greater challenges than same-site expansion. The organization leveraged automated acceptance testing and standardized practices to onboard subcontractors. Remote workers spent several weeks with local teams before working independently. The same coding standards, unit test requirements, automated acceptance tests, and continuous integration system applied to all teams.

Communication difficulties proved most challenging. For six months, a Product Owner proxy at the main site reduced requirement misunderstandings. Subsequently, a local person assumed this proxy role.

One Product Owner became overloaded, so the organization classified Product Backlog items into major requirement areas with teams focusing on particular areas. In hindsight, areas proved too small (two teams per area), creating unnecessary complexity and reducing transparency compared to larger areas with more teams.

Specification personnel from product management required significant persuasion to work with teams supporting the Product Owner. The organization attempted implementing Area Product Owners as described in LeSS but failed largely because the existing Product Owner, from product management, resisted delegating decision-making authority. Teams worked with various feature experts depending on current work.

With more than eight teams at one site, a single Sprint Review became burdensome. The organization shifted to sequential reviews where the Product Owner and feature experts visited each team at the main site sequentially, with each review lasting maximum 30 minutes. This approach allowed teams to selectively attend reviews of interest. Remote teams received separate reviews via teleconferencing with a local proxy conducting local reviews.

Current Team Structure

The organization now operates over 20 teams, with the majority developing and documenting features. Supporting teams include performance testing, system testing, coaching, and continuous integration system (CIS) teams. Performance and system testing teams execute tests requiring special network elements in dedicated test labs at separate sites—coordination between multiple teams across locations proved infeasible for limited resources.

The coaching team supports modern engineering practices, helps teams solve technical challenges, and accelerates organizational learning.

Managers eventually formed a regular feature team, selecting work from the Product Backlog and working collaboratively. This solution suited most managers with strong development backgrounds. Some managers focused on ScrumMaster roles, working closely with agile coaches to remove impediments.

A few traditional project managers remained for historical reasons but had no actual project-management work. ScrumMasters worked to prevent these managers from disrupting teams. These managers helped remove identified impediments and supported the Product Owner, though mostly remained underutilized.

LeSS Huge Adoption Analysis

Transitioning from LeSS to LeSS Huge structure presented challenges, with less success than desired.

Since the product involved technical standards for public inbound and outbound interfaces, the organization defined Requirement Areas around these interface families. However, distinct areas existed for inbound versus outbound interfaces. Some requirements completed entirely within single areas, validating this approach. Frequently, however, complete requirements involved choreography between inbound and outbound messaging, creating dependencies between teams in different areas.

The organization created self-inflicted wound dependencies. Upon recognizing the problem, reorganizing areas so most interactions occurred within single larger Requirement Areas would have been preferable.

Implementing the Area Product Owner concept proved difficult. Feature experts performed requirement refinement with teams, but the Product Owner resisted delegating decision-making power to feature experts or allowing them to function as real Area Product Owners. This resistance became visible in Sprint Planning and Reviews where the single Product Owner insisted on controlling everything. Teams struggled obtaining proper feedback about items during sprints or reviews. Sequential reviews with individual teams for only 30 minutes each resulted in poor or skipped inspection and lacked in-depth discussion.

An external interview study conducted in early 2010 surveyed 16 key-role participants at the main site regarding LeSS adoption and changed work perception. The biggest finding: “none of the people interviewed would like to go back to the old way of working.”

The primary negative finding revealed that after two years of LeSS practice, people lacked clear understanding of the framework, its operation, and the rationale behind practices. This highlighted the necessity for intensive education programs emphasizing the “why” behind framework elements. ScrumMasters had inadequately explained foundational principles.

Despite conflicting organizational forces, LeSS adoption remained confined to the product development organization. The broader organization only showed impact at the lowest level through feature team formation. First-level managers formally remained team managers while focusing primarily on development as team members implementing Product Backlog items. Each manager still handled company bureaucratic requirements for subordinates.

Conclusions

Selecting the LeSS framework and adopting agile practices significantly accelerated time-to-market and provided flexibility that traditional sequential methods never offered. The previous gateway product using sequential lifecycle models required twice the development time. Sequential lifecycle approaches with single-function and component teams would have prevented the major directional change the organization implemented. LeSS enabled this organizational agility.

Automated acceptance testing proved invaluable when adding new teams, maintaining high code base quality.

The organization should have emphasized LeSS adoption more thoroughly when expanding team count, as new teams—despite possessing some Scrum experience—lacked LeSS familiarity and remained confused about new working methods. Formal education appeared necessary for understanding the larger development picture beyond coaching-acquired practices.

Transitioning from LeSS to LeSS Huge required advance planning rather than ad-hoc implementation, with explicit agreement from the Product Owner bottleneck to empower Area Product Owners with real decision-making authority.

Feature-team-level LeSS adoption functioned effectively. However, sustainable organizational change requires focusing on formal organizational structure; otherwise, organizations risk gradually reverting to traditional designs.

---

About the Author

Ran Nyman has been applying Scrum and LeSS for large-scale agile adoptions at Nokia Networks. He is a Certified LeSS Trainer.

---

Original article: InfoQ - Developing a High Capacity Network Gateway with LeSS