+43-676-330-4803ContactImprint en de

Blog

Purchasing Power Parity Prices

As of July 1, 2020 , we’re offering adjusted fair pricing based on where you live, for all online workshops.
Our aim is to make workshops more accessible to all folks around the world, regardless of where they live, or how their economic situation looks. Today, We’re starting by removing some pricing obstacles that prevent fair and broad access to knowledge and learning.

Price adjustment will initially be group into two regions and based on PPP.

Standard Rates 100%
Australia, Austria, Bahrain, Belgium, Brunei, Canada, Cyprus, Denmark, Finland, France, Germany, Ireland, Italy, Iceland, Japan, Kuwait, South Korea, Luxembourg, Macau, Malta, Netherlands, New Zealand, Norway, Oman, San Marino, Saudi Arabia, Singapore, Spain, Sweden, Switzerland, Taiwan, United Arab Emirates, United Kingdom, United States, and Qatar.

Adjusted Rates 40% (Standard-Price x 0,4 = PPP0,4 price)

Brazil, Thailand, South Africa

Adjusted Rates 60% (Standard-Price x 0,6 = PPP0,6 price)

All Countries not listed above.

Take a look now which training you want to attend!

Systems Architecture oder Board Design: Wo bin ich richtig?

Vielleicht spielst du gerade mit dem Gedanken, dich für eines unserer Trainings zum Flight-Levels-Modell anzumelden. Wenn du ein öffentliches Training besuchen willst, hast du derzeit neben dem Flight Levels Coach zwei Optionen: Flight Levels Systems Architecture und Flight Levels Board Design. Was ist der Unterschied zwischen diesen beiden Trainings? In aller Kürze:

Boards spielen im Flight-Levels-Modell eine große Rolle, weil wir die Situation einer Organisation explizit machen müssen. Damit wir wissen, mit welchen Zusammenhängen und Voraussetzungen wir es zu tun haben, müssen wir sie so gut wie möglich sichtbar machen – das funktioniert mit Boards eben sehr gut. Doch physische oder elektronische Boards sind nur der augenscheinlichste Teil eines „Flight-Levels-Systems“. Zu einem System zählen wir auch die sogenannten Flight Items, also die Arbeiten, die sich auf den Boards wiederfinden. Außerdem gehören zum System die Personen oder Teams, die an der Bearbeitung der Flight Items beteiligt sind und die Formen der Interaktion zwischen diesen Beteiligten – damit sind in erster Linie regelmäßige Meetings, Retrospektiven etc. gemeint.

Weil so ein Board ja vermeintlich schnell gebaut ist, tappen viele Organisationen in die Falle und wollen sofort damit loslegen. Meine erste Frage, wenn ich in ein Unternehmen komme, lautet aber nicht „WIE bauen wir ein Board?“, sondern „WELCHE Boards müssen wir überhaupt bauen?“. Dann passiert Folgendes: Es wird die Gleichung „Board = Organisationsstruktur“ aufgestellt. Wir brauchen Boards für Teams, Abteilungen und Bereiche.

Nun ja, was soll ich sagen: Diese Gleichung ist falsch! Boards sollen dabei helfen, den Fluss der Arbeit durch die Organisation zu verbessern. Boards, die der Organisationsstruktur folgen, zementieren hingegen nur die bestehenden Silos. Den Kunden eines Unternehmens ist aber völlig egal, wie gut die Silos der Aufbauorganisation funktionieren – sie wollen gute Produkte und Services konsumieren. Deswegen ist es extrem wichtig, sich gut zu überlegen, welche Boards im Sinne der Lieferung an den Kunden gebaut werden sollten. Genau damit beschäftigen wir uns in Flight Levels Systems Architecture (FLSA).

 

Flight Levels System Architecture (FLSA)

Das Flight-Levels-Modell klingt sehr einfach und deswegen findet es wahrscheinlich auch den großen Anklang. So gut wie in jeder Organisation gibt es zumindest eine strategische und operative Ebene, und diese Ebenen versuchen wir in einen regelmäßigen, koordinierten Austausch zu bringen. So weit, so easy.

Doch wie sieht das aus, wenn eine Organisation nicht 10, sondern 1000 Mitarbeiter oder mehr hat? Hm, schon nicht mehr so easy. Wo verlaufen da die Flight Levels, wo fangen sie an und wo hören sie auf und welche Systeme werden auf welchem Flight Level benötigt? Richtig gelesen: Fast immer gibt es auf einer Ebene nicht nur ein Flight-Levels-System, sondern gleich mehrere.

In FLSA stellen wir uns anhand von Fallbeispielen der Teilnehmerinnen und Teilnehmer die Frage: Welche Flight-Levels-Systeme werden in der Organisation benötigt, um die Leistung für den Kunden zu erbringen, die wir erbringen wollen? In welcher Beziehung stehen diese Systeme? Wie verteilt sich die Arbeit über die einzelnen Systeme? Wie tauschen die Menschen in diesen Systemen untereinander die Informationen aus?

