Agil für alle Bücher

Agile bietet echte und effektive Antworten auf eine Frage, die Führungskräfte wach hält: „Wie kann man in einer sich schnell verändernden und unvorhersehbaren Welt erfolgreich bleiben?“ Diese Methode hat den Markt bereits erobert und bewiesen, dass sie einer der besten Ansätze für die Erstellung und Bereitstellung von Software ist. Agile for All richtet sich an Praktiker. In diesem Buch erfahren Sie, wie ganze Unternehmen - von Produktmanagern und Entwicklern bis hin zu Vermarktern und Führungskräften - einen „flexiblen“ Ansatz verwenden können.

Matt LeMay erklärt einfach und ohne Slang, was Agile ist und bietet konkrete und effektive Schritte, mit denen jedes Team seine Aufgaben so effizient wie möglich realisieren kann. Sie finden viele Beispiele, die für jede Art und Größe von Organisationen geeignet sind - von Start-ups bis zu großen Unternehmen -, mit denen Sie den Agile-Ansatz in verschiedenen Tätigkeitsbereichen implementieren können.

Tauchen Sie ein in die agile Praxis: "whoopee!"

Als ich als Produktmanager arbeitete, hatte ich viele vorgefertigte agile Praktiken und Frameworks zur Hand, die ich als Team verwenden konnte. Diese Frameworks beziehen sich ausschließlich auf die Bedürfnisse von Softwareentwicklungsteams und wurden in der Praxis von Tausenden von Experten getestet, von denen viele freundlicherweise ihre Erfahrungen in Form von zugänglicher Literatur und Blog-Posts geteilt haben.

Als ich anfing, als Berater zu arbeiten, konnte ich jedoch nicht sofort verstehen, wie man diese Methoden in Bezug auf völlig unterschiedliche Ziele der neuen Teams einsetzt. Die Ergebnisse unserer Arbeit - Analyseberichte, die nach monatelangen Konsultationen erhalten wurden, Seminare zur Imagebildung des Kunden - unterschieden sich erheblich von Softwareprodukten, da wir keine klare und objektive Möglichkeit mehr hatten, die Leistung dieser Ergebnisse zu überprüfen. Darüber hinaus wurden in unseren Rollen alle Grenzen im Vergleich zu den Rollen im Entwicklungsteam aufgehoben, da wir jetzt alle eine gemeinsame Sache gemacht haben und uns nicht unter den Titeln „visueller Designer“ oder „Front-End-Entwickler“ versteckt haben.

In diesem prozeduralen Durcheinander haben wir versucht, eine Reihe von Standardproblemen zu bewältigen, die bei Teams auftreten, die nicht technische Ergebnisse erzielen. Das Thema dieser Ergebnisse erweitert sich während unserer Arbeit unmerklich und unweigerlich, insbesondere wenn wir von Zwischenzuständen (Skizzen) zu vollwertigen Dokumenten und Präsentationen gewechselt sind. Der kundenorientierte Zweck jedes Ergebnisses blieb uns manchmal unklar, deshalb haben wir in solchen Fällen das Thema Forschung erweitert, um nichts zu „verpassen“. Trotz der Tatsache, dass wir gerne zusammenarbeiten, haben wir nicht immer verstanden, wer, wofür, wann und warum verantwortlich war.

Es ist erwähnenswert, dass die „gesetzlichen“ agilen Methoden nicht immer perfekt in die Struktur unseres Teams oder die Ergebnisse passten. Wir haben jedoch verstanden, dass die grundlegenden agilen Prinzipien uns in die richtige Richtung halten können. Deshalb haben wir uns Fragen gestellt, die die Grundlage dieses Buches bildeten: Wie klar verstehen wir die Bedürfnisse unserer Kunden? Können wir alle Arbeitsmissverständnisse durch rechtzeitige Zusammenarbeit beseitigen? Stellen wir sicher, dass die Einführung neuer Informationen in den Workflow nicht zu einer vollständigen Verarbeitung des Materials führt?

