This Agile case study is drawn from the experience report “Keeping schedule while negotiating content on a scale” written by Maarit Laanti.
The year was 2005, and Nokia, the mobile giant of its era, faced a familiar challenge for large organizations adopting Agile: how to balance fixed timelines with the flexibility Agile calls for. Their current approach, known as “Water-Scrum-Fall,” forced teams to follow a strict set of requirements upfront.
Agile was only used during the development phase, which limited their ability to adapt or respond to new information.
The result was predictable: development moved fast, but teams had no room to adjust, and products sometimes launched outdated or missing key features.
1. Background: Embracing true Agility
In Nokia’s fast-paced environment, missing opportunities were costly. The question was how to stay aligned with Agile’s principles—particularly “responding to change over following a plan”—in such a large organization.
At the time, an attempt to be thorough with requirements often led to long planning periods and rigid structures that held teams back. There was a clear need for flexibility, but it had to work within a structure that kept everyone focused on the big picture.
This shift wasn’t just procedural; it was cultural. Nokia’s journey to Agile maturity would require regular reflection, transparency, and a spirit of collaboration across the board.
2. The solution: A self-similar, people-centric model
Nokia introduced a “fractal” information model, inspired by the self-similar patterns in nature. The model used a hierarchy of priorities—Boulders, Rocks, and Pebbles—to let teams prioritize work flexibly within the fixed timeframes they needed.
Larger items like Boulders required alignment across teams and management. Rocks had a broader system impact but were easier to tackle. Pebbles were smaller, team-level tasks.
This system let teams set high-level goals while adapting their approach as they learned more about each project’s needs.
To support this flexible structure, Nokia introduced multi-level backlogs, giving each team autonomy within its scope:
- Program Content Backlog: Contained large, high-impact priorities shared across the organization.
- Program Backlogs: Held items requiring cross-team collaboration for implementation.
- Scrum Team Backlogs: Focused on tasks specific to each team, allowing for team-level planning and responsiveness.
- Sprint Backlogs: Detailed the tasks for each sprint cycle, enabling rapid adjustments.
This fractal structure maintained Agile’s iterative cycle at all levels, ensuring alignment without sacrificing flexibility.
By mirroring Agile’s iterative model across the organization, teams could make changes to their plans without losing sight of their overall objectives.
3. Key insights: The power of collaboration and transparency
The fractal model delivered more than just structure; it offered new insights into Agile at scale.
One key addition was the use of Enablers, a concept for adding visibility to support tasks.
For example, creating testing environments became visible work in the backlogs rather than hidden labor. This transparency helped teams accurately measure their capacity and empowered managers to understand the full scope of the work. It reinforced Agile’s values of open communication and continuous improvement.
The model also eased tensions between leadership and teams by creating a shared language of Boulders, Rocks, and Pebbles. Each group could see its role in the bigger picture, reducing conflict and fostering collaboration, all while honoring the Agile principle of “individuals and interactions over processes and tools.”
4. The outcome: An Agile model that scales
Nokia’s fractal information model proved to be a powerful tool, enabling one of the largest agile transformations at the time. The model’s success in fostering alignment, adaptability, and transparency laid the groundwork for what we now call the Scaled Agile Framework (SAFe), which Nokia’s approach heavily influenced.
By allowing teams to work on meaningful tasks and adjust as they learned, Nokia was able to improve product relevance, speed up feedback cycles, and enhance stakeholder satisfaction.
5. Lessons learned: Continuous improvement as a way forward
Nokia’s journey showed that scaling Agile is an ongoing process, requiring reflection and adaptability at every step. Early on, they realized the importance of regular check-ins to stay aligned and adjust priorities. This commitment to Agile’s iterative mindset kept them resilient and ready to pivot.
The organization also learned that transparency through Enablers and prioritization with Boulders, Rocks, and Pebbles helped teams manage workloads sustainably, aligning with the Agile principle of “sustainable pace.”
6. Reflections and future considerations
Nokia’s story is a lasting reminder that scaling Agile is about more than expanding practices; it’s about embedding a mindset of collaboration, reflection, and responsiveness.
The fractal model became a blueprint, balancing structure with the freedom to change. By embracing this self-similar model, Nokia created a framework that allowed them to meet the demands of a fast-evolving market with confidence and agility.
Read the original experience report “Keeping schedule while negotiating content on a scale” written by Maarit Laanti.
Agile is a mindset, not a rigid set of rules. Download a printable copy of the Agile Manifesto and 12 Principles here.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
