Good Contents Are Everywhere, But Here, We Deliver The Best of The Best.Please Hold on!
Data is Loading...
Your address will show here +12 34 56 78

Key Take Aways:

A passionate team can be recognized by the quality of the product or service they provide. They create something that creates value in the world, not just a product.

I would say that you can’t look for passion by looking at the team. When you look at the outcome of their work, at the quality of the product or services that the team produces, as seen by their customers, you will know if it’s a passionate team. You will know it because passion exudes in the product, the outcome or the final deliverable that comes out of a passionate team. You will see it in the quality of the products that they produce, and just before we started recording, we were talking about two different kinds of microphone, right? The one that you are using right now, which sounds awesome. And another one, which is driven by what I would call a marketing focused American company who doesn’t understand the use of their technology. […]

Well, it doesn’t need to be easy to use, necessarily, it depends on what kind of product we are talking about. But in the case of a microphone that is used for recording in a, like for example the microphone that I’m using, it’s used for recording anywhere. It’s not used for recording in a studio, right? So you need to deal with all kinds of other sound problems. And you see that. People are actually thinking about how the product is going to be used, and they transfer that into the product itself. It doesn’t need to be an easy to use product. It can be a very complex, I don’t know, spectrometer, or whatever. It doesn’t need to be something that is easy to use. But it clearly helps the people using it to solve a real problem that they have. And it does solve very often in ways that are very hard to replicate, because they required a lot of passion to develop that kind of a product.


In most passionate teams, there is constructive conflict, where ideas are the focus, not the people.

[…]Well, actually, in my experience, the best teams I worked with, there’s conflict. And sometimes, when you’re an outsider, you might even think that they are fighting with each other, but they are not. What they are trying to do, the process they are going through, is this constructive conflict whereby ideas are the focus of their discussion, not the people. It’s not about your idea vs. my idea. But it’s about multiple ideas, and which one should we try, and how to we develop it, so in the end, out of those conflicts emerged other ideas that no one in that meeting or conversation ever thought about before, but they were developed and further improved with multiple perspectives, and together as a team, they created something new. So this constructive conflict is definitely one of the most important things that I would say you would see in a high-performing or a passionate team, if you will.[…]


Passionate teams work in an environment, where diversity can be expressed. When they argue, they learn, as they have to express their unstated assumptions.

[…]I would say that a team, if it’s more than two people, and even in two people, that could happen, a team is a complex social system. And in my experience, you can’t remove diversity from a social system. What you can do is that you can quench it, you can stop it from emerging. And this is very much done, I’m thinking about Germany, the country we both lived in, you still live there. Where the opinion of the boss is always the one that matters. And that’s one way to constrain a social system, in order to create order, there’s a reason for it, but that does not remove the diversity in those teams, it just stops it from being expressed. And I would say that in passionate teams, there is an environment where diversity can be expressed, where it’s okay to disagree, and actually in fact we look for opportunities for disagreement, not to fight, although it might look like fighting from the outside, but rather to learn. And when we get into a discussion and we start arguing even, when we put arguments, then we learn, because we have to express unstated assumptions that we had. And we have to listen to other assumptions that may be different than ours. That’s my hypothesis, at least, that you can’t remove diversity from a complex system. You just need to find ways to let it emerge.[…]


Passionate teams don’t accept external constraints. They embrace them and then they change them. They own the way they are working.

[…]And actually, there’s one perhaps another characteristics of a passionate team, is that they don’t accept external constraints, they embrace, but then they change external constraints. Like for example, in this particular team that I was working with, we introduced Scrum. And in Scrum, there’s this thing that, you know, you do the sprint planning in the beginning, and then you do the planning poker and so on. And this team just stopped estimating. They took in the Scrum constraint of doing the planning and the estimation and so on, and then at some point they decided, hey, this is not useful for us anymore, we’ll stop it. Another thing that they did is that they had the Jira board, where they had all of the stories that they were working on, and at some point they said, this is not useful for us, we should use a physical board. They were collocated, so that was easy for them, and they started using a physical board. And then later on, we changed rooms, we went to another room in another part of the building, and they designed the room themselves. And the room, if you entered that room, you would say, „These guys are crazy.“ It looked totally different from a normal room in that company. […]