Wir haben begonnen, diese Fragen regelmäßig bei Planungs- und Nachbesprechungen zu stellen und den Workflow so zu ändern, dass er unsere Ideen und Antworten widerspiegelt. Nachdem wir ungefähr ein Jahr lang experimentiert hatten, verwandelten wir unseren Ansatz in eine WHPI-Praxis (gelesen als „woooops!“ Oder „Warum, Wie, Prototyp, Iteration“). WHPI besteht aus vier Schritten, die in der Tabelle angegeben sind. 6.3. Zunächst entscheiden Sie gemeinsam, warum Sie das Ergebnis an erster Stelle setzen, welche Auswirkungen Sie erwarten und welchen Wert Ihr Kunde erhalten wird. Dann entscheiden Sie, wie Sie diesen Wert bereitstellen und wie das Endergebnis aussehen soll. Schließlich vertrauen Sie einem der Teammitglieder für eine begrenzte Zeit an, einen Prototyp zu erstellen, der die Erfahrung widerspiegelt, die Sie für den Kunden erstellen möchten. Anschließend iterieren Sie diesen Prototyp und prüfen, ob er die im ersten Schritt festgelegten Ziele erreichen konnte.


Wir haben festgestellt, dass WHPI ein leistungsstarkes agiles Tool ist, das unabhängig von seinen Aufgaben und Zielen in jedes Team eingebettet werden kann. Im Folgenden finden Sie eine kurze Beschreibung der einzelnen WHPI-Schritte sowie einige Tipps zur Implementierung und Verwendung dieser Methoden als Teil Ihres Teams.

SCHRITT 1: Warum

Für diesen Schritt versammeln wir mehrere wichtige Projektteilnehmer (2–4) und diskutieren schnell eine Reihe von Projektzielen oder -ergebnissen. Wenn möglich, versammeln wir uns in einem einzigen physischen (oder virtuellen) Raum und arbeiten alle Ideen aus, die während des Arbeitsprozesses auf Aufklebern aufgezeichnet wurden. Normalerweise dauern diese Besprechungen 15 bis 30 Minuten. Obwohl solche Zeitrahmen für solch wichtige Besprechungen schwierig und unpraktisch erscheinen mögen, spiegeln sie eine wichtige Wahrheit wider: Wenn Sie die Hauptziele nicht in 15 bis 30 Minuten bestimmen können, müssen Sie weitere Informationen einholen, bevor Sie fortfahren. Zu diesem Zeitpunkt wurde uns mehrmals klar, dass es notwendig ist, Grundlagenforschung zu betreiben, um unsere Annahmen zu bestätigen oder unseren Kunden einige klärende Fragen zu stellen. Nachdem wir einen einzigen Satz von „Warum“ -Zielen erstellt haben, stellen wir sie in den Mittelpunkt, damit sie den Rest des Arbeitsprozesses steuern.

Wenn wir beispielsweise nach einem Meeting einen Analysebericht erstellen, schreiben wir häufig drei Hauptgründe auf Aufkleber:

• Vermittlung eines Verständnisses der treibenden Kraft des Projekts an die Geschäftsleitung.
• Erinnern Sie die Teilnehmer an wichtige Erkenntnisse während des Meetings.
• Interesse bei Mitarbeitern wecken, die nicht an der Besprechung teilgenommen haben.

Bitte beachten Sie, dass keiner dieser Punkte direkt angibt, wie wir unsere Ziele erreichen werden - dazu später mehr!

SCHRITT 2: Wie

Nachdem wir die Ziele des Projekts festgelegt haben, gehen wir zu der schwierigen Aufgabe über, zu bestimmen, wie diese erreicht werden sollen. Wir nennen diesen Schritt oft „Definition von Werkzeugen“ - das heißt, wenn wir wissen, was wir tun werden, müssen wir über Werkzeuge und Ansätze nachdenken. Ich empfehle, mit denselben Besprechungsteilnehmern von „Warum“ zu „Wie“ zu wechseln. Wenn Sie ein „Wie“ definieren, verstehen Sie häufig, warum mindestens ein Hauptziel des Teams „Warum“ tatsächlich ein „Wie“ -Schritt auf Führungsebene ist.

