The Mental Leaps — More, Faster, Better, Happier & More Innovative!
Experiences and Insights From a Large Lean/Agile Transformation Journey
Introduction
In this article, I’ll share experiences and insights from a Lean/Agile transformation journey in a 2000+ people product development unit in 10 locations resulting in 4x value throughput, 2x speed, 10x quality, and, happier, more engaged people who are more innovative.
I’ll talk about three mental leaps that we made on our journey:
- From methods & tools to principles & mindset:
Tools and methods can work in some contexts and not in others. If you have your principles and mindset, then you can adapt or create your methods and tools that fit your context. When realizing this, we made a mental leap from a focus on methods and tools to a focus on principles and mindset - From resource efficiency to flow efficiency:
With a need to reduce both costs and time-to-market we were looking for alternatives to the “resource efficiency” focus, i.e. keeping people and equipment fully utilized all the time. We realized that our ability to innovate around state-of-the-art algorithms for optimizing packet data flows in mobile radio networks is also applicable for our product development processes. We made a mental leap from “resource efficiency” to “flow efficiency”, i.e. a focus on keeping work items moving through the process without waiting times thereby delivering value as quickly as possible. - From scattered experiences to continuous innovation:
We were solving problems as they occurred using task forces 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.
DISCLAIMER: LEGO® is a trademark of the LEGO Group, which does not sponsor, authorize or endorse this article.
Our Context
First, a bit about the context. In our 2G and 3G product development unit, we’re 2000+ people including partners in 100+ teams in 10 locations in Sweden, Poland and China. The product consists of 10s of millions of lines of real-time, embedded software (up to 15 years of legacy code) helping more than one billion people in more than 150 countries communicate using mobile data, video and speech calls. This is done through 2G and 3G mobile communications technology in around 250 mobile communication networks each consisting of tens of thousands of radio base stations and hundreds of radio network controllers, see Figure 1 below.
The radio base stations convert analog radio waves to digital packet streams using advanced digital signal processing algorithms. A radio network controller is a combination of an advanced packet data router and a telecom switch simultaneously handling 100,000 subscribers with downtime of less than 10 minutes per year, and, handling the movements of all these subscribers across the network.
As an example, one of the mobile operators in France runs a network consisting of more than 10,000 radio base stations and more than 100 radio network controllers that handle millions of subscribers moving around France and the world without dropping the data connection or voice call.
Starting with Why
This is the first — and by far the — most important question:
Why change? Or, even better, how come we wanted to improve?
Figures 2 and 3 below show people waiting for the announcement of the new pope, first in 2005 and then in 2013 and illustrate how the Apple iPhone, first launched in 2007, transformed the lives of hundreds of millions of people.
A consequence is that the data traffic in the mobile networks is doubling every 12–18 months making the growth exponential and faster than Moore’s law for semiconductors.
This was our reason to change since we didn’t get an exponential amount of additional funding every year, but rather a flat or decreasing budget since our product had passed the zenith of its life cycle.
Departure
Our Heritage
Our heritage was very much classic waterfall development: hundreds of people time-sliced into several 2–3 year projects overlapping in time since 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 6–9 months manual integration and testing phase as illustrated in Figure 4 below. During our strategy work 2008–2010, we gradually realized that the potential for significant improvements in this way of working was highly questionable and, as a consequence, that we had to try something fundamentally different. Our biggest challenges in 2010 were product quality, the inability to deliver what our customers needed when they needed it, and, to keep up with the exponential data traffic growth mentioned in the previous section.
Initial Inspiration
We had heard about a product development unit in our company located just outside Helsinki in Finland that had seen very promising initial results regarding lead times and quality from working Agile. They were also using the same hardware and software platform that we were using to build their multimedia gateway application.
We sent several delegations to Finland in late 2010 and early 2011 to go see and have a conversation to learn more. Everyone that came back was impressed and inspired by what they had seen: few if any slide-decks, real teams talking about delivering value to customers several times per month, confident and relaxed managers believing in what they were doing, and, information radiators giving teams fast feedback on quality based on continuous integration and automated test cases.
When asking for the secret recipe and expecting a document or a slide deck of hundreds of pages, we got the one-pager in Figure 5 below and the advice to focus on three things initially: (1) continuous integration, (2) continuous integration, and, (3) continuous integration (!) — most probably since almost all of our testing at the time was manual.
We also got the tip to read Larman and Vodde’s “Scaling Lean & Agile Development” for pragmatic guidance on what to try and what to avoid. Additionally, we got an offer for internal coaching and mentoring on Agile and Lean at scale that we happily accepted.
What Worked Well Early On
Here’s what worked well for us early on in our transformation journey.
The development organization and the product management organization were very much aligned on needs, and direction thanks to strategy work done together earlier.
We avoided using classic command and control, top-down, big-bang change management. Instead, 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, working according to a prioritized backlog of transformation topics — guided by a quantified five-year vision also known as our long-term KPIs (Key Performance Indicators) that came from the strategy work done earlier — more on this later. Additionally, we were fortunate to have experienced people from our role model organization in Finland as coaches and mentors from the very beginning of our transformation journey. Finally, our Scrum Masters, Agile/Lean coaches and organization coaches self-organized into a coach community that collaborated with similar coach communities in other parts of the company — sharing and learning from each other.
Other early key decisions by the core team include:
- 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 that is highly useful when you have more than 10–20 teams) for scaling which enables
1. independent prioritization in backlogs per Requirement Area;
2. transparent development capability with a set number of teams per Requirement Area that can be changed quarterly, and,
3. easier competence building for teams. - Continuous Programs (no projects) enable continuous feedback, learning and improvements of ways of working in the programs.
- Co-located, semi-permanent end-to-end cross-functional feature teams avoid handovers and waiting thereby improving both quality and lead-time — for an example see Figure 6 below. The teams could choose to use Scrum or Kanban at the team level.
- The gradual ramp-up of cross-functional teams enabled feedback, learning and adjustments.
- Continuous Integration with automated, continuous and fast feedback to the teams also improved the delivery speed, team learning and product quality.
- Thorough, hands-on training in Agile and Lean principles and practices from early on with a 2-day Certified Scrum Master course for everyone in the organization.
- Managers taking a more coaching stance — asking questions rather than providing answers; getting results through transparency and trust rather than control and micro-management, and, daring to be patient and persevere, rather than going for quick fixes and silver bullet thinking.
Mental Leap #1: From Methods & Tools to Principles & Mindset
So, let’s take a look at our first mental leap!
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 external thought leaders like Mary and Tom Poppendieck and Don Reinertsen;
- a company culture of always thinking for ourselves,
we moved to try to apply the principles of flow, visualizing our work for transparency and having a mindset of continuous learning and experimentation.
Principles and Mindset: Point to the Destination and Explain Why
One principle we tried was to point to the destination or give a direction and WHY based on our needs as illustrated in Figure 7 below.
Here’s an example of this: In 2010, we set up the following long-term Key Performance Indicators (KPIs) for 2015 based on our needs to improve quality, lead-time, value delivery and employee engagement, and, feedback that our vision statement was too abstract and needed to be complemented with something more concrete.
- 4x more value to exceed our customers’ expectations.
- 2x faster time-to-market to be more responsive to our customers’ needs.
- 10x better quality to secure our customers’ trust.
- 75% of our people are fully engaged.
This was done before we knew how to achieve these rather aggressive targets. The key learnings for us were that it was good to have long-term KPIs aiming five years ahead and not only for the next quarter, and, that we used a balanced set of targets that helped us avoid sub-optimization. So, did we achieve these ambitious long-term KPIs in 2015? Yes, we did!
The decision and usage of KPIs were by no means easy since targets can always be misused. We found them to be useful to show progress to ourselves internally in our organization which gave us additional energy and engagement, as well as to our external stakeholders who valued the regularity and transparency. Having a set of long-term KPIs 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.
Principles and Mindset: From Large Batches to Smaller Batches
Traditionally, in large organizations large batches rule since economies of scale will give you a cost advantage — see Figure 8 below. A key insight for us was that small batches will give you better quality and shorter lead times thanks to faster feedback loops and hence quicker learning and adjustments as you go. This also means that you deliver more value to your customers and gain a value advantage — see Figure 9 below.
Try: Slicing the Elephant into Carpaccio Pieces
Figure 10 below gives a concrete example of moving from a large batch to smaller batches, where we see the following steps for “slicing the elephant into carpaccio pieces” (kudos to Alistair Cockburn and Henrik Kniberg) for a large feature:
- The feature was originally planned for two teams.
- The feature was then split into two parts after a dialogue involving the cross-functional development team the product owner, the customer unit and the customers.
- After this, the sub-features were further split into sub-parts.
- One team could do sub-parts 1 and 2 in half the time compared to the original feature lead-time, and it turned out that parts 3 and 4 were not needed by any customers, hence they were not developed. Moreover, it turned out that parts 5 and 6 were very important to one customer, whereas parts 7 and 8 were not important to any customers. Subparts 5 and 6 were so important that the product owner decided to re-prioritize a team from another feature to this feature, hence adding one more team to develop sub-parts 5 and 6 twice as fast.
To summarize: smaller slices meant that we could deliver customer value faster (and get paid faster as well) and the early splitting into slices meant that we could get customer feedback and change direction quickly.
Try: Improvements as Small Experiments
Based on our experiences, we recommend that you avoid big bang change initiatives from the top and overcome resistance to change by doing small trials that can be easily rolled back if they don’t give the expected improvement, i.e. go for experiments that are safe to try as shown in Figure 11 below.
Principles and Mindset: From Local Sub-Optimization to Global Awareness
Figure 12 below shows how (some) Swedes play football on Midsummer’s Eve often spiced up with Vodka. You’re laughing but this is actually how many — if not most — companies operate.
As contrast, Figure 13 shows how the best football teams play: everyone on the team sees the whole field and works together to win.
Try: End-to-End Visualization Room
Something we have found extremely valuable to secure global awareness and understanding is a visualization room with a board showing all features and what stage of development they are in — from customer needs to solutions delivered in operation. Stakeholders meet at least once a week in the room at the visualization board to get features out of the blocked state and improve the flow by visualizing, managing and removing queues and impediments in the product development process, see Figure 14 below.
The visualization board in Figure 15 below shows features as colored sticky notes divided into six horizontal Requirement Area columns (useful for customer-needs-based scaling when you have more than 10–20 teams). The vertical columns show different process steps, e.g. concept study, pre-pre-study, pre-study, … A pink sticky note on a feature indicates that the progress of the feature is blocked. By looking at the board, you see the status of 100+ features at a glance. Here it’s visible that certain process steps (columns) are full of features waiting, indicating a bottleneck in this step or the adjacent step. When this happens, it’s time to act, e.g. by limiting the number of features ongoing in parallel = limiting the Work-in-Process (WIP).
Principles & Mindset over Practices
Our final lesson learned for this mental leap: Agile and Lean are both mindsets. Agile is described by four values, defined by 12 principles manifested through an unlimited number of practices as illustrated in Figure 16 below.
So, you learn the game — the mindset, the values, the principles and the practices; then you play the game using the practices; finally based on experiences and insights grounded in a thorough understanding of the mindset and principles, you can (re)define the game. This is extremely important since (re)defining the game with your custom practices to suit your own changing needs is vital in a world where the rate of change will never be slower than today.
Mental Leap #2: From Resource Efficiency to Flow Efficiency
In Figure 17 below, the guy in Silo 4 is very busy and the girl in Silo 1 has just finished her current task, but since they are working in silos and are trying to keep themselves fully utilized, she cannot see that the guy in Silo 4 might need some help to complete his task. So, overall, while everyone strives to be 100% occupied all the time, they are sub-optimizing for the overall business since we get delays and quality issues and hence unhappy customers. Or, as someone brilliantly put it:
Busyness is seldom good business.
Researcher and Toyota expert Niklas Modig was trying to answer the question “What is Lean?” and realized that the question is really “What is efficiency?” and discovered that there are two distinct answers: resource efficiency and flow efficiency.
Let’s look at Figure 18 below where 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. One example of high resource efficiency is seen in the upper left quadrant: the equipment in a steel mill which it 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: the ambulance emergency service where it’s crucial to fulfill the needs of the patient as soon as possible since it’s a matter of life or death. Here, it’s not as important to keep the resources busy and we are willing to trade low resource efficiency for high flow efficiency.
Now, think about an IT organization. What’s the maximum utilization they would run their servers at? It’s around 60–70%, otherwise, there will be delays in the applications running on the servers and the delays will become exponentially larger the closer we get to 100% utilization.
In Lean and Flow thinking, it’s crucial to start working on improving flow efficiency and then improve resource efficiency, see Figure 19 below. The reason is that starting with resource efficiency will make it virtually impossible to achieve both resource efficiency and flow efficiency. So, it’s not about resource efficiency or flow efficiency, it’s not binary. We need both, otherwise, experience shows that we won’t get out of the resource utilization trap.
How did we explain flow efficiency to our engineers and leaders so they could start to take more balanced actions and make better decisions?
Let’s take a look at the example in Figure 20 below: it’s a traffic jam on a highway, i.e. the road is at 100% resource utilization, but the flow efficiency is zero since all the vehicles stand still — it’s what we call a parking lot (!) Moreover, it doesn’t help if we add more vehicles or new, better engines.
In addition to cars on highways, we also looked at the Toyota Production System, the Scania Production System and the Swedish Health Care System to understand and get inspired. Our people understood, but were reluctant to use these insights, saying things like “Our context is so special, what we do and how we do it is knowledge work which is very different from manufacturing, healthcare and highways.”
Try: Story-Telling Around Flow in Our Products
Then, myself and a colleague took “the Don of Flow”, Mr. Reinertsen’s 2-day master class on the principles of product development flow and he started by asking us why we were taking his class — see Figure 21 below. His point is that we in Ericsson use all the principles of flow in the algorithms in our telecommunications and data-communications products every single day — applying them to flows of data packets. This is relevant since the flow objects in product development, e.g. trouble tickets or features, flow in a high variability environment just as the flow objects in our products, e.g. data packets. Hence, we can be inspired by the algorithms in our products when we want to improve our processes!
Don also told us that “Companies that are already implementing these ideas […] have achieved 5–10 times improvements in […] their development process.”
So, we started story-telling about how we secure the flow of packets with low latency in our products could be used as inspiration for how to secure the flow of features with short lead-time in our processes, as illustrated in Figures 22–24 below.
One example of a story we told is given in Figure 23 below. In a typical mobile network product, we ensure high capacity by controlling the arrival rate of users or data packets, managing the departure rate of users or data packets, managing overload in the product and dimensioning the product. We use algorithms to do this, e.g. back-pressure to control the arrival rate, drop data packets to manage overload, various scheduling mechanisms to maximize the departure rate and sophisticated planning to dimension the product and network for the proper service level. All these algorithms for ensuring high capacity in a mobile network can serve as inspiration for ensuring high capacity in our product development answering questions like how can we avoid overloading product development, what can we do if the product development becomes overloaded (and how can we detect it) and how can we maximize the throughput of flow objects, e.g. trouble tickets, features or product releases.
Another story we told is shown in Figure 24 below. To secure performance in our radio base station product, we start by making sure that the functionality works. In the next step, we check that the performance, e.g. latency, is OK for one or a few users. In the final step, we check that the functionality and the performance are OK for many users, i.e. that we can have as many users as possible in the radio base station, i.e. high resource utilization. We thus see the similarity between how we work with our products and what the leading Lean/Flow thinkers recommend: first flow efficiency, then resource efficiency.
Try: Use Several Leverage Points to Improve
We also discovered the insights from applied systems thinker Donella Meadows that understanding, actions and decisions based on paradigm shifts — like moving from resource efficiency to flow efficiency — gives a much better leverage than only measuring, e.g. lead-time, as illustrated in Figure 25 below. Then again, let’s use all available leverage points to improve and get better!
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 task forces at major customer outages, i.e. typical ad-hoc activities locally in our part of the enterprise. Our customers were complaining about what they perceived as a lack of corporate memory and the ability 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, you also want to prove that it has value, e.g. through a prototype, a trial, or an experiment. So, innovation can be related to technology, products, ways of working, business models, leadership, strategy, budgeting, … In our corporate culture, innovation is often thought of as technology and product inventions manifested as patents.
Try: Plan for Innovation
Based on our experiences, we suggest trying to plan for innovation by setting aside 30% for learning, innovation and improvements both in products and ways of working since this is needed to improve your capabilities and products over time as shown in Figure 26 below.
In our case, by having our head of product and head of product development on stage together in an all-hands meeting asking for this, we were clear on the expectations on the organization. We understood that it in reality would probably not be 30% but rather 5–10% due to strong customer pull for features. Still, if we had said 10%, it would in practice be close to 0%.
Try: Continuous Innovation Towards the Vision
We have also seen how having a long-term, five-year vision, in our case half the lead-time, four times the value throughput, ten times the quality and more than 75% of our people being highly motivated and engaged, helps direct the innovation, i.e. experiments, prototypes, trials and demos, in the right direction as illustrated in Figure 27 below.
We also recommend using one single challenge instead of the classic balanced scorecard to focus the innovation efforts even more toward the area where you have the biggest need currently and work with this challenge for 1–3 quarters until you are done. One example of a quarterly challenge in Figure 27 above that we used was this: Every sprint deployed to a live network with added value and higher quality. Our development teams then used this challenge to come up with experiments, trials and prototypes that they wanted to do to contribute to making the challenge, and thus also the strategy, happen.
The story-telling we used here was borrowed from Ferrari where the culture builds on the founder Enzo Ferrari’s words “The best Ferrari we ever produced is always the next one.” — see Figure 28 below.
Try: Learning Days
One example of securing time and space for innovation is our Learning Days that grew into a full-day, multi-site, multi-track, internal conference with internal content from teams, engineers and leaders, as well as invited external speakers — run every sprint, i.e. every three weeks, see Figure 29 below. Most organizations do this at most once or twice a year if they do it at all.
It started with one person having an idea that was allowed to grow and continued to grow during the year thanks to support from the organization. The fact that we never had to chase topics, that it has continued to grow and that people are both encouraged and willing to attend is what has made it possible. It works because it‘s “low maintenance” and a “no-fuss” event that has become a tradition/ceremony within the organization thanks to the regularity of the sprint cadence.
Try: !nnovation Operating System (!OS)
Figure 30 below contains 107 words, 737 characters describing our !nnovation Operating System (!OS). It is a way to articulate and operationalize a wanted culture for innovation based on the successful patterns we have seen. We have used applied systems thinking in the form of the Human System Action Tool developed by Hendrik Esser to ensure that the patterns found cover all important dimensions, i.e. wanted behaviors, needed capabilities, enabling structures and supporting processes — that all contribute to innovation = value from ideas.
Summary
Our large-scale Lean/Agile transformation journey 2010–2016 gave us 4x value throughput, 2x speed, 10x quality and happier, more engaged people who are more innovative.
During the journey, we made three mental leaps:
- From methods & tools to principles & mindset
- From resource efficiency to flow efficiency
- From scattered experiences to continuous innovation
What will Your next mental leap be?
For Further Inspiration and Learning
This article is based on the following presentations:
Schön: The Mental Leaps — More, Faster, Better, Happier & More Innovative! (Continuous Delivery and DevOps Conference Scandinavia, Copenhagen) Video Slidedeck
Schön: The Mental Leaps @ Ericsson (Scania Spark for Change, Stockholm). Video Slidedeck
Schön: The Mental Leaps @ Ericsson (Innovation Roundtable, Paris)
Schön: The Mental Leaps at Ericsson 3G (Mix-IT Conference, Lyon). Video Slidedeck
Schön: The Mental Leaps at Ericsson 3G (XP Conference, Helsinki)
Schön: The Mental Leaps at Ericsson 3G (Stockholm Software Craftsmanship Meetup)
Forss, Schön: The Mental Leaps at Ericsson 3G (Agile Conference, Orlando)
Schön: Flow Thinking @ Ericsson 3G (Lean Kanban Conference, Stockholm)
Forss, Schön: Flow Thinking (Lean Kanban Conference, Hamburg). Video Slidedeck
This article is the starting point for the following article in Cutter Business Technology Journal, Vol. 32, No. 5, 2019 on “Cutting Edge Agile” with Alistair Cockburn as Guest Editor: Mental Leaps: More, Faster, Better, Happier, and Innovative! (registration required). The Cutter Business Technology Journal article is also available here.
You can find my work on leadership, strategy and Lean/Agile, e.g. the books The Art of Change, The Art of Strategy and The Art of Leadership, at Yokoso Press, Medium, SlideShare and YouTube.
Additional articles, books and videos for further inspiration and learning regarding flow, Lean, Agile and applied systems thinking are given below.
Articles
Kniberg, Cockburn: Elephant Carpaccio Exercise
Larman, Vodde: Lean Primer
Meadows: Leverage Points: Places to Intervene in a System
Mikkonen, Seikola, Ari Jouppila, Engblom: How We Learn to Stop Worrying and Live with Uncertainties
Reinertsen, Thomke: Six Myths of Product Development
Schön: How Do We Get Speed, Innovation and Engagement?
Schön: Skating to Where the Puck is Going to Be — Se7en Game Changers for Organizations
Books
Larman, Vodde: Scaling Lean & Agile Development
Modig, Åhlström: This is Lean — Resolving the Efficiency Paradox
Mary Poppendieck, Poppendieck: The Lean Mindset: Ask the Right Questions
Reinertsen: Principles of Product Development Flow
Ulfsparre, Bjuhr, Eriksson, Holste, Lund, Pucar Rimhagen, Tötzel: XXL Agile & Lean Coaching
Presentations
Esser: The Human System Action Tool. Video Slidedeck
Kniberg: The Resource Utilization Trap
Modig: The Efficiency Paradox
Reinertsen: An Introduction to Second Generation Lean Product Development
Sidky: The Secret to Achieving Agility at Scale
Schön: How Do We Get Speed, Innovation and Engagement?
Schön: Skating to Where the Puck is Going to Be — Seven Game Changers for Organizations. Video Slidedeck Interview
Kudos
Håkan Forss — for inspiration, coaching and LEGO :-)
Craig Larman and Bas Vodde — for crystal clear, written, pragmatic guidance.
Niklas Modig — for new perspectives on lean and flow.
Mary Poppendieck & Tom Poppendieck — for inspiration on the lean mindset.
Don Reinertsen — for an economic view on lean, and, rigorous flow principles.
Hendrik Esser — for discussions and constraints for applied systems thinking.
Stephen Denning and the Learning Consortium — for conversations on mindset and story-telling.
Björn Tikkanen, Henrik Kniberg and Jonas Boegård for encouraging me to write things up.
The Flow Fans (you know who you are :-) and everyone in Product Development Unit 2G/3G at Ericsson for making this happen, together!