The leader of a passionate team is constantly working on creating the environment that allows the team to express their creativity and their ingenuity every day.

[…]We have these amazing examples of companies that delegate the decision about making the customer happy to the lowest level of the organization, like Nordstrom, the department store, there’s a whole book about it, I think it’s called, „Radical Management“ by Steve Denning, where he talks about putting the client first or the customer first in everything we do. And the way to do that is to actually delegate the decision making to the fringes of the organization, because those are the people who are actually in touch with the „reality“ of what it is to work with clients, to be in front of clients every day when they are at work. So, for me the role of the leader is someone who enables the people who do the real work, who solve the real problems in product development, who develop the real product, to be able to make decisions.


Now, what does that mean? In very practical terms, it means that the product owner is not a person outside the team. I shudder to think and to hear when people in Scrum say that the product owner is not a team member. That is the most ridiculous idea I’ve ever heard in my career. Of course the product owner is part of the team. Otherwise, the team has no ownership over the product. By definition. If you put the product owner outside the team, the team is just a bunch of lackeys, servants to the product owner. That makes absolutely no sense. The team is the most creative, intelligent group to develop the product. So I would say that leaders need to create the environment, for example making the product owners part of the team, getting the developers to actually talk to and interact with customers, real customers. That kind of actions, that’s there for the leader. The leader in a passionate team is constantly working on creating the environment that allows the team to express their creativity and their ingenuity every day.[…]


Passionate teams do not fall from the sky. They are not an accident, they are not created by magic tools either. They are created by constant, daily endeavor, effort and reflection.

[…]Well, so, first of all, I think that you should all read the blog post that Marc published on the passion model, and hopefully at some point even the book. But that’s not enough. What I would say is that once you understand the model and once you understand those characteristics that Marc describes, then it’s time to go back to basics. Passionate teams are created on the day to day practice of creating amazing, hyper-performing, really passionate teams. Passionate teams do not fall from the sky. They are not an accident, they are not created by magic tools either. They are created by constant, daily endeavor, effort, reflection, just like the Agile manifesto says.[…]



Willkommen zur ersten Folge des Podcasts “Passionate Teams”. Wir sprechen in dieser Folge mit Christoph Hüls, Head of Merck Group Innovation Strategy. In dieser Folge teilt er mit uns seine Definition passionierter Teams und sein 4-P-Modell, welches er verwendet, um die optimalten Voraussetzungen für passionierte Teams zu schaffen. Viel Spaß beim Zuhören.


Christoph Hüls (Gast) ist Innovations Evangelist, Entrepreneur und Menschenfreund. Bevor er Chief Innovation Officer bei Merck KGaA, Darmstadt wurde, war er in verschiedenen Positionen in F&E, Projektmanagement, Portfoliomanagement, Business Development, Corporate Venturing bei der Hoechst AG, Novartis SA und Merck Serono. Sehr prägend für seine berufliche Laufbahn war die Zeit als CEO eines letztlich erfolgreichen Start-Ups in den Zeiten der Finanzkrise nach 2001. Christoph ist davon überzeugt, dass Menschen den Unterschied für Erfolg machen.

Marc Löffler (Gastgeber) ist Autor, Keynote Speaker und Agile Coach. Bevor er mit agilen Methoden in Berührung kam, hat er als traditioneller Projektmanager bei Firmen wie die Volkswagen AG oder die Siemens AG gearbeitet. Seine Leidenschaft ist es, Unternehmen dabei zu helfen das agile Wertesystem auf ihre Organisation zu übertragen. Er liebt es neue Einsichten zu generieren indem er Teams dabei unterstützt, Probleme aus einem anderen Blickwinkel zu betrachten. Im Jahr 2014 erschien sein Buch „Retrospektiven in der Praxis“ beim dpunkt.verlag.

Lust auch einmal dabei zu sein? Dann melde Dich einfach bei mir.



