CUTTER BUSINESS TECHNOLOGY JOURNAL  VOL. 32, NO. 5
  

Come along with me through the experiences and insights from the ups and downs of an Agile journey in a 2,000+-person product development unit in 10 locations in Sweden, Poland, and China, resulting in a quadrupling of value throughput; a doubling of speed; a tenfold increase in quality; and happier, more engaged people who are, ultimately, more innovative.  

Three mental leaps emerged from our journey:

1. From methods and tools to principles and mindset. Tools and methods can work in some contexts but not others. If you have your own principles and mindset, then you can adapt or create your own methods and tools to fit your context. Once we realized this, we made a mental leap from a focus on methods and tools to a focus on principles and mindset.

2. From resource efficiency to flow efficiency. With a need to reduce both costs and time to market, we were looking for alternatives to a resource efficiency focus (i.e., to keeping people and equipment fully utilized at all times). We realized that our ability to innovate around state-of-the-art algorithms for optimizing packet data flows in mobile radio networks was also applicable to our product development processes. So we made a mental leap from resource efficiency to flow efficiency (i.e., to a focus on keeping work items moving through the process without waiting times, thereby delivering value as quickly as possible).

3. From scattered experiences to continuous innovation. We were solving problems as they occurred using taskforces in fire-fighting mode, lacking corporate memory and a common direction. By creating a shared direction, a common purpose around the need to improve, and learning how to scale our innovation efforts, we made the leap from scattered experiences to a culture of continuous innovation.

Departure

Context, Heritage, Why

The product development unit, headquartered in Stockholm, Sweden, comprised over 2,000 people, including partners in 100+ teams in 10 locations in Sweden, Poland, and China. The product consists of tens of millions of lines of real-time, embedded software (with up to 15 years’ legacy code), helping more than 1 billion people in more than 150 countries communicate using 2G and 3G mobile data, video, and speech calls.

Our heritage was classic waterfall development: hun­dreds of people time-sliced into several two- to three-year overlapping projects. We had two product releases per year  —  with a system engineering phase based on requirements from a product management organization, a design and development phase, and a six- to nine-month manual integration and testing phase. During strategy sessions, we gradually realized that the poten­tial for significant improvements to this way of working was highly questionable and, consequently, we had to try something fundamentally different.

Our biggest challenges were product quality, an inability to deliver what our customers needed, and keeping up with the exponential data traffic growth following the introduction of the iPhone.

Initial Inspiration

We had heard about a product development unit in our company located just outside Helsinki, Finland, that saw very promising initial results in terms of lead times and quality from working in an Agile manner.¹ We sent several delegations to Finland to learn more. They all found inspiration from what they saw: few, if any, slide decks; real teams talking about delivering value to cus­tomers several times per month; confident and relaxed managers who clearly believed in what they were doing; and information radiators giving teams fast feedback on quality based on continuous integration of automated test cases.

We asked for the “secret recipe,” expecting a docu­ment or a slide deck of hundreds of pages; instead, we received just one page with the advice to focus on three things initially: continuous integration, continuous integration, and continuous integration  —  most probably because almost all of our six- to nine-month release testing at the time was manual.

We were also advised to read the book Scaling Lean & Agile Development² for principled, yet pragmatic, guid­ance on what to try and what to avoid, and several leadership teams started reading circles. In addition, we were offered internal coaching and mentoring on Agile and Lean at scale that we happily accepted.

What Worked Well Early On

The development organization and the product man­agement organization were very much aligned on needs and direction thanks to strategy work done together over several years. Additionally, the heads of these organizations were curious and eager to learn and improve themselves as well as the organization, illustrating author Frederic Laloux’s wise words, “An organization cannot evolve beyond its leader­ship’s stage of development.”³

We avoided using classic command-and-control, top-down, big-bang change management after a long and heated debate on which approach to use. Since we wanted leaders to be role models and to start acting their way into new thinking, we set up a core team of willing and able formal and informal leaders (“influencers”) from all parts of the organization. This core team was meeting openly and transparently one full day per sprint (i.e., once every three weeks) and working according to the prioritized backlog of topics to be resolved ,  guided by a quantified five-year vision (also known as our long-term key performance indicators [KPIs]) that came from the strategy work done earlier. In addition, we were fortunate to have experienced people from our role model organization in Finland as coaches and mentors from the very beginning of our journey. Finally, our scrum masters, Agile/Lean coaches, and organization coaches self-organized into a coaching community that collaborated with similar coaching communities in other parts of the company  —  sharing and learning from each other. Early on, key decisions made by the core team included:

