Rethinking Agile- Book Summary & Notes

Rethinking agile — Why agile teams have nothing to do with business agility written by Dr. Klaus Leopold should be a must read for any Organisation and its leaders running a transformation or starting one. As mentioned on its backcover — “This book shows what goes wrong with many agile transitions, and why the desired improvements fail to materialize. You also learn how to get out of a dead end and what can be done before starting a transformation in order to prevent heading down a dead end to begin with.

A little preview: Do not start by making teams agile — this will save your nerves and lots of money!”

I had read this book when it came out, and re-read it again after a covnersation with Dr. Leapold and a few other practitioners on the “Flight Levels Academy” community. Here is my summary of the book, and if you like it, I recommend you to buy the print edition as it is an illustrated book, and you will thank me later. For more summaries, please check all the published summaries here: https://sunishchabba.medium.com/ and you can follow me to be notified of upcoming summaries.

Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility — Summary

PART 1: The Problem “We want agility!”

This is about a company that wanted to be prepared for the future and paved the way there with good intentions. Actually, nothing could go wrong. Upper management was committed, the budgets were available, the agile coaches were booked. It was taking so much time to implement good ideas that the competition was already two steps ahead with a similar product, although these younger and more dynamic rivals had not reached the same level of market penetration. Unfortunately, the company had become a follower over the last few years, leading to difficulty even in its day-to-day business.

Something needed to change, that much was clear. And management quickly figured out what needed to improve:

1. The Time-to-Market should be optimized.
2. Using fast customer feedback, necessary changes should be recognized and integrated earlier. That means: The customer must be significantly more involved in the development process than they had been till now.
3. The company should be ready for the future. Digitalization, the Internet of Things, machine learning, and cryptocurrencies were only a few of the buzzwords that kept coming up in the discussions. But there would be no future company if they continued operating so rigidly in the market.

TRANSFORMATION PREPARATIONS — EXEMPLARY

600 IT employees were encouraged to use agile methods in order to get the business back on track. To achieve this, the head of internal organizational development was given the mandate to implement an 18-month transformation project.

The departments and teams could even choose the agile framework they wanted to use. However, management established some parameters that everyone needed to follow — because the project initiators promised the greatest leveraging effect based on these conditions:

1. All teams should be cross-functional. In doing this, the initiators wanted to eliminate any existing dependencies to reduce coordination effort and waiting time, thus improving Time-to-Market.
2. Every team should be organized according to the premise: One team, one product.

Even if the teams could choose the agile method they wanted to use, the following minimum requirements needed to be fulfilled:

a. The work should be visible, i.e. it should be visually managed.

b. Every team was compelled to hold daily Standups in front of the boards.

c. Regular Retrospectives should provide the teams a perspective on possibilities for improvement.
d. Two measurements should be established as an additional feedback mechanism for the teams and the transformation. Not to define quantitative goals, but to have further reference points for assessing the effectiveness of the measures and improvements being implemented. The following measures would help with this:

1 Throughput: The number of work items that are completed in a given timeframe (such as projects per month, Stories per Sprint, etc.). In Scrum, this is referred to as Velocity.

1 Cycle Time: This indicates how fast work is completed.

Actionables:

1. Standups: Standups are short meetings that occur frequently — daily, for example — while standing before a task board or Kanban board. Within a maximum 15-minute timeframe, the group discusses what needs to be done to complete the work, how impediments and quality issues will be dealt with and who should work on what. The focus is on the work, not on the individual members in the group.
2. Retrospective: The goal of a Retrospective is to perform a collaborative review of how work was executed over a given timeframe and infer improvements from this review. Operational work is intentionally exposed in order to observe, from a meta-level, the working methods, processes, effects of previous improvements, feedback from customers and colleagues, as well as the team’s morale.

THE TRANSFORMATION PROCESS