Schon seit ein paar Jahren ist Scrum quasi Standard in der Softwareentwicklung. In den letzten Jahren springen jetzt auch vermehrt andere Bereiche auf den Scrum-Zug, wie z.B. Hardwareentwicklung, HR oder Organisationsprojekte. Wenn ich mir allerdings viele dieser Scrum-Implementierung anschaue, stelle ich häufig fest, dass zwar Scrum eingeführt wurde, sich aber trotzdem nicht allzu viel geändert hat. Aber woran liegt das? Ganz einfach: Scrum löst keine Probleme und wird es auch nie machen. Wenn Du auf ein Kliff zuhältst, wird Scrum Dir dabei helfen es noch schneller zu erreichen.

Aber für was ist Scrum dann gut? Ganz einfach: Es macht Deine Probleme transparent und schafft eine Umgebung, in der man gefahrlos experimentieren kann. Also eine Umgebung, in der man auch mal etwas Neues ausprobieren kann. Durch die eingebaute Feedbackschleife, erfährt man relativ schnell, ob die neue Idee was taugt oder nicht und man kann sie problemlos rückgängig machen. Und genau hier liegt der Hund begraben: Die neuen Ideen und der Mut diese umzusetzen muss von Dir kommen.

Scrum ist wie eine böse Schwiegermutter. Es zeigt auf, was nicht funktioniert, lösen musst Du es aber selbst. Niemand anderes als Du und Dein Team müssen Scrum Leben einhauchen. Scrum selbst ist nur ein Framework. Solange Du oder deine Organisation, die nicht zu übersehenden Probleme ignorieren oder nur fadenscheinige Maßnahmen ergreifen, so lange wird Scrum kaum Mehrwert bringen.

Hier ein paar Beispiele: Scrum definiert ein Product Backlog, in welchem die Anforderungen nach Business Value geordnet sind. Kopiert man allerdings nur Ihr bestehendes Anforderungsdokument 1 zu 1 ins Backlog und man kann keine Aussage darüber treffen, was sinnvollerweise als Nächstes implementiert werden muss („alles ist wichtig“), dann hilft das auch nichts. Wenn bei Deinen Sprint Reviews nur das Team anwesend ist und keinerlei Stakeholder oder Kunden, wirst Du ein Produkt entwickeln, welches der Markt nicht braucht. Wenn Ihr Euch in Euren Retrospektiven lediglich auf die Symptome und nicht auf die Ursachen fokussieren, wirst Du keine tiefgreifenden Veränderungen umsetzen können. Wenn Du nicht in der Lage bist, am Ende eines Sprints etwas Fertiges zu liefern, machst Du nichts weiter, als Deine bisherige Arbeit im 2 Wochen Rhythmus abzuarbeiten. In Scrum musst Du täglich testen und integrieren. Wenn Du in Deinem Daily Scrum immer noch die „3 Fragen“ beantwortest, wirst Du Schwierigkeiten haben, den Reporting-Modus zu verlassen und ein selbstorganisiertes Team zu werden. Ich könnte diese Liste noch unendlich lange fortsetzen.

Und die Quintessenz dieses Artikels? Es geht wie immer nur um Dich. Probleme verschwinden nicht von alleine und erst Recht nicht, wenn Du Scrum nutzt (das gleiche gilt übrigens auch für Kanban). Am Ende musst Du es selbst in die Hand nehmen. Scrum kann Dich dabei unterstützen, aber umsetzen musst Du es selbst.


Agile Retrospektiven

Möchtest Du das neue Jahr mit besseren Retrospektiven starten? Dann habe ich genau das Richtige für Dich:

1 – Bring was zu Essen mit
Es ist immer eine gute Idee, etwas zu Essen zu einer Retrospektive mitzubringen. Es können so einfache Dinge sein wie z.B. Schokolinsen, Salzstangen oder Kekse. Du wirst sehen: Mit diesem kleinen Trick, kannst Du die Stimmung schon zu Beginn Deiner Retrospektiven heben.

