Read the book: «Scrumster»
Scrumster
Wer Erfolg haben will, muss
wissen, was schiefgehen kann.
Achim Schneider
Auf einen Blick
Vorwort
TEIL I Über dieses Buch
Einleitung
Was ist eigentlich Scrumster?
TEIL II Der Countdown
Platz 10 - Working Software
Platz 9 - Self-organizing Team
Platz 8 - Development Equipment
Platz 7 - Cross-functional Team
Platz 6 - Integration
Platz 5 - Technical Excellence
Platz 4 - Daily Scrum
Platz 3 - Feature Teams
Platz 2 - Definition of Done
Platz 1 - Release
Zum guten Schluss
TEIL III Zusatzinformationen
Agil vs. Klassisch
Gründe des Scheiterns
Das ultrakleine agile Glossar
Literaturhinweise
Für Margit.
“Scheitern ist ein Umweg, keine Sackgasse.”
Zig Ziglar
Autor, Motivations- und Verkaufstrainer
Vorwort
Herzlichen Dank für das Interesse an Scrumster. Diese Neugier sollten Sie sich bewahren. Das wird Ihnen helfen, mit agilen Vorgehensweisen umzugehen.
Agile Methoden sind aus der heutigen Software-Entwicklung nicht mehr wegzudenken und ein unverzichtbarer Bestandteil geworden. Der traditionelle Software-Development-Prozess nach der Wasserfall-Methode ist schon lange tot, weil die Vorhaben zu oft scheitern. Auf Veränderungen kann damit nur viel zu träge reagiert werden, da dieses Vorgehensmodell viel zu starr und unflexibel ist. Namhafte Studien belegen, dass nahezu 80% aller klassischen Projekte ihre Ziele nicht erreichen.
Es müssen also andere Methoden angewandt werden, um bei der Software-Entwicklung bessere Resultate erzielen zu können. Den Ausweg suchen nun viele Firmen und Firmengründer in der Nutzung von agilen Frameworks wie Scrum, SAFe® oder LeSS®.
Agile Methoden helfen dabei, auf Veränderungen zu reagieren und das drohende Scheitern möglichst früh zu erkennen. Diese Erkenntnis gibt uns die Möglichkeit, dagegen zu steuern; das alleine kann dann durchaus schon als Erfolg gewertet werden.
Abbildung 1 Der Flow
Ein Schlüssel zum Erfolg und zum Erreichen der maximalen Effizienz eines agilen Teams liegt in dessen Fähigkeit in den „Flow“ zu gelangen. Der Flow ist ein als beglückend empfundener Bewusstseinszustand, der bewirkt, dass man in seiner Aufgabe völlig aufgeht, sodass diese sich wie von selbst erledigt. Er führt zu einer Schaffenskraft. In dieser Lust ist ein Team äußerst motiviert und effizient.
Beim Schreiben dieses Buches bin ich oft in den Flow gekommen. Da sind die Kapitel geradezu von selbst entstanden. Da habe ich Zeit und Raum um mich herum vergessen. Da war es nicht anstrengend, sondern äußerst beglückend. Es gab aber auch Zeiten, in denen es mir schwer fiel, die leeren Seiten zu füllen. Jetzt können Sie bestimmt nachempfinden, was mit Flow gemeint ist.
Das Anwenden agiler Methoden ist ein bisschen wie ein Strategiespiel, das nur wenige, einfache Grundregeln hat. Man benötigt nur wenig Zeit, um die Regeln zu erlernen, man braucht aber ein Leben lang, um das Spiel zu beherrschen. Schach ist ein solches Strategiespiel mit wirklich simplen Grundregeln. Für jede der nur sechs unterschiedlichen Figuren gibt es ganz einfach zu erlernende Zugregeln, aber es gibt Tausende von Büchern, die beschreiben, wie man das Spiel gut spielt. Sie können versuchen all diese Bücher zu lesen, aber Sie werden trotzdem ein lausiger Schachspieler bleiben, wenn Sie das Spiel nicht selbst spielen.
Wie meistens im Leben gibt es einen Trick. Sie lernen einfach von den Erfahrungen anderer. Beobachten Sie andere beim Schachspielen. Lauschen Sie Großmeistern bei deren Analyse von Spielzügen und Interpretationen von Spielentwicklungen. Natürlich ersetzt das nicht selbst zu spielen, aber die Praktiken und Erfahrung anderer zu kennen und zu verstehen, wird Ihnen einen großen Schub geben und es vermeidet, dass Sie die häufigsten, bereits bekannten Fehler überhaupt machen.
Die Herausforderung beim Schach ist seine hohe Komplexität, die zur Folge hat, dass ein Spieler sein Leben lang an der Verfeinerung seines Stils und seiner Spielstärke arbeiten kann. Die Strategie ist zwar ein wichtiger, aber nicht der einzige Aspekt dieses Spiels. Schach hat auch psychologische Komponenten, kann grundsätzliche Einsichten vermitteln, stellt Herausforderungen an den Geist und bietet manchem Spieler auch einen Spiegel der eigenen Persönlichkeit. Hinzu kommt, dass eine von beiden Spielern elegant geführte Partie als Kunstwerk empfunden werden kann. Und genau das beinhaltet das vorliegende Buch. Es ist eine Wiederholung dessen, was der Autor erlebt hat und zwar für Sie in Zeitlupe, damit Sie, liebe Leserinnen und Leser, genau verstehen können, worauf es ankommt.
Abbildung 2 Aus Beobachtung lernen
Mit Hilfe von Extrem Programming, Kaizen, Kanban oder Scrum erhoffen sich ganze Heerscharen von Managern und Firmengründern, schneller, flexibler und zielgerichteter auf sich verändernde Rahmenbedingungen, Kundenanforderungen und Märkte reagieren zu können. Dies kann aber nur gelingen, wenn die agile Vorgehensweise so angewandt wird, dass sich der damit erhoffte Nutzen auch einstellt.
Vom Standpunkt einer größeren oder großen Firma aus betrachtet stellt sich zusätzlich die Aufgabe der Skalierung. Wie kann man agile Methoden mit einer Organisation nutzen, die aus vielen Abteilungen und Unterabteilungen besteht?
Die Umsetzung von „lean and agile“ in die Praxis ist nicht trivial. Es warten viele Fallstricke und Sackgassen auf uns. Im Gegensatz zu Startups, die agile Methoden ohne Vorbehalte und ohne Vorgeschichte mit großem Erfolg einfach nutzen können, hat eine traditionsreiche Firma die Herausforderung, ihre bestehenden Methoden und Prozesse auf „agil“ umzustellen. Dies hat großen Einfluss darauf, wie agil und erfolgreich man sein kann.
Untersuchungen und Thesen darüber, wann und warum auch agile Methoden scheitern können, sind rar. Das agile Manifest (http://agilemanifesto.org/iso/de/principles.html) empfiehlt ein wichtiges Prinzip anzuwenden: „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten dementsprechend an“. Das wurde gemacht und daraus entstand Scumster: 10 Gründe, warum agile Methoden scheitern können.
TEIL I Über dieses Buch
„Fehler sind das Tor zu neuen Entdeckungen.“
James Joyce
Irischer Schriftsteller
Einleitung
Für wen ist dieses Buch?
Dieses Buch ist für alle, die schon Erfahrungen mit agilen Methoden gesammelt haben. Sei es dadurch, dass sie einfach ins kalte Wasser geschmissen wurden oder sich mit Hilfe einer Fortbildung auf ihre nächste Herausforderung vorbereiten durften. Es schadet also nicht, wenn Sie bereits Teil eines Scrum Teams waren oder noch immer sind. Auch die Anwendung von Kanban oder Extrem Programming ist hilfreich für das Verständnis des Buchinhalts, aber nicht zwingend erforderlich. Die Grundwerte des agilen Manifests sollten Ihnen aber in jedem Falle geläufig sein. Dieses Buch vermittelt keine Kochrezepte. Es beschreibt die persönlich gemachte Erfahrung im Umgang mit agilen Methoden. Die Inhalte sind so gewählt, dass sie für agile Teams und deren Linienmanagement hilfreich sind.
Abbildung 3 No more Cargo Cult
Für wen ist das Buch nicht?
Anhänger der „Cargo Cult Mentalität“ werden hier leider enttäuscht werden. Ein stumpfes Nachahmen und Aneinanderreihen von „agilen best practices“ und agilen Ritualen führt leider nicht dazu, dass sich der vollständige Nutzen agiler Methoden einstellt. Ein Versuch, durch symbolische Handlungen wirtschaftlichen Erfolg und öffentliche Anerkennung zu erreichen, wird nicht funktionieren. Sie müssen verstehen wollen, warum die Dinge gemacht werden und warum sie in einem agilen Kontext funktionieren. Erst dann werden Sie sich aus Überzeugung darauf einlassen können.
Was sollten Sie mitbringen?
Die Grundbegriffe agiler Methoden sollten Sie bereits verstanden haben. Fachbegriffe wie Daily Scrum, Sprint Review, Retrospective, Definition of Done oder Self-Organizing sollten Ihnen grundsätzlich vertraut sein, denn diese werden hier nicht näher erläutert. Sie sollten damit bereits etwas anfangen können oder sich diese Grundlagen noch erarbeiten. Zur ersten Orientierung finden Sie im Anhang dieses Buches eine ultrakurze Erläuterung der wichtigsten in diesem Buch verwendeten agilen Begriffe.
Abbildung 4 Ihre Mitbringsel
Was bietet dieses Buch?
Dieses Buch beschreibt die über Jahre hinweg gesammelten Erfahrungen beim praktischen Anwenden agiler Methoden. Wenn Sie sich schon einmal gefragt haben, ob das eigentlich normal ist, dass bei Ihnen im Scrum Team so gut wie jede User Story über mehrere Sprints bearbeitet werden muss, dann sind Sie hier genau richtig. Hier finden Sie sich und Ihr Team vielleicht sogar in einem der Praxisbeispiele wieder. Das soll Ihnen die Augen dafür öffnen zu erkennen, was schiefläuft. Selbsterkenntnis ist bekanntlich der erste Schritt zur Besserung.
Über den Autor
Achim Schneider hat über 30 Jahre praktische Erfahrung in der Softwareentwicklung. Er hat kommerzielle Vorhaben in unterschiedlichen Branchen und in unterschiedlichsten Rollen geleitet, verantwortet oder begleitet. Er ist zertifizierter Professional Scrum MasterTM nach scrum.org, zertifizierter Professional Scrum Product OwnerTM nach scrum.org, zertifizierter SAFe® Agilist (SA) nach dem Scaled Agile Framework® und Senior Project Manager. Seine praktischen Erfahrungen in Bezug auf die Anwendung von lean & agil sind Grundlage für dieses Buch.
Über die Illustrationen
Die im Buch verwendeten Skizzen sind als Reflexion des Erlebten in Form von Sketching auf einem iPad entstanden. Diese Bilder verbindet der Autor jeweils mit bestimmten Situationen seiner persönlichen Erfahrung. Die Abstraktion dient dazu, eine Verwechslung mit realen Personen auszuschließen.
Konventionen
In diesem Buch werden Konventionen verwendet, die Ihnen die Lektüre erleichtern sollen. Neue wichtige Begriffe werden im Text „kursiv“ ausgezeichnet. Treten diese Begriffe gehäuft auf, wird die normale Darstellung beibehalten, um den Lesefluss aufrechtzuerhalten.
Tipps aus der PraxisVerwenden Sie die Praxistipps, um schnell nachzulesen, was Sie tun können, um Scrumster zu vermeiden.
Praxistipps in den jeweiligen Kapiteln werden besonders ausgezeichnet. Ein Beispiel für einen Praxistipp sehen Sie oben. Praxistipps stellen eine Zusammenfassung der wichtigsten Punkte aus dem jeweiligen Kapitel dar. Beim ersten Lesen sollten Sie die Praxistipps einfach überspringen und darunter weiterlesen. Wenn Sie dieses Buch später einmal zur Hand nehmen, helfen Ihnen die hervorgehobenen Praxistipps, wenn Sie schnell einen Rat benötigen.
Was ist eigentlich Scrumster?
Scrumster ist eine Sammlung von typischen Fehlern, Missverständnissen und Fehlinterpretationen, die dazu führen, dass die anfängliche Euphorie aller Beteiligten, endlich agil zu sein, schnell in Ernüchterung umschlägt. Scrumster möchte aufzeigen, was alles schiefgehen kann, um dieses vermeiden zu können.
Scrum und Co.
Schauen wir uns einmal das recht einfache Konzept von Scrum an. Es existiert ein priorisierter „Product-Backlog“, der die Anforderungen an das zu erstellende Produkt enthält. Der „Product-Owner“ priorisiert die Backlogeinträge und das „Scrum Team“ selektiert daraus eine passende Untermenge und setzt diese in einem „Sprint“ einer zuvor festgelegten Dauer um. Ergebnis eines jeden Sprints ist funktionierende Software.
Klingt doch ganz einfach, oder?
Der Zyklus, in dem funktionierende Software erstellt werden soll, beträgt bis zu 30 Tage. In der Regel werden Zyklen von 10 Tagen vereinbart. Somit wiederholt sich das ganze Vorgehen also alle zwei Wochen.
Was kann passieren?
Wird das agile Framework nicht richtig und konsequent eingesetzt, besteht die große Gefahr, dass das Scrum Team in einem Hamsterrad endet und rotiert und das Management im Hintergrund nur noch anfeuert. Dann haben wir „Scrumster“.
Scrumster ist also eine Situation, bei der etwas massiv aus dem Ruder gelaufen ist. Keiner der Beteiligten hat sich das so gewünscht oder beabsichtigt, dorthin zu gelangen. Aber trotzdem ist es passiert. Dann fragt sich jeder, woran es gelegen hat, dass man so ins Chaos geschlittert ist, ohne es zu bemerken, oder wer eigentlich Schuld daran hat.
Ursachenforschung betreiben
Jeder hat doch sein Bestes gegeben, oder? Waren etwa die alten Haudegen der Firma zu starrsinnig? Haben die unseren Ansatz zur agilen Softwareentwicklung unterlaufen und zum Scheitern gebracht?
Wie kann der drohende Kollaps vermieden werden? Welche Dinge führen überhaupt zu diesem Kollaps?
Eine Analyse ist es allemal wert, um hinter das Geheimnis des Scheiterns zu kommen. Und genau das wurde gemacht und in diesem Buch festgehalten, damit Sie, liebe Leserinnen und Leser, davon profitieren können.
Ihr Nutzen
Einmal erkannte Missverständnisse oder Fehlinterpretationen können Ihnen dadurch hoffentlich erspart bleiben. Wenn Sie weitere wertvolle Erfahrungen gemacht haben, die Sie mit anderen teilen wollen, würde ich mich über eine Nachricht von Ihnen freuen.
Der Aufbau dieses Buches
Das hier zusammengestellte Best-of der größten Irrtümer bei der Anwendung agiler Methoden ist sicherlich sehr subjektiv, die gewählte Reihenfolge sicherlich auch. Aber eine Veröffentlichung des ersten Entwurfs zu diesem Manuskript im Intranet unserer Firma bekam so viel positives Feedback und hat so viel Interesse geweckt, dass ich mich dazu entschlossen habe, die vorliegenden Erkenntnisse einem größeren Publikum zur Verfügung zu stellen.
Was erwartet Sie nun?
Auf den folgenden Seiten sind die häufigsten Gründe dafür, warum agile Methoden scheitern können, in einem illustren Countdown zusammengestellt.
TEIL II Der Countdown
Platz 10 - Working Software
Funktionierende Software ist schon im agilen Manifest proklamiert und eine Grundvoraussetzung agiler Methoden, um ermitteln zu können oder besser gesagt, um messen zu können, was man schon erreicht hat.
Bewährtes in neuem Look
Ganz neu ist diese Erkenntnis allerdings nicht. Ins klassische Projektmanagement übertragen handelt es sich hierbei um „earned values“ oder auf Deutsch den „Fertigstellungsgrad“, ein Werkzeug des Projektcontrollings, um den Projektfortschritt zu verfolgen. Eine Bewertung des Projektfortschritts erfolgt in agilen Methoden wie Scrum am Ende jedes Sprints.
Die agile Grundannahme
Jeder Sprint stellt eine Investition dar und verfolgt das Ziel, dem erhofften Ergebnis einen Schritt näher zu kommen.
Abbildung 5 Die agile Grundannahme
Nach jedem Sprint soll in agilen Vorgehensmodellen überprüft werden, was tatsächlich erreicht wurde. Das so entstandene agile Artefakt ist „working software“. Unsichtbar und nur in der unbewussten Wahrnehmung der Beteiligten befindet sich die agile Grundannahme. Es wird grundsätzlich davon ausgegangen, dass Investitionen, die „funktionierende Software“ als Ergebnis haben, dauerhaft erhalten bleiben, weil Software, die einmal funktioniert, keinem „Verschleiß“ unterliegt. Einmal von der Wartung dieser Software abgesehen, ist das die agile Grundannahme.
Trifft das eigentlich zu?
Ob diese Grundannahme tatsächlich zutrifft, hängt nun im Wesentlichen von Ihrem Umfeld ab, in dem Sie sich bewegen. Ein Sprint wird in aller Regel zunächst in einer Entwicklungsumgebung entstehen. Ob in dieser Umgebung auch die Bewertung hinsichtlich „working software“ angestellt wird oder nicht, bestimmt maßgeblich, ob schon alle nötigen Investitionen getätigt sind oder nicht.
Tipps zu Working SoftwarePrüfen Sie, welche unausgesprochenen Annahmen in Ihrem Umfeld existieren und finden Sie einen transparenten Umgang damit.
Legen Sie es doch fest
Der Begriff „working software“ muss also für Ihre Verhältnisse definiert werden, damit jedem klar ist, was er bedeutet und was eben nicht. Ein Beispiel hierfür könnte sein:
Working software bedeutet für uns, dass das Produkt in der Entwicklungsumgebung installiert und benutzbar ist.
Will man das noch deutlicher formulieren, kann man auch beschreiben, was nicht unter „working software“ zu verstehen ist:
Working software hat bei uns die Eigenschaften, dass diese noch nicht auf einer „Staging-Umgebung“ (Test-, Integrations-, Referenz- oder Produktivumgebung) bereitgestellt wurde, noch nicht an den späteren Betreiber übergeben wurde und noch nicht mit einem Bestell- und Abrechnungsprozess versehen ist und damit noch keinen kommerziellen Beitrag zum Geschäftsergebnis liefern kann.
Weitere „working“ Aspekte
Abhängig von Ihrem Umfeld treffen hier weitere oder andere Aspekte zu. Sofern keine klare und von allen Beteiligten verstandene und akzeptierte Definition von „working software“ vorhanden ist, bewegen Sie sich auf höchst riskantem Boden.
Tipps zu Working SoftwareDefinieren Sie „working software“. Holen Sie in Ihrem Umfeld die Akzeptanz zur Definition von „working software“ ein und ergänzen Sie damit Ihre Definition of Done. Stimmen Sie zusätzliche Backlog-Einträge für „working software“ aus Entwicklungssicht mit dem Product Owner ab.
Extreme Programming
Der Begriff „working software“ wurde durch die agile Methode des Extreme Programming geprägt. Dort bedeutet er, dass eine Software voll integriert, getestet, zum Kunden ausgeliefert oder in der Produktionsumgebung installiert werden kann.
Abbildung 6 Extreme Programming
Das bedeutet aber nicht, dass diese Software fehlerfrei läuft und frei von Abstürzen ist. Es bedeutet nur, dass Unit Tests gemacht und grundlegende Qualitätssicherung betrieben wurden und man sich davon überzeugt hat, dass sie grundsätzlich läuft. Ob diese „extreme“ Festlegung eine für Ihre Verhältnisse adäquate Definition von „working software“ ist, müssen Sie für sich prüfen.
Mogeln ist verlockend
Viele Scrum Teams machen zusätzlich den Fehler, bei der Bewertung ihres Sprintergebnisses zu mogeln. Beispielsweise wird halbfertige Software, die z.B. mit technischen Schulden („technical debt“) belastet ist, als „working software“ deklariert, ohne dass eine User Story zur Beseitigung der technischen Schuld mit dem Product Owner vereinbart und in den Product Backlog eingestellt wird. Das ist dann so, als hätte das Team die technische Schuld unter den Teppich gekehrt.
Abbildung 7 Technical debt
Das führt dazu, dass das Management annimmt, dass etwas abgeschlossen ist und keine späteren Investitionen mehr benötigt, was real betrachtet nicht stimmt.
Transparenz gewinnt
Die Gründe dafür, dass die Software am Ende eines Sprints nicht wirklich fertig ist, sind vielschichtig, aber letztlich doch unerheblich. Entscheidend für alle Beteiligten ist, dass das Scrum Team am Ende jedes Sprints schonungslos transparent macht, was funktioniert und was nicht. Schönreden ist zwar verlockend, aber nicht die Lösung. Das holt einen später wieder ein.
Tipps zu Working SoftwareSorgen Sie für Transparenz bei der Bereitstellung von working software.
Typisch „working“
Auf dem Bild „Working Software“ ist eine typische, als „working“ deklarierte Software abgebildet. Diese wird von allen Seiten gestützt, ist zusammengeflickt, weist Lücken oder Löcher wie ein Schweizer Käse auf und passt an den Schnittstellen kaum zusammen. Wird dies nicht transparent gemacht, so löst dies eine Kettenreaktion aus.
Push oder Pull
Wie kommt es eigentlich in agil arbeitenden Teams dazu, dass etwas fertig wird? Der wesentliche Unterschied zur gängigen Arbeitsweise ist, dass Arbeit nicht „zugewiesen“ wird (Push-Prinzip). Es gibt niemanden, der den Teammitgliedern eine Aufgabe zuteilt. Vielmehr holen sich die Teammitglieder die Aufgaben aus dem Backlog, sobald sie dafür Kapazitäten zur Verfügung haben (Pull-Prinzip). Wann eine Aufgabe zur Bearbeitung ausgewählt wird, hängt damit vom individuellen Fortschritt der Teammitglieder und vom Fortschritt des ganzen Teams ab.
Abbildung 8 Push- oder Pull-Prinzip
Unfertiges vermeiden
Aus der traditionellen Fertigungsindustrie wissen wir, dass unfertige Produkte gebundenes Kapital darstellen. Daher ist jedes Fertigungsunternehmen bestrebt, den Bestand an nicht fertiggestellten Erzeugnissen möglichst gering zu halten. Ein anderes Beispiel wäre: Es soll eine Brücke über einen Fluss gebaut werden. Ungefähr zur Hälfte der Bauzeit beschließt das Team, mit dem Bau einer zweiten Brücke zu beginnen. Das führt dazu, dass der Bau an der ersten Brücke langsamer vorangeht und an der zweiten Brücke nicht mit voller Kraft gebaut werden kann. Die in die Brücken investierte Arbeit kann nicht dazu genutzt werden, den Fluss zu überqueren. Sie können sich vorstellen, was passiert, wenn Sie den Bau einer dritten Brücke parallel beginnen.
Übertragen auf die agile Softwareentwicklung bedeutet dies, dass eine angefangene Aufgabe Kapital bindet. Solange die Aufgabe nicht fertiggestellt wurde, kann die in die Aufgabe investierte Arbeit in keinen Nutzen umgewandelt werden. Der Nutzen hat hier natürlich zwei Aspekte. Zum einen ist der Nutzen gemeint, den potentielle Kunden aus dem fertiggestellten Produkt erzielen können, und zum anderen ist natürlich der potentielle Gewinn gemeint, der mit der Vermarktung des fertigstellten Produkts erzielt werden kann. Daher sind unfertige Tasks sozusagen eine „Verschwendung“. Je länger eine Aufgabe im Zustand „unfertig“ verbleibt, umso größer wird diese „Verschwendung“. Genau das ist mit dem agilen Begriff „waste“ gemeint.
Abbildung 9 Ständig neue Brücken bauen
Agile Teams sollen daher das Prinzip verfolgen, Aufgaben eher fertigzustellen, statt immer neue Aufgabe anzufangen. Das wird mit „start finishing – stop starting“ einprägsam auf den Punkt gebracht.
Work in Progress
Im vorigen Abschnitt wurde dargestellt, dass unfertige Tasks vermieden werden sollen, da unfertige Aufgaben Kapital binden. Ein Instrument agiler Methoden zur Vermeidung von „waste“ ist daher die Begrenzung der Anzahl gleichzeitig „in Bearbeitung“ befindlicher Aufgaben. Das bezeichnen die agilen Methoden mit „Limit Work in Progress (WiP)“. Rein wirtschaftlich betrachtet stellt eine Begrenzung der gleichzeitig in Arbeit befindlichen Tasks eine wirksame Maßnahme zur Begrenzung des gebundenen Kapitals dar. Für ein agiles Team bedeutet dies aber die Möglichkeit, sich auf die wesentlichen Dinge zu konzentrieren. Es ist nicht einfach, die wesentlichen Dinge zu identifizieren, daher sollte das Team sich darüber austauschen und zumindest die wesentlichen Aspekte in „working software“ verwandeln.
Tipps zu Working SoftwareSchaffen Sie ein Klima, in dem man wieder stolz auf seine Arbeit sein kann.
Das Dilemma aus Don‘t Waste und Don’t Debt
Ein Entwicklungsteam, das für produzierte Verschwendung und für produzierte technische Schuld gerügt wird, steckt in einem fast ausweglosen Dilemma. Das ist gleichbedeutend mit: Der Eimer, in dem normalerweise „waste“ landet, wird mit einem Schloss versehen und die technische Schuld muss vom Team daher unter den Teppich gekehrt werden. Da aber beides in der Natur der Softwareentwicklung begründet ist, muss ein offener Umgang mit diesem Dilemma gefunden werden, anstatt es totzuschweigen.
Abbildung 10 Don’t Waste und Don’t Dept
Sei stolz drauf
Ein wichtiger Gradmesser zur Bewertung von „working software“ darf an diese Stelle nicht unterschlagen werden. Das Entwicklungsteam weiß am besten, unter welchen Entbehrungen ein Inkrement entstanden ist. Wenn das Team stolz auf seine Arbeit sein kann, dann ist das ein starker Indikator für „working software“.
Platz 9 - Self-organizing Team
Von Helden und Sagen
Die sich selbst organisierenden Teams sollen bewirken, dass Helden, die das Projekt am Ende retten, nicht mehr benötigt werden. Schließlich identifiziert sich das ganze Scrum Team mit der Aufgabe und hat die volle Entscheidungsbefugnis und volle Verantwortung für das Ergebnis. Soweit die Theorie.
Wer hat die Verantwortung?
Wenn man sich das oben gesagte genauer überlegt, ist das eine riesige Verantwortung, die auf einem Scrum Team lastet. Dies muss man daher genauer betrachten. Das Entwicklungsteam hat sicherlich die fachliche Verantwortung für das produzierte Ergebnis. Die kommerzielle Verantwortung befindet sich in der Realität, aber meistens außerhalb des Scrum Teams. Diese wird vom Produktmanager, der Business Unit oder dem Sponsor wahrgenommen, die aber nicht wirklich Teil des Scrum Teams sind. Das sind wichtige Stakeholder.
Tipps zu Self-Organizing TeamKlären Sie, wie weit die Kompetenzen des sich selbst organisierenden Teams reichen.
Wer soll das managen?
Management ist viel zu wichtig, als dass man es alleine den Managern überlassen sollte. Selbstorganisation bedeutet Selbstmanagement. Das bedeutet dann konsequenter Weise auch, dass ein Team nicht mehr auf „Managemententscheidungen“ warten muss. Das allerdings geht vielen Managern heute noch zu weit. Sie sehen: oft klaffen hier Anspruch und Wirklichkeit auseinander. Was bei Ihnen gilt, müssen Sie mit Ihrem Umfeld klären. Überlegen Sie auch, wann Sie Ihr Management über wichtige Entscheidungen informieren oder wann Sie den Rat des Managements einholen.
Über Motivation
Woraus bezieht also ein agiles Team die Motivation, sich mit einer Aufgabe zu identifizieren? Die Prinzipien des agilen Manifests gehen davon aus, dass die Mitarbeiter eines agilen Teams grundsätzlich schon motiviert sind. Dort heißt es: „errichte Projekte rund um motivierte Individuen“. So weit, so gut. Aber woher kommt die so als selbstverständlich vorausgesetzte Motivation?
Abbildung 11 Motivation
Eine weitere Quelle für Motivation soll der Wettstreit nach technischer Exzellenz, der besten Architektur und dem besten Design sein. Ohne motivierte Mitarbeiter funktioniert also gar nichts.
Woher kommt Motivation?
Hier ist auch das Management gefordert, eine Atmosphäre im Unternehmen zu schaffen, damit die Mitarbeiter eine ausreichende Grundmotivation mitbringen. Dies kann z.B. durch einen Führungsstil erreicht werden, der den Manager zum Unterstützer und Förderer seiner Mitarbeiter macht. Das Zauberwort heißt hier „lean management“ oder „servant leader“. Aber die größte Motivationsquelle ist, wenn man stolz auf seine Arbeit sein kann und dies respektiert wird.
Motivation für Veränderung
In einer Welt, die ständigen Veränderungen ausgesetzt ist, wird die Gabe, sich auf diese Veränderungen schnell einzustellen, zum Wettbewerbsvorteil. Der Grundgedanke dabei ist, dass in einer nach agilen Methoden arbeitenden Welt besonders schnell auf Veränderungen reagiert werden kann, weil jeder Mitarbeiter selbst für die nötigen Verbesserungen sorgt. Das Management kann nicht mehr jede einzelne Verbesserung vorgeben. Nur diejenigen, die die Arbeit im Detail kennen und ausführen, haben ausreichend Einblick, um schnell genug Verbesserungen zu identifizieren und umzusetzen.
Wer muss Veränderungen beherrschen?
Die Fähigkeit einer Organisation zur ständigen Verbesserung ist heute ein wichtiger Erfolgsfaktor für Unternehmen. Und Verbesserung kann meist nur dadurch entstehen, indem man sich oder seine Arbeitsweise selbst anpasst. Diese eigene Anpassung muss von innen heraus entstehen, ohne dass das Management diese vorgibt, sonst wäre die Reaktionszeit der Organisation zu träge und der Wettbewerb hätte einen Vorteil. Um die Wirkung der eigenen Anpassung zu maximieren, ist es wichtig, dass alle daran teilhaben und in die gleiche Richtung ziehen, also die gleiche Ausrichtung haben und verfolgen. Die Leadership-Theorie hat dafür den Begriff „Alignment“ geprägt. Die Aufgabe der Führungskräfte verändert sich dadurch. Im agilen Arbeitsumfeld ist statt eines „Zuckerbrot- und Peitsche-Managements“ eher ein Management gefragt, das auf Vertrauen und Selbstorganisation setzt.
Tipps zu Self-Organizing TeamOhne Grundmotivation ist es schwierig, daher binden Sie das Linien-Management ein.
Dies ist ein gewaltiger Veränderungsprozess, der vom Management und in den Köpfen der Manager vollzogen werden muss. Eine Installation von ein paar, nach einem agilen Framework arbeitenden Teams ist also wenig erfolgsversprechend, wenn parallel dazu keine Veränderung in der Managementkultur einhergeht.
The free sample has ended.