In this company, the changes went to the core. At the same time, method choice was left to the teams themselves — depending on what the employees found appropriate for their area of responsibility. During implementation, the following steps were interwoven with one another and, as such, were not completed sequentially.

1. TRAINING

All 600 IT employees took part in a one-day basic training which focused on “agile mindset”.

1. REORGANIZATION THROUGH SELF-ORGANIZATION
   The company realigned the cross-functional teams according to the product structure. The employees were not simply assigned to individual teams. Management only decided which teams were needed for which products. So, instead of teams being assigned from above, a marketplace was organized. Over two days, team leaders used display booths to advertise their team and the available jobs. A budget was assigned to each team ahead of time so they could “buy” the necessary employees. The employees were allowed to decide in which team they wanted to work. After the teams had formed, team members then took part in the necessary training. For example, there were Scrum Master and Product Owner trainings, and if a team had decided to use Kanban, they could visualize their initial workflow in a system design workshop and at the same time consolidate the team.
2. EXTERNAL SUPPORT
   Reorganizing 600 people is an ambitious program. In a short period of time, the people in this company were supposed to do — sometimes in completely new roles — something that they have never done before. The company hired 16 external Agile coaches to execute the needed training, provide an outsider’s perspective on implementing the agile methods and help the teams practice using these methods.

Actionables:

1. System Design workshop: The visible end product of a System Design workshop is a Kanban board. The most important objective in such a workshop is to gain a mutual understanding about how a group of people are currently working together. The visualization does not represent a desired or dictated process, rather it represents what is actually being done right now. This current Kanban system is the starting point for improvements. That’s why it is so important that a Kanban system is designed by those who are using it.

THE RESULTS AFTER TWELVE MONTHS

To implement the minimum requirements — creating cross-functional product teams, visualization, Standups, Retrospectives and measurements — the company set an eighteen-month timeframe. The plan seemed to be working:

● More than 80 percent of the teams were “fully transformed” (directly quoted from the Transition Manager) and fulfilled the stipulated framework conditions.

● Every six months an employee survey was conducted and the most current survey showed that communication and coordination had qualitatively improved. The teams kept each other up to date on the status of their work, and they knew who was doing what and who was responsible for what.

THROUGHPUT TREND OF THE SCRUM TEAMS

Scrum Variables:

1. In Scrum, velocity is the measure of team’s throughput. It shows how much functionality a team can deliver in a Sprint. The amount that can be delivered is measured in Story Points.
2. A User Story is used to formulate a requirement, for example on a piece of software to be developed. In the Agile world, a simple format has been established:

As a <type of user>,

I want <some goal or objective>

so that <benefit, value>.

1. Story Points represent the complexity of a User Story, not the time required. When estimating several Stories, the complexity of the Stories are determined in relation to one another.

The Transition Team first looked at how velocity changed in the Scrum teams. In every Sprint, a Scrum team makes a commitment to complete a certain amount of work (in Scrum-speak we would be talking about the number of User Stories or Story Points). At the end of each Sprint, the amount of committed work is compared to what actually gets delivered — this result is recorded on the y-axis (Number of Story Points). This gives us the velocity or throughput of a team in a given timeframe.

The diagram shows the aggregated velocity of the Scrum teams within the company. The dotted line represents the results that were expected. When everything is running smoothly in a Scrum team, the velocity should continuously increase. The expectations of increased speed were fairly low at the beginning: The team needed to get used to the new working methods. However, after this initial training period, if Retrospectives are also held and continuous improvements are made, the line should steadily continue upwards and never turn downwards. Nonetheless, the actual trend of the Scrum teams looked completely different. The teams managed to get off to a good start and velocity increased sharply. Then all of a sudden, the line flattened out and was now in a downward trend. The performance had strongly diminished over time.

CYCLE TIME TREND OF THE KANBAN TEAMS