2 – Setzt Euch ein Ziel
Die meisten Retrospektiven starten jedes Mal auf der grünen Wiese, ohne die Ergebnisse der letzten Retrospektiven zu beachten. Versuche stattdessen mal etwas Anderes: Setzt Euch ein klares Ziel für die nächsten 2-3 Monate, wie z.B. die Code-Qualität zu verbessern. Auf dieses Weise haben Eure nächsten Retrospektive ein klares Ziel und nur themenbezogene Probleme werden diskutiert. Zusätzlich könnt ihr auf den Ergebnissen der letzten Retrospektiven aufbauen und Eurem Ziele Schritt für Schritt näherkommen. Mehr zum Thema “Zielgerichtete Retrospektiven” findest Du hier.

3 – Experimentiere
Wir alle arbeiten in einem komplexen, adaptiven System. Das bedeutet, dass dieses System nicht vorhersehbar ist. Du weißt nie, ob die definierten Aufgaben aus der letzten Retrospektive, den gewünschten Erfolg haben werden. Deshalb bevorzuge ich, von Experimenten zu sprechen. Wenn Du ein Experiment startest, möchtest Du Deine Hypothese (dein erwarteter Effekt) beweisen. Wenn das nicht möglich ist, versuchst Du einfach ein anderes Experiment. Das machst Du so lange, bis Deine Hypothese war wird. Zusätzlich impliziert der Begriff „Experiment”, dass man ruhig auch mal etwas probieren darf. 

4 – Diskutiert Eure Experimente im Planning
Eines der größten Probleme in Retrospektiven ist, dass die definierten Experimente im Tagesgeschäft untergehen. Um dieses Problem zu umgehen, sollte man die definierten Experimente im Backlog aufnehmen und diese wie jeden anderen Eintrag im Backlog behandeln. Das heißt, dass man die Experimente auch im Planning 2 in einzelne Aufgaben herunterbricht. Jetzt ist Dein Experiment Teil des Sprint Backlogs und kann wie jede andere Aufgabe einfach getrackt werden.

5 – Fokussiert Euch auf ein Experiment
Ein anderer Fehler, der sehr häufig gemacht wird ist, dass sich das Team zu viel vornimmt. Fokussiert Euch stattdessen auf genau EIN Experiment. So könnt ihr sicherstellen, dass genug Kapazitäten zur Verfügung stehen, um an diesem Experiment zu arbeiten. Nichts nervt mehr, als eine Liste von Experimente, an denen niemand gearbeitet hat. Hier noch ein Pro-Tipp: Werft die anderen brillianten Experimentideen nicht fort. Nehmt sie stattdessen in einem Experimentbacklog auf. Wenn im Laufe des Sprints noch Kapazitäten frei sind, kann man sich das nächste Experiment schnappen. Ferner, kann man die nächste Retrospektive extrem kürzen, indem man einfach das Experimentbacklog hernimmt und das nächste Experiment, mit der größten Aussicht auf Erfolg für den nächsten Sprint auswählt.

Ich hoffe Euch gefallen diese kleinen Tricks. Ich würde mich freuen von Euch zu hören, wenn Ihr sie ausprobiert habt. Viel Spaß dabe


Agile Retrospektiven

Wer kennt das nicht: Jede Retrospektive startet mit dem Sammeln von Daten, um auf dieser Basis den Rest der Retrospektive zu gestalten. Oft genug passiert es, dass immer wieder die gleichen Dinge diskutiert werden und man scheinbar nicht vom Fleck kommt. Und trotzdem beginnt man bei jeder Retrospektive wieder auf der grünen Wiese.

Stattdessen kann es Sinn machen, sich für einen festgelegten Zeitraum auf ein Thema zu fokussieren und dieses zum zentralen Element der nächsten Retrospektiven zu machen. Nehmen wir z.B. an, dass ein Team schon länger Probleme mit der Produktqualität hat. Mehrfach wurde versucht, dieses Thema in den Griff zu bekommen, aber es waren meist nur Tropfen auf den heißen Stein. Nun entscheidet man sich im Team dazu, dieses Thema für die nächsten drei Monate fokussiert zu verfolgen. In jeder Retrospektive befasst man sich nun explizit damit, das Qualitätsproblem in den Griff zu bekommen.