• A pull-based approach for product discovery using the Kanban method to visualize early phase studies, as well as one product owner and one product backlog with strict priorities

• Requirement areas (collections of customer needs from an outside-in perspective) with 20 or more teams each, enabling:

• Independent prioritization in backlogs per requirement area

• Transparent development capability with a set number of teams per requirement area, changeable on a quarterly basis 

• Easier domain competence building for teams

• Continuous programs instead of traditional projects for each new release, enabling continuous feedback, learning, and improvement to ways of working in the programs

• Colocated, semipermanent, end-to-end, cross-functional feature teams, which, by avoiding handovers and waiting, would improve quality and lead time; teams could choose to use Scrum or Kanban at the team level

• Gradual ramp-up of cross-functional teams to enable feedback, learning, and adjustments

• Heavy investments in continuous integration with automated, continuous, and fast feedback to the teams, which would improve delivery speed, team learning, and product quality

• Thorough, hands-on training in Agile/Lean principles and practices from the beginning, with a two-day certified scrum master course for ­all in the organization

• A more defined coaching stance for managers, including asking questions rather than providing answers, achieving results through transparency and trust rather than control and micromanagement, and daring to be patient and persevere, rather than going for quick fixes and silver-bullet thinking

A few years into the journey, we involved managers in redefining the expectations of a manager in an Agile context and, in the next big organizational change, used this redefinition when recruiting managers.

The decision to use requirement areas and feature teams was preceded by a long and heated debate in which several key people argued for using the existing prod­uct architecture and corresponding component teams. Our insight was that using component teams would lead to very many dependencies when developing new features, impacting many components, and that managing these dependencies would slow down development significantly.

Other important, external prerequisites that were in place before the journey started included:

• Expectations, support, and concrete targets for change and improvements from the head of the business unit who was also a member of the senior executive team.

• A global leadership model and corresponding training of all leaders since the late 1990s based on situational leadership (i.e., that managers are expected to adjust their behavior to each individual’s needs in the context of the situation at hand).⁴ This model was complemented in the mid-2000s by hands-on coaching training based on the GROW model and later on additional coaching training based on David Rock’s book Quiet Leadership.⁵

• A global product development doctrine evolving since the mid-2000s and a corresponding training program for senior technical leaders based on self-assessments, followed by extensive sharing and learning in teamwork exercises focusing on the current needs of participants and their organizations. The doctrine was formulated as 12 principles for large-scale, world-class product development and was influenced by internal exper­iences and external inspiration, such as Lean product development and Agile software development.

Mental Leap 1: From Methods and Tools to Principles and Mindset

Initially, we started practicing the methods and using the tools — Scrum, Kanban, and continuous integration — by the book and with help from internal and external coaches. Then, thanks to:

• Our initial focus on our needs and the direction we wanted to go,

• Inspiration from thought leaders like Mary and Tom Poppendieck⁶ and Don Reinertsen,⁷ and,

• A company culture of always thinking for ourselves,

… we moved to trying to apply the principles of flow, visualizing our work for transparency, and having a mindset of continuous learning and experimentation.

Point to the Destination and Explain Why

We set up the following long-term (five years into the future) KPIs based on our needs to improve quality, lead time, value delivery, and employee engagement along with feedback that our original vision statement was too abstract; we needed to complement it with something more concrete. Within five years, we would:

• Quadruple value to exceed customer expectations

• Halve time to market to be more responsive to customer needs

• Improve quality tenfold to secure customer trust

• Have at least 75% of our people fully motivated and engaged

We decided on the KPIs before we knew how to achieve these rather aggressive targets. The key learnings for us were that it is good to have long-term KPIs, aiming five years ahead and not only for the next quarter, and that a balanced set of targets would help us avoid subopti­mization. The decision on and usage of KPIs was by no means easy due to the misuse of targets. We found them to be useful, however, to show progress to our­selves internally in our organization, providing us with additional energy and engagement, as well as to our external stakeholders, who valued the regularity and transparency. Having a set of long-term KPIs set five years into the future also gave the message that this is not a quick fix that will be ready in a quarter or two.