At the team level, the cycle time is fairly easy to determine: For each completed piece of work, the time difference between the start date and completion date is calculated. Ideally, the cycle times become shorter over time. A slight increase is expected in the cycle time to start with because the teams must get used to their new working methods. Afterwards, however, the line should quickly trend downwards. In this company, the cycle time increased slightly at the beginning but only marginally decreased over time. The line followed a downward trend, but the improvement did not even reach the 1 percent mark. It was clear that the Time-to-Market or the ability of the teams to deliver the end product had not changed much.

PART 2: The Causes–Looking for Stumbling Blocks

A huge pile of money had been put into this agile transformation. And now the overall goal — being able to react more quickly to market needs — had not been achieved and was in fact further away than before. Finally, an employee of the Transition Team of this company asked me tonavigate the situation and then hold a workshop to work through the assumptions and viewpoints of the decision makers — because making the IT agile was a request from the highest level. Behind their good intentions, was there a solid understanding about the interrelationships in the value stream, or did they just blindly hop on the Agile bandwagon? Afterwards, I requested to be shown the work and metrics from several teams in order to find out what underlying assumptions were used as they approached their agile transformation.

CAUSE #1: THE PITFALL OF SIMPLISTIC INFERENCE IN THE CHANGE PROCESS

When a company wants to change, the people within the company want to know what the result will be and how they will get there. So, they search for assurances, and plans give them this assurance. Having a plan is a good thing. It only becomes problematic if the decision makers are drawn towards simplistic inferences or reach for blueprints, which have become plentiful in the Agile scene.

Some of the simplistic inferences included:

1. We must become agile in order to reach this goal.
2. We need agile teams using agile methods that are extremely fast at delivering our products. We need Scrum Masters, Product Owners, Agile Coaches, and and and…
3. We need to define which roles are allowed to do what, who must sit in which meeting, and how frequently these meetings should be held…

What is the result after these inferences have been made? The entire organization talked about the most exciting questions, such as “Can the Product Owner take part in a Retrospective?” or “Is the Scrum Master also allowed to do work operatively in the team?” It was also easy to argue over isolated opinions: “We definitely won’t use Scrum because then we must work with Timeboxes” vs. “We definitely won’t use Kanban because it doesn’t have Timeboxes”.

This organization made a wrong turn early on in their thought process and along the way had confused the means for the purpose. At the very beginning, it was going about improving their Time-to-Market — now, however, everyone was talking about stupid rules that were written down years ago in some kind of agile framework.

Key Takeaway: Implementing agile methods is a means-not the purpose-for achieving business agility.

CAUSE #2: DEALING WITH DEPENDENCIES BETWEEN TEAMS AND PRODUCTS

After navigating through the management situation, I continued on to the teams. I found it amazing that all teams had made — as was required by the framework conditions — their work visible. Very often though, I saw an area on boards everywhere: “External Waiting”. Every team had visualized this area differently but always with the indication that a team could not work further on that task. They were waiting on deliveries, information or on services, such as opening ports in the firewall or making changes to database fields in a different product. In many cases it meant that the process must continue on another board within the organization since it wasn’t just dealing with dependencies on external deliverers.

WHAT DID THEY FORGET TO CONSIDER?

1. One product, many teams. It was correct that each team, in most cases, only worked on one product. However, several teams were often needed for one product. This created dependencies between the teams working on the same product.

2. Dependencies between products. The products themselves weren’t completely independent from one another. When a change was made in Product 1, something also needed to be changed in Product 2.

3. Peculiarities in knowledge work. We’re talking about 600 people in IT here. In so-called knowledge work, I don’t know any organization with more than 30 employees that has absolutely no dependencies and a single team generating 100 percent value for the customer.

Key Takeaway: There should be as many dependencies eliminated as possible. Most important, though, is good management of every dependency which remains since the idea of eliminating all dependencies in an organization is not realistic. An organization is not a container for completely independent teams — at least not in knowledge work.

CAUSE #3: AN INCOMPLETE VALUE STREAM