Die Antworten auf diese Fragen halten wir in einer Visualisierung fest, die uns alle benötigten Systeme und ihre Zusammenhänge zeigt.

Wenn wir dieses Diagramm erstellt haben, machen wir einen ersten Detaillierungsschritt: Welche Flight Items und welche Flight Routes gibt es in diesen Systemen? Anders ausgedrückt: Wir überlegen, wie die einzelnen Systeme ineinander greifen.

Wie bereits erwähnt, handelt es sich bei den Flight Items um die Arbeiten, die durch die Flight-Levels-Systeme fließen. Die Frage lautet also: Welche Arbeiten werden in den einzelnen System gemanagt? Auf einem Strategieboard werden wir zum Beispiel nicht die Tasks eines Teams der operativen Ebene sehen. Manches ist aber schwieriger zuzuordnen: Was gehört zum Beispiel auf ein Flight-Level-2-Board? Wie brechen wir die 5-Jahres-Strategie auf Tasks herunter und passt das überhaupt zusammen? Wo und wie können wir messen, welche Erfolge und Misserfolge wir haben?

Die Flight Routes beantworten die Frage, wo im Gesamtkontext der Organisation die Arbeit entsteht. Wo wird entschieden, woran gearbeitet wird? Wer ist von der Entscheidung betroffen? Wie schafft es die Arbeit von der Entscheidung bis zur Lieferung? In diesem Zusammenhang besprechen wir auch die Interaktionen zwischen den einzelnen Systemen: Wo sind welche Meetings in welcher Form sinnvoll?

Die entworfene Flight-Level-Architektur ist natürlich kein Selbstzweck, sondern sollte in der Organisation verankert werden. Im letzten Teil des Workshops besprechen wir daher den Take-off-Plan – einen agilen Veränderungsplan. Wir gehen nicht ins Detail, aber ihr erfahrt, worauf ihr besonders achten solltet.

Hier noch mal zusammengefasst die wichtigsten Themen des Flight Levels Systems Architecture Workshop:

  • Bauen einer Flight Levels Architektur
  • Definieren der Flight Items und Flight Routes
  • Festlegen der wichtigsten agilen Interaktionen
  • Erarbeiten eines ersten Take-Off-Plans

 

Flight Levels Board Design (FLBD)

Der Titel dieses Trainings ist genau genommen nicht korrekt, weil er nicht alles einschließt, was ihr hier lernt. Wir haben die Bezeichnung aber bewusst so gewählt, um zu zeigen, dass es um die aktive, tägliche Arbeit mit Flight-Levels-Systemen geht. Naturgemäß ist das wesentlich mehr als nur das Artefakt „Board“. Bei der Inbetriebnahme von und der folgenden regelmäßigen Arbeit mit  Flight-Levels-Systemen wiederholen sich immer wieder die folgenden Schritte:

Wie diese Schritte in der Praxis funktionieren, sehen wir uns an diesen zwei Tagen an. Selbstverständlich bauen wir Boards, und zwar Flight-Level-2-Systeme. Dabei steht die Frage im Mittelpunkt: Was ist ein funktionierender Arbeitsfluss und wie helfen Boards dabei, diesen „Flow“ zu schaffen?

Besonders wichtig: Beide Trainings setzen auf jeden Fall grundlegendes, noch besser jedoch fortgeschrittenes Wissen in agilen Arbeitsmethoden voraus. Und hier nochmal zusammengefasst, worum es in den beiden Trainings geht:

  • Flight Levels System Architecture stellt die Frage: Welche Boards bzw. Arbeitssysteme werden in der Organisation gebraucht?
  • Flight Levels Board Design stellt die Frage: Wie bauen wir diese Boards bzw. Arbeitssysteme?

What gets done at which Flight Level?

What gets done at which Flight Level and what should be happening at that flight level? We encounter this question over and over. This is partly due to how we use terms like “strategy”, “strategy operationalization”, end-to-end coordination, etc.

There is nothing worse than creating confusion by using inconsistent and undefined terms. This article will answer this question again for everyone (including us), so that we will remain uniform in our communication about flight levels.

The Flight Levels Model is a way of thinking that can be applied to any company. It is compatible at all levels with existing methods and is not itself another “method”. The Flight Levels Model is a tool for reflection. What can we leverage within the company in order to improve our business agility and achieve the desired direction in the market?