One important example of how we used these long-term KPIs to influence the culture was a three-month design stop. Quality measurements showed that our product quality was getting worse, so we asked all teams to stop developing new features and instead fix outstanding internal faults and resolve customer trouble tickets to remove technical debt. Ultimately, this symbolic, yet concrete, decision proved to be a turning point — letting everyone in the organization understand that quality was truly important and with management finally comprehending that better quality results in higher speed, rather than that quality is mere talk and traded for speed. Moreover, the design stop proved the importance of having a head of product development and a head of product management who trusted each other and dared to take risks together in a corporate business climate, where inability to deliver short-term results could lead to demotion.

From Large Batches to Smaller Batches

Traditionally, large batches rule since economies of scale provide a cost advantage. A key insight for us was that small batches deliver better quality and shorter lead times thanks to faster feedback loops and, hence, quicker learning and ongoing adjustments. This strat­egy delivers more value to customers, and the organi­zation gains a value advantage.

We struggled quite a lot to turn theoretical understanding into practical use. We offered several “ele­phant carpaccio exercises”⁸ to get the point across in a concrete way, and we also included this exercise in the product development training mentioned above. As time passed, we found our own concrete example of the value of slicing, as described below and shown in Figure 1:

• We originally planned a feature for two teams.

• We split the feature into two parts after a dialogue involving the cross-functional development team, the product owner, the customer unit, and the customers.

• After this, we split the sub-features into subparts.

• One team could do subparts 1 and 2 in half the time compared to the original feature lead time, and it turned out that customers did not need subparts 3 and 4; hence, they were not developed. Moreover, it seemed that subparts 5 and 6 were crucial to one customer, whereas subparts 7 and 8 were not important to any customers, so they were not developed. In fact, subparts 5 and 6 were so vital that the product owner decided to reprioritize a team from another feature to this feature, hence adding one more team so that subparts 5 and 6 could be developed twice as fast as would otherwise be possible.

In summary, smaller slices meant that we could deliver customer value faster (and get paid faster!), and the early splitting into slices meant that we could get cus­tomer feedback and change direction quickly. Plus, we now had a success story that we could share and get people excited about!

Another example of the beauty of smaller batches is to avoid big-bang change initiatives from the top and to overcome resistance to change by doing small trials that can easily roll back if they don’t offer any improvement (i.e., go for experiments that are safe to try). One example is how we gradually ramped up the cross-functional teams, starting with one team.

From Local Suboptimization to Global Awareness

Something we found extremely valuable to secure global awareness and understanding was a visualization room with a board showing all features and stages of development —  from customer need to solution delivered and in operation (see Figure 2). Stakeholders would meet at least once a week in the room at the visualization board and via video­conference to get features out of a blocked state and to improve the flow by visualizing, managing queues, and removing impediments in the product development process. However, we struggled with the videoconferencing system and keeping the boards synchronized across multiple locations; indeed, we sometimes got totally lost in feature-tracking tools and troubleshoot­ing the videoconferencing system.

The visualization board pictured in Figure 3 shows features as colored sticky notes divided into six hori­zontal requirement area rows. The vertical columns show different development stages. A pink sticky note on a feature, for example, indicates a block in the progress of the feature. By looking at the board, you see the status of 100+ features at a glance. Here, it’s clearly visible that certain development stages (col­umns) are full of features waiting, indicating a bottleneck in this step or in the adjacent step. When this happens, it’s time to act (e.g., by limiting the number of features ongoing in parallel) — that is, limiting the work in process (WIP).

Most of all, we learned that Agile and Lean are mindsets. Agile is described by four values, defined by 12 principles manifested through an unlimited number of practices. We learned the game — the mindset, the values, the principles, and the practices. Then we played the game using the practices. Finally, based on experiences and insights grounded in a thorough understanding of the mindset and principles, we were able to (re)define the game with our own practices and tools to suit our needs.

Mental Leap 2: From Resource Efficiency to Flow Efficiency

What Is Efficiency? 

Toyota expert Niklas Modig, trying to answer the question “What is Lean?” realized that the question is really, “What is efficiency?” and discovered that there are two distinct answers: resource efficiency and flow efficiency.⁹