Here were teams of between 7 and 14 people working in an IT department with 600 employees in a company that was twice as large as the department itself.

“Okay, so you are in development”, I commenced with my questioning. “When you have finished development, then everything is completely finished and value for the customer has been generated?” At first, everyone nodded vigorously, some even let out an emphatic “Yes, of course!”. After a moment of reflection, though, another person tentatively raised their voice: “Well, more precisely, integration comes afterwards.” Good to know! Together we modeled integration as part of the value creation illustration.

“But after integration, everything is finished?”, I continued to ask. The team members gave themselves a moment to think before they answered. “Actually, after integration comes business department acceptance.” The board grew another step with the acceptance tests. Gradually, the team got used to the idea that this board was going to be somewhat longer. I didn’t even need to ask about the next step. “After that, we of course need to do a release”, was immediately thrown at me. Now I hit the brakes for a moment. With “Integration”, “Acceptance Testing” and “Release”, we had three steps visualized on the board that could have a substantial impact on the Time-to-Market. For this reason, I wanted to look at the steps more closely and asked, “At what intervals is integration done? And how often are acceptance tests performed and how often are there releases?” The core of the puzzle began to reveal itself. Integration was in a relatively timely manner, namely monthly. However, the acceptance testing as well as the releases were only done four times a year. This is extremely useful information when it’s going about improving the Time-to-Market.

WHERE THERE IS A FLOW, THERE IS ALSO A SOURCE

If there is a downstream, there is often also an upstream. Before development can even start, presumably some decisions need to be made. I packaged this in the (not so subtle) question: “At the beginning of the board stands the Backlog. So, you just simply start and nothing happens beforehand?” Of course, that wasn’t the case. “No, you can’t really say that it starts here. The Backlog is just the starting point for development.” That’s a good piece of information, so we renamed the Backlog “Development Backlog” and continued rowing upstream.

Several other team members started to clear off the space on the left side of the board, adding more columns. One glance was enough and they started telling me everything that was

happening upstream. It looked more or less like this:

● First, product ideas were collected in an idea pool.

● These ideas were roughly sorted during a triage (a preliminary selection).

● Business case rough drafts were created for the selected ideas.

● The business case rough draft then went to the Steering Committee, who decided whether or not an idea should be followed.

● Once the Steering Committee approved the rough draft, a detailed business case was created.

● The detailed business case again needed to get final approval from a committee.

Resultantly, the entire value stream had grown a bit.

Key Takeaway: There was no end-to-end management of the value-creation chain.

CAUSE #4: WIP LIMITS AT THE WRONG PLACE

Working on too many things at the same time is one of the biggest afflictions in organizations — work is not limited. As mentioned, many people in this company had spent time delving into agile methods and principles, including limiting the Work in Process (WIP). WIP limits are generally associated with Kanban, denoted as numbers at the top of individual columns showing the maximum amount of work allowed in the system at any given time. Almost all the teams in this company that used Kanban worked with WIP-limited systems. There is also an “implicit” WIP limit in Scrum. It comes from working in Sprints and the associated Commitment to a certain amount of work that should be completed in the Sprint. During a Sprint, no additional work is allowed to be pushed into the system, thus defining more or less a maximum WIP per Sprint. The effect of implicit or explicit WIP limits is, among other things, that the cycle times decrease and the predictability of work completion increases. The good thing was that almost all teams in this company worked with explicit or implicit WIP limits. Unfortunately, it didn’t seem to help.

WHAT IS THE PROBLEM WHEN STRATEGIC PORTFOLIO MANAGEMENT IS MISSING? Strategic portfolio management is the part of an organization that decides which initiatives will be implemented when. Executive management makes decisions every day about whether or not projects will be started. They not only make these decisions isolated from their executive management colleagues, as well as from all others in the company who must implement the project — they make decisions without considering all the other projects currently being implemented. Isolated individual decisions continuously increased the WIP of the initiatives — despite the initiatives needing to be limited.

