Be the team coach who enables your team to deliver real value.
As a Scrum Master or Team Coach, you support your team in working together with focus, overcoming obstacles, and continuously growing step by step. Yet between high expectations, complex dynamics, and the balance of facilitation, coaching, and conflict resolution, the role can quickly become challenging. We know this situation well – and we understand how valuable it is to find confidence and your own style within it.
Our trainings and workshops provide you with hands-on tools and strategies to guide teams effectively, strengthen collaboration, and embed change in a sustainable way. Whether you are new to the role or want to further expand your skills, we help you grow with clarity and confidence – and truly make a difference for your teams.
Team coaching is more than facilitating meetings and applying methods.
It’s about strengthening responsibility within the team, providing guidance, and enabling real value creation – even in complex and uncertain situations. In our trainings, we show you what it really takes to make that happen.
No courses are currently available. Ask for a custom taylored inhouse training.
Got more than four participants or want to upskill your entire team?
Then our customized in-house trainings and workshops are just what you need. Starting at five participants, they’re especially cost-effective and tailored precisely to your team’s needs.
Whether it’s Scrum, Kanban, or scaling with SAFe – we adapt to your setup. From setting goals with OKRs or roadmaps, driving innovation with Design Thinking, structuring work with MVPs, story mapping, and small releases, to team dynamics.
Book your free (yet priceless) consultation today.
Whether you come to our training alone or learn together as a team, our first-class trainers and coaches bring years of practical experience to the table, helping you to apply everything you learn confidently and directly in your company.
The training was very intense yet simplistic, I have no problem understanding scrum concepts and implementation. All thanks to our trainers, I have a learning experience that has changed my career trajectory in a positive way
Maryjane
The training was very intense yet simplistic, I have no problem understanding scrum concepts and implementation. All thanks to our trainers, I have a learning experience that has changed my career trajectory in a positive way
Maryjane
Such a wonderful training , she was so patience and knowledgeable .
Anuoluwapo
Such a wonderful training , she was so patience and knowledgeable .
Anuoluwapo
The trainers are amazing and they make the content very interesting with the help of the drawings on the charts. They make sure to bring examples on how to apply these concepts in daily life of testers.
Not to forget, the trainings were a lot of fun. Certain fun activities helped the whole group understand the concepts much better, which otherwise would have been hard to understand.
All in all a 10 out of 10 to the trainers for an amazing training!
Swetha
The trainers are amazing and they make the content very interesting with the help of the drawings on the charts. They make sure to bring examples on how to apply these concepts in daily life of testers.
Not to forget, the trainings were a lot of fun. Certain fun activities helped the whole group understand the concepts much better, which otherwise would have been hard to understand.
All in all a 10 out of 10 to the trainers for an amazing training!
Swetha
Our trainings are interactive, hands-on, and full of energy. With a strong workshop character, real exchange at eye level, and a good dose of fun. You’ll work on real-world challenges using methods our trainers apply daily in actual organizations.
Absolutely. All our trainers have over 12 years of experience—working with teams, leaders, and entire organizations. They bring deep expertise and real-life stories that make your training tangible, relevant, and inspiring.
Yes, absolutely. There are no hidden costs with us. Certification fees are included in the training price—whether it’s from the Scrum Alliance or SAFe.
To keep discussions diverse and open, we allow a maximum of four participants from the same company per training. If you’re five or more, an in-house training is usually the better fit—just get in touch via our contact form.
Our trainings run in small groups of up to 10 participants—large enough for lively discussions, small enough for personal exchange. This way, we can address your individual questions and create an intensive learning experience.
You can cancel or reschedule free of charge up to two weeks before the training. After that, the full price applies. In case of unexpected emergencies (like illness), we’ll of course find a fair solution—just give us a call.
Yes! Early birds benefit from reduced pricing, and we also offer group discounts for multiple participants from the same company. Just reach out to us—we’ll find the best option for you.
We truly stand behind what we do. If you’re an individual participant and not satisfied with the training, you’ll get your money back—no questions asked.
This is a story about the path for a scrum team who started to use Kanban and the results of
the transition, which brought considerable improvements in performance but also improved
the situation for the development team.
The EMU team is working within the product line Human Vision, in the Continental ADAS
business line. The products provide a wide range of visualizations to support parking or
giving a better view around the car. Right now, the team works in the end phase of a
customer project for a good but demanding customer. The project is running in SAFe.
Why did the EMUs want to try out Kanban, it is a mature Scrum team that actually loves
Scrum? On the other hand, as most of us have experienced, in project “end phases” things
are not always running 100% smooth.
The customer felt the bug tickets were not prioritized high enough and that things generally
took too long. The customer was also unhappy with lack of flexibility for the frequent
unplanned “must have” tasks and had limited understanding for the team’s preference to
work on planned items.
The team on the other hand was annoyed with the, already mentioned, unplanned
customer items and the need to allocate time for unplanned review for external
contributions. They were disturbed that people often ran out of planned work in the end of
the sprint and that sometimes some items took very long time to get done. The team was
also, and still is quite large, in the project end phase with some 15 members. This resulted in
long and sometimes inefficient Scrum meetings. So far, the Emu’s did not want to split up in
two, more Scrum sized teams. One reason was it would be hard to make the teams
independent.
This was the situation when Felix, the EMU Scrum master and Martin, the PO searched for a
new way of working. We had already earlier had some lose chats about Kanban but now
they had gotten a buy-in from the EMU development team and asked if we together could try out if Kanban could improve the situation. It needs to be said, the EMU team is very
open for change and were encouraging the experiment.
We planned two workshops; one to run a flow simulation with the team. It was an online
version of Klaus Leopold’s “the Ship building simulation – improving and scaling Kanban”
(please find on YouTube). It is a great visualization about the difference of flow for a push
system and a pull system, with WIP limits. When running in pull mode the throughput
improves a bit but the changes in lead-time and predictability are enormous. Such a
simulation is a very good start to understand the ideas of pull and flow from Kanban.
The second meeting was a STATIK workshop, which is a “Systems Thinking Approach To
Introduce Kanban”. It is a systematic approach to investigate the situation from a holistic
point of view, where the whole team takes active part to define the way of working. When
is the service fit for purpose? What are sources for dissatisfaction? What kind of
requirements do we have? What is the performance? Thereafter you agree on a workflow
model, agree on how to handle different classes of services, and finally design a Kanban
system. The STATIK process helps to ensure we consider many facets of the situation, helps
us to get a common understanding and provides an agreement for the setup and next steps.
Finally, the still engaged team discussed and agreed on explicit rules for handling of the
process and the Kanban board. A stringent and “lived” set of rules is key for a successful
Kanban implementation. They agreed on WIP Limits for of the various workflow states and
on rules to always pick the highest prioritized item from the Selected items, even if it does
not fit to your expertise, to not move items backwards in the flow, that impediments are not
counted in the WIP but are discussed every day and that they have at maximum one blocker
in an expedite lane, that is allowed to break the WIP limit and order of execution.
The EMUs agreed to keep many of the processes from their Scrum that worked well, like
standups, review meetings, retrospectives and backlog refinement. These are also explicit
cadences in Kanban. The general cadence for e.g., review and retrospective is still two
weeks.
However they stopped estimation of items after a while, since the value of estimation is
lower in Kanban and to save time. Even if items are not mapped to sprints the team focuses
more on breaking down items as much as sensible, but in all cases shorter than two weeks.
They also have more focus on getting items “really done”, by including unit test and
documentation in the items.
For the replenishment of selected items, the active backlog for the team, they introduced a
rule to fill up when the number of selected items goes below a defined level (right now 5
items).
The new way of working had several positive effects. The customer got a considerably
higher throughput and some improvement in lead time but also experienced better
flexibility for ad hoc requests. The customer could also be confronted with direct impact on
putting urgent tasks in the backlog. This helped the stakeholders to reduce the number of
items with highest priority to get better focus.
For the team the new process has improved many things in addition to the feedback “more
pleasant / Less painful”. The team has got more flexibility and has less overhead, for
instance with leaving out estimation and having less discussions. “We have better focus on
the right things”, “we always have something important to work on” and “unpopular items
do not hang around for long time anymore”. In fact, even quality improved, since there is no
temptation to take a shortcut to get an item ready for the sprint end, now you can spend an
extra day or two to get something “really done”.
Other effects were better co-operation and a more active inspect and adapt process, with
more improvement proposals from the team. This may be the result after any change.
On the other hand, the team misses the end of a sprint when you can slow down, think a bit
and then start up again. In their Kanban setup the process still runs in a more continuous
mode, with less time for calm downs and re-thinkings.
Interesting enough the major change in delivery after introducing Kanban was in terms of
throughput, where the team delivered around 40% more during the 6 months after the
transition, compared to the 6 months before.
Also the lead time improved but not as significant, with a 15% reduction for the 85%
percentile (the lead time at which 85% of the items are closed).
The limited change in lead time is probably based on that the mature EMUs already had
focus on closing items in the scrum setup, but also due to the complicated long items that
turn up in every project end phase, when the simple things have already been fixed.
The increase in throughput is not fully clear, the team claimed in a presentation based on
early results “We do not know why we close more items (too good to be true?)”. However
also after 6 months there is a significant improvement. The reason is probably based on better cooperation between team members, where the WIP limits could lead to more pair
work, together with even more focus on finishing items. Further there was less down time
for developers, that earlier sometimes happened in the end of the sprints.
The improvement may also be related to other factors like item size and improved learning
and experience of developers.
For the EMU team the Kanban process improved the general performance in terms of
throughput and lead time, but it also improved the flexibility and focus to work and close
the most critical items. This has helped the team to provide a better service to the
customer.
The customer can be confronted with direct impact on putting urgent tasks in the backlog.
This helps the stakeholders to not put in too many items with highest priority.
The team experienced the new way of working as “more pleasant / Less painful”, within a
process that they had defined themself. The benefits are for instance less overhead in the
process, the urgent customer requests that earlier destroyed the planning are now business
as usual and there are always most important items to work on, earlier team members were
often without work in the end of the sprint. The team also owns the process better; when
the customer and/or PO now comes with a tricky request to be taken up “now” the team
asks “Is it a blocker? … well if it is not, please put it in the “selected” column, we’ll work on it
next”.
The initial workshops with flow simulation and STATIC helped to explain the benefits with
Kanban but also to get a buy in from the team. It is their process.
The Scrum master and Product Owners are obviously happy with the way Kanban turned
out but what would they do if they had to start from scratch:
Martin, the PO, “If I started up a new project I would probably start with Scrum and then
consider applying Kanban when team and project get more mature. In the early phase the
Scrum process seems to provide better structure to encounter too much flexibility from the
stakeholders.“
Felix, the SM, “the next thing to try out is to split the big team in two or three teams.”
For the last three months the project has an even higher demand on resolving items fast. At
this point the simple bugs were already fixed, what remains are complicated issues and
performance problems that require maximal focus. To encounter the situation the team,
still open for experimentation, decided to temporarily split up in four focus/topic sub teams,
which maintained own specialized backlogs. To further gain momentum, the whole
worldwide team co-located in Ulm for a week, it was a required and very appreciated move
to align on the last activities and tasks within the project before code freeze.
In the new setup the standup meetings were held per topic team, with a second common
standup with representatives for each topic team to align the whole team. The positive
effects were improved co-operation and communication in the small teams, including very
fast review and further improved throughput. A minor downside was the reduced
transparency for focus on the right things, since not all team members participated and
aligned in the common daily standup.
In the last weeks the sub teams joined into the normal EMU team again, since the most
critical specific work were closed into a more general bug fixing phase.
Felix Paffrath Conti, Martin Bürker Conti and Mats Olof Winroth improuv.
Nach zwei Jahren Zwangspause hat heuer das erste Post-Corona Global Scrum Gathering in Denver stattgefunden. Noch hat die ScrumAlliance keine Teilnehmerzahlen bekannt gegeben, aber geschätzt haben etwa 400-500 Menschen den Weg zu den Rockies gefunden. Angeblich haben sich nochmal eine ähnliche Anzahl von Teilnehmenden virtuell hinzugeschaltet. Für ein amerikanisches Gathering waren auffallend viele Menschen aus anderen Teilen der Welt angereist. Fast die Hälfte kam aus Europa, Asien, Südamerika und Asien – nur aus Australien und der Antarktis konnte ich niemanden finden. Was im Fall der Antarktis auch verständlich ist. Allen Beteiligten merkte man an, wie sehr sie danach lechzten, mal wieder “echte Menschen” kennenzulernen, sich nicht nur per Zoom-Kachel auszutauschen. Und so waren die Pausen und “Social Events” fast wichtiger als das Konferenzprogramm.
Besonders stachen die drei Keynotes aus dem Programm hervor. Bereits im “Vorprogramm”, dem “Guides Retreat” hielt Mike Cohn einen launigen Rückblick auf die Gründung der Scrum Alliance vor 20 Jahren, als er gemeinsam mit Ken Schwaber das erste Certified Scrum Master Training gegeben hatte: “We gave that training and the participants asked for a certification, so Ken invented the Certified Scrum Master.” Eine Entscheidung aus der mittlerweile über eine Millionen Zertifikate hervorgegangen sind. Freundlicherweise überging Mike Cohn die Konflikte innerhalb der Agilen Community, die diese Entscheidung zur Folge hatte, aber das wäre dem Anlass wohl auch nicht angemessen gewesen.
Die Konferenz selbst wurde von Chris Gardners Keynote eröffnet, dessen Aufstieg aus schwierigsten Verhältnissen zum Multimillionär 2006 unter dem Titel “Das Streben nach Glück” mit Will Smith in der Hauptrolle verfilmt worden war. Gardner betreibt heute Programme zur Förderung von Schülern an Brennpunktschulen.
Als dritte Keynote hielt Seth Godin der Community den Spiegel vor: “Ihr kümmert Euch zu sehr um Terminologie und Worte. Geht raus und verändert die Welt!” Und weiter “Do things that matter for people who care”.
Das weitere Programm war vor allem auf individuelle Entwicklung fokussiert. Vorträge und Workshops für Scrum Master und Product Owner zum einen, aber auch ein umfangreiches Programm zum Thema Führung. Das Konferenzprogramm schien sich da am Zertifizierungsprogramm der Scrum Alliance mit dem “Path to CSP” und dem CAL Programm zu orientieren.
Spanned fand ich vor allem, welche Themen nicht oder kaum vorkamen. Insbesondere das Thema Skalierung wurde so gut wie gar nicht angesprochen. Das mag zum einen daran liegen, dass die Kooperationen der Scrum Alliance mit Bas Vodde (LeSS) und Jeff Sutherland (Scrum@Scale) jeweils unter keinem guten Stern standen. Die Kooperation mit Sutherland endete sogar vor Gericht. Es könnte aber auch eine beginnende Strömung in der Agilen Community widerspiegeln, die in großen Skalierungsansätzen eher eine Bürokratisierung als eine Agilisierung sieht (siehe dazu auch den Beitrag “How not to Scale”, den ich gemeinsam mit Hendrik Esser, Darja Smite und Marcin Floryan im “emergence” Magazin veröffentlicht habe).
Sehr viele Agile Transformationen scheitern tatsächlich nicht an fehlenden Strukturen, sondern nicht angemessenen Führungsansätzen. Hier hilft Ausbildung der Führungskräfte mehr, als spezifische Skalierungsframeworks. Wenn sich die Scrum Alliance strategisch auf diesen Bereich fokussiert, könnte das ein gutes Alleinstellungsmerkmal im agilen Bereich werden. Zwanzig Jahre nach dem ersten Scrum Master Training könnte sie damit ihren neuen Existenzgrund gefunden haben. Ob bewusst, oder eher aus Versehen, ist dabei weniger wichtig, als die Frage, ob sie diese Richtung nun konsequent weiter verfolgt. Vielleicht gibt das Global Scrum Gathering im Oktober in Lissabon schon erste Antworten darauf. Unabhängig von Strategie und Politik war es einfach mal wieder schön, echte Menschen zu treffen und neue Kontakte aufzubauen. Das hat nicht nur der Agilen Community die letzten zwei Jahre gefehlt.
Martina ist mit Sicherheit die erfahrenste Entwicklerin im Team. Sie kennt sich gut aus mit dem System und hat Ahnung davon, wie man eine gute Architektur erstellt. Das ist aber kein Grund, die anderen Teammitglieder herumzukommandieren, finden diese. Sie fangen an, hinter Martinas Rücken über sie zu reden. “Sie tut so als wäre sie unsere Chefin, das ist sie aber nicht! Immer von oben herab, das geht mir auf den Senkel.” Beim letzten Product Backlog Refinement lag Martinas Schätzung für eine Story deutlich über den anderen. Diesmal schlossen die Teammitglieder sich aber nicht, wie so oft, Martinas Meinung an. Nach einer hitzigen Diskussion über den “richtigen” Schätzwert schimpft Martina gereizt: “Meine Güte, dann macht doch was ihr wollt! Klar, wenn ihr wieder nur diesen Quick and Dirty Code schreibt, geht es natürlich schneller, und das fliegt uns dann um die Ohren”. Wenn dies kein Online-Meeting wäre, würde sie sicher den Raum verlassen und die Tür hinter sich zuknallen.
Tim steht nicht gerade im Ruf, der fleißigste zu sein. Er achtet penibel auf die Einhaltung seiner Arbeitszeiten, ist bei der Auslegung seiner Pausenzeiten aber großzügig. Selbst vor dem Release-Datum, wenn alle anderen noch mal so richtig reinklotzen, hält Tim sich vornehm zurück. Beim Daily Scrum sind Spannungen selbst über die Zoom-Fenster spürbar. Gestern bemerkte Elisa schnippisch: “Na, ist der Herr diesmal mit seinen Aufgaben fertig geworden? Ansonsten wäre ich natürlich liebend gern bereit, sie noch mit zu erledigen, denn ich habe ja sonst nichts zu tun.” Tim sah sehr eingeschüchtert aus, berichtete aber sachlich über seine Tätigkeiten, als ob nichts wäre.
Klaus, der Product Owner, und Manuela, das Teammitglied, sind unterschiedlicher Meinung. “Wir müssen unbedingt dieses Feature mit ins nächste Release nehmen, sonst steigt uns unser Stakeholder aufs Dach, und ich bekomme Riesenärger”, sagt Klaus. Manuela entgegnet: “Aber du weißt doch, wir haben uns am Ende vom letzten Sprint geeinigt, dass wir auf jeden Fall dieses Reenngineering machen müssen, sonst häufen wir weiter technische Schulden an.”
Was tun als Scrum Master:in?
Zunächst mal: ruhig Blut und Nachdenken: Handelt es sich hier überhaupt um einen Konflikt, und wenn ja, um was für einen?
Viele Menschen haben Angst vor Konflikten. Sie befürchten Verletzungen. Die meisten von uns tragen schlimme Erfahrungen aus Konfliktsituationen mit sich herum. Als Scrum Master:in bist du verantwortlich, dich um den Konflikt zu kümmern, aber am liebsten würdest du ihn unter den Teppich kehren, aber das ist der falsche Weg. Mit diesem Blog-Artikel möchte ich dir Mut machen, konstruktiv mit Konflikten umzugehen.
Heiße Konflikte kann man nicht übersehen oder überhören. Sie werden leidenschaftlich ausgetragen. Die Konfliktparteien kämpfen für ihre Ziele und darum, sich durchzusetzen. Emotionen haben die Herrschaft über die vernünftigen Teile des Gehirns übernommen, so dass man den Argumenten der Gegenseite gegenüber nicht mehr zugänglich ist. Die Situation mit Martina im Product Backlog Refinement ist so ein Konflikt. Heiße Konflikte kündigen sich oft an durch Vorboten wie verdrehte Augen oder genervtes Stöhnen. Du hast dann die Chance einzugreifen und eine Eskalation zu vermeiden. Dann besteht eine gute Chance zur Klärung, zum Beispiel indem du die gemeinsamen Ziele herausarbeitet. Wichtige Sofortmaßnahme, um eine Eskalation zu verhindern: Sich nicht selbst in den Konflikt reinziehen lassen, sondern einen klaren und kühlen Kopf bewahren. Pause einläuten, damit sich die erhitzten Gemüter beruhigen können.
Ein kalter Konflikt ist weniger leicht zu erkennen. Es findet wenig direkte Kommunikation statt, man spürt Frustration und Enttäuschung. Die Konfliktpartner gehen sich aus dem Weg, beschränken sich auf Dienst nach Vorschrift, und die Qualität der Zusammenarbeit nimmt ab. Das macht kalte Konflikte schwieriger zu bearbeiten. Tim und seine Teammitglieder zeigen Anzeichen eines kalten Konflikts. Vielleicht ist etwas in der Vergangenheit passiert, was dazu geführt hat. Deine Aufgabe ist hier, den unter den Teppich gekehrten Konflikt wieder hervorzuholen. Das erfordert Mut und Fingerspitzengefühl. Es könnte nämlich sein, dass der glimmende Konflikt wieder richtig auflodert. Wichtig ist es, für eine sichere Umgebung zu sorgen und dafür, dass die Konfliktpartner respektvoll miteinander umgehen.
Und manchmal liegt auch gar kein Konflikt vor, sondern einfach eine Meinungsverschiedenheit, wie bei Klaus und Manuela. Sie tauschen sich leidenschaftlich, aber sachlich aus und schlagen nicht unter die Gürtellinie. Dann kannst du dich “ganz normal” als Facilitator betätigen und dafür sorgen, dass die Argumente gehört und verstanden werden.
Konflikte gehören zum Alltag in Teams, die gemeinsam Verantwortung übernehmen und Entscheidungen treffen sollen. Gerade in der Team-Building oder Forming-Phase treten sie häufig auf. Konflikte sind notwendig, damit Teams aus Fehlern der Vergangenheit lernen, entscheidende Maßnahmen ergreifen und das gesamte Talent und die Erfahrung des Teams nutzen können. Wir wollen “psychologische Sicherheit” erreichen: jede:r soll seine Meinung frei äußern können, über Schwierigkeiten und Fehler sprechen können. Das funktioniert nicht, wenn die Menschen Angst vor Konflikten haben.
Patrick Lencioni hat sich in seinem Buch “The Five Dysfunctions of a Team” mit Konflikten beschäftigt. Dort beschreibt er fünf Ebenen, die aufeinander aufbauen.
Die Angst vor Konflikten ist eine direkte Folge der ersten Dysfunktion, dem fehlenden Vertrauen. Ohne die Leitplanken, die das Vertrauen bietet, fürchten die Teammitglieder, dass jeder Konflikt in persönliche Sticheleien und unproduktive Streitereien ausartet, so dass sie Konflikte ganz vermeiden. Folge davon sind die drei oberen Ebenen: fehlendes Commitment, Vermeidung von Verantwortung und damit auch schlechte Ergebnisse.
Beim Umgang mit Konflikten musst Du zunächst unterscheiden zwischen inhaltlichen Konflikten, die (noch) nicht eskaliert sind und eskalierten Konflikten, bei denen die inhaltliche Meinungsverschiedenheit längst keine Rolle mehr spielt. Zu letzteren hat sich das Eskalationsmodell von Johann Glasl als hilfreiches Werkzeug etabliert [ Konflikteskalation nach Friedrich Glasl – Wikipedia. ] Als Scrum Masterin solltest Du aber das Team dabei unterstützen, Konflikte gar nicht erst eskalieren zu lassen. Hier ist das Wissen um die 4 Giftstoffe in Beziehungen – Schuldzuweisung, Verachtung, Verteidigung und Abschottung – und ihre Gegenmittel hilfreich. Es handelt sich um die häufigsten Fehlverhaltensweisen in Teams, die sich direkt negativ auf die Teamarbeit und vertrauensvolle Beziehungen auswirken. Die vier Gifte zu kennen und zu teilen trägt dazu bei, Verständnis füreinander zu wickeln und Konflikteskalation zu verhindern. Dies ist besonders wichtig, da jeder Mensch – bis zu einem gewissen Grad – von Zeit zu Zeit eines oder mehrere von ihnen anwendet. Es liegt einfach in unserer DNA.
Das Konzept der vier Gifte – auch die vier Reiter der Apokalypse genannt – wurde von John Gottman, entwickelt, der vor allem zu Beziehungsanalyse und Ehestabilität geforscht hat. Er behauptet, eine Methode entwickelt zu haben, mit der mit 90 % Wahrscheinlichkeit vorausgesagt werden kann, welche neu verheirateten Paare verheiratet bleiben und welche nach 4 bis 6 Jahren geschieden sein werden. Und diese Methode basiert auf dem Konfliktverhalten der Partner:innen. Es sind grundlegende Verhaltensmuster, die du vielleicht in dir selbst und deiner Partner:in erkennst – und die auch Teammitglieder in sich tragen. Mehr zu dem Thema findest du hier: Teamwork: 4 toxins that make teams derail, and how to avoid them (shinecoachingbarcelona.com).
Hier ist eine Übersicht über die vier Gifte und ihre Gegengifte:
| Gift | Beispiele für Gegengifte |
|---|---|
| Schuldzuweisung | Kritisiere – wenn überhaupt – das Verhalten und nicht die Person. Besser sind konkrete Verbesserungsvorschläge. Wenn du selbst kritisiert wirst, versuche es nicht persönlich zu nehmen. Hör gut zu und versuche, die Notlage deines Gegenübers zu erkennen. Vielleicht ist eine Entschuldigung angebracht? |
| Verachtung | Sprich über deine Beobachtung und deine Wahrnehmung der Verachtung. Welche Wirkung hat diese Verachtung auf dich? Äußere deinen Wunsch, wie die Situation anders zu lösen sei. |
| Verteidigung | Überlege dir: “Was wäre wenn… 2% von dem, was ich da höre, wahr wären?” Wenn du merkst, dass jemand anfängt, sich zu verteidigen, äußere Respekt und Anerkennung. Hör gut zu, was die Person sagen will, vielleicht fühlt sie sich nicht ausreichend gehört. |
| Abschottung | Die Abschottung ist normalerweise eine Reaktion auf Angst oder Gefahr. Versuche einen sicheren Raum ohne Angst zu schaffen. |
Du kannst dieses Konzept in Form eines Workshops mit deinem Team erforschen. In vorpandemischen Zeiten, als wir noch gemeinsam in Räumen gearbeitet haben, sah das so aus: die vier Gifte wurden auf PostIts geschrieben und auf dem Boden in vier Quadranten ausgelegt. Die Teammitglieder wurden gebeten, sich zu dem PostIt zu stellen, das ihr typisches Konfliktverhalten am ehesten beschreibt. Jede:r darf etwas dazu sagen Das geht ganz spielerisch, gibt oft Grund zum Lachen und bringt die Leute einander näher. Sie erkennen Muster, die erklären, warum es im Team zu Konflikten kommt, und entwickeln Verständnis füreinander. Dann überlegt das Team gemeinsam, welche Gegengifte sie anwenden können. Vielleicht kann man daraus direkt Teamregeln ableiten. Den Workshop kann man auch remote mit Miro-Boards machen, es ist aber nicht so wirkungsvoll.
Voraussetzung für so einen Workshop ist, dass die Teammitglieder bereit dazu sind. Dies solltest du durch Einzelgespräche vorbereiten. Du erkennst nun die Vergiftungen der Teammitglieder: Tim hat sich abgeschottet, als Reaktion auf eine Schuldzuweisung. Martina hat mit Schuldzuweisungen reagiert. Als Gegengift könntest du Tim beiseite nehmen und ein Gespräch unter vier Augen mit ihm führen. Vielleicht hat er gute Gründe dafür, warum er immer pünktlich nach Hause will und seinen Arbeitseinsatz auf das Notwendige reduziert. Ihn vor allen Leuten mit seinem Verhalten zu konfrontieren, würde ich nicht empfehlen. Danach könntest du eine Diskussion im Team führen mit dem Ziel, Vereinbarungen zum Arbeitseinsatz zu treffen. Vielleicht sind die 2% Wahrheit in Tims Arbeitsweise, dass er sich vor Überlastung schützen will, und vielleicht würde das den anderen auch ganz gut tun.
Auch im Fall von Martina würde ich mit einem persönlichen Gespräch beginnen. Vielleicht fühlt sie sich in ihrer Rolle als Expertin nicht ausreichend gewürdigt. Vielleicht kann sie eine neue Verantwortung darin finden, eher als Coach zu agieren.
Fazit: du bist als Scrum Master:in gefragt, bei Konflikten einzugreifen und zu verhindern, dass sie eskalieren und das Team schädigen. Damit du nicht auf Dauer den Hut des Konfliktlösers tragen musst, arbeite mit deinem Team daran, dass sie Konflikte selbst erkennen und lernen, sie konstruktiv zu nutzen. Das ist ein Schritt auf ihrem Weg zum effektiven Team. Deine Aufgabe ist es, für die psychologische Sicherheit zu sorgen, dass dies möglich werden kann. Und noch etwas: wenn du dich dem Konflikt nicht gewachsen fühlst, suche dir Hilfe bei Menschen, die den Umgang mit Konflikten gelernt haben – und nicht nur einen Blog-Artikel darüber gelesen haben. Oder besuche unser Training zum Advanced Certified Scrum Master Advanced Certified Scrum Master – vor Ort oder Live-Online (improuv.com). Die Inhalte dieses Blog-Artikels besprechen wir dort ausführlich.
Nach welchen Kriterien ordnet ihr euer Product Backlog? Nach Abhängigkeiten zwischen Produkt-Komponenten oder Teams? Nach Verfügbarkeit von bestimmten Experten? Nach der Lautstärke von Stakeholder-Stimmen? Oder lasst ihr wirtschaftliche Erwägungen in die Ordnung einfließen?
Als Product Owner:in seid ihr – laut Scrum Guide – nicht nur für ein effektives Backlog Management zuständig, sondern auch für die Maximierung des Werts des Produkts. Das bedeutet aus ökonomischer Sicht: die Maximierung des Profits, den ihr mit dem Produkt generieren könnt. Dazu hat sich Don Reinertsen in seinem Buch “The Principles of Product Development Flow” viele Gedanken gemacht. Ich möchte ein paar wesentliche Gesichtspunkte daraus extrahieren, die beim Product Backlog Management helfen, gute ökonomische Entscheidungen zu treffen. Genauer gesagt soll es darum gehen, das Product Backlog nach ökonomischen Kriterien zu ordnen, seine Größe und den Anteil für Releases festzulegen.
In der Praxis werden ganz unterschiedliche Ziele für die Produktentwicklung angegeben: Innovation erzeugen, Qualität verbessern, einen Plan einhalten, Verschwendung reduzieren… Sehr häufig hat die Product Owner:in sich mit Zielkonflikten herumzuschlagen, zum Beispiel: ist es besser, das Produkt jetzt zu releasen, oder sollten erst die bekannten Fehler beseitigt werden? Die einhellige Meinung in der agilen Community ist: Technische Schulden sind des Teufels und sollten auf jeden Fall vermieden werden. Aber ist diese Meinung immer ökonomisch gerechtfertigt? Ein weiteres Beispiel: Sollte das Produkt mit einem Minimum an Features auf den Markt, um frühes Feedback zu bekommen, oder sollten lieber noch ein paar weitere Features eingebaut werden, um die Chance auf begeisterte Kunden zu erhöhen? Wäre es nicht großartig, wenn wir diese Möglichkeiten anhand einer Größe vergleichen könnten, die den Einfluss auf den Profit während des gesamten Produkt-Lebenszyklus ausdrückt? Schauen wir uns das an dem ersten Beispiel von oben an:
Option A: Wieviel kostet es, das Release zu verschieben, bis alle Fehler beseitigt sind? Die CoD ist der in der Verzögerungszeit entgangene Gewinn. Sie ist in der Regel nicht konstant über die Zeit. Die Konkurrenz schläft nicht… vielleicht verpassen wir durch die Verschiebung ein wichtiges Marktfenster, und die Gewinnerwartung geht auf Null. Währenddessen steigen die Entwicklungskosten weiter an. Die folgende Abbildung aus dem Kanban Maturity Model der Kanban University zeigt verschiedene mögliche Zeitverläufe.
Die Verzögerung hat noch einen weiteren Nachteil: Da wir ein späteres Feedback vom Markt erhalten, leben wir länger mit der Unsicherheit, dass unser Produkt nicht gekauft wird.
Option B: Wieviel kostet es, die Fehlerbeseitigung zu verschieben, bis das Produkt am Markt ist? Wir erzeugen technische Schulden. Die Beseitigung eines Fehlers wird um so teurer, je weiter wir sie in die Zukunft verschieben, da es im Produkt Seiteneffekte gibt und der Testaufwand steigt. Außerdem besteht das Risiko, Kunden durch schlechte Qualität zu verärgern und dadurch einen Imageverlust zu erleiden.
Diese beiden Optionen mit konkreten Zahlen zu versehen, ist schwierig und abhängig vom jeweiligen Kontext, aber allein die Überlegungen dahinter sind sehr aufschlussreich. Sie helfen, Entscheidungen rational abzusichern und sich nicht (nur) auf sein Bauchgefühl zu verlassen. Solche Entscheidungen sind in der Regel stabiler und lassen sich besser begründen – auch wenn der Stakeholder mit der lauten Stimme anruft. Also: Quantifizieren wenn möglich, aber nicht um jeden Preis.
Verzögerungen kosten also Geld. Sie führen zu
Wie kommen diese Verzögerungen überhaupt zu Stande? Die Antwort ist: durch Wartezeiten. Wie bitte? Wir sind doch alle ständig am Rotieren und füllen Wartezeiten sofort mit neuen Aktivitäten. Genau da liegt das Problem: wir betrachten den einzelnen Menschen, oder das einzelne Team (allgemein: einen Service), und sehen deren Auslastung. Was wir nicht im Blick haben, ist die Arbeit, die von einem Service zum anderen weitergereicht wird. Vor ausgelasteten Services entstehen Warteschlangen, die das Weiterreichen zur nächsten Station verzögern. Am einfachsten können wir uns das an einer Schlange im Supermarkt veranschaulichen. Sobald der Service (in diesem Fall die Kassierer:in) nicht mehr nachkommt mit Kassieren, bildet sich eine Schlange. Wenn wir erst an der Wursttheke, dann an der Brottheke und dann noch einmal an der Kasse in der Schlange stehen müssen, verzögert sich die Gesamtdurchlaufzeit um so mehr.
Warteschlangen sind die Hauptursache für Verzögerungen und damit für Verschwendung in der Produktentwicklung. Um das zu verstehen, helfen zwei Erkenntnisse aus der Warteschlangentheorie:
Das Product Backlog ist eine Warteschlange, in dem Product Backlog Items (PBIs) auf ihre Abarbeitung warten. Jeder Service, der in der Produktentwicklung eine Rolle spielt, hat eine eigene Warteschlange. Das können unterschiedliche Teams sein, die gemeinsam an einem Produkt arbeiten, aber auch Einheiten außerhalb der Entwicklung, wie z.B. Marketing oder die Rechtsabteilung. Wir sollten also unsere Aufmerksamkeit weg von der Auslastung der einzelnen Services hin zu den Arbeitsaufträgen lenken. Solche gekoppelten Warteschlangensysteme sind, wenn es auch Rückkopplungen gibt, chaotische Systeme im mathematischen Sinne, die nicht vorhersehbares Verhalten zeigen – und sich mit traditionellen Planungen nicht in den Griff bekommen lassen.
Na prima, nachdem wir dieses Problem verstanden haben, finden wir eine Lösung: wir verringern die Auslastung der Services bzw. erhöhen deren Kapazität. Das macht der Supermarkt ja auch, wenn bei langen Schlangen zusätzliche Kassen geöffnet werden. Leider ist das nicht umsonst zu haben: wir brauchen zusätzliches Personal oder Schulungen, durch die das Personal an unterschiedlichen Stellen eingesetzt werden kann. Ist das ökonomisch gerechtfertigt? Dazu sollten wir statt der Größe die Kosten der Warteschlangen betrachten. Diese können wir durch die Reihenfolge der Einträge in der Warteschlange beeinflussen. Product Backlog Items (PBIs) mit großer CoD kommen ganz nach oben. Als weitere Regel kommt hinzu: kurze Aufträge vor langen Aufträgen. Kurze Aufträge blockieren den Service weniger lang und führen schneller dazu, dass die Warteschlange sich wieder abbaut. Die Abbildung veranschaulicht zwei Fälle: im ersten Fall ist der erste Job der mit hoher CoD und niedriger Dauer. Im zweiten Fall ist es umgekehrt. Der Unterschied ist deutlich zu erkennen: die hohen CoDs akkumulieren sich im zweiten Fall über einen längeren Zeitraum.
Eine weitere Möglichkeit, Wartezeiten zu reduzieren, ist die Verwendung von geringen Stapelgrößen (Batch Size). Damit ist die Anzahl von zusammengehörigen Arbeitseinheiten gemeint, also z.B. die Tasks in einem Sprint, oder die Features (und deren Tasks) in einem Release. Die bisherigen Betrachtungen gingen davon aus, dass Arbeit vereinzelt und zeitlich gleichmäßig verteilt beim Service ankommt. Das entspricht z.B. einem Team, dass eine bestimmte Zahl von kleineren Bugs mit mittlerer Auslastung erledigen kann. Die Realität ist aber nicht so. Arbeitsaufträge kommen zufällig, mit variablen Zeitabständen und variabler Größe und in Stapeln. Wie bei einem Restaurant, wenn ein Bus mit 40 hungrigen Touristen vorfährt. Plötzlich steigt die Warteschlange und damit die Wartezeit rapide an. Das Personal gerät in Stress, arbeitet an der Auslastungsgrenze, wodurch sich der Effekt noch verstärkt. Die Stapelgrößen sind oft nicht offensichtlich und eine Frage der “Flughöhe”: Für ein Produktentwicklungs-Team versteckt sich hinter einem großen Requirement oder Feature ein Stapel von kleineren Arbeitsaufträgen.
Eine Möglichkeit, Stapelgrößen und die Länge von Warteschlangen zu begrenzen, sind Work In Progress (WIP) Limits. WIP ist die Anzahl der Arbeitseinheiten, die noch nicht fertiggestellt sind. zum Beispiel durch ungetesteter Code oder halb-umgesetzte Anforderungen. Wir können WIP kontrollieren, indem wir die Annahme von weiteren Aufträgen verweigern, wenn das WIP-Limit erreicht ist. Ein extremer Ansatz ist, die neuen Aufträge komplett zu verwerfen. Eine andere Möglichkeit ist, sie zu blockieren. Sie bleiben dann “weiter oben” in der Prozesskette hängen, wo sie weniger Kosten verursachen. Zum Beispiel ist es oft besser, neue Opportunities in einer Warteschlange zu halten und nicht in die Produktentwicklung eintreten zu lassen. Denn dort erhöhen sie die Auslastung, verursachen Kosten und Overhead.
Don Reinertsen zeigt an einem Beispiel, dass bereits moderate WIP-Begrenzungen einen großen ökonomischen Effekt haben können: bei einem WIP-Limit, das doppelt so groß ist wie der durchschnittliche WIP ohne Limit, entstehen Kosteneinsparungen durch die verminderte CoD, die fast 10mal so groß sind wie die zusätzlichen Kosten durch zurückgewiesene Aufträge. Natürlich sollten bei hohem WIP besonders solche Aufträge abgewiesen werden, die eine geringe Werterzeugung bieten.
In einer iterativ-inkrementellen Entwicklung helfen die Sprints, Stapelgrößen klein zu halten. Kanban-Systeme, die den Namen verdienen, sind per Definition WIP-limitiert. Es geht aber auch um Releases – in Sinne von kleinen Stapelgrößen und schnellem Feedback – möglichst häufig erfolgen sollten. Bei unserer ökonomischen Betrachtung stehen diesem Vorteil die Transaktions- oder Overhead-Kosten gegenüber, die mit einem Release verbunden sind, z.B. Systemtests, manuelle Tests, Dokumentation, Freigabe, Auslieferung. Eine Investition in gute Infrastruktur zur Verringerung der Transaktionskosten, zum Beispiel durch Automatisierung, kann sich dann schnell auszahlen .
Wie oben schon erwähnt, besteht eine Produktentwicklung nicht nur aus einem Product Backlog bzw. einer Warteschlange, sondern aus ganz vielen. Das klassische Projektmanagement, die Kritische-Pfad-Analyse und die Wertstromanalyse gehen davon aus, dass die Produktentwicklung eine lineare Sequenz von Schritten ist. Das muss aber nicht so sein. Bei manchen Aufträgen wird mehrfach die Unterstützung des Marketing-Teams benötigt. Bei anderen ist vor allem ein Backend-Team involviert. Bei wieder anderen liegt der Engpass bei den Nutzern, die den Akzeptanztest durchführen sollen. Statt einer linearen Abfolge haben wir ein Netzwerk von Funktionen und können von der Funktionsweise des Internets lernen: Das Produkt wird in Pakete heruntergebrochen, die durch dieses Netzwerk wandern, so wie es für das jeweilige Paket sinnvoll ist, und wie es der jeweilige Belastungs- und Warteschlangenzustand der Stationen erlaubt.
Noch eine Erweiterung der bisherigen Erkenntnisse. Wir können sie auf ein einzelnes Product Backlog anwenden, aber auch auf einer höheren Ebene auf ein ganzes Programm oder Portfolio von Projekten. Ein Riesen-Problem ist häufig, dass Mitarbeiter oder ganze Teams nicht nur in einem Projekt mitarbeiten, sondern in mehreren gleichzeitig. Es gibt keine WIP-Limits. Kein Wunder, dass die Fertigstellung von Projekten oft so lange dauert. Leider gibt es oft Hemmungen, einmal gestartete Projekte einzustellen. Statt dessen werden ihnen die Mitarbeiter:innen entzogen, so dass sie weder tot noch lebendig sind – Zombie-Projekte.
Die folgende Darstellung veranschaulicht dies für vier Projekte. Im ersten Fall laufen alle parallel. Im zweiten Fall werden zunächst Projekt 1 und 2 fertiggestellt, bevor 3 und 4 gestartet werden. Davon profitieren nicht nur Projekt 1 und 2 (geringere CoD), sondern auch 3 und 4: sie können von den Ergebnissen von 1 und 2 lernen, und sie vermeiden Overhead durch die geringere Laufzeit.
Zum Abschluss noch zwei persönliche Bemerkungen zu den Arbeiten von Don Reinertsen: ich finde den ökonimischen Blickwinkel wichtig und notwendig für eine wirtschaftlich denkenden Product:Ownerin. Das Buch ist jedoch nicht gerade leichte Kost, und mir fällt es schwer, seine quantitativen und statistischen Analysen nachzuvollziehen und auf eigene Beispiele zu übertragen. Weiterhin vermisse ich Aspekte, die über die Ökonomie der Produktentwicklung hinausgehen, zum Beispiel Nachhaltigkeitsaspekte. Es ist wichtig zu erkennen, dass Überlastung von Mitarbeitern zu CoD führt, aber noch wichtiger ist es sich zu überlegen, was das für ihre Gesundheit bedeutet. Folgekosten für Umwelt oder Gesellschaft sollten auch in eine ökonomische Betrachtung einbezogen werden. Die Cost of Delay einer solchen Maßnahme ist jetzt schon riesig und wird immer größer.
“Scrum Teams sind interdisziplinär, d.h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen.” (Scrum Guide).
In diesem Blog-Beitrag geht es um interdisziplinäre – oder auch näher am englischen Original cross-funktionale – Teams. Bereits vor Scrum hatten sich herausgestellt, dass diese Teams besonders erfolgreich sind bei der Entwicklung von innovativen Produkten (The New New Product Development Game (hbr.org)). Mit Scrum sind sie dann so richtig populär geworden. Als Scrum in den 1990ern entstand, waren Entwicklungsabteilungen in Form von funktionalen Teams organisiert: es gab Kästchen im Organigramm für die Entwickler:innen (damals noch nicht gegendert 
) und die Tester:innen, oft noch aufgeteilt in Integrations- und Systemtest. Ich erinnere mich an meine Zeit in einem großen Konzern damals, als es gerade Mode wurde, Testabteilungen in Indien aufzubauen, um Kosten zu sparen. Weiterhin gab es Spezialfunktionen wie Systemarchitekt:innen (von bösen Zungen als “Elfenbeinturm-Architekten” bezeichnet), Risk Manager, Integrationsmanager, Requirement Engineers… alle in ihren eigenen Abteilungen, und damit Diener ihrer jeweiligen Herren, den Abteilungsfürsten. Andere Teile des Unternehmens, die nicht direkt zur Entwicklung gehörten, wie z.B. Produktmanagement und Marketing, waren außen vor. Ein cross-funktionales Team dagegen vereinigte die Menschen, die mit ihren unterschiedlichen Expertisen zur Entstehung eines Produktes beitragen sollten, und schwor sie auf ein gemeinsames Ziel ein. Was für ein Fortschritt!
Die Vorteile liegen auf der Hand:
All das waren wichtige Verbesserungsschritte – die oft nur gegen den Widerstand der Abteilungsfürsten durchzusetzen waren. Allerdings waren nicht alle Probleme damit gelöst. Es existierten weiterhin Abhängigkeiten zwischen cross-funktionalen Teams, die gemeinsam an einem Produkt arbeiteten. Der Grund: Die Zuständigkeit der Teams beschränkte sich auf einzelne Komponenten des Produkts. Damit die Anteile der einzelnen Komponenten zusammenpassen, ist ein Planungsschritt notwendig, der diese Anteile identifiziert. Zur Erzeugung des Produktes müssen die Beiträge der Komponenten zusammengebaut werden. Es gibt also Analyse, Entwicklung, Integration und Test mit den entsprechenden Verantwortlichkeiten – ist das wirklich der große Fortschritt im Vergleich zum klassischen Wasserfallprozess?
Feature Teams sind cross-funktionale Teams, die end-to-end Verantwortung für komplette kunden-orientierte Features übernehmen und so eigenständig Wert für Kunden erzeugen können. Hört sich gut an (s. Feature Teams – Large Scale Scrum (LeSS)) – in der Realität ist es ein sehr anspruchsvolles Unterfangen, Feature Teams aufzustellen. Als Voraussetzung sind hervorragende technische Fähigkeiten nötig wie kontinuierlicher Integration, Test und Auslieferung, die leider in vielen Organisationen nicht vorhanden sind. Der Schritt von Komponenten- zu Feature Teams erfordert eine Umorganisation mit vielen Reibungsverlusten. Ich habe als Coach erlebt, dass Organisationen mehrere Versuche und Experimente gebraucht haben, bevor sie genügend Erfahrung beisammen hatten, sich als Feature Teams aufzustellen (s. z.B. German Big Insurance – Large Scale Scrum (LeSS)). Und selbst wenn dies in der Software-/Produktentwicklung gelingt, besteht ein end-to-end-Prozess aus weiteren Aktivitäten, angefangen mit dem Portfolio-Management über Budgetfreigabe bis zum Marketing, die man in großen Organisationen nicht auch noch in den Feature Teams unterbringt.
Also: cross-funktionale, end-to-end Teams sind ein wichtiger Baustein für agile Unternehmen. Um wirkliche Business Agility zu erreichen und damit in der Lage zu sein, als gesamte Organisation schnell zu reagieren und zu liefern, braucht es eine Sicht auf die Abhängigkeiten und Interaktionen zwischen den Teams und die dort entstehenden Wartezeiten. Mit einem Blick auf das gesamte System und seine Wertschöpfungsketten sollte man zunächst herausfinden, wo es kritische Abhängigkeiten gibt und wirklich hakt, um dann an diesen Stellen gezielte Verbesserungen vornehmen zu können.
Agilität ist als Denkansatz längst über die Software- bzw. Produktentwicklung hinausgewachsen – und damit auch die cross-funktionalen Teams. Ich habe solche Teams in allen möglichen Bereichen unterstützen dürfen: von einem Team, das ein IT-Sicherheitskonzept zum Schutz gegen Hackerangriffe entwickeln sollte, bis hin zu einem Team, das Governance-Richtlinien zur Sicherstellung von Nachhaltigkeitsaspekten erstellen sollte. Mitglieder in diesen Teams waren Personen aus der Unternehmenskommunikation und der Organisationsentwicklung, Jurist:innen, Change Manager, Vertreter:innen aus den einzelnen Regionen… mit den nötigen Entscheidungsbefugnissen und Entlastung von operativen Tätigkeiten ausgestattet, können solche Teams sehr effektiv arbeiten.
Sind die cross-funktionalen Teams – zumindest als Grundbaustein – also ein Allheilmittel, wenn es um die effektive Lösung von komplexen Problemen geht?
Denken wir zurück an die so oft geschmähten “Silos” (dieser Begriff wird heute von den meisten Agilisten mit einem unverkennbar abwertenden Gesichtsausdruck verwendet). Die Leistung der “Silos” besteht in der Weiterentwicklung einer bestimmten Expertise, die allen Mitgliedern des “Silos” gemeinsam war. Also zum Beispiel Test-Kompetenz. Damit sorgte das “Silo” dafür, dass Fachwissen in einer Organisation entsteht und erhalten bleibt. Die Motivation dahinter ist die Erhöhung von Qualität und Effizienz – was in der agilen Welt heute als ewig gestrige Denkweise und kontraproduktiv bei der Lösung komplexer Probleme verschrien ist. Erfolgreiche Organisationen brauchen aber beides: agiles Vorgehen bei der Nutzung von neuen Chancen UND effizientes Vorgehen bei etablierten Prozessen mit wenig Unsicherheit. Durch die gemeinsame Expertise schaffen die “Silos” ein Zusammengehörigkeitsgefühl, das langfristiger sein kann als die Entwicklung eines Produktes. Wo bleibt dieser Aspekt bei den cross-funktionalen Teams? Na klar, dafür gibt es die “Communities of Practise (CoP)” – ein team-übergreifender Zusammenschluss von Personen einer bestimmten Fachrichtung wie Test oder Architektur. Im Gegensatz zu den “Silos” aber eher informell und damit im Zweifelsfall weniger wichtig als die Arbeit im “eigentlichen”, cross-funktionalen Produktteam.
Dieser Zusammenhang ist mir deutlich geworden bei der Lektüre von “Extra-Dependent Teams” (David Kesby). David argumentiert, dass die gängige Team-Lehre zwischen “richtigen” Teams und “work groups” unterscheidet. Die Team-Lehre suggeriert, dass jede Gruppe sich am besten zu einem “richtigen” Team entwickeln sollte, weil sie nur dadurch “high performing” werden kann. Dazu sind – so lehrt uns die Lehre – bestimmte Attribute notwendig, wie ein gemeinsames Ziel, gemeinsame Verantwortung und Interdisziplinarität. Dabei wird verkannt, dass die “work group” ein hervorragendes Modell zum Beispiel für CoPs ist. Um zu vermeiden, dass “work groups” als bloßes Übergangsstadium zum “richtigen” Team und damit als minderwertig betrachtet werden, nennt David sie “extra-dependent” Teams – im Gegensatz zu den “inter-dependent Teams”, unseren Produktteams. Die Mitglieder der extra-dependent Teams arbeiten nicht ständig zusammen, sondern hauptamtlich als Mitglieder von inter-dependent Teams. Sie erfüllen aber eine wichtige Aufgabe, indem sie gemeinsam lernen, strategisch wichtiges Wissen erzeugen und gute Praktiken, Richtlinien, Tools… für die Organisation bereitstellen. Im Gegensatz zu CoPs, die eher informell sind, sind diese extra-dependent Teams in der Regel eine Organisationseinheit mit einer gemeinsamen Führungskraft.
Ein anschauliches Beispiel für ein extra-dependent Team ist die Schwangerschaftsgruppe zur Geburtsvorbereitung. Das inter-dependent Team ist die einzelne Familie. Die Familie hat damit ein gemeinsames Ziel: ein gesundes Baby auf die Welt zu bringen. Die Geburtsvorbereitungsgruppe hat kein gemeinsames, sondern ein identisches Ziel. Übertragen auf die agile Welt sind dies Einheiten, “Silos”, von Tester:innen, Designer:innen, Produkt-Manager:innen, Scrum Master:innen…
Ein weiteres Beispiel sind wir – improuv. Wir arbeiten als Coaches und Berater:innen bei unseren Kunden als Mitglieder von inter-dependent Teams. Wir bilden aber auch gemeinsam mit unseren improuv-Kolleg:innen ein extra-dependent Team: wir entwickeln neuen Ideen, führen kollegiale Fallberatungen und tauschen unsere Erfahrungen aus. Unser identisches Ziel ist es, gemeinsam zu lernen und Spaß dabei zu haben – und improuv langfristig erfolgreich zu machen.
Je größer die Organisation ist, desto eher werden bestimmte Funktionen zentral zusammengefasst: HR, Legal, Finance, Marketing, Sales, Procurement… sind Beispiele dafür. Um Kundenorientierung und damit Business Agility zu erreichen, sollte das Geschehen jedoch nicht von diesen Zentraleinheiten bestimmt werden, sondern vom Kunden, bzw. von kundenorientierten Teams. Die Aufgabe der Zentraleinheiten ist es, diese zu unterstützen. Ein Business Partner aus HR, der für einen bestimmten Bereich zuständig ist, ist “interdependent” Mitglied dieses Bereichs und gleichzeitig “extradependent” Mitglied seiner HR-Einheit.
Extra-dependent Teams sind die Realität in Organisationen. Nach Untersuchungen von David in drei Organisationen machen sie zwischen 43 un 69% aller Teams aus! Wir sollten also vermeiden, alle Teams über einen Kamm zu scheren und extra-dependent Teams in das Raster eines inter-dependent Teams zu pressen. Das führt nur zu Frustration und nicht zu der erwarteten Verbesserung der Performance.
Fazit: Cross-funktionale Teams sind super – aber bitte nicht als Dogma. Die Arbeit an Produkten ist eben nur ein Teil einer agilen Organisation. Ein Team ist mehr als die Summe seiner Mitglieder – und eine Organisation ist mehr als die Summe seiner Teams.
Nach welchen Kriterien ordnet ihr euer Product Backlog? Nach Abhängigkeiten zwischen Produkt-Komponenten oder Teams? Nach Verfügbarkeit von bestimmten Experten? Nach der Lautstärke von Stakeholder-Stimmen? Oder lasst ihr wirtschaftliche Erwägungen in die Ordnung einfließen?
Als Product Owner:in seid ihr – laut Scrum Guide – nicht nur für ein effektives Backlog Management zuständig, sondern auch für die Maximierung des Werts des Produkts. Das bedeutet aus ökonomischer Sicht: die Maximierung des Profits, den ihr mit dem Produkt generieren könnt. Dazu hat sich Don Reinertsen in seinem Buch “The Principles of Product Development Flow” viele Gedanken gemacht. Ich möchte ein paar wesentliche Gesichtspunkte daraus extrahieren, die beim Product Backlog Management helfen, gute ökonomische Entscheidungen zu treffen. Genauer gesagt soll es darum gehen, das Product Backlog nach ökonomischen Kriterien zu ordnen, seine Größe und den Anteil für Releases festzulegen.
In der Praxis werden ganz unterschiedliche Ziele für die Produktentwicklung angegeben: Innovation erzeugen, Qualität verbessern, einen Plan einhalten, Verschwendung reduzieren… Sehr häufig hat die Product Owner:in sich mit Zielkonflikten herumzuschlagen, zum Beispiel: ist es besser, das Produkt jetzt zu releasen, oder sollten erst die bekannten Fehler beseitigt werden? Die einhellige Meinung in der agilen Community ist: Technische Schulden sind des Teufels und sollten auf jeden Fall vermieden werden. Aber ist diese Meinung immer ökonomisch gerechtfertigt? Ein weiteres Beispiel: Sollte das Produkt mit einem Minimum an Features auf den Markt, um frühes Feedback zu bekommen, oder sollten lieber noch ein paar weitere Features eingebaut werden, um die Chance auf begeisterte Kunden zu erhöhen? Wäre es nicht großartig, wenn wir diese Möglichkeiten anhand einer Größe vergleichen könnten, die den Einfluss auf den Profit während des gesamten Produkt-Lebenszyklus ausdrückt? Schauen wir uns das an dem ersten Beispiel von oben an:
Option A: Wieviel kostet es, das Release zu verschieben, bis alle Fehler beseitigt sind? Die CoD ist der in der Verzögerungszeit entgangene Gewinn. Sie ist in der Regel nicht konstant über die Zeit. Die Konkurrenz schläft nicht… vielleicht verpassen wir durch die Verschiebung ein wichtiges Marktfenster, und die Gewinnerwartung geht auf Null. Währenddessen steigen die Entwicklungskosten weiter an. Die folgende Abbildung aus dem Kanban Maturity Model der Kanban University zeigt verschiedene mögliche Zeitverläufe.
Die Verzögerung hat noch einen weiteren Nachteil: Da wir ein späteres Feedback vom Markt erhalten, leben wir länger mit der Unsicherheit, dass unser Produkt nicht gekauft wird.
Option B: Wieviel kostet es, die Fehlerbeseitigung zu verschieben, bis das Produkt am Markt ist? Wir erzeugen technische Schulden. Die Beseitigung eines Fehlers wird um so teurer, je weiter wir sie in die Zukunft verschieben, da es im Produkt Seiteneffekte gibt und der Testaufwand steigt. Außerdem besteht das Risiko, Kunden durch schlechte Qualität zu verärgern und dadurch einen Imageverlust zu erleiden.
Diese beiden Optionen mit konkreten Zahlen zu versehen, ist schwierig und abhängig vom jeweiligen Kontext, aber allein die Überlegungen dahinter sind sehr aufschlussreich. Sie helfen, Entscheidungen rational abzusichern und sich nicht (nur) auf sein Bauchgefühl zu verlassen. Solche Entscheidungen sind in der Regel stabiler und lassen sich besser begründen – auch wenn der Stakeholder mit der lauten Stimme anruft. Also: Quantifizieren wenn möglich, aber nicht um jeden Preis.
Verzögerungen kosten also Geld. Sie führen zu
Wie kommen diese Verzögerungen überhaupt zu Stande? Die Antwort ist: durch Wartezeiten. Wie bitte? Wir sind doch alle ständig am Rotieren und füllen Wartezeiten sofort mit neuen Aktivitäten. Genau da liegt das Problem: wir betrachten den einzelnen Menschen, oder das einzelne Team (allgemein: einen Service), und sehen deren Auslastung. Was wir nicht im Blick haben, ist die Arbeit, die von einem Service zum anderen weitergereicht wird. Vor ausgelasteten Services entstehen Warteschlangen, die das Weiterreichen zur nächsten Station verzögern. Am einfachsten können wir uns das an einer Schlange im Supermarkt veranschaulichen. Sobald der Service (in diesem Fall die Kassierer:in) nicht mehr nachkommt mit Kassieren, bildet sich eine Schlange. Wenn wir erst an der Wursttheke, dann an der Brottheke und dann noch einmal an der Kasse in der Schlange stehen müssen, verzögert sich die Gesamtdurchlaufzeit um so mehr.
Warteschlangen sind die Hauptursache für Verzögerungen und damit für Verschwendung in der Produktentwicklung. Um das zu verstehen, helfen zwei Erkenntnisse aus der Warteschlangentheorie:
Das Product Backlog ist eine Warteschlange, in dem Product Backlog Items (PBIs) auf ihre Abarbeitung warten. Jeder Service, der in der Produktentwicklung eine Rolle spielt, hat eine eigene Warteschlange. Das können unterschiedliche Teams sein, die gemeinsam an einem Produkt arbeiten, aber auch Einheiten außerhalb der Entwicklung, wie z.B. Marketing oder die Rechtsabteilung. Wir sollten also unsere Aufmerksamkeit weg von der Auslastung der einzelnen Services hin zu den Arbeitsaufträgen lenken. Solche gekoppelten Warteschlangensysteme sind, wenn es auch Rückkopplungen gibt, chaotische Systeme im mathematischen Sinne, die nicht vorhersehbares Verhalten zeigen – und sich mit traditionellen Planungen nicht in den Griff bekommen lassen.
Na prima, nachdem wir dieses Problem verstanden haben, finden wir eine Lösung: wir verringern die Auslastung der Services bzw. erhöhen deren Kapazität. Das macht der Supermarkt ja auch, wenn bei langen Schlangen zusätzliche Kassen geöffnet werden. Leider ist das nicht umsonst zu haben: wir brauchen zusätzliches Personal oder Schulungen, durch die das Personal an unterschiedlichen Stellen eingesetzt werden kann. Ist das ökonomisch gerechtfertigt? Dazu sollten wir statt der Größe die Kosten der Warteschlangen betrachten. Diese können wir durch die Reihenfolge der Einträge in der Warteschlange beeinflussen. Product Backlog Items (PBIs) mit großer CoD kommen ganz nach oben. Als weitere Regel kommt hinzu: kurze Aufträge vor langen Aufträgen. Kurze Aufträge blockieren den Service weniger lang und führen schneller dazu, dass die Warteschlange sich wieder abbaut. Die Abbildung veranschaulicht zwei Fälle: im ersten Fall ist der erste Job der mit hoher CoD und niedriger Dauer. Im zweiten Fall ist es umgekehrt. Der Unterschied ist deutlich zu erkennen: die hohen CoDs akkumulieren sich im zweiten Fall über einen längeren Zeitraum.
Eine weitere Möglichkeit, Wartezeiten zu reduzieren, ist die Verwendung von geringen Stapelgrößen (Batch Size). Damit ist die Anzahl von zusammengehörigen Arbeitseinheiten gemeint, also z.B. die Tasks in einem Sprint, oder die Features (und deren Tasks) in einem Release. Die bisherigen Betrachtungen gingen davon aus, dass Arbeit vereinzelt und zeitlich gleichmäßig verteilt beim Service ankommt. Das entspricht z.B. einem Team, dass eine bestimmte Zahl von kleineren Bugs mit mittlerer Auslastung erledigen kann. Die Realität ist aber nicht so. Arbeitsaufträge kommen zufällig, mit variablen Zeitabständen und variabler Größe und in Stapeln. Wie bei einem Restaurant, wenn ein Bus mit 40 hungrigen Touristen vorfährt. Plötzlich steigt die Warteschlange und damit die Wartezeit rapide an. Das Personal gerät in Stress, arbeitet an der Auslastungsgrenze, wodurch sich der Effekt noch verstärkt. Die Stapelgrößen sind oft nicht offensichtlich und eine Frage der “Flughöhe”: Für ein Produktentwicklungs-Team versteckt sich hinter einem großen Requirement oder Feature ein Stapel von kleineren Arbeitsaufträgen.
Eine Möglichkeit, Stapelgrößen und die Länge von Warteschlangen zu begrenzen, sind Work In Progress (WIP) Limits. WIP ist die Anzahl der Arbeitseinheiten, die noch nicht fertiggestellt sind. zum Beispiel durch ungetesteter Code oder halb-umgesetzte Anforderungen. Wir können WIP kontrollieren, indem wir die Annahme von weiteren Aufträgen verweigern, wenn das WIP-Limit erreicht ist. Ein extremer Ansatz ist, die neuen Aufträge komplett zu verwerfen. Eine andere Möglichkeit ist, sie zu blockieren. Sie bleiben dann “weiter oben” in der Prozesskette hängen, wo sie weniger Kosten verursachen. Zum Beispiel ist es oft besser, neue Opportunities in einer Warteschlange zu halten und nicht in die Produktentwicklung eintreten zu lassen. Denn dort erhöhen sie die Auslastung, verursachen Kosten und Overhead.
Don Reinertsen zeigt an einem Beispiel, dass bereits moderate WIP-Begrenzungen einen großen ökonomischen Effekt haben können: bei einem WIP-Limit, das doppelt so groß ist wie der durchschnittliche WIP ohne Limit, entstehen Kosteneinsparungen durch die verminderte CoD, die fast 10mal so groß sind wie die zusätzlichen Kosten durch zurückgewiesene Aufträge. Natürlich sollten bei hohem WIP besonders solche Aufträge abgewiesen werden, die eine geringe Werterzeugung bieten.
In einer iterativ-inkrementellen Entwicklung helfen die Sprints, Stapelgrößen klein zu halten. Kanban-Systeme, die den Namen verdienen, sind per Definition WIP-limitiert. Es geht aber auch um Releases – in Sinne von kleinen Stapelgrößen und schnellem Feedback – möglichst häufig erfolgen sollten. Bei unserer ökonomischen Betrachtung stehen diesem Vorteil die Transaktions- oder Overhead-Kosten gegenüber, die mit einem Release verbunden sind, z.B. Systemtests, manuelle Tests, Dokumentation, Freigabe, Auslieferung. Eine Investition in gute Infrastruktur zur Verringerung der Transaktionskosten, zum Beispiel durch Automatisierung, kann sich dann schnell auszahlen .
Wie oben schon erwähnt, besteht eine Produktentwicklung nicht nur aus einem Product Backlog bzw. einer Warteschlange, sondern aus ganz vielen. Das klassische Projektmanagement, die Kritische-Pfad-Analyse und die Wertstromanalyse gehen davon aus, dass die Produktentwicklung eine lineare Sequenz von Schritten ist. Das muss aber nicht so sein. Bei manchen Aufträgen wird mehrfach die Unterstützung des Marketing-Teams benötigt. Bei anderen ist vor allem ein Backend-Team involviert. Bei wieder anderen liegt der Engpass bei den Nutzern, die den Akzeptanztest durchführen sollen. Statt einer linearen Abfolge haben wir ein Netzwerk von Funktionen und können von der Funktionsweise des Internets lernen: Das Produkt wird in Pakete heruntergebrochen, die durch dieses Netzwerk wandern, so wie es für das jeweilige Paket sinnvoll ist, und wie es der jeweilige Belastungs- und Warteschlangenzustand der Stationen erlaubt.
Noch eine Erweiterung der bisherigen Erkenntnisse. Wir können sie auf ein einzelnes Product Backlog anwenden, aber auch auf einer höheren Ebene auf ein ganzes Programm oder Portfolio von Projekten. Ein Riesen-Problem ist häufig, dass Mitarbeiter oder ganze Teams nicht nur in einem Projekt mitarbeiten, sondern in mehreren gleichzeitig. Es gibt keine WIP-Limits. Kein Wunder, dass die Fertigstellung von Projekten oft so lange dauert. Leider gibt es oft Hemmungen, einmal gestartete Projekte einzustellen. Statt dessen werden ihnen die Mitarbeiter:innen entzogen, so dass sie weder tot noch lebendig sind – Zombie-Projekte.
Die folgende Darstellung veranschaulicht dies für vier Projekte. Im ersten Fall laufen alle parallel. Im zweiten Fall werden zunächst Projekt 1 und 2 fertiggestellt, bevor 3 und 4 gestartet werden. Davon profitieren nicht nur Projekt 1 und 2 (geringere CoD), sondern auch 3 und 4: sie können von den Ergebnissen von 1 und 2 lernen, und sie vermeiden Overhead durch die geringere Laufzeit.
Zum Abschluss noch zwei persönliche Bemerkungen zu den Arbeiten von Don Reinertsen: ich finde den ökonimischen Blickwinkel wichtig und notwendig für eine wirtschaftlich denkenden Product:Ownerin. Das Buch ist jedoch nicht gerade leichte Kost, und mir fällt es schwer, seine quantitativen und statistischen Analysen nachzuvollziehen und auf eigene Beispiele zu übertragen. Weiterhin vermisse ich Aspekte, die über die Ökonomie der Produktentwicklung hinausgehen, zum Beispiel Nachhaltigkeitsaspekte. Es ist wichtig zu erkennen, dass Überlastung von Mitarbeitern zu CoD führt, aber noch wichtiger ist es sich zu überlegen, was das für ihre Gesundheit bedeutet. Folgekosten für Umwelt oder Gesellschaft sollten auch in eine ökonomische Betrachtung einbezogen werden. Die Cost of Delay einer solchen Maßnahme ist jetzt schon riesig und wird immer größer.