In Figure 4, we see resource efficiency on the vertical axis and flow efficiency on the horizontal axis. By resource efficiency, we mean keeping people and equipment as fully utilized (“busy”) as possible. By flow efficiency, we mean fulfilling customer needs as quickly as possible. We can see one example of high resource efficiency in the upper-left quadrant: the equipment in a steel mill, which makes sense to keep fully utilized since it’s extremely expensive. In the lower-right quadrant, we see an example of high flow efficiency and low resource efficiency: an ambulance emergency service where it’s crucial to fulfill the needs of the patient as soon as possible since it’s often a matter of life or death. In this case, it’s not as important to keep the resources busy, and we are willing to trade low resource efficiency for high flow efficiency. In product development, it is equally important to fulfill the needs of your customers faster than the competition does, or you will soon not have any customers left; without customers, it does not matter that you are utilizing your equipment and people very efficiently at a low cost.

In flow thinking, it’s crucial to first start working on improving flow efficiency and then improving resource efficiency. Starting with resource efficiency will make it virtually impossible to achieve both resource efficiency and flow efficiency since the higher the resource utili­zation, the longer the response time or lead time. How­ever, the decision is not a binary choice, one of either resource efficiency or flow efficiency; we need both.

Storytelling Around Flow in Our Products

We needed a way to explain flow efficiency to our engineers and leaders so they could start to take more balanced actions and make better decisions.

So we looked at traffic jams on a highway: the road is at 100% resource utilization, but the flow efficiency is zero since all vehicles are at a standstill  —  the highway has become a parking lot. Moreover, it doesn’t help if we add more vehicles or new, better engines for the vehicles.

We also looked at servers. What’s the maximum utilization at which you would run your servers? It’s around 60%–70%; otherwise, there will be delays in the applications running on the servers, and the delays become exponentially larger the closer we get to 100% utilization. Resource efficiency impedes flow efficiency.

In addition to cars on highways and servers, for greater understanding and inspiration, we also looked at the Toyota Production System, the Scania Truck Production System, and the Swedish Health Care System, all of which are pedagogical examples of prioritizing flow efficiency over resource efficiency. The engineers understood but were still reluctant to use these insights, saying things like, “Our context is special; we’re doing creative knowledge work for global, mobile networks, which is very different from manufacturing, healthcare, highways, or servers.”

Then, a few of us took Reinertsen’s master class on the principles of product development flow. He started by asking us why we were there, his point being that our company already knows and uses all the principles of flow in the algorithms in our datacom products every single day  —  applying them to flows of data packets. This is relevant since the flow objects in product devel­opment (e.g., trouble tickets or features) flow in a highly variable environment, just as the flow objects in our products do. Hence, the algorithms in our products could inspire us when we want to improve our proc­esses! Moreover, we prioritize flow efficiency over resource efficiency initially in our products.

So we started storytelling about how the way in which we secure the flow of packets with low latency in our products to achieve both speed and high throughput could provide inspiration for how to secure the flow of features with short lead time and high throughput in our processes. This resonated with almost all the engineers.

Mental Leap 3: From Scattered Experiences to Continuous Innovation

Our heritage was doing large-scale, lessons-learned exercises at the end of our development projects and root-cause analyses following taskforces at major cus­tomer outages (i.e., local ad hoc activities in isolated parts of the enterprise). Our customers were complaining about what they perceived as a lack of corporate memory and the inability to systematically work on improving our ways of working and our products.

Now, what is innovation? Well, we have chosen to define innovation as “value from ideas” so, in addition to having an idea, we also want to prove that it has value (e.g., through a prototype, a trial, or an experiment). With this definition, we can relate innovation to technology, products, ways of working, business models, leadership, strategy, budgeting, recruitment, and so on. However, in the traditional corporate cul­ture, people often think of innovation only as technol­ogy and product inventions manifested as patents.

Plan for Innovation

Based on our experience, we suggest trying to plan for innovation by setting aside 30% of time for learning, innovation, and improvements, both in products and ways of working. You need innovation to improve your capabilities and products over time, as shown in Figure 5. It also shows that an idea can come anytime. It is an innovation until it has proven to be valuable, and it requires time to show the value of an idea.

In our case, by having our head of product management and head of product development on stage together in an all-hands meeting asking for 30% of time allocated to innovation, we were really clear on the expectations on the organization. We understood that it, in reality, it would probably not be 30% but rather 5%-10% due to strong customer pull for features. Still, if we had asked for 10%, it would in practice have been close to 0%.

Continuous Innovation Toward the Vision

We have also seen how a long-term, five-year vision — in our case, a vision of half the lead time, four times the value throughput, 10 times the quality, and more than 75% of our people being highly motivated and engaged — helps direct innovation (i.e., experiments, prototypes, trials, and demos) in the desired direction.