Key Takeaway: There was no strategic-portfolio management.

PART 3: The Solution It’s flying, it’s flying …an improvemen

Often, at the planning phase of large-scale change projects, I introduce the Flight Levels model right at the start. Flight Level describes how high an airplane is flying. If you are flying at a very high altitude, you can see for miles in the distance but at the same time you cannot see every detail on the ground. On the other hand, if you are flying at a lower altitude, you can almost look into the bedroom window, so to speak. However, you can no longer recognize the areal extent of the city. Each flight level has its own characteristics and advantages but also has limitations on what can be seen.

Using the Flight Level model, we can find out which level of the organization offers the best leverage for improvement. It isn’t important which methods are used at each level. Instead, it is more important how the communication and cooperation is set up between the Flight Levels and between the various departments within each level.

FLIGHT LEVEL 1: OPERATIONAL LEVEL

Let’s start closest to the ground. The first Flight Level belongs to the teams that complete the daily work. A team can optimize themselves, or better said can optimize their individual workflow by implementing four essential actions:

● They visualize their work.

● They use WIP-Limits.

● They integrate routine feedback loops such as measurements, Daily Standups or Retrospectives in their process.

● They determine improvements through these feedback loops and implement them.

The method a team uses to develop a product or provide a service — agile or whatever — is completely irrelevant because the Flight Level model works independently of any particular method. In order to generate value for the customer, these individual systems typically must cooperate in some fashion. If you ignore this fact and place your focus only on optimizing individual teams, the risk of suboptimization arises. The reason for this is the dependencies between teams: There will always be some dependencies that cannot be resolved. These dependencies need to be managed at Flight Level 2.

FLIGHT LEVEL 2: COORDINATION

With Flight Level 2, we zoom out from the team level in order to visualize the value stream, which is the way particular product is created or service is fulfilled. The focus at Flight Level 2 is on the coordina- tion of end-to-end, from idea to reality, value- generating activities. At Flight Level 2, the interactions between teams are optimized.

Important: Flight Level 1 and Flight Level 2 must communicate with one another. That’s why at Flight Level 2, in terms of optimizing collaboration in a value stream, we use the same that are used at the team level:

● The work will be visualized.

● WIP limits will be utilized.

● There are routine feedback loops, such as Standups and Retrospectives with the team representatives.

● Improvements are derived and implemented from what is learned in the feedback loops.

FLIGHT LEVEL 3: STRATEGIC PORTFOLIO MANAGEMENT

At this level, one of the most important questions to be answered is: How much work can be sustained in the organization and is the work aligned with the strategy? At this flight level, it’s going about wisely choosing and combining strategic initiatives, projects and products to be developed, recognizing dependencies and optimizing flow through the value creation chain based on the actual resources available. It is recommended that the overall company strategy and supporting strategies, such as those from the various locations, are clearly visible on the Flight Level 3 board.

The Flight Level model is neither an organizational model nor a maturity model — Flight Level 3 is not three times better or more important than Flight Level 1. The Flight Levels are a tool to help you think and communicate and should simply make you aware at which level (and not in a hierarchical sense) leverage is available for solving a problem. Each Flight Level has a different focus:

● At Flight Level 3, the focus is on prioritizing upcoming projects and initiatives according to the strategic direction of the company.

● At Flight Level 2, the focus is on breaking down the chosen projects and initiatives into actionable pieces and coordinating the work with the participating operational units.

● At Flight Level 1, the teams involved in the operational work separate the tasks of the project/initiative into smaller packets and are focused on delivering them.

Generally speaking, it can be said that: The higher the Flight Level, the greater the leveraging effect. If the possibility exists to start an agile transformation at Flight Level 3, you should do it.

IMPROVEMENT 1: MAKE DEPENDENCIES VISIBLE AND MANAGE THEM