Im vorherigen Abschnitt haben wir das folgende „Warum“ identifiziert: „Interesse bei Mitarbeitern wecken, die nicht an der Besprechung teilgenommen haben.“ Bevor wir diese Methode anwenden, definieren wir ein ähnliches Ziel wie folgt: "Erklären Sie den Teilnehmern die Sprache und die Rahmenbedingungen, damit sie Informationen mit ihren Kollegen teilen können." Nachdem wir jedoch begonnen hatten, das „Warum“ vom „Wie“ zu trennen, stellten wir fest, dass wir zwei Schlüsselfragen übersehen hatten: Warum ist es wichtig, dass Menschen diese Aufgaben mit Kollegen teilen und wie können wir den Prozess der Zielerreichung vereinfachen? Ist Sprache und Rahmen das, was Menschen wirklich brauchen? Wie wir in diesem Buch besprochen haben, hilft die vorrangige Berücksichtigung der Kunden und ihrer Bedürfnisse häufig dabei, den erwarteten Arbeitsaufwand zu reduzieren oder zu verstehen, dass das gewünschte Ergebnis erheblich von dem abweicht, was wir erreichen wollten.

Angesichts des „Warum“ aus dem letzten Abschnitt können wir das folgende „Wie“ identifizieren, um den Workflow zu steuern:

• Erstellen Sie einen kurzen zweiseitigen Analysebericht, der leicht zu verstehen und zu verbreiten ist.
• Verwenden Sie einprägsame Zitate von Teilnehmern, um der Geschäftsleitung das Verständnis für die treibende Kraft zu vermitteln.
• Verwenden Sie Besprechungsfotos, um die Teilnehmer an aufschlussreiche Momente zu erinnern.
• Fördern Sie positive Ergebnisse und begrenzen Sie die Detailgenauigkeit, um das Ergebnis fokussiert zu halten und ein breites Interesse zu wecken.

Wie Sie sehen können, bietet „wie“ einen Aktionsplan oder einen Plan, um alle erforderlichen Bedingungen zur Erreichung der beabsichtigten Ziele zu schaffen. Dieser Schritt bestimmt die Form unseres Ergebnisses, spricht direkt unser „Warum“ an und bietet klare und sich bewegende Grenzen, um den Verlust der Kontrolle über die gewünschten Ergebnisse zu verhindern. Mit einem solch klaren Plan können Sie Aufgaben delegieren, um viel schneller Ergebnisse zu erzielen, unabhängig davon, welchen Ansatz Sie in den nächsten Schritten verwenden.

SCHRITT 3: Prototyp

Durch die Definition von „Warum“ und „Wie“ können wir einen zeitlich begrenzten Prototyp erstellen. Das Wort "Prototyp" kann viele Dinge in verschiedenen Kontexten bedeuten. Im Rahmen dieser Methode definieren wir einen Prototyp wie folgt:

• Ein Prototyp ist kein Modell oder Planungsdokument. Es wird im selben Format wie das gewünschte Ergebnis oder Ergebnis erstellt. Beispielsweise ist der „Prototyp“ einer Präsentation mit Folien eine Präsentation mit Folien. Der „Prototyp“ einer gedruckten Broschüre ist eine gedruckte Broschüre.
• Ein Prototyp wird in einem begrenzten und vorgegebenen Zeitraum erstellt. (Erstellt als Teil des Zeitboxens.)

Mit anderen Worten, wir schaffen „die Voraussetzungen für das Erreichen der maximalen Anzahl von Projektzielen („ Warum “) mithilfe genehmigter Ansätze und Tools („ ​​Wie “) im selben Format und mit demselben Zeitrahmen wie das gewünschte Ergebnis. Bei kleinen Projekten wie Postern kann der ursprüngliche Prototyp wie ein fertiges Ergebnis aussehen. Bei großen Projekten wie einem vierzigseitigen Bericht kann der erste Prototyp aus 20 vollständigen Seiten bestehen, die in zwei Hälften gefaltet, zusammengeheftet und von Hand ausgefüllt werden (mit nummerierten Seiten, Überschriften, kurzen Ergebnissen und Stellen für Bilder).

Wie wir in Kapitel 3 besprochen haben, ist es unser Ziel, der Erfahrung des Kunden so nahe wie möglich zu kommen, indem wir unsere eigene Version von „funktionierender Software“ erstellen. Dinge, die in Modellen und Planungsdokumenten gut aussehen, funktionieren in Präsentationen, Berichten und Besprechungen nicht. Die Überprüfung der ersten Ergebnisse mithilfe der Prototypmethode half uns, in die Erfahrung des Kunden einzudringen, die Anzahl der Verbesserungen zu verringern und die anfänglichen Annahmen genauer zu analysieren.

In der Regel bestimmen wir ein Teammitglied, das für die Erstellung des primären Prototyps verantwortlich ist. Oft ist dies eine Frage der Freizeit: Wer kann in den nächsten Tagen mehrere Stunden Zeit für den ersten Versuch einplanen? Wir haben festgestellt, dass zwei Stunden Arbeit die Standardbeschränkung für die Erstellung eines Prototyps sind, mit der Sie eine Grundlage für den Vergleich mit den Zielen des Projekts erstellen und Raum für Entwicklung und Iteration lassen können.

SCHRITT 4: Iteration

Nach dem Erstellen des ersten zeitlich begrenzten Prototyps wird das ursprüngliche Team von Teilnehmern (oder ein Teil des Teams) zusammengestellt, um den Prototyp zu analysieren und die nächste Iteration zu diskutieren. Unsere ersten Diskussionen fanden im Plus / Suggest-Format statt, in dem jedes Mitglied des Teams über erfolgreiche Aspekte und über verbesserungsbedürftige Elemente spricht. (Wir haben in unseren Retrospektiven genau das gleiche Format verwendet und sind schnell darauf zurückgekommen.) Wir haben dieses Format schrittweise in die sogenannte Diskussion „Schützen, Ausschließen, Verbessern“ umgewandelt. Nach der Präsentation des Prototyps teilen die Teilnehmer drei Arten von Bewertungen:

• Was sollte für die nächsten Iterationen übrig bleiben, da es so viel wie möglich dem „Warum“ entspricht.
• Was kann aus den folgenden Iterationen ausgeschlossen werden, da es nicht allen "Warum" entspricht.
• Was sollte für die nächsten Iterationen verbessert werden, da es immer noch helfen kann, das notwendige „Warum“ zu erreichen.

Der Hauptunterschied zwischen diesem Ansatz und dem traditionellen Plus- / Angebotsformat besteht in einer offenen Diskussion darüber, was von den folgenden Iterationen ausgeschlossen werden muss. Wir haben begonnen, diesen Ansatz zu verwenden, nachdem wir festgestellt haben, dass die erfolgreichsten Änderungen für Iterationen auch bei den größten Projekten nach dem Ausschluss und nicht nach dem Hinzufügen erfolgen. Eine offene „Ausnahme“ während der Diskussionen ermöglicht es den Teilnehmern, Aspekte zu verfolgen, die entfernt werden können, was genauere und fokussiertere Ergebnisse liefert. Indem wir alle drei Arten von Überprüfungen mit dem zuvor vereinbarten „Warum“ in Einklang bringen, lösen wir alle potenziellen Konflikte, vermeiden unangenehme Momente und halten das Projekt in die richtige Richtung.

Nach dem Sammeln von Feedback wandelt eines der Teammitglieder diese Überprüfungen in einen anderen zeitlich begrenzten Prototyp um. In einigen Fällen führt dies zu einer vollständigen Überarbeitung des letzten Prototyps (z. B. einer Überarbeitung der Präsentation). In anderen Fällen führt dies zur Erstellung eines neuen Prototyps basierend auf alten Prototypen (z. B. eines Berichts über die Ergebnisse in Word basierend auf handgeschriebenen Prototypen). Diese aufeinanderfolgenden Iterationsrunden können von einer Person, die den ersten Prototyp erstellt hat, oder von einem anderen Teammitglied gesteuert werden. Bei der zweiten oder dritten Iteration befindet sich der Prototyp häufig in den Händen der Person, die die Hauptverantwortung für die Präsentation des modifizierten Produkts trägt. Darüber hinaus sieht der Prototyp bei der zweiten oder dritten Iteration fast vollständig und bereit für die endgültige Überarbeitung aus.

»Weitere Informationen zum Buch finden Sie auf der Website des Herausgebers
» Inhalt
» Auszug

25% Rabatt auf Gutschein für Händler - Agile

Nach Bezahlung der Papierversion des Buches wird ein elektronisches Buch per E-Mail verschickt.