We also recommend using one single challenge (instead of a balanced scorecard or objectives and key results [OKRs]) to focus the innovation efforts more toward the area where you have the biggest need currently and to work with this challenge for one to three quarters, or until you overcome the challenge. Here’s an example of a challenge we used: Every sprint deployed to a live network with added customer value and higher quality. Our development teams then used this challenge to come up with experiments, trials, and prototypes that they wanted to try in order to contribute to overcoming the challenge. We tried several different approaches to find out what would work best in our context: a top-down challenge versus bottom-up workshops to identify the challenge, a duration of one-quarter versus several quarters, and a fuzzy challenge versus a clearly defined challenge.

Learning Days

We received feedback that it was difficult to find time for innovation. One example of securing time and space for innovation is our “Learning Day” events, with each Learning Day a full-day, multisite, multitrack, internal conference with content mostly in the form of presen­tations and workshops from teams, engineers, and leaders, as well as invited external speakers. We run a Learning Day every sprint (i.e., every three weeks). Figure 6 shows an example of a Learning Day.

Most organizations do this at most once or twice a year, if they do it at all. For us, it started with one person having an idea, and it grew into a “self-playing piano,” thanks to a wiki page open to all, the regularity of the sprint cadence, and some gentle nudging of people and teams we knew had cool stuff to share.

Remaining Challenges

There are, of course, some areas where we are still struggling, such as the following:

• Crystal-clear line of sight to customers. There are still too many organizational layers between teams and customers and almost no interactions between customers and teams.

• Collaboration with global support functions (e.g., with HR for speedy recruitment with quality and with finance for more collaborative and flexible budgeting practices).

• Software “craftership.” Despite several tries, we have yet to see sustainable, self-organized communities of practice working on areas such as clean code and refactoring.

• Coaches and managers for the future. Several team/organization coaches and managers with experiences from this journey left the company or were let go during downsizing, meaning we have lost many people with suitable leadership skills for the future.

• Battles from within. How do we continue evolving without becoming a UFO, an alien life-form that other parts of the business want to shoot down?

• Cross-enterprise sharing. How do we spread our insights to other parts of the company, where many feel they are too busy to learn and improve?

Conclusion

Over five years, our large-scale Lean/Agile transformation journey resulted in a quadrupling of value throughput, a doubling of speed, a tenfold increase in quality, and happier, more engaged people who are more innovative. We struggled during the journey and are still struggling in some areas. But our three mental leaps propelled us to continuous improvement. What will be your next mental leap?

Acknowledgements

I would like to thank the following people: Håkan Forss,  for inspiration, coaching, and LEGO; Craig Larman and Bas Vodde, for crystal-clear, written, pragmatic guidance; Niklas Modig,  for new per­spectives on Lean and flow; Don Reinertsen,  for an economic view on Lean and rigorous flow principles; Åke Sundelin, Jonas Wigander, Hendrik Esser, Inga-Lill Holmqvist, and Lars-Ola Damm for how to train senior technical leaders in world-class product development; Stephen Denning and the Learning Consortium,  for conversations on mindset and storytelling; Björn Tikkanen, Henrik Kniberg, and Jonas Boegård, for encouraging me to write; and, finally,  Magnus Thornberg, Mårten Pehrson, and everyone in Product Development Unit 2G/3G at Ericsson for making this happen, together!

References

¹Paasivaara, Maria, Benjamin Behm, Casper Lassenius, and Minna Hallikainen. “Large-Scale Agile Transformation at Ericsson: A Case Study.” Empirical Software Engineering, Vol. 23, No. 5, October 2018.

²Larman, Craig, and Bas Vodde. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley Professional, 2008.

³Laloux, Frederic. Reinventing Organizations. Nelson Parker, 2014.

⁴Hersey, Paul, and Kenneth H. Blanchard. Management of Organizational Behaviour. Prentice Hall, 1977.

⁵Rock, David. Quiet Leadership: Six Steps to Transforming Performance at Work. HarperBusiness, 2007.

⁶Poppendieck, Mary, and Tom Poppendieck. The Lean Mindset: Ask the Right Questions. Addison-Wesley Professional, 2013.

⁷Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

⁸Kniberg, Henrik, and Alistair Cockburn. “Elephant Carpaccio Exercise Facilitation Guide.” 11 July 2013.

⁹Modig, Niklas, and Par Ahlstrom. This Is Lean: Resolving the Efficiency Paradox. Rheologica Publishing, 2012.