Value for the customer is only created when they receive the right product. The customer doesn’t care how the people working on and delivering the product were organized and structured. They only care about the value created for them. That’s why a structural reorganization should not be the beginning of an agile change initiative. Business agility is achieved when delivering value to the customer is optimized. Sooner or later, it becomes clear what needs to change in the organizational structure to support this.

MANAGING DEPENDENCIES BETWEEN TEAMS: DEVELOPING PRODUCT BOARDS

If dependencies cannot be eliminated, you must manage them. How can you get a handle on managing these dependencies?

1. Visualizing. First of all, those involved with each product thought about how it was developed, how the teams collaborated in the development process and at which points in the process, as well as in which direction, dependencies existed. For each product, this process was visualized on a product board. For smaller teams, we found out that this visualization could replace the team board because there was much more useful information, often with much better quality, on the product board. At the same time, the product board also gave them an overview of the broader context.
2. Limiting. If you want to achieve a faster time-to-market, for example, you must limit the units which have the greatest influence over it. At Flight Level 2, this means not starting more than you can finish.
3. Establishing feedback loops. A combined product board itself is not enough. The board doesn’t affect much, it simply portrays a situation. That’s why I advise against putting all the brainpower into visualizing and setting up buffers, swim lanes and impediments.

MANAGING DEPENDENCIES BETWEEN PRODUCTS: OPERATIONAL PORTFOLIO MANAGEMENT

On the product boards, there was still an area called “Waiting on External”. “Waiting on External” means there is a dependency outside of the depicted product value stream. Whether at the team or product level, dependencies are inconvenient. How can you get control over the dependencies at the product level?

1. Visualizing. We detailed the working process for these products (the portfolio) on one board. By doing this, the dependencies between the products became internal dependencies. These dependencies didn’t need to be depicted separately because they are actively managed by communicating through feedback mechanisms like Portfolio Standups. In operational portfolio management, external dependencies are those necessary connections and influences that are located outside of the product development, such as dependencies to suppliers.
2. Limiting. Next, we made sure that there was an optimal amount of work in this system; at the Portfolio Level, for example, it is the number of Epics.For me, one of the most important criteria for prioritization was the desired outcome a piece of work should deliver.
3. Establishing feedback loops. Again, feedback loops were set up in order to discuss what the product boards were showing. The dependencies were able to be managed, and necessities and possibilities for improvement could be identified. More specifically, the feedback loops were comprised of Portfolio Retrospectives and Portfolio Metrics. In operational portfolio management, for example, it is interesting to know how many days the cycle time is increased due to waiting on external dependencies. If we want to manage the dependencies between several products, it’s a good idea to bring all the products together on a single board and, as a result, establish a collective Backlog.

IMPROVEMENT 2: INTEGRATING THE UPSTREAM Business agility is the ability of a company to adjust to changes in the market and the demands of their customers. If the company’s solution for this is to simply make a department or even just a single team agile, they haven’t understood the challenge. Of course, you can apply agile practices exclusively to product development or service delivery, but as we observed in this company, the effect is limited. When agile teams reach the borders of the non-agile portion of the organization, they will eventually get stuck and be unable to reach their goals.

IMPROVEMENT 3: STRATEGIC PORTFOLIO MANAGEMENT

Business agility doesn’t work if an organization is comprised of agile islands while the logic of the surrounding processes remains the same and certain groups exempt themselves from practicing agility. Business agility starts at the top because executive management is still responsible for the strategic direction in most organizations. In the agile scene, many believe that organizations must manage without any hierarchy. I also think that many organizations are too hierarchical, but I do not believe that it can work without any management whatsoever.

Real business agility integrates the upstream and the downstream into a single value stream to create a fast and steady workflow. Put another way: Strategy, operations, development and delivery closely work together and, most import- antly, towards the same goal. For this to function properly, executive management must be on board.

Recommendations:

● It is recommended to hold Strategic Portfolio Standups on a weekly basis in order to make necessary decisions in a timely manner and in the context of the projects currently running.

● It makes sense to hold the individual meetings and workshops more often at the beginning and then get a feeling for the frequency that best fits your situation. Also, don’t make the meetings fill up the entire evening — we are talking about meetings taking about 15 min- utes when they are held twice weekly, for instance.

PART 4: The Result What was the result after all of this?

HOW CAN YOU MAKE YOUR BUSINESS AGILE?

DISCLAIMER: This is not an exhaustive list and has no particular order. Some steps must be done more than once.

START AT THE TOP

The first agile team to be established should be upper management. When I arrive at a company to help them get out of a rut in their agile transformation they are currently stuck in, managers are often very proud to show me their visualization abilities. “We have a task board which we use to track our management tasks. Next, we will work on the tickets ‘Create Annual Budget’ and ‘Check Employee Utilization’.” Congratulations on the fantastic to-do list with Post-Its, but not everything you stick a Post-It on is agile. The job of upper management is to really consider what business agility means, which pr.oblems need to be dealt with and above all what their role is in this process.

AGILITY BEGINS WITH THE CHANGE PROCESS

You cannot implement new ways of working and thinking on schedule. All of the successful transformation projects already experienced during the transformation process itself what they ultimately wanted to achieve. Should teams make incremental deliveries? Then don’t write a two-year transformation plan. Changing from push to pull means finding allies, marketing the idea and getting everyone invested in delivering customer value faster.

FOCUS ON THE GOAL, NOT ON THE METHOD

In some companies, “Agile” is turned into a type of cargo cult. The methods are worshipped, but not the goal. It doesn’t matter at all if a Standup takes 5 minutes or 20 minutes. Do you want to make your business agile or do you want to simply implement agile methods in your company?

AGILITY IS NOT A TEAM AFFAIR If you want an agile business, your focus should be on generating value (organizational processes) and not on organizational structure. Clearly, you need teams for the processes to work. But it makes little sense to optimize teams come hell or high water because optimal teams encompassed by broader bad processes contributes very little to business agility.

IDENTIFY THE FLIGHT LEVELS Since business agility is not a team affair, you should identify which Flight Level in your organization will be able to address which problem. Should initiatives be completed more quickly? Then the number of initiatives must be limited rather than optimizing teams.

MANAGE AND ELIMINATE DEPENDENCIES (EXACTLY IN THIS ORDER)

You must get used to the fact that there will always be dependencies within an organization, regardless how it is structured. And I use the words “always” and “never” very sparingly. So, let me repeat myself: There is no use in copying the magical structure of a different company, even if it seems like the right solution.

INCORPORATE THE DRIVERS FOR LEAN BUSINESS AGILITY AT EVERY FLIGHT LEVEL

Let’s assume you have identified the various Flight Levels within your company. Regardless if a team, product or strategy board will be built, the following four steps should be incorporated at every flight level:

1. Make the work and the processes explicit.
   Ít is essential to depict the existing processes and not the required or desired processes. Progress is best achieved when you start with the status quo.
2. Consciously manage WIP.
   WIP limits are one of the most powerful management tools available. Setting WIP limits means understanding which WIP impacts what. And sometimes this means increasing a WIP limit again or simply leaving it as it is.
3. Frequent feedback loops.
   Nobody wants to make a company agile just because there is nothing better to do. Agile transformations pursue specific goals, so it is extremely helpful to know where you are at right now. You need regular feedback from experiences. Metrics can clearly show if an action had an effect or not. You can then decide accordingly to do more or less of something, or discontinue doing something completely.
4. Improve.
   Don’t invest too much energy in trying to find the perfect visualizations, perfect WIPs and perfect meetings on your first try and then keep them that way forever and ever. There is no such thing as the absolute right whatever, only something that works right now. The trick behind business agility is improvement. Therefore, start doing as soon as possible, reflect on what you are doing and improve upon it.