Flight Level 3 is dedicated to strategy. Here, objectives are defined and are put into a larger temporal context (e.g. three-year or five-year goals). Then, the focus is placed on the next year, the next three months, or some short-term timeframe. What does the company want to concentrate on in the next iteration? Which actions bring us closer to our goal and how will progress be measured? One popular tool for this strategy work is OKR – Objectives and Key Results (see https://de.wikipedia.org/wiki/Objectives_and_Key_Results). Regardless how the strategy is developed and how many hierarchical levels are at Flight Level 3, eventually “actions” (also known as initiatives, activities or projects) are created that will need to be coordinated end-to-end at Flight Level 2. ATTENTION: Strategic topics from the levels below can and must be included in the strategic planning!

These actions are prioritized at Flight Level 3 and serve as input for Flight Level 2, where actions are started as soon as capacity is available (pull principle). This prioritization and the selection of actions to be executed in the next iteration creates the focus required to move forward efficiently and purposefully.

Each strategy topic has one or more actions. At regular intervals, the goal status is jointly evaluated by participants of all Flight Levels, which creates transparency for Flight Level 2 (and subsequently also for Flight Level 1). The joint evaluation shows how the initiatives/actions/things contribute to the company’s strategy. Strategic alignment can be so simple.

At each Flight Level there can (but not necessarily!) be several, possibly even hierarchical, boards – even at Flight Level 3. An example: The strategy of an IT-heavy company for the next iteration includes management’s business goals and the IT department’s technical initiatives. Several top-level strategy boards will exist, but a consolidated view must be generated. This consolidated view is also a strategic view with a synopsis of the two top-level topics. When developing this derived strategy board, inputs from both sides are prioritized, dependencies taken into account and the focus of the project is defined.

Flight Level 2 is the workbench of end-to-end coordination in the company. The initiatives from Flight Level 3 become the backlog items for Flight Level 2. The work or initiatives to be carried out in the next iteration are derived from this backlog. Flight Level 2 is a coordination level. Large tasks (sometimes called Epics) taken from the backlog are prioritized and placed in the implementation backlog for the teams (Flight Level 1). The teams take work (pull principle) when they have capacity available.

Each action is accompanied by “agile interactions” at regular intervals (stand-up meetings, workshops, etc.). By doing this, the flow of work through the system is maintained and improved, if necessary. These interactions also establish the area of focus for the next iteration at Flight Level 2, making it clear what Flight Level 1 should be delivering.

Flight Level 2, and the agile interactions taking place here, play a central role in the coordination and resolution of dependencies between teams/products/initiatives. Managing, and in the best case even resolving, these dependencies is often the biggest lever to improve the flow of work in the system. That’s why this topic is so important to us.

The working system at Flight Level 2 can also consist of hierarchical boards. If the boards at Flight Level 2 are oriented towards products, for example, there can be one or more coordination boards for product groups. It may also be necessary to coordinate work between different products when multiple products need to be changed for the implementation of a strategic theme. This results in dependencies that need to be managed.

Last but not least, Flight Level 1 creates the deliverables – it is the operational level in the company. This is where the operational teams who receive work from Flight Level 2 (Epics) are based. For each iteration, the teams concentrate on a certain scope (e.g. in Scrum it is the sprint target) and implement these tasks. On Flight Level 1, for example, the user stories from Epics are cut into tasks and implemented. Short iterations are planned and the finished work is delivered.

For the coordination, each team sends representatives to the agile interactions of Flight Level 2. But even at Flight Level 1 itself, there can (and will) be such interactions from a certain size of the company. Standups are an example of this. Another example would be a common architecture board, with whose help the teams coordinate the architecture of the product to be delivered. However, such a board is not a Flight Level 2 board, as it deals with topics that directly affect the delivery of the work.

As already mentioned in Flight Level 3, strategic or cross-product topics might arise which cannot be handled as purely operational work within the scope of normal activities. There might be topics that have a significant influence on the strategy. In this case, it is up to Flight Level 1 to pass these topics on to Flight Level 2 or even 3 so that they can be planned in the coming iterations.

The agile interactions at and between all levels are the tactical component of the work. Here, the existing competences can be organized around the work in such a way that the outcome, rather than the output, is maximized. “Outcome” means doing the right thing – and that doesn’t always have to happen super-efficiently. For an economically managed company, it is much more important to deliver the right thing and not be fully loaded than to deliver the completely wrong thing at full capacity.

This is what we see most often in organizations: the focus must be on the outcome. Companies often deliver a great deal (output), but have the feeling that they cannot achieve anything (no economically noticeable outcome).

Organizations must learn to align their competencies and capacities with the work, and not to align the work with the competencies. Otherwise, a lot may be delivered, but not what results in the sense of the strategy. But that is a different story and will be examined in more detail in another article.

Who shall be the voice of the Rethinking Agile audio book?

We are currently in the process of bringing Rethinking Agile to the audio world. We have already pre-selected three possible voices and want your help by selecting the final one. Please listen to the samples below and select one of the speakers in the form and send us what you think! If you would like to be notified when the Rethinking Agile audio book is published, please leave us your e-mail address. This is optional. Thank you for your help!