Zu Beginn einer solchen Retrospektive, werden die Ergebnisse der letzten Experimente zur Verbesserung der Qualität auf deren Erfolg untersucht, also überprüft, ob die damals aufgestellte Hypothese korrekt war. Wenn ja, kann man sich dem nächsten Problem zuwenden. Wenn nein, macht es zuerst einmal Sinn nach den Ursachen zu forschen, um dann darauf basierend, das nächste Experiment zu starten.

Es macht Sinn zu Beginn des Zeitraums, ein kurzes Rating zu machen, wo man derzeit beim anzugehenden Thema steht und dann einen gemeinsamen Zielwert festzulegen, den man in den nächsten Monaten erreichen will. Erst nach dem Erreichen dieses Werts, nimmt man sich dem nächsten Thema an.

Die Vorteile eines solchen Format sind der klare Fokus auf ein Problem und die Vermeidung, immer wieder die gleichen Themen zu besprechen. Gleichzeitig bekommen Retrospektiven wieder einen Sinn, der vor allem bei länger laufenden agilen Transitionen mit der Zeit abhandengekommen sein kann.

Was denkt Ihr? Könnte Euch der Einsatz von zielgerichteten Retrospektiven helfen?


Sie kennen das vielleicht: Ihre Firma hat sich dafür entschieden auf agile Methoden, wie z.B. Scrum zu setzen. Das Management verspricht sich davon eine höhere Produktqualität, eine bessere TTM (Time To Market), ein besseres Risikomanagement, endlich mal Projekte, die in Zeit und Budget abgeschlossen werden, usw. Obwohl mal sich genau an den Scrum Prozess gehalten hat, stellt sich aber nach ein paar Monaten heraus, dass keine der Versprechen eingetroffen sind. Der Scrum Master probiert verzweifelt ein neues Tool nach dem anderen aus, aber keines hat den gewünschten, langfristigen Effekt. Nach und nach fällt das Team zurück in den ursprünglichen Prozess und am Ende heißt es: Scrum funktioniert bei uns nicht. Und Sie haben recht. Nur weil ich mein totes Pferd mit einem schöneren Sattel ausgestattet habe, wird es trotzdem nicht wieder davongaloppieren. Um das zu verstehen, muss man ein paar Schritte zurückgehen und sich fragen, wie Scrum entstanden ist.

„Erfolg hat nie etwas mit dem implementierten Prozess zu tun, aber immer mit den Menschen.“ – Marc Löffler

Scrum ist im Grunde nichts anderes, als eine Sammlung von „Best Practises“, welche man zusammengeschnürt hat und jetzt unter dem Namen „Scrum“ verkauft. Aber wo kommen dieses „Best Practises“ her?

Immer wenn irgendwo ein Projekt extrem gut gelaufen ist, hat man sich angeschaut, wie das Team dort gearbeitet hat und die Prozesse kopiert. Oder man hat selbst in einem solchen Team gearbeitet und die Prozesse entsprechend dokumentiert. Da das ja so prima funktioniert hat, kopiert man diese Prozesse eins zu eins in den neuen Kontext und hat natürlich die Erwartung, dass es wieder so gut läuft. Dabei vergisst man allerdings eines: Erfolg hat nie etwas mit dem implementierten Prozess zu tun, aber immer mit den Menschen. Es ist so, als würde man sich die Geige von David Garret organisieren und erwarten, dass man jetzt genauso gut spielen kann. Muss ja schließlich an der Geige liegen, dass er so gut spielen kann. Aber interessanterweise erwartet das hier niemand.

Schon im agilen Manifest steht:

„Individuen und Interaktionen mehr als Prozesse und Werkzeuge“ – Agile Manifesto

Leider wird das viel zu oft ignoriert. Es macht keinen Sinn sich um die Verbesserung der Prozesse zu kümmern, bevor man sich mit dem Team auseinandergesetzt hat. In den Fällen, wo ein Team außergewöhnlich gut war, hat man es immer mit einem leidenschaftlichen Team zu tun. Ein passioniertes Team kann alles erreichen, auch wenn die Bedingungen nicht optimal sind. Es ist selbst dann in der Lage etwas Brauchbares zu liefern, wenn der vorgegebene Prozess mehr als suboptimal ist, während ein schlechtes Team auch dann nichts auf die Straße bringt, wenn es den besten Prozess zur Verfügung gestellt bekommt. Ein passioniertes Team ist also Grundvoraussetzung, wenn ich Erfolgreich sein will. Was aber brauche ich, um ein solch passioniertes Team zu bekommen?

Um eine passioniertes Team aufzubauen, bedarf es verschiedener Elemente. Je mehr diese Elemente ausgeprägt sind, desto besser. Hier kommt das PASSION Modell in Spiel. Das Modell definiert die verschiedenen Elemente und deren mögliche Ausprägungen, welche die Basis für passionierte Teams darstellt. Die folgenden Elemente sind Teil des Modells:

Passion (Leidenschaft)

Idealerweise verbindet die Mitglieder eines Teams die Leidenschaft für das Thema an dem sie arbeiten und die Technologie, welche Sie entwickeln/einsetzen. Je mehr jemand für ein Thema brennt desto besser.

Adaptable (Anpassungsfähig)

In der heutigen Zeit gehört Veränderung zum Alltag. Ein passioniertes Team ist in der Lage mit jeder Art von Veränderung klar zu kommen und sich schnell der jeweiligen Situation anzupassen und sogar einen Vorteil daraus zu gewinnen.

Strong Vision (Starke Vision)

So lange ich als Teammitglied nicht weiß, wohin es gehen soll, kann ich auch keine sinnvollen Entscheidungen treffen, was mich wiederum in meiner Selbstorganisation einschränkt oder mich zu (falschen) Annahmen animiert. Ohne eine starke, erstrebenswerte Vision, kann keine echte Passion in einem Team entstehen.

Strength Oriented (Stärkenorientiert)

Eine Studie von Cisco zu Beginn des Jahres 2016 fand heraus, dass die Teammitglieder in ihren besten Teams vornehmlich gemäß ihren Stärken eingesetzt wurden. Anstatt zu versuchen, die Schwächen abzustellen, macht es mehr Sinn auf die Stärken der einzelnen Mitarbeiter zu setzen und diese weiterzuentwickeln.

Independent (Unabhängig)

Je unabhängiger ein Team von unternehmensweiten Prozessen ist, desto besser. Nur wenn ein Team seinen Prozess, zumindest in Teilen, selbstbestimmen kann, kann echte Leidenschaft entstehen. Erfahrungsgemäß sind generelle, unternehmensweite Prozesse eher hinderlich, als dass sie einen Mehrwert schaffen. Nicht umsonst hat z.B. BMW für seine Elektroautos eine eigene Firma gegründet, die unabhängig vom Gesamtunternehmen BMW agieren kann.

Oneness (Einheit)

Bei einem passionierten Team, lässt sich das einzelne Teammitglied von außen nicht mehr ausmachen. Das gesamte Team tritt als Einheit auf. Kein „Blaming“ oder „Finger Pointing“, alle Erfolge oder Misserfolge werden gemeinsam getragen. Diese Einheit bleibt oft über die Arbeit hinaus bestehen.

Nimble (Flink)

In der heutigen Welt kann man es sich nicht mehr erlauben langsam sein. Man muss in der Lage sein, sich schnell in neue Themen einzuarbeiten oder getroffene Entscheidungen schnell über Bord zu werfen. Nur wer dazu in der Lage ist, wird langfristig Erfolge feiern können. Für passionierte Teams ist die „Flinkheit“ Teil der DNA.

Für jedes dieser Elemente habe ich 4 Stufen definiert. Anhand dieser Elemente und Abstufungen lässt sich das eigene Team gut einschätzen. Zusätzlich werden Schwächen offenbar, die es auszumerzen gilt, um den Weg zu einem passionierten Team frei zu machen. Erst wenn man sich um das Thema „Individuen und Interaktionen“ gekümmert hat, macht es Sinn sich um das Thema Prozess zu kümmern. Selbstverständlich kann ein solches Team auch von Scrum profitieren. Nur macht es eben keinen Sinn darauf zu hoffen, dass Scrum bestehende Probleme im Team lösen wird. Im Gegenteil, meist werde sie dadurch erst recht schlimmer. Auch muss ein Team dazu in der Lage sein, sich den Scrum Prozess an ihren eigenen Kontext anzupassen.

Abonnieren Sie meinen Newsletter und laden Sie sich exklusiv das Dokument mit den Beschreibungen der einzelnen Stufen herunter. 


Es gibt mittlerweile tausende Teams weltweit, die Scrum praktizieren. Trotzdem behaupte ich, dass nur ein kleiner Teil dieser Teams Scrum wirklich lebt und damit erfolgreich ist. Aus meiner Sicht kann man erfolgreiche Teams an den folgenden Punkten erkennen:

1 – Kontinuierliches Lernen

Viele agile Teams werden mit der Zeit faul. Insbesondere dann, wenn es augenscheinlich gut läuft. Man lehnt sich zurück und die kontinuierliche Weiterentwicklung gerät ins Stocken. Man bleibt also in seiner kuschelig, warmen Komfortzone und hat nicht so recht Lust den nächsten Schritt zu gehen. Dies führt dazu, dass die Ergebnisse des Teams nach und nach immer schlechter werden und die Vorteile, die ein agile Prozess bringen kann, verblassen. Wenn z.B. ein Sprint Planning, nach einem halben Jahr noch genau gleich abläuft wie zu Beginn der agilen Reise, dann ist das Team auch nicht agil unterwegs. Im idealen Fall sieht ein Scrum Prozess nach einem Jahr komplett anders aus, als am Anfang der agilen Transition. Warum das so ist, ist klar: Der Mensch ist ein Gewohnheitstier und um Gewohnheiten zu ändern, braucht es immer eine Gewisse Energie und ein klares Ziel vor Augen. Charles Duhigg hat dazu ein wundervolles Buch geschrieben: The Power of Habit: Why We Do What We Do, and How to Change. Genau hier kommt der Scrum Master ins Spiel, dessen Aufgabe es ist, das Team immer wieder daran zu erinnern, dass es noch besser geht. Gleichzeitig muss er zusammen mit dem Product Owner und den Stakeholdern sicher stellen, dass die Ziele, welche mit dem Produkt erreicht werden sollen, für das Team immer transparent sind und vor allem attraktiv. Leider ist das Thema der fehlenden Produktvision und fehlender Ziele weit verbreitet. Dabei gibt es zu diesem Thema sehr schöne und vor allem effektive Methoden, wie z.B. Impact Mapping.

2 – Gegenseitiges Unterstützen

Ein weiteres Merkmal eines erfolgreichen Scrum Teams ist die gegenseitige Unterstützung. Allzu oft, sitzt jedes Teammitglied alleine vor dem Rechner und arbeitet an seiner Aufgabe. Pair Programmig? Fehlanzeige! Oft trauen sich die einzelnen Personen nicht, nach Hilfe zu fragen und versuchen sich selbst durch zu kämpfen. Dummerweise führt dieses Verhalten zu einer extremen Verlangsamung des Teams und am Ende zu einer schlechteren Produktqualität. Das Fragen nach Hilfe ist in guten Scrum Teams kein Problem, sondern an der Tagesordnung. Schon beim Betreten des Teamraums kann man anhand der „Köpfe pro Rechner“ sehen, wie es um die gegenseitige Unterstützung bestellt ist. In guten Teams sitzen zu jeder Zeit mindestens zwei Personen zusammen vorm Rechner. Je mehr, desto besser. Die Aufgabe des Scrum Masters ist es eine Kultur des gegenseitigen Unterstützen zu generieren. Sei es, indem er im Daily explizit fragt, ob jemand Hilfe braucht oder zusammen mit dem Team eine Pairing Matrix aufstellt.

3 – 50/50 Kommunikation

Lästern, Mobbing und „Finger Pointing“ sind der Tod jedes Teams. Demzufolge auch eines Scrum Teams. Man kann das sehr schön an den Kommunikationsmustern im Team erkennen. Spricht man im Team auffallend oft über andere, ist das ein schlechtes Zeichen. In einem guten Team sprechen die einzelnen Teammitglieder genauso oft über sich selbst, wie über andere. Es ist häufig ein Zeichen von erhöhter Unzufriedenheit, wenn der Fokus primär auf anderen Menschen liegt und man schlecht über sie spricht. Wenn man als Scrum Master mit einem Teammitglied zu tun hat, der dazu neigt sich über andere zu beschweren oder sie schlecht zu machen, sollte man versuchen den Fokus des Teammitglieds auf das Positive zu lenken. Techniken hierfür gibt es z.B. im Lösungsfokussierten Coaching. Ein sehr gutes Buch zu dem Thema ist Agile Teams lösungsfokussiert coachen von Veronika Kotrba und Ralf Miarka.

4 – Energie

Wer kennt sie nicht: Die Scrum Zombies. Teams, die scheinbar völlig unbeteiligt alle Scrum Meetings durchziehen und die Motivation auf dem Nullpunkt ist. Das sind oft Veranstaltungen, bei denen man das Gefühl hat, dass einem Energie entzogen wird, anstatt welche zu bekommen. Häufig hängt das damit zusammen, dass die Teams schon seit Monaten und Jahren den gleichen Trott haben und schon seit langer Zeit keinerlei Veränderungen mehr stattfinden. Oft kann man das in Unternehmen beobachten, bei denen die Kultur überhaupt nicht auf agile Teams zugeschnitten ist und bei denen Transparenz zum Thema Ziele und Visionen ein Fremdwort sind (falls sie überhaupt existieren). In erfolgreichen Teams ist das genaue Gegenteil der Fall. Schon morgens im Daily Scrum ist die Energie im Team zu spüren, wenn der Arbeitstag gemeinsam geplant wird, Tagesziele gesetzt werden und man sich gegenseitig Hilfe anbietet. Ich persönlich gehe aus diesen Meetings immer ganz beschwingt heraus. Man kann diese Energie förmlich spüren, als Kraft bei der ein Team auf ein gemeinsames, attraktives Ziel zusteuert. Wenn man gemeinsam alles daran setzt, dass am Ende ein tolles Produkt entsteht. Wie schon bei Punkt 1 erwähnt, sind klare Ziele und eine Produktvision mit der jeder etwas anfangen kann, einer der Erfolgsfaktoren in erfolgreichen Scrum Teams. Ist man hier gut aufgestellt, ist man auf einem guten Weg. Auch beim Thema Energie.

5 – Fokus auf Kunden

Es hilft niemandem etwas, wenn man alle Anforderungen in Zeit, Kosten und Leistung implementiert hat aber den Kunden völlig aus den Augen verloren hat. Das Ende vom Lied ist ein Produkt, dass niemand haben will und man genauso gut in die Tonne schmeissen kann. Leider gibt es immer noch genug Produktmanager da draussen, die zu Wissen meinen, was der Kunde will ohne jemals mit einem gesprochen zu haben. Erfolgreiche Teams haben einen starken Fokus auf den Kunden. Sie wollen wissen, was der Kunde genau will und testen regelmäßig ob ihre Annahmen stimmen. Ein regelmäßiges Sprint Review ist eine feine Sache, aber wenn man hier kein Feedback vom tatsächlichen Nutzer des Produkts bekommt, ist es nahezu wertlos. Erfolgreiche Teams wissen das und lassen das täglich in ihre Arbeit einfließen. Je näher Teams am Nutzer dran sind, umso besser. Nur so werden sie in die Lage versetzt, die besten Produkte zu entwickeln. Für den Scrum Master muss es eine der wichtigsten Aufgaben sein, dafür zu sorgen, dass das Team das notwendige Nutzer Feedback bekommt. Er sollte sich nicht allein vom Feedback des Product Owners abspeisen lassen. Im Buch Lean Startup: Schnell, risikolos und erfolgreich Unternehmen gründen von Eric Ries gibt es einige spannende Methoden, wie man solches Feedback einholen kann. Was denkst Du? Deckt sich das mit Deinen Erfahrungen? Welche Erfolgsfaktoren kennst Du? Ich freue mich auf viele Kommentare.