The Mental Leaps — More, Faster, Better, Happier & More Innovative!

Introduction

In this write-up I’ll share experiences and insights from a Lean/Agile transformation journey in a large product development unit resulting in 4x value throughput, 2x speed, 10x quality, and, happier, more engaged people that are more innovative.

I’ll talk about three mental leaps that we made on our journey:

  1. From methods & tools to principles & mindset:
    Tools and methods can work in some contexts and not in others. If you have your own principles and mindset, then you can adapt or create your own 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
  2. From resource efficiency to flow efficiency:
    With a need to reduce both costs and time-to-market we were looking for alternatives to “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.
  3. 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 write-up.

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.

Figure 1: Parts of a mobile communication network.

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 000s of subscribers with downtime 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 the 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 illustrates how the Apple iPhone, first launched in 2007, transformed the lives of hundreds of millions of people.

Figure 2: Announcing the new Pope in 2005.
Figure 3: Announcing the new Pope in 2013.

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 of this way or working was highly questionable and, as a consequence, that we had to try something fundamentally different. Our biggest challenges in 2010 were product quality, 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.

Figure 4: Our heritage — overlapping waterfall projects with big upfront design.

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 late 2010 and early 2011 to go see and have a conversation in order to learn more. Everyone that came back were 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 clearly 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.

Figure 5: Inspiration from our colleagues in Finland — Scrum and Continuous Integration.

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, direction thanks to strategy work done together earlier.

We avoided using classic command and control, top-down, big bang change management. Instead, we setup 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 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 on a quarterly basis, and, 
    3. easier competence building for teams.
  • Continuous Programs (no projects) enables continuous feedback, learning and improvements of ways of working in the programs.
  • Co-located, semi-permanent end-to-end cross-functional feature teams avoids 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.
Figure 6: Cross-functional team SuperSonic at their kick-off.
  • 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 trying 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 giving a direction and WHY based on our needs as illustrated in Figure 7 below.

Figure 7: Pointing to the destination, giving direction and answering ”why?”

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 fully engaged.

This was done before we knew how to achieve these rather aggressive targets. The key learnings for us was 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 avoiding sub-optimization. So, did we achieve these ambitious long-term KPIs in 2015? Yes, we did!

The decision and usage of KPIs was 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 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.

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.

Figure 8: Delivering in large batches for cost advantage.
Figure 9: Delivering in smaller batches for value advantage.

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 Alastair Cockburn and Henrik Kniberg) for a large feature:

  1. The feature was originally planned for two teams.
  2. 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.
  3. After this, the sub-features were further split into sub-parts.
  4. 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. In fact, subparts 5 and 6 where 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.

Figure 10: Slicing a feature to secure faster value delivery and quicker feedback and learning.

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.

Figure 11: Run improvements as small experiments that are safe to try.

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.

Figure 12: Playing cone football with limited visibility and only very local awareness.

As a contrast, Figure 13 shows how the best football teams play: everyone on the team sees the whole field and work together to win.

Figure 13: Playing real football with full visibility and global awareness.

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 need to solution delivered an in operation. Stake-holders meet at least once a week in the room at the visualization board to get features out of blocked state and improve the flow by visualizing, managing and removing queues and impediments in the product development process, see Figure 14 below.

Figure 14: Visualization room with key stakeholders and video conference link to other sites.

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 clearly visible that certain process steps (columns) 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 = limiting the Work-in-Process (WIP).

Figure 15: A visualization board securing global awareness at a glance, and, hinting what to do.

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.

Figure 16: Mindset, values and principles > practices. Source: Ahmed Sidky.

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 own 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.”

Figure 17: A typical organization where the people work isolated from each other.

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.

Figure 18: Examples of high resource efficiency (steel mill) and high flow efficiency (emergency service).

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 the resource efficiency, see Figure 19 below. The reason is that by 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 the resource utilization trap.

Figure 19: Start aiming for high flow efficiency, then aim for high resource efficiency.

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.

Figure 20: Resource utilization and lack of flow on a highway.

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 being 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.”

Figure 21: Inspiration from “the Don of Flow”.

So, we started story-telling about how we secure flow of packets with low latency in our products could be used as inspiration for how to secure flow of features with short lead-time in our processes, as illustrated in Figures 22–24 below.

Figure 22: Internal story-telling how flow in our processes is similar to flow in our products.

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.

Figure 23: Ensuring high capacity in processes is similar to ensuring high capacity in products.

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 is 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.

Figure 24: First flow efficiency, then resource efficiency in both processes and products.

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!

Figure 25. Use different leverage points to improve a system. Source: Donella Meadows.

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 really 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 would have said 10%, it would in practice be close to 0%.

Figure 26: Planning with less than full utilization creates an environment for innovation.

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.

Figure 27: Many small experiments towards the next challenge on the way to the vision.

We also recommend using one single challenge instead of the classic balanced scorecard to focus the innovation efforts even more towards 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 in order 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.

Figure 28: Ferrari.

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.

Figure 29: Learning Days — hands-on workshop (left) and example schedule (right).

It started with one person having an idea that was given the opportunity to grow and continued to grow during the course of 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 secure 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.

Figure 30: !nnovation Operating System (!OS) based on Hendrik Esser’s Human System Action Tool.

Summary

Our large-scale Lean/Agile transformation journey 2010–2016 gave us 4x value throughput, 2x speed, 10x quality and happier, more engaged people that 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 write-up 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

You can find my work on leadership, strategy and Lean/Agile, e.g. The Art of Strategy, on 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.

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!