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
Scrum

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.

0

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

0

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?

1

PASSION Modell
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. 

0

Scrum
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.
8

Scrum
Es gibt tonnenweise agile Tools da draussen. Aber was ist der beste Weg, solche Tools im Unternehmen einzuführen?

1 – Starte erst einmal ganz ohne elektronisches Tool

„A fool with a tool is still a fool“. Bevor man irgendein abgefahrenes, agiles Tool einkauft, sollte man ein Gefühl dafür haben, wie Scrum, XP oder Kanban im eigenen Kontext funktionieren. Wenn man von Anfang an auf ein elektronisches Tool setzt, besteht die Gefahr, dass man nicht den Prozess nutzt, der am besten zur eigenen Situation passt, sondern den Prozess, den das Tool standardmäßig vorgibt. Jedes Tool bringt eine eigene Vorstellung mit, wie man Scrum und Co. implementieren sollte.

2 – Nutze Stift und Papier

Du brauchst kein ausgefallenes agiles Kollaborationstool um Deine agile Reise zu beginnen. Alles was Du brauchst ist eine Whiteboard oder eine Korkwand, ein paar Super Stickies und Stifte. Wenn Ihr als Team am gleichen Ort seid, ist das tatsächlich alles was ihr braucht. Keine elektronischen Tools, die ständig von der Arbeit ablenken und kein ständiges Rumgefummel, um es endlich dazu zu bewegen, das zu machen, was Du willst. Das ist der beste Weg, um herauszufinden, wie man ein agiles Framework implementiert. Wenn Du dann verstanden hast, um was es bei „Agile“ geht und weißt wie Du es so anpassen kannst, dass es in Deinem Kontext funktioniert, dann ist es Zeit für Schritt 3.

3 – Starte möglichst einfach

Wenn Du immer noch glaubst, ein agiles Tool zu benötigen, dann starte so einfach wie möglich. Mit Google Docs kannst Du ein Kanban Board in 15 Minuten aufsetzen. Oder nutze ein simples Post-It basiertes Tool, wie Kanbanery, Flow oder Trello. Die meisten dieser Tool kosten nichts, zumindest für kleine Teams. Der größte Vorteil dieser Tools ist, dass sie keinem eigenen Prozess folgen und man sie einfach an die eigenen Bedürfnisse anpassen kann.

4 – Wähle weise

Du bist immer noch hier? Du brauchst also ein „richtiges“ agiles Tool? Dann wähle weise! Wie schon gesagt, gibt eine Menge Tools auf dem Markt. Wenn Du Schritt 1 befolgt hast, weißt Du, wie Dein agiler Prozess (derzeit) aussieht. Du brauchst also ein Tool, dass man einfach an Deinen Prozess anpassen kann. Wenn sich das Tool nur schwer konfigurieren lässt, streiche es von der Liste. Sei nie voreilig bei der Auswahl, denn Du wirst die nächsten Jahre mit dem Tool leben müssen. Deshalb sollte es das „Richtige“ sein.

5 – Lasst Euch schulen

Nachdem Ihr Euch für ein Tool entschieden habt, ist es wichtig, dass alle im Team eine Schulung erhalten. Jeder sollte wissen, wie man das Tool bedient. Es gibt nichts schlimmeres, als einen Scrum Master, der während dem Sprint Planning mit dem Tool kämpft und alle schauen zu.

Fazit

Meiner Ansicht nach, macht ein großes agiles Tool nur in verteilten Teams Sinn. In allen anderen Fällen schadet es der Produktivität, anstatt sie zu fördern. Wie seht ihr das? Welche Erfahrungen habt Ihr mit den verschiedenen Tools gesammelt? Ich bin gespannt auf Eure Kommentare.
0

Kanban, Scrum

In der Vergangenheit durfte ich schon des Öfteren beobachten, wie Scrum Teams auf (Software) Kanban gewechselt haben. Die Gründe dafür waren vielfältig, aber nur selten die „Richtigen“. Hier eine kleine Auswahl:

  • „Die ganzen Scrum Meetings kosten zu viel Zeit“
  • „Irgendwie klappt das mit Scrum nicht so richtig, lasst uns Kanban versuchen“
  • „Cool, bei Kanban brauchen wir nur ein Board mit ToDo, Doing, Done und schon kann es los gehen“
  • „Die ständigen Retrospektiven nerven, ich mag unseren Prozess so wie er ist“
  • „Wir kriegen es nicht hin, nach jedem Sprint lauffähige Software zu schreiben. Bei Kanban gibt es diese Regel nicht…“
  • „Dauernd müssen wir neu planen, das gibt es bei Kanban nicht“
  • usw…

In keinem der oben genannten Fälle, ist man bei Kanban besser aufgehoben, zumindest wenn man es ernsthaft betreiben möchte. Wenn ein Team aus einem dieser Gründe zu Kanban wechseln möchte, so machen Sie im Endeffekt nichts anderes, als vor ihren Problemen zu flüchten. Viele der Prinzipien, auf denen Scrum und Kanban beruhen sind ähnlich, deshalb werden am Ende auch die Probleme bestehen bleiben.

Beide Methoden beruhen z.B. auf dem Prinzip der bösen Schwiegermutter: Sie halten einem ständig den Spiegel vor Augen, um auf die eigenen Unzulänglichkeiten zu verweisen. Die Probleme werden dadurch aber nicht gelöst, sondern lediglich sichtbar gemacht. Für die Problemlösung selbst ist das Team verantwortlich, egal bei welcher Methode. Es ergibt keinen Sinn in eine andere Methode zu flüchten, nur weil man seine Angelegenheiten nicht in den Griff bekommt.

Beide Methoden haben einen starken Fokus darauf, möglichst schnell und möglichst häufig releasefähige Software-Inkremente auszuliefern. Bei Kanban sogar noch mehr, als bei Scrum, da man durch das Fehlen von Iterationen theoretisch ständig neue Updates liefern kann und zumindest formal nicht auf einen Reviewprozess angewiesen ist (den es trotzdem meist gibt). Und genau hier haben viele Softwareteams die größten Probleme.

Beide Methoden verlangen den ständigen Fokus auf einen kontinuierlichen Verbesserungsprozess. Hier wird vor allem bei Kanban häufig der Fehler gemacht, dass man ein einfaches Board „an die Wand wirft“, welches in keinster Weise den aktuellen Prozess darstellt und wenn der tatsächliche Prozess dargestellt wird, wird dieser nur selten angepasst, obwohl das eines der Kernelemente von Kanban ist.

Der Wechsel zu Kanban kann durchaus sinnvoll sein, wenn man sich dabei bewusst ist, dass man sich selbst immer mitnimmt und sich auch bei Kanban die Probleme nicht von selbst lösen. Dann steht einem erfolgreichem Wechsel nichts mehr im Weg.

Welche Erfahrungen habt ihr beim Wechsel zu Kanban gemacht?

3

PREVIOUS POSTSPage 1 of 2NO NEW POSTS