More on this book
Community
Kindle Notes & Highlights
If instead you place the focus on the organizational processes and permanently optimize it to fulfill the customers' needs, it's possible that at some point the organizational structure will change. But then the structure is oriented towards necessities and current insights, not on wishes. "Agile" is what the organization becomes through its own development, not something that goes live according to a particular deadline. Organizational change should start with the organizational processes because fulfilling customer wishes, as well as the Time-to-Market, is a question of the processes used,
...more
FAST Agile - dynamic org structure
the management and teams were mostly shocked at first. Their idea was to eliminate as many dependencies as possible. That's why teams were newly arranged as cross-functional teams where each one was only working on one product. The teams shouldn't even have to wait on other teams. And yet there were a number of dependencies visible
FAST Agile solves for this...
What did they forget to consider? 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. 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. And when something in Product 2 was altered, something in Product 7 also needed a change. Peculiarities in knowledge work. We're talking about
...more
FAST Agile solves for this...
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.
FAST Agile solves for this...
despite all of the cross-functional and teams-for-products separation efforts in this company, many acute dependencies still existed. The situation did not improve when the teams started using agile methods. A team might phenomenally increase their performance and continuously improve themselves, but the effect of this local improvement is limited to the team itself. Stringing together locally optimized units does not create a globally optimized system—as much as I hate to say it. Quite the opposite: If a team optimizes itself to the highest degree, the entire value chain can get messed up.
...more
FAST Agile solves for this...
If we want to increase the system output, we must ensure that the right team is working on the right thing at the right time.
Sounds a whole lot like Open Space - and - FAST Agile!
An organization's agility is not created by stringing together a bunch of agile teams.
Agility is created when the interactions between teams are agile.
Business agility is not created when teams hold their Daily Standups and search for improvements during their Team Retrospectives. That is at best (local) agile development, which is okay. However, it has nothing, ABSOLUTELY NOTHING, to do with business agility.
Despite these agile development practices, this organization remained a lame duck.
You can do Scrum perfectly, and still have a lame duck organization.
For a long time, Kanban and Scrum were basically seen and marketed as high-speed plug-ins for teams. So WIP limits became instruments to limit the amount of work in the teams so that the teams would be faster. Fundamentally, this is okay if these teams only work for themselves and are not part of a larger context. However, teams are usually part of a larger organizational context,
You must limit the work where you want the effect, the value and the benefits of WIP limits to be realized.
they tried to implement agility with a classical project management approach.
Change and agility were seen as issues for the teams rather than for the entire organization.
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.
FAST checks all of these
In order to generate value for the customer, these individual systems typically must cooperate in some fashion—no team is an island. If you ignore this fact and place your focus only on optimizing individual teams, the risk of suboptimization arises. Yes, you will have a high-performing team. However, the overall performance of the organization, i.e. the combined performance of all teams, remains the same in the best case, but will most likely decrease.
Welcome to the world of system thinking! Local optimization often leads to global sub-optimization (see the keyboard example in Part 2). The reason for this is the dependencies between teams: There will always be some dependencies that cannot be resolved. These dependencies need to managed—that
Or in the case of FAST, self-managed.
The trick is getting the right team to work on the right thing at the right time.
FAST Agile solves this via self-organization! Open Space - the right people will have the right conversations at the right time...
If the possibility exists to start an agile transformation at Flight Level 3, you should do it. Because the only agile team that you absolutely need at the beginning of an agile transformation or change initiative is an agile upper-management team that practices agile strategic portfolio management. Everything else follows from here—lead by example.
I have seen corporate divisions with more than 2000 employees radically rid themselves of all their old meeting formats.
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.
knowledge in the organization is distributed in a way that the business priorities cannot be optimally addressed. What we see is another example, at a higher level, of local sub-optimization vs. global optimization. If each product has its own Backlog, uneven knowledge distribution within the organization would not be noticeable. The product teams optimize their own area, which is not necessarily what is best for the entire organization. The advantage of a collective Backlog when managing several products is that such irregularities are made visible.
FAST Agile Product Map...
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.
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. This might make placing the blame easier but isn't the least bit helpful to the company or its customers.
Agile is only ever a local optimization. For business agility, you need to look at the entire organization, system and culture.
When we talk about business agility, we are talking about the inner workings of the organization. Reaction time must be quicker and this starts with a new budgeting process—in
Beyond Budgeting
Determining the time and/or cost is a similarly protracted procedure of estimations, approval and new estimations, just like external order requests. The primary product from this process is very expensive paper because ultimately the estimates will most likely be incorrect.
FAST Estimation solves for this
It took five days to estimate that it would take the IT department one day to implement a certain feature. Another classic: cost estimations. It costs 80,000 Euros to estimate that a feature would cost 30,000 Euros to implement.
I am not saying that estimations are completely unnecessary. I do believe, though, that the effort for making estimations needs to be limited if the business should become agile. An estimation only needs to be as exact as necessary, not as exact as possible. In order to decide for or against an idea, you need nothing more than an approximate size of the implementation.
FAST Estimation...
Whether or not an idea has a future can only be determined if you show the customer something they can evaluate.
Business agility means going from idea to delivering value to the customer as quickly as possible. This works when an organization is not split into groups of people giving orders and groups of people executing orders and instead gradually removes the demarcation between "us" and "them". Dealing with and overcoming dependencies on each other can help the organization become more cohesive.
Teal
Trying to make a company agile does not inevitably make this situation better. Cross-functional teams are great to have and an important part of the company. However, it doesn't necessarily mean that old prejudices just disappear. Now you just have cross-functional Team A that performs better than cross-functional Team B. Instead of functional silos, there are cross-functional silos. Congratulations! If you reduce the dependencies and combine teams according to product lines, Product Y is naturally more idiotic than Product Z. And taken from the portfolio point of view, there are only complete
...more
Ditch bonuses
sounds. It is a cultural process that already starts with recruitment. The required maxim should be "don't hire skills, hire attitude".
Cross-functionality is a company mentality and not an organizational setup for teams. It means creating an environment where it is ok, or even desired, to perform poorly locally (whilst learning) if it helps the overall performance of the organization.
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.
I also think that many organizations are too hierarchical,
Getting executive management on board is not always easy, however. The expensive MBA knowledge is deeply anchored in their minds. But an agile company doesn't need a business administrator at the top, it needs a business leader.
Managers are constantly running from one appointment to the next, they are completely overbooked and are pressured from all sides. Nonetheless, they must be the pilots on the agile journey to avoid just sinking money into the local sub-optimization hole.
Strategy, operations, development and delivery closely work together and, most importantly, towards the same goal. For this to function properly, executive management must be on board.
While development teams followed all the rules and limited their work with blood, sweat and tears, the strategic level continued to start one initiative after the other. And that is exactly what happens in many companies wanting to become agile. This approach creates two conditions: confusion and stress.
In an organizational system, the ratio between initiatives that have been started to those that have been completed has a direct effect on the time-to-market. Strategic portfolio management is responsible for keeping this ratio in the correct balance and aligning these initiatives to the overall strategy. In order to align the work in the entire organization to the strategy, upper management must be willing to unequivocally and explicitly communicate the strategy and all the current initiatives within the organization to the employees.
The business silos isolated their innovation in a sluggish, centrally-controlled process and then pushed the work towards the IT silos where implementation occurred. IT was forced into the role of a mere supplier—a cost center. Today, innovation comes from the entire organization, including the IT employees. Management finally realized that product developers are close to the market and their understanding of development is especially valuable. As before, certain decisions are still made centrally, but the process leading up to the decision making is no longer centrally managed.
At the beginning of its transformation process, the company found out the hard way that business agility cannot work if only a part of the organization takes responsibility for it.
product development is for the most part a complex process, administrative tasks are often complicated [Snowden, Boone 2007 and Stacey 2000].
For the routine processes, people who are comfortable doing this routine work are hired.
Focus on Outcome rather than Output If you want an agile business, you should focus on the result and its effect, i.e. the outcome, rather than on the quantity, i.e. the output. In our company today, agility is no longer seen as delivering the largest quantity of initiatives as possible. Instead, more emphasis is placed on considering beforehand—even by the employees recommending ideas—what and how much an initiative contributes most and where the focus should be placed.
the goal of business agility is to positively impact the business metrics. It´s great if you deliver eight percent more features – but if nobody needs them, you have eight percent more garbage.
Start at the top The first agile team to be established should be upper management. And when I say agile, I mean agile. There has to be more than just lip service and generously delegating responsibility for the transformation to the lower hierarchy—"You have our blessing, go forth and become agile! It doesn't have anything to do with us."
The job of upper management is to really consider what business agility means, which problems 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.
Should an organization practice the pull principle? Then the employees must also be allowed to "pull" the changes. 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.
Do you want to make your business agile or do you want to simply implement agile methods in your company?
