Die ultimative Einführung in das agile Projektmanagement

Der Auftrag

Sie sind dafür verantwortlich, die neueste und größte Initiative Ihres Unternehmens umzusetzen, die das Gesicht von „Widgets International“ für immer verändern wird. Es ist ein Softwareprojekt, das Ihre Kunden fesseln und begeistern, das Leben Ihrer Kollegen erleichtern und dem Unternehmen Millioneneinnahmen bescheren wird. Es gibt viel Vorfreude, Inbrunst, Aufregung und Erwartung. Sie müssen es so schnell wie möglich erledigen, damit Ihr Unternehmen davon profitieren kann. Der zukünftige Erfolg des Unternehmens hängt von Ihnen ab. Alle Augen sind auf dich gerichtet. Du kannst nicht scheitern.

Zuerst denkst du dir: „Super, ich bin bereit für die Herausforderung. Lass uns das Ding erledigen!“ Sie halten einen Moment inne, treten zurück und denken sich: „Okay, also wie machen wir das?“ Sie beginnen, mit Ihren Kollegen und Kollegen zu sprechen. Sie verbringen viel Zeit damit, nach Best-Practice-Softwareentwicklungs- und Projektmanagementtechniken zu suchen, aber die Optionen und Ansätze sind zahllos. Akronyme und Methoden gibt es in Hülle und Fülle. Bemerkenswerte steigen an die Spitze. Zweifel schleichen sich ein. Welchen sollen wir nehmen? Wie kann ich den Erfolg garantieren? Was ist, wenn ich die falschen Entscheidungen treffe?

Wenn es um die Verwaltung von Softwareprojekten geht, gibt es eine aufregende Mischung von Optionen, die von unzähligen Meinungen unterstützt werden. Stimmen aus den Ecken des Raums flüstern: „Versuchen Sie es so“; andere schreien: „Das ist der einzige Weg, es zu tun“; und der Rest wimmert nur: „Mach das gar nicht, mach einfach weiter.“ In Wirklichkeit sprechen all diese Stimmen etwas Wahres. Aber was wichtig ist, ist herauszufinden, was für Ihre Bedürfnisse, Ihr Team, Ihr Unternehmen und Ihre Kunden richtig ist.

In Szene setzen

Es gab eine Zeit, in der das Softwareprojektmanagement in einem von drei Lagern saß. Da waren die schweren Frameworks, die es Ihnen ermöglichten, Entscheidungen darüber zu treffen, wie Sie ausführen und liefern, und gleichzeitig eine Struktur bieten, um Kontrolle und Governance aufrechtzuerhalten. Es gab vorgeschriebene sequentielle Methoden wie Wasserfall, die Sie dazu zwangen, langwierige Projekte zu planen, alle Ihre Anforderungen zu verstehen und zu erfüllen, komplexe Systeme zu entwerfen und zu genehmigen, viel Code zu schreiben und dann zu testen (alles bevor Ihr Kunde es zum ersten Mal sieht Zeit). Und schließlich die weniger vorgeschriebenen, aber iterativen Softwareentwicklungslebenszyklen (SDLC), die ein schnelles Prototyping oder größere Systeme fördern, die in inkrementellen Schritten entworfen, gebaut und geliefert werden, wobei jedes auf dem anderen aufbaut.

Agile Softwareentwicklung und agiles Projektmanagement wurden aus den Unzulänglichkeiten des Wasserfalls und den Vorteilen der iterativen Ansätze zur Softwarebereitstellung geboren. Sie können ihre Wurzeln bis in die 1950er Jahre zurückverfolgen, Vordenkerrolle in den 70er Jahren, Reife in den 90er Jahren und Akzeptanz in den 00er Jahren. Im Jahr 2001 erstellte eine Gruppe von Praktikern und Experten das Agile Manifest, das darauf abzielt, 4 Werte und 12 Leitprinzipien zu definieren, die den Geist der agilen Softwareentwicklung verkörpern und ihre Entwicklung fördern sollen. Und es hat sich definitiv weiterentwickelt.

Etwas einfach Agile zu nennen, ist nicht besonders hilfreich. Das Wort bedeutet selbst im Softwarekontext für verschiedene Personen oder Organisationen unterschiedliche Dinge. Es gibt viele Facetten, Definitionen, Implementierungen und Interpretationen. Jedes Gremium, das Agilität annimmt, neigt dazu, zu versuchen, ihm seine eigene Definition zu geben.

Es genügt zu sagen, dass agile Softwareentwicklung und Projektmanagement eine Gruppe verwandter Verhaltensweisen, Frameworks, Techniken und Konzepte sind, die grundsätzlich die Bereitstellung der richtigen funktionierenden Software so früh und so oft wie realistisch möglich begünstigen.

Ich habe bereits erwähnt, dass Agilität in Bezug auf Softwareentwicklung oder Projektmanagement verschiedene Dinge sein kann. Kurz gesagt, agile Softwareentwicklung kümmert sich um die Entwicklung großartiger Software in einem Business-as-usual (BAU)- oder Projektkontext. Agiles Projektmanagement hingegen kümmert sich um die Governance und Kontrolle, die für die Durchführung komplexer Projekte erforderlich sind, einschließlich, aber nicht beschränkt auf Software.

Es gibt viele agile Softwareentwicklungsmethoden wie Scrum, Kanban, XP und Lean Software Development. Aber so wie es beim Rugbyspiel um mehr als nur Gedränge geht, so ist es auch Agile. Isoliert adressieren diese agilen Paradigmen nicht den gesamten Lebenszyklus des Projektmanagements, der in komplexen Projekten erforderlich ist, wie z. B. Governance, Ressourcen, Finanzen, explizites Risikomanagement und viele andere wichtige Projektmanagementkonzepte. Für diese sollten Sie vielleicht PMI Agile oder PRINCE2 Agile in Betracht ziehen – stellen Sie es sich als „Governed Agilität“ vor.

Warum müssen wir agil sein?

Vor langer Zeit durchstreiften wir das Land, um Nahrung und Unterkunft zu sammeln, um zu überleben. Sie waren einfache Bedürfnisse, aber ziemlich agil. Einige Zeit später wuchsen und gediehen Länder und Volkswirtschaften auf dem Rücken der Industriellen Revolution. Dies war die Geburtsstunde von Management und Kontrolle und der Verlust von Agilität. Jetzt befinden wir uns im Informationszeitalter oder der Revolution, in der Unternehmen Wissensarbeiter beschäftigen. Wissensarbeiter sind Sie, Ihre Partner und Ihre Kollegen und Kollegen, die bestrebt sind, großartige Lösungen für Kunden-, Geschäfts-, soziale, wirtschaftliche und weltweite Probleme zu schaffen. Wissensarbeiter wenden Analyse, Wissen, Argumentation, Verständnis, Fachwissen und Fähigkeiten auf oft lose definierte und sich ändernde Bedürfnisse an. Diese Unternehmen und Arbeitnehmer benötigen Methoden und Techniken, die mit den Prozessen und Verfahren des alten Industriezeitalters nicht erfüllt werden können. Agilität unterstützt Interaktionen.

Kaum ein Softwareprojekt kann souverän an den Start gehen und alles wissen, was es braucht, um ohne Änderungen wertvolle und funktionierende Software zu liefern. Veränderungen bieten sowohl Chancen als auch Risiken für den Erfolg eines Projekts. Nicht verwaltete Chancen können den Unterschied zwischen einem großartigen Unternehmen und einem großartigen Unternehmen ausmachen. Unkontrolliertes Risiko bedeutet Katastrophe und Ruin. Agil verwaltet Veränderungen.

Durch die Einführung von Agile können Sie auf sich ändernde oder neue Anforderungen reagieren. Es befähigt Entwicklungsteams, die Experten zu sein und Entscheidungen zu treffen, die von einem engagierten, vertrauensvollen und informierten Unternehmen unterstützt werden. Es ermöglicht Ihnen, Ihren Kunden das zu liefern, was sie wirklich wollen. Letztendlich gibt es Ihnen und Ihrem Unternehmen die Kontrolle über die Bereitstellung qualitativ hochwertiger, wertvoller Software, die die Bedürfnisse und Erwartungen der Kunden erfüllt und gleichzeitig so früh wie möglich eine Rendite auf Ihre Investitionskosten erzielt. Agilität schafft Wert.

Die Einführung von Agile ist mit Kosten verbunden. Es kommt nicht umsonst. Die Umstellung auf einen agilen Ansatz für die Softwarebereitstellung kann ein schwieriger Weg sein. Wenn Sie jedoch die Agile-Philosophie verinnerlichen, vorsichtig vorgehen, das richtige Team mit der richtigen Einstellung engagieren, die Dinge aufschlüsseln, es erreichbar und realistisch machen und auf Feedback reagieren, werden Sie belohnt. Agile betont die Zusammenarbeit.

Im Folgenden sind einige Vorteile aufgeführt, die Sie erwarten können:

• Schnelle Markteinführung
• Frühere Umsatzgenerierung
• Regelmäßige Lieferung mit echtem Mehrwert
• Schutz für Ihre Investition
• Daten, Daten, Daten
• Bessere Produktqualität
• Überschaubare Erwartungen
• Höhere Kundenzufriedenheit
• Leistungsstärkere Teams
• Verbesserte Sichtbarkeit des Fortschritts
• Berechenbarkeit, Transparenz und Vertrauen
• Überschaubares Risiko

Erfolg ist nicht endgültig, Scheitern nicht fatal: Es zählt der Mut weiterzumachen.

Winston Churchill hat das vielleicht nie wirklich gesagt, aber ich denke, es ist eine ziemlich gute Zusammenfassung von Agilität. Wir wissen, dass Agile für die meisten Projekte der beste Weg nach vorne ist. Es ermutigt Sie, nach Erfolg zu streben, aber wir wiederholen es immer und bauen weiter darauf auf. Agile wird Sie zum Scheitern ermutigen, aber scheitern Sie früh und machen Sie weiter. Den Mut zu haben, weiterzumachen und die richtige Lösung basierend auf den Erkenntnissen Ihrer Kunden zu entwickeln, ist das, was sich lohnt.

Denken Sie daran, dass Sie Agile an Ihre Bedürfnisse anpassen können. Verwenden Sie die Methode und Governance, die für Ihr Unternehmen geeignet sind. Wo immer Sie beginnen, bleiben Sie dem Inhalt, Kontext und Geist der Methode, die Sie verwenden, treu – bleiben Sie bei der Stange. Wenn Sie gerade erst anfangen, lernen Sie . Wenn Sie es schon eine Weile tun, verstehen Sie . Wenn Sie großartig werden, bewerben Sie sich . Schließlich, wenn Ihr Unternehmen und Ihre Projekte komplex und voneinander abhängig sind, regieren Sie . Im Laufe der Zeit werden Sie und Ihre Teams herausfinden, was für Ihr Unternehmen am besten funktioniert.

Durchführbarkeit

Jetzt denkst du also: „Okay, ich verstehe. Wie fange ich an? Wo soll ich anfangen?" Nun, bei allem Guten fangen wir am Anfang an. Und bei Agile fragt man sich: „Welchen geschäftlichen Nutzen möchte ich liefern?“ Schließlich führen wir Projekte durch, um Geschäftswert zu generieren. Um festzustellen, ob sich das Projekt lohnt, um den Geschäftswert abzuleiten, müssen Sie verstehen, ob es machbar ist.

Vision

Soll Ihr Projekt den Umsatz steigern, in einen neuen Markt eintreten, mehr Kunden gewinnen, die Kundenwahrnehmung verbessern oder das Leben für ein bestimmtes Problem, das Sie identifiziert haben, erleichtern? Vor diesem Hintergrund können Sie Ihre „Vision“ formulieren.

• Ihre Vision kann aus verschiedenen Quellen stammen – Ihrem eigenen mutigen Startup zur Lösung eines gemeinsamen Problems, der Unternehmensführungsstrategie, dem Lieblingsprojekt Ihres CEO, einem bestimmten Produktteam oder sogar den Bedürfnissen Ihres Kunden.
• Versuchen Sie, einen Schritt von Ihren eigenen Schuhen zurückzutreten und zu „sehen“, wie die Zukunft mit Ihrem neuen Produkt oder Ihrer neuen Dienstleistung in den Händen Ihrer Kunden aussieht.
• Binden Sie Ihre Stakeholder ein – den CEO, den Produktspezialisten und die Kunden. Trainieren Sie es, versuchen Sie es nicht isoliert. Hinterfragen Sie Annahmen und validieren Sie Argumente.
• Schreiben Sie es auf, halten Sie es kurz. Konzentrieren Sie sich auf den Geschäftswert.
• Verfeinern Sie es, bis Sie sich alle einig sind, dass die Vision bei allen Anklang findet und eine gemeinsame Interpretation trifft, die angibt, wohin Sie gehen.
• Ihre Vision ändert sich selten, wenn sie gültig ist. Wie Sie dorthin gelangen, wird es sicherlich.

Die Leute kaufen nicht, was Sie tun oder wie Sie es tun. Sie kaufen das „Warum“ Sie es tun. Dies schafft die emotionale Verbindung zwischen Ihrem Unternehmen und Ihren Kunden. Die Vision wird dazu beitragen, dies zu veranschaulichen.

Ist es machbar?

Machbarkeit kommt in mindestens ein paar Schattierungen. In der Regel möchten Sie verstehen, ob Ihre Vision einer besseren Zukunft für Ihr Unternehmen und Ihre Kunden sowohl technisch machbar als auch für Ihr Unternehmen machbar ist.

• Wenn Ihre Vision darin besteht, in weniger als einer Stunde überall auf der Welt zu reisen, haben Sie möglicherweise ein Problem mit der technischen Machbarkeit. Da Wissenschaft, Physik und Technologie diesen Traum noch nicht ganz eingeholt haben, ist Ihre technische Lösung möglicherweise nur in der Theorie realisierbar. Wenn Ihre Lösung neu wäre, würde dies außerdem weit über die Idee eines Minimum Viable Product (MVP) hinausgehen.

• Um die technische Machbarkeit Ihres Produkts zu testen, sollten Sie es entweder in einem Discovery-Prototypenprojekt weiter untersuchen oder in den frühen Phasen des Projekts einen Spike durchführen. Sie werden wissen, welche Methode Sie verwenden müssen, indem Sie über den Umfang oder die Komplexität der Lösung nachdenken, die Sie im Sinn haben.

  „Einige der besten Erkenntnisse, die meine Teams zum Verständnis der technischen Machbarkeit gewonnen haben, stammen aus der Durchführung eines Spikes. Und oft gewinnt die einfachste Lösung!“

• Die zweite zu berücksichtigende Machbarkeitsstufe ist, ob Sie, Ihr Team oder Ihr Unternehmen über die Fähigkeiten und die Motivation verfügen, um es zum Laufen zu bringen. Um ein Beispiel zu verwenden, wenn Sie großartig darin sind, Kuchen für Ihren Kindergeburtstag zu Hause zu backen, ist das süß. Aber wenn Sie daraus ein Unternehmen machen wollen, das weltweit die besten Kuchen verkauft, müssen Sie verstehen, ob Sie es skalieren, das Geschäft sowie die Produktion handhaben, den Vertrieb und die Erfüllung verwalten und sich um den Kundenservice kümmern können.
• Diese Art von Vision könnte auf lange Sicht erreichbar sein. Aber im Moment vielleicht nicht. Skalieren Sie es also zurück, denken Sie klein, nehmen Sie einen kleinen Teil, der realistisch aussieht, und konzentrieren Sie sich darauf, das bestmögliche kleinere Ziel zu erreichen. Wenn es Ihnen gelingt, Ihre Kunden zu begeistern und zu begeistern, bringen Sie sie dazu, für mehr zurückzukommen und es ihren Freunden zu erzählen, und skalieren Sie es dann von dort aus, indem Sie Ihr Kundenfeedback als Leitfaden und Kompass verwenden.
• Außerdem müssen Sie wissen, ob Ihr Projekt in Bezug auf Budget und Zeitrahmen machbar ist. Kann sich Ihr Unternehmen dieses Projekt leisten? Ist der Zeitrahmen erreichbar? Zeit und Geld sind zwei der drei Einschränkungen in einem agilen Projekt, die fest sind. Unser Ziel ist es, innerhalb einer bestimmten festen Zeit und innerhalb eines bestimmten festen Budgets zu liefern.
• Die Qualität eines Produkts bezieht sich auf das Endprodukt, das Ihre Kunden verwenden, und auf die Engineering-Praktiken, die Ihr Team verwendet, um großartige, robuste und zuverlässige Software zu liefern. Auch Qualität kommt bei uns nicht zu kurz. Qualitätskriterien hingegen können sich ändern. Wenn Sie nicht daran denken, einen Ferrari zu bauen, wird das Produkt möglicherweise nicht als hochwertig wahrgenommen. Wenn Sie keine Weltraumraketen bauen, können die fertigungstechnisch erreichten Toleranzen viel höher sein. Setzen Sie frühzeitig den richtigen Ton und die Erwartung.

Jetzt, wo Sie bestätigt haben, dass Ihr Traum mehr ist als Schokoladenfantasie, machen Sie sich daran, Ihre Annahmen zu testen und den Menschen zu beweisen, dass es sich lohnt, in dieses Unterfangen zu investieren.

Rechtfertigung

Nun, je nach Ihren Umständen wird die Rechtfertigung in verschiedenen Formen kommen. Aber im Wesentlichen wollen Sie beweisen, dass dieses Projekt die Erfolgskriterien der Kunden erfüllt, Erfolgsaussichten hat, Wert liefert und erschwinglich ist.

• Geben Sie Ihre Annahmen basierend auf Ihren Kundenbedürfnissen an und validieren Sie sie dann. Das Lean Startup bietet eine hervorragende Anleitung, um zu erkennen und zu beweisen, dass Ihr Produkt von Ihren Kunden benötigt wird und Wert schafft.

• Schreiben, testen und validieren Sie Ihren Businessplan. Nun, das sieht nicht so aus wie die, die Ihre Bank oder Ihr Wirtschafts- und Finanzmajor Ihnen aufgetragen hat. Verwenden Sie sie nicht – sie verfallen, bevor die Tinte getrocknet ist. Sehen Sie sich stattdessen das Business Model Canvas an. Dies ist im Wesentlichen ein Kurzform-Businessplan, der Ihren Fokus auf Ihr Wertversprechen, Ihre Kunden, Einnahmen und Kosten legt. Verwenden Sie es, um zu überprüfen, ob Sie ein Geschäft haben, das funktionieren wird.

  „Ich habe diesen Rat einmal ignoriert und viel Zeit damit verbracht, einen langatmigen traditionellen 50-seitigen Businessplan zu schreiben. Es hat mich nirgendwohin gebracht. Alle Annahmen, die ich gemacht hatte, waren unbegründet, und alle Prognosen, die ich gemacht hatte, konnten nicht validiert werden. Es war eine schmerzhafte und teure Erfahrung, die mich gelehrt hat, es nie wieder zu tun.“

• Wenn Sie in einem ausgereiften Unternehmen mit Portfolios von Projekten in einer komplexen Umgebung tätig sind, kann eine Finanzmodellierung erforderlich sein. Wenn Sie müssen, tun Sie dies erst, nachdem Sie das oben Gesagte bewiesen haben.
• Sobald Sie Ihr MVP erstellt haben, kann es sinnvoll sein, einen traditionelleren Geschäftsplan zu erstellen – zum Beispiel, wenn Sie sich um eine Finanzierung oder Auswahl innerhalb des Portfolios konkurrierender Projekte und Ressourcen Ihres Unternehmens bemühen müssen. Dies wird jedoch ein Geschäftsplan sein, der auf den oben verwendeten Tools basiert und von ihnen informiert wird. Leichter wird es auch.
• Verwenden Sie diese Werkzeuge auf jeden Fall als lebende, atmende Artefakte. Verwenden Sie sie als Führer und Richtschnur. Sie sind niemals statisch. Beziehen Sie sich auf sie und überarbeiten Sie sie, wenn sich Ihr Projekt oder Geschäft weiterentwickelt.

Sobald Sie Ihre Rechtfertigung haben und alle Ihre Stakeholder an Bord sind, werden Sie Feuer und Flamme sein.

Die Durchführbarkeitsphase wird normalerweise einmal im Leben Ihres Projekts durchgeführt. Möglicherweise stellen Sie fest, dass Sie die Vision und Machbarkeit des Projekts überdenken, insbesondere wenn Ihre Daten, Kunden, Ihr Markt oder Ihr Unternehmen dies anzeigen. Zumindest werden sie Ihre Leitlichter sein.

Einleitung

Fantastisch. Die Entscheidung ist gefallen, das Projekt hat grünes Licht und Sie können bauen. Nun, fast. Ich weiß, du denkst: „Komm schon, wirklich? Wenn wir das jetzt nicht tun, werden wir es nie tun. Lassen Sie uns diese Show auf den Weg bringen!" Aber bedenken Sie Folgendes: Bei Agile geht es um nichts anderes, als darum, frühzeitig und oft Wert zu liefern und gleichzeitig Ihre Kunden zu begeistern. Sich etwas Zeit zu nehmen, um herauszufinden, wie Sie Ihr Projekt am besten umsetzen können, ist die beste Grundlage für den Erfolg.

Das Team

Wenn Sie im Sport an Ihr Lieblingsmannschaftsspiel denken, werden Sie in der Lage sein, Schlüsselrollen zu erkennen, die es der Mannschaft ermöglichen, so zu spielen, wie sie es tun. Traditionell finden Sie einen Manager, einen Kapitän und den Rest des Kaders. Darüber hinaus finden Sie Trainer, Physiotherapeuten, Ernährungsberater und eine Auswahl an unterstützendem Personal. Aber wenn wir uns das Rugbyspiel ansehen, gibt es ein Team innerhalb eines Teams: die Spieler, die das Gedränge bilden. Dieses Rudel besteht aus bestimmten Spielern, deren Aufgabe es ist, den Ball zurückzugewinnen und das Spiel fortzusetzen. Wenn ein Gedränge im Spiel ist, arbeiten die Spieler jeder Seite ohne Anführer als eine Einheit so kooperativ, kommunikativ und effizient wie möglich, um den Ball wieder in Ballbesitz zu bringen. Es ist das Rugbyspiel, das Jeff Sutherland dazu inspirierte, seine Softwareentwicklungsmethodik „Scrum“ zu nennen.

• Scrum ist nicht die einzige Softwareentwicklungsmethode im Agile Playbook. Aber es ist dasjenige, das das agile Konzept und die Verhaltensweisen der Teamarbeit, der Motivation von Einzelpersonen, der Schaffung vertrauensvoller Beziehungen, der Selbstorganisation, der dienenden Führung, der Kommunikation, der Transparenz und der Zusammenarbeit am besten beschreibt.
• Ihr Team wird weitgehend durch die Umstände gebildet, in denen Sie sich befinden. Möglicherweise stehen Ihnen Entwickler zur Verfügung. Einige, keiner oder alle von ihnen sind möglicherweise in unterschiedlichem Maße mit Agile vertraut. Möglicherweise möchten Sie ein neues Team einstellen oder mit einem Drittanbieter zusammenarbeiten.
• Andere Rollen werden ebenfalls benötigt, aber wir werden diese später besprechen.
• Es wurde gesagt, dass Sie Ihre Technologie gewählt haben, wenn Sie Ihr Entwicklungsteam bilden. Je nachdem, woher Sie Ihr Team zusammenbringen, verfügen sie über spezifische Fähigkeiten. Denken Sie also sorgfältig darüber nach, wie Sie Ihr Entwicklungsteam zusammenstellen und ob Sie eine technische Bewertung durchführen müssen, bevor Sie an diesen Punkt Ihrer Reise gelangen.
• Das bringt uns zu funktionsübergreifenden Teams. Teams funktionieren am besten, wenn sie zusammenarbeiten, wenn Einzelpersonen unabhängig von ihrem Titel anpacken, um die Arbeit zu erledigen. Versuchen Sie, ein Team aufzubauen, das autark ist, und Personen, die mehr als eine Rolle übernehmen.
• Bauen Sie ein Umfeld, eine Kultur und ein Beziehungszentrum auf – einen Ort, an dem das Team seine Leistung erbringen kann, ohne Einschränkungen oder Beschränkungen. Geben Sie dem Team die Tools, Mitarbeiter, Ressourcen und den Raum, um effektiv und leistungsfähig zu sein.
• Beschränken Sie die Teamgröße auf nicht mehr als sieben oder acht. Wenn Sie viel mehr Entwickler benötigen, teilen Sie das Team in mehrere neue Teams auf. Jedes Team könnte dann für einen bestimmten Funktionsbereich verantwortlich sein. Wenn Sie mehrere Teams an mehreren Standorten haben, sollten Sie ein Scrum of Scrums abhalten. Und wo diese in komplexen Umgebungen zahlreich sind, verwenden Sie agiles Projektmanagement.
• Stellen Sie sicher, dass das Team, das Unternehmen, die Stakeholder und sogar die Kunden Zugang zueinander haben. Stellen Sie sicher, dass sie kommunizieren und zusammenarbeiten, und beseitigen Sie alles, was dem Fortschritt im Wege steht. Tägliche Kommunikation ist das beste Mittel gegen Projektbeschwerden. Wenn Menschen sprechen, erledigen sie Dinge.

Es gibt viele Möglichkeiten, ein Team für die Bereitstellung von Software zusammenzustellen.

Projektübersicht

Im Machbarkeitsschritt haben Sie das „Warum“ Ihres Projekts herausgefunden und entweder Ihr Selbstvertrauen aufgebaut, um Ihr Startup voranzutreiben, oder Sie haben Unterstützung erhalten, um fortzufahren. Die Projektbeschreibung ist das lebendige Dokument, das das „Warum“ mit dem „Was“, „Wann“ und „Wer“ zusammenbringt. Es ist „lebendig“, weil sich Ihr Wissen, Ihr Verständnis und Ihr Weg ändern können, wenn Sie Fortschritte machen. Dieses Dokument einmal geschrieben zu lassen und nie wieder darauf zurückzukommen, überlässt Ihre Gedanken nur einem bestimmten Zeitpunkt. In einer agilen Welt kann sich Ihre Point-in-Time-Referenz früh wöchentlich oder sogar täglich ändern, daher ist es wichtig, diese aktuell zu halten.

• Ein großartiges Werkzeug zum Zusammenfassen und Pflegen Ihres Projektbriefings ist etwas, das Jonathan Rasmusson in seinem Buch The Agile Samurai das „Inception Deck“ nennt. Hier finden Sie großartige Ratschläge, wie Sie sicherstellen können, dass alle, die an Ihrem Projekt interessiert, davon betroffen oder daran beteiligt sind, auf derselben Seite sind.
• Der größte Feind bei der Durchführung von Projekten ist ein unklares, inkonsistentes oder einfach nur unterschiedliches Verständnis dessen, was das Projekt ist und welche „Anforderungen“ erfüllt werden müssen. Wenn auch nur ein wichtiger Stakeholder ein anderes Verständnis oder eine andere Ansicht von dem hat, was Sie tun, können die Konsequenzen erheblich sein.
• Eine gute Projektbeschreibung kommuniziert:
  1. Eine gemeinsame und vereinbarte Erwartung zwischen Stakeholdern und Teammitgliedern.
  2. Ein Verständnis des Projekts, mit dem gleichen Verständnis für alle Parteien.
  3. Das Ziel, die Vision, das Ziel, der Umfang und der Projektkontext.
• Sie werden eine Menge guter Informationen für das Briefing aus Machbarkeit gesammelt haben. Die Projektbeschreibung hilft Ihnen, Antworten auf Suchfragen zu definieren und zu finden. Es bringt Stakeholder, Ihre Daseinsberechtigung, übergeordneten Umfang, Risiken, Ziellösung , Budget, Zeitplan, Erwartungen und Prioritäten zusammen.

Einmal hielt mich ein Kollege in einem Flur an und fragte mich, wo er die Projektbeschreibung für das Projekt herbekommen könne. Ich witzelte: „Wir brauchen kein Briefing, wir sind agil“. Er sah verwirrt aus, als würde er meinen Verstand oder meine Autorität in Frage stellen. Er hatte recht damit.

Bevor Sie fortfahren, vergewissern Sie sich, dass alle auf derselben Seite sind, arbeiten Sie daran, stellen Sie die schwierigen Fragen und befestigen Sie sie an einem Ort, an dem die Leute anhalten, sie lesen, kommentieren und bei der Überarbeitung helfen können.

Kultur und Arbeitsweisen

Sie kennen die Arbeitsweise und Kultur Ihres Unternehmens, die Art und Weise, wie es Dinge erledigt. Agilität kann naturgemäß einige dieser Arbeitsweisen in Frage stellen, die Ihr Unternehmen im Laufe der Jahre kultiviert hat. Erwarten Sie nicht, dass Agile implementiert wird und dass jeder es von Anfang an liebevoll annimmt. Einige Leute finden es vielleicht verwirrend und betrachten es nur mit Furcht und Furcht. Manche Leute weigern sich vielleicht offen, sich darauf einzulassen. Dies sind Herausforderungen und Wahrnehmungen, die Sie überwinden müssen. Aber gehen Sie in Ihren frühen Tagen nicht herum und schwenken Sie den Agile-Stick, um jeden zu schlagen, der nicht damit zuhören will. Das schafft kein Vertrauen, Akzeptanz oder Engagement.

Ich war ein Fan davon, große sprichwörtliche Stöcke zu schwenken, und es brachte mir viel negative Presse ein. Ich drehte es um, aber nicht bevor ich vorher erhebliche Schmerzen hatte.

Wenn Sie sich auf den Weg der Adoption machen, gehen Sie vorsichtig, respektvoll und mit Empathie vor. Wenn Sie in einem knarrenden alten traditionellen Geschäft tätig sind, ist dies vielleicht nicht der beste Ansatz, um das gesamte Unternehmen in Einklang zu bringen. Fangen Sie klein an und verdienen Sie sich nach und nach Respekt und Anerkennung. Beginnen Sie nur mit Ihrem Team. Sobald Sie anfangen, schnellere Software mit besserer Qualität als je zuvor bereitzustellen, werden die Leute dies bemerken und Ihr Spiel spielen wollen. Wenn sie es tun, bieten Sie ihnen den Ball an, führen Sie sie auf einen Kaffee aus und lassen Sie sie in Ihre neue Welt eintauchen. Hilf ihnen.

Lassen Sie Ihr Team jetzt, da es weiß, worum es bei dem Projekt geht, und Ihre Pläne für die Einführung von Agile vereinbart sind, das Team entscheiden, wie es sich verhalten und als Team arbeiten möchte.

• Leiten Sie Ihr Team an, um die agilen Konzepte, Techniken, Verhaltensweisen und Rahmenbedingungen zu identifizieren, die Ihrer Meinung nach Ihren kollektiven Bedürfnissen entsprechen.
• Nehmen Sie Anfragen von Ihren Teammitgliedern entgegen, welche Anforderungen sie haben, damit sie ihre bestmögliche Leistung erbringen können. Einige dieser Anfragen können Sie sofort lösen. Andere benötigen möglicherweise Budget oder externe Hilfe. Tun Sie, was Sie können, um dies zu erreichen.
• Dies sind Ihre ersten Schritte, um ein wahrer Servant-Leader zu werden.
• Erwägen Sie, eine angemessene Schulung zu den Konzepten und Techniken zu organisieren, die Ihr Team übernehmen möchte. Dies ist der beste Weg, um sicherzustellen, dass alle Ihre Teammitglieder, sogar alle Beteiligten, auf derselben Seite sind und dieselbe Nachricht erhalten. Arbeiten Sie mit einer Lieferantenorganisation zusammen, die ihr Angebot auf Ihre Bedürfnisse zuschneiden kann.
• Seien Sie umsichtig. Niemand wird ein agiler Ninja sein, nachdem er ein paar Tage in einem Workshop gelernt hat, wie man agil wird. Dein Weg wird lang sein. Das Wort „werden“ ist ziemlich definierend. Nur wenn Sie Agile wirklich annehmen, werden Sie seinen Wert erkennen. Es sollte Sie begeistern. Wenn es dich begeistert, dann errege auch andere.
• Jetzt, da sich Ihr Team auf die Konzepte und Techniken geeinigt hat, seine Wünsche erfüllt wurden und es sich im Agile-Training befindet, lenken Sie die Aufmerksamkeit Ihres Teams auf sich selbst und darauf, was es von Ihnen, dem Unternehmen und einander erwartet.
• Definieren Sie einige Arbeitsweisen (WoW) innerhalb und durch das Team, um Vertrauen, Beziehungen und Erwartungen aufzubauen. Das WoW ist kein Krieg und Frieden . Es sollte kurz und prägnant sein, zwischen sieben und zehn stichpunktartige Sätze. Diese Sätze sagen deutlich aus, wie sich Menschen verhalten, kommunizieren, zusammenarbeiten, unterstützen, liefern und gemeinsam Leistung bringen. Es sollte auch angeben, was das Team von dem Unternehmen erwartet.

• Agilität ist sowohl eine Denkweise als auch Leitprinzipien und Konzepte. Es hilft Ihnen, sich in der Art und Weise zu entwickeln, wie Sie sich verhalten, denken, verhandeln, interagieren, kommunizieren, Leistungen erbringen und sich verbessern. Es beruht auf motivierten Einzelpersonen, die sich gegenseitig unterstützen, um gemeinsam als Einheit ein gemeinsames Ziel zu erreichen. Es gibt ein afrikanisches Sprichwort:

Inzwischen sollte Ihr Team super aufgeregt, energiegeladen und motiviert sein. Binden Sie sie jetzt weiter mit Ihrem Rückstand an User Stories ein.

Rückstand

Zweifeln Sie nicht daran, dass Ihr Projekt mit Unsicherheiten verbunden ist. Sie können unmöglich genau wissen, was nötig ist, um so früh im Leben das richtige Produkt für Ihre Kunden zu entwickeln. Man kann nicht sehnsüchtig in eine Kristallkugel blicken und die Zukunft vorhersagen.

Im „Backlog“ oder „Product Backlog“ leben Ihre Anforderungen. Agile bevorzugt das Schreiben von kurzen, prägnanten Aussagen, die die Essenz einer „Anforderung“ erfassen. Das Backlog ist einfach eine lange Liste von Einträgen, wobei jeder Eintrag eine einzelne, diskrete „Anforderung“ als User Story definiert. Und ab jetzt verwenden wir das Wort User Story und nicht mehr „Requirement“. Du fragst wahrscheinlich "warum?" Das ist eine gute Frage. Seit einer gefühlten Ewigkeit wird die Angabe der Features oder Facetten, die ein Kunde in einem Softwareprojekt benötigt, immer als Anforderung bezeichnet. Dieses Wort hat eine Interpretation, die in Agile keinen Wert hat. Das Oxford-Wörterbuch definiert es als:

Eine Sache, die gebraucht oder gewollt ist. Oder, eine Sache, die obligatorisch ist; eine notwendige Bedingung.

Und leider, wenn wir uns daran machen, zu definieren, was unsere Lösung sein sollte, und sagen, dass die Dinge „obligatorisch“ sind, werden wir am Ende in Schwierigkeiten geraten. Es ist zu einfach zu sagen, dass all diese User Stories obligatorisch sind. Wenn wir diese Ansicht vertreten, laufen wir Gefahr, den Zeitplan und das Budget zu überschreiten, wenn wir versuchen, alles in einem bestimmten Umfang zu liefern. Es ist kein Problem zu sagen, dass diese Geschichten für dieses Produkt benötigt werden, damit die Lösung realisierbar ist, wir wollen nur die Interpretation dieses bestimmten Wortes vermeiden.

• Schreiben Sie Geschichten immer aus der Perspektive einer Persona. Eine Persona repräsentiert einen Benutzer oder Stakeholder der Lösung. Es ist eine gute Idee, diese Personas zu entwickeln, bevor Sie mit einem Backlog beginnen.
• Schreiben Sie in dieser Phase nur kurze, einfache Aussagen, die im Grunde eine Erinnerung suggerieren, zum richtigen Zeitpunkt ein tieferes Gespräch über die User Story zu führen.
• Echte Menschen denken in Aufgaben, die sie erledigen müssen, um ein Ziel zu erreichen. Schreiben Sie Ihre Geschichten aus der Persona-Perspektive und im Hinblick darauf, was sie erledigen müssen.
• Sie müssen nicht den gesamten Rückstand schreiben – schreiben Sie einfach so viel, wie Sie sich vorstellen können, dass Ihre Kunden benötigen werden, damit Ihr Produkt rentabel ist.
• Sie werden später im Laufe des Produktlebens feststellen, dass sich User Stories ändern, an Bedeutung gewinnen oder an Bedeutung verlieren oder vollständig gelöscht werden können. Häufiges Loslassen, Feedback einholen und einschätzen, was Priorität hat, wird dieses Verhalten beeinflussen.
• Schreiben Sie Geschichten nicht isoliert. Binden Sie Ihr Team, Ihre Stakeholder und sogar Ihre Kunden ein. Storys können während der Laufzeit eines Projekts jederzeit aktualisiert werden, sollten jedoch nicht geändert werden, sobald die Entwicklungsarbeit an ihnen begonnen hat.
• Einige Ihrer Geschichten können als „Epen“ betrachtet werden. Dies sind große Geschichten, die viel abdecken und die näher am Zeitpunkt der Lieferung in kleinere Geschichten unterteilt werden.
• Erwägen Sie die Verwendung des INVEST-Modells, einer Checkliste zur Validierung der Qualität einer guten User Story.
• Jeder kann dem Backlog eine Story hinzufügen. Es sollte ganz unten oder auf einem speziell angelegten „Parkplatz“ platziert werden. Diese hinzugefügte Geschichte dient als Aufforderung, mit dem Team und dem Unternehmen zu diskutieren. Wenn das Unternehmen und das Team dies unterstützen, kann es dann geschätzt und priorisiert werden
• Sie können auch die Teile des Systems berücksichtigen, die am riskantesten sind. Wenn Sie eine User Story oder ein Feature haben, das komplex, neu oder technisch unbekannt ist, priorisieren Sie diese ganz oben in Ihrem Backlog. Auf diese Weise versuchen Sie nicht, die herausfordernden und kritischen Teile Ihres Produkts nur Wochen vor Ihrer ersten Veröffentlichung zu liefern.

Sobald Sie ein Backlog haben, das Ihre Anforderungen erfüllt, können Sie die darin enthaltenen Storys schätzen, sie nach Priorität ordnen und einen Release-Plan erstellen.

Schätzung und Priorisierung auf hoher Ebene

High-Level-Schätzung ist der Prozess der Größenbestimmung Ihres Rückstands. Wie „groß“ ist das Projekt und welchen Wert liefert es? Priorisierung ist der Prozess der Entscheidung, welche Geschichten für Sie am wichtigsten sind, die Realisierbarkeit des Produkts und die Interessen Ihrer Kunden. Wir möchten die Artikel mit dem höchsten Wert so früh wie möglich liefern, um dem Unternehmen den größten Nutzen zu bieten, Feedback vom Kunden zu erhalten und uns nicht um Kleinigkeiten zu kümmern. Die Ausgabe ist ein geordneter Rückstand, der nach Priorität geordnet und in angemessener Größe ist.

• Geschichten an der Spitze gelten als die wertvollsten. Wir wollen die wertvollsten Artikel so früh wie möglich liefern.
• Es gibt viele Techniken zur Dimensionierung und Schätzung, aber an dieser Stelle möchten Sie nur ein gutes ungefähres Gefühl für die Größe einer Geschichte bekommen.
  • Verwenden Sie T-Shirt-Größen, relative Größen, ideale Tage oder Story Points.
• Sie werden zu diesem Zeitpunkt auch nicht alle verfügbaren Informationen haben, und das ist in Ordnung. Lauf einfach damit.
• Beziehen Sie Ihre Interessengruppen oder Ihren Produktmanager, falls Sie einen haben, und das Team, das die Arbeit erledigen wird, mit ein.
• Wir möchten, dass diejenigen, die das Werk entwerfen, entwickeln und testen, es dimensionieren, denn die Experten sind die besten Personen für die Schätzung.
• Das Team kann damit beginnen, Geschichten in kleinere Teile zu zerlegen. Wenn dies passiert, schreiben Sie Geschichten, die granularer, aber diskreter sind.
• Das Team kann auch damit beginnen, einige Geschichten zu bewerten, da natürlich einige Dinge vor anderen geliefert werden müssen, um die Technologie oder eine bestimmte Benutzerreise zu unterstützen.
• Zwischen Ihnen und dem Team können Sie auch anfangen, Lücken im Rückstand zu finden, die gefüllt werden müssen. Füllen Sie diese Lücken einfach mit neuen Geschichten und schätzen und priorisieren Sie sie entsprechend.
• Die Priorisierung erfolgt am einfachsten mit einer MoSCoW-Analyse. MoSCoW ist eine einfache Technik, die Ihnen bei der Entscheidung hilft, welche Geschichten „must have“ sind, damit Ihr Produkt erfolgreich ist.
• Sie können einen Priorisierungsdurchgang durchführen, bevor die Schätzung beginnt. Die Dimensionierung bestimmter Elemente kann jedoch auch eine Entscheidung über die Priorität und den tatsächlichen Geschäftswert bestimmen. Spielen Sie also Schätzung und Priorisierung gegeneinander aus, aber streiten Sie sich nicht darum!
• Keine zwei Geschichten können so wichtig sein wie die andere. Die Geschichte auf Rang 1 ist wichtiger oder wertvoller als die Geschichte auf Rang 2.
• Eine großartige Möglichkeit, die Bedeutung oder den Wert einer Geschichte zu demonstrieren, besteht darin, ihr einen Geldwert hinzuzufügen. Wenn zum Beispiel davon ausgegangen wird, dass Geschichte A 5000 $ an zusätzlichen Einnahmen bringt und Geschichte B 100 $ anziehen könnte, dann ist Geschichte A wertvoller. Ebenso ist Geschichte C wertvoller, wenn Geschichte C das Unternehmen mehr rettet als Geschichte D.
• Sobald Sie Ihren Rückstand bemessen haben, bleibt Ihnen eine Zahl übrig. When we come to release planning, that number will help us understand how much can be delivered by our team within a given timeframe.

Remember that you don't need to know all your user stories up front. Also, remember that it's not necessary to deliver all of your stories before a customer sees your product. You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

Release Planning

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. The moral of the story is:

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don't do it yet. Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

Adaptive Planning

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

Story Creation

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

Sprinting

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• Das Arbeiten in kleinen Schritten hat einen großen Vorteil. Das bedeutet, dass Sie sich nur auf die unmittelbare Zukunft der Bereitstellung konzentrieren und mit neuem Input, Feedback und Lernen innerhalb eines kurzen iterativen Zyklus auf Änderungen reagieren können.
• Führen Sie zu Beginn eines Releases einen Sprint 0 durch. Dadurch können sich das Team, das Unternehmen und Ihr Projekt-Release vorbereiten und die Denkweise für eine erfolgreiche Bereitstellung festlegen. Zeichnen Sie das grundlegende technische Framework und die Architektur, die die Grundlage für die Veröffentlichung unterstützen. Richten Sie Umgebungen, Konten und Tools ein. Führen Sie Spikes durch, um schwierige oder unbekannte Probleme zu verstehen. Arbeiten Sie Ihre User Stories in Vorbereitung auf Sprint 1 aus. Bei Sprint 0 geht es darum, sich vorzubereiten.
• Verfeinern Sie während einer Veröffentlichung das Backlog weiter. Wenn Sie mehr verstehen oder etwas Neues lernen, können sich Ihre Prioritäten ändern, neue Anforderungen können sich entwickeln und was Sie zuvor für eine großartige Funktion gehalten haben, kann vollständig entfernt werden.
• Beginnen Sie keine Arbeit, die keine Chance hat, innerhalb eines Sprints abgeschlossen zu werden. Wenn dies nicht möglich ist, zerlegen Sie es in kleinere Stücke. Und beginnen Sie keine neue Arbeit, wenn die zuvor begonnene Arbeit noch nicht abgeschlossen ist. Sie schaffen keinen Wert, indem Sie viele Dinge beginnen, die nicht als abgeschlossen betrachtet werden können. Vermeiden Sie außerdem Kontextwechsel. Dies ist die Aktivität, eine Aufgabe zu beginnen, gestört zu werden, eine andere zu beginnen und, was am problematischsten ist, auch nicht zu Ende zu führen.
• Begrenzen Sie die Menge an Arbeit, die das Team gleichzeitig bearbeitet. Wenn Sie beispielsweise drei Entwickler und einen Tester haben, können Sie den Entwicklern und dem Tester ein WIP-Limit auferlegen.
• Fügen Sie einem Sprint niemals mehr Arbeit hinzu, nachdem er geplant wurde. Stoppe niemals einen Sprint mittendrin. Ausnahmen hiervon sind:
  • Wenn Sie schneller als erwartet abgeschnitten haben, ziehen Sie in Betracht, die nächste Story von oben aus dem Backlog zu nehmen, solange sie angemessen vorbereitet ist.
  • Wenn der Sprint so schlecht läuft, dass er nicht abgeschlossen wird. Dies geschieht normalerweise nur, wenn eine Katastrophe irgendeiner Beschreibung stattgefunden hat.
  • Wenn das Sprint-Ziel aufgrund sich unmittelbar ändernder Anforderungen des Unternehmens nicht mehr unterstützt werden kann.
• Wenn Sie einen Sprint abbrechen, tun Sie dies anmutig, nehmen Sie sich Zeit, um sich neu zu konzentrieren, und starten Sie einen neuen Sprint wie jeden anderen.
• Ziehen Sie gegen Ende eines Releases einen finalen Release-Sprint in Betracht. Es werden keine neuen Funktionen geschrieben, einige Fehler können behoben werden, und es können Vorbereitungen getroffen werden, um tatsächlich eine neue Version Ihres Produkts für Ihre Kunden freizugeben. Das heißt nicht, dass Sie in der Zwischenzeit keine inkrementellen Kundenversionen erstellen können – es ist nur so, dass dies ein kontrollierter, gemessener und nachhaltiger Veröffentlichungsmechanismus ist.
• Am Ende einer Version könnten Sie einen einwöchigen Sprint in Betracht ziehen. In diesem Sprint arbeiten Sie möglicherweise mit dem Team zusammen, um einige neue Ideen aufzuschlüsseln oder eine neue Technologie zu entwickeln. Dies sind großartige Tools, die dem Unternehmen zugute kommen und dem Team Raum zum Nachdenken und zur Kreativität geben. Es ist nicht zum Herumalbern gedacht und wird trotzdem Wert schaffen. Genauso braucht jeder eine Pause. Wenn Sie zu dieser Zeit Urlaub machen, können Sie Ihre Trittfrequenz und Geschwindigkeit in guter Form halten, wenn Sie mitten in der Veröffentlichung sind.

Erledigt definieren

Es ist sehr wichtig zu definieren, was „erledigt“ wirklich bedeutet. Es gibt viele Versionen von „fertig“ im Leben Ihres Projekts – was es bedeutet, mit einer Geschichte, einer Veröffentlichung oder einem ganzen Projekt „fertig“ zu sein. Es läuft alles darauf hinaus, was Sie, Ihr Team und Ihr Unternehmen als vollständig bis zum richtigen Qualitätsniveau betrachten, um die Versandbereitschaft zu gewährleisten.

Für Ihr Team ist die Definition einer „Fertig“-Story etwa so, dass der gesamte Code vollständig ist, Peer-Review hat, die definierten Akzeptanzkriterien erfüllt, Einheiten getestet, UAT-fähig ist und in Ihr Code-Repository übertragen wird. Um die Weitergabe einer Geschichte vom Designer zum Entwickler zum Tester zu ermöglichen, müssen Definitionen von „erledigt“ von der nächsten Person in der Kette akzeptiert werden. Ihr Product Owner wird Erwartungen haben, was dies für ihn bedeutet, um das Produktinkrement für Ihre Kunden freizugeben. In jedem Fall muss sich jeder darüber im Klaren sein, was „erledigt“ bedeutet, und sich verantwortungsvoll dafür einsetzen, dass seine Bedeutung erfüllt wird. Definieren Sie Ihre Definition von „erledigt“, kommunizieren Sie sie, einigen Sie sich darauf und entwickeln Sie sie weiter. Fertig erledigt.

Kontinuierliche Messung

Wenn Sie es nicht messen können, können Sie es nicht verwalten. Gleiches gilt für Verbesserungen. Die Notwendigkeit, empirische Daten in einem agilen Projekt zu sammeln, ist fast so wichtig wie das Blut durch die Adern fließt! Woher wissen Sie, was verwaltet, korrigiert oder verbessert werden muss, wenn keine Daten vorhanden sind? Nun, einfach gesagt, Sie verlassen sich auf Ihr Bauchgefühl und unbegründete Vermutungen, die bei genauerer Prüfung ziemlich schnell auseinanderfallen. Und je nachdem, wer die Prüfung durchführt, kann dies ein ziemlich unbequemer Ort sein. Stellen Sie also von Beginn Ihres Projekts an sicher, dass Sie wissen, wie Sie Fortschritte demonstrieren und an welchen Maßstäben andere Ihren Erfolg sehen werden.

Glücklicherweise ist Agile vollgepackt mit nützlichen Tools und Techniken. Gehen Sie als Erstes zurück zum Agilen Manifest, geben Sie die folgenden Wörter in Ihr bevorzugtes Textverarbeitungsprogramm ein, vergrößern Sie sie auf 96 pt, drucken Sie sie aus und bringen Sie sie für alle sichtbar an der Wand an:

Ihre größte nachweisbare Stärke bei der Bereitstellung von Software besteht darin, sie den Menschen zu zeigen, die arbeiten und tun, was sie tun soll. Dies wird nicht nur Ihre Kunden glücklich machen, sondern auch Ihrem Team großen Respekt einbringen und die Räder für eine größere Akzeptanz im Unternehmen schmieren.

Hier sind einige andere Werkzeuge:

• Das tägliche Standup: Es gibt ein paar Variationen dieser Zeremonie, aber das Wesentliche ist, dass alle Teammitglieder von Angesicht zu Angesicht miteinander sprechen: Halten Sie es kurz, bleiben Sie konzentriert und bleiben Sie locker. Wenn etwas ausführlich diskutiert werden muss, parken Sie es für ein längeres Gespräch zwischen denjenigen, die nach dem Aufstehen benötigt werden. Wenn Hindernisse auftreten, schreiben Sie sie wie eine Geschichte auf, fügen Sie sie Ihrem Backlog hinzu und beheben Sie sie so schnell wie möglich. Alles, was Ihr Team behindert, verlangsamt seinen Fortschritt und zeigt sich in reduzierter Geschwindigkeit und Software, die nicht den Erwartungen entspricht.
• Geschwindigkeit: Ist ein historisches Werkzeug. Es ist ein bisschen wie diese finanziellen Warnungen, die sagen, dass vergangene Performance keine Garantie für zukünftige Performance ist. Aber im Fall von Agile hoffen wir, eine weitgehend reibungslose Teamgeschwindigkeit zu erreichen. Es ist die Geschwindigkeit, die es uns ermöglicht, die zukünftige Leistung und das Vertrauen in unsere Pläne zu prognostizieren. Es kann Einflüsse außerhalb Ihrer Kontrolle geben, die die Anzahl der für einen bestimmten Sprint ausgegebenen Story Points verringern können. In diesem Fall können Sie sich wahrscheinlich erholen. Verwenden Sie Geschwindigkeit niemals als Stock, um Ihr Team zu schlagen; es wird dir keinen Gefallen einbringen. Eine Sache ist sicher, dass die Geschwindigkeit in den ersten 2–4 Sprints unregelmäßig sein wird. Irgendwann in diesem Zeitrahmen sollten Sie jedoch anfangen, Konsistenz und Stabilität zu sehen. Wenn Ihre Geschwindigkeit von einem Extrem zum anderen schwankt, haben Sie ein Problem, das Sie mit Ihrem Team lösen müssen.
• Das Burndown-Diagramm: Nun, diese Fortschrittsmessung ist heikel. Aus diesem Grund habe ich keinen Link angegeben, um mehr zu erfahren – Sie müssen Ihre eigenen Nachforschungen anstellen und als Team und Unternehmen zustimmen, was für Sie arbeitet. Der Grund, warum es dornig ist? Nun, nicht eine Ressource da draußen erzählt die gleiche Geschichte! Eine Sache, die vereinbart wurde, ist, dass es innerhalb eines Sprints oder einer Version zeigt, wie Sie sich in Bezug auf Ihre Timebox verhalten. Bei täglicher Wartung zeigt es, ob Sie auf dem richtigen Weg sind oder abweichen. Einige Teams verwenden es, um darzustellen, wie viel Wert noch geschaffen werden muss, andere verwenden es, um zu zeigen, wie viel Arbeit noch zu erledigen ist. Ersteres ist eine Feier des Erfolgs und der Wertschöpfung, letzteres ist weniger inspirierend und motivierend.
• Das Burnup-Diagramm: Wenn Sie Arbeitsabschlussquoten anzeigen müssen, verwenden Sie dafür das Burndown-Diagramm. Mit dem Burnup-Diagramm können Sie jedoch zeigen, wie viel Wert geschaffen wurde und wie viel mehr Wert Sie bis zum Ende des Sprints schaffen möchten. Ein viel motivierenderes Werkzeug für ein Team, um dem Unternehmen zu zeigen, was getan wurde (oder wenig, wenn die Dinge nicht so gut laufen …) und was sie noch im Auge haben. Verwenden Sie in jedem Fall die Diagramme, um zu erkennen, wo der Fortschritt nicht wie erwartet verläuft, und suchen Sie nach Mustern oder Abweichungen, um diese schnellstmöglich zu beheben, um das zugrunde liegende Problem zu beheben. Aktualisieren Sie sie täglich für Sprints und einmal am Ende eines Sprints für Release-Versions-Charts.
• Aufgabentafeln: Dies sind großartige visuelle Strahler, um die Wertschöpfung zu demonstrieren. Wenn sie täglich oder zu einem beliebigen Zeitpunkt des Tages aktualisiert werden, zeigen sie sofort den Fortschritt an. In Kombination mit Kanban sind sie auch großartige Tools, um den Fluss und Blockaden im System zu visualisieren. Wenn Sie sehen, dass viele Entwicklungen abgeschlossen wurden, aber das Testen nicht so produktiv ist, können Sie das Problem sehen und angemessen und schnell reagieren.

Andere zu berücksichtigende Tools sind Agile Earned Value, Zykluszeit und kumulative Flussdiagramme (CFDs).

Halten Sie diese Maße, Diagramme und andere Tools sichtbar, vorzugsweise laut und stolz an einer Wand, damit alle sie sehen können. Das Team, Stakeholder und andere interessierte Parteien können sofort den Status eines Projekts einsehen. Es ist transparent und dient als wertvolles Kommunikationsinstrument. Wenn Sie diese Artefakte nicht an eine Wand hängen können, verwenden Sie gemeinsam nutzbare und kollaborative Tools und stellen Sie sicher, dass diejenigen, die darauf zugreifen möchten, sie haben.

Ständige Verbesserung

Versuchen Sie während Ihres gesamten agilen Lebens herauszufinden und zu lernen, wo Verbesserungen vorgenommen werden können. Lektionen werden nicht erfasst und am Ende eines Projekts gelernt. Es ist wie die Fahrprüfung zu bestehen und versuchsweise die erste Fahrt ohne Fahrlehrer zu unternehmen. Sie werden wissen, was funktioniert und was Sie tun sollen, aber im Laufe der Zeit werden Sie Ihre fahrerischen Fähigkeiten und Fähigkeiten anpassen und neue Techniken erlernen. Sie werden sogar schlechte Angewohnheiten annehmen. Suchen Sie nach ihnen, verstehen Sie sie und finden Sie Wege zur Verbesserung.

Es gibt viele Möglichkeiten, herauszufinden, was nicht funktioniert, und Abhilfe zu schaffen. Der eingebaute Ansatz dazu in Agile ist die Retrospektive. Dies ist das primäre Werkzeug zur Reflexion und Anpassung. Nehmen Sie sich am Ende jedes Sprints Zeit mit dem Team, um zu verbessern, wie die Arbeit erledigt wird, wie Qualität geliefert wird, wie die Effizienz maximiert, wie Verschwendung minimiert und die Kapazität gesteigert werden kann. Wenn Sie Verbesserungsmaßnahmen identifizieren, sollten Sie nicht versucht sein, alle Ihre Probleme sofort zu beheben. Identifizieren Sie diejenigen, die die größte Wirkung haben und im nächsten Sprint implementiert werden können. Messen und beobachten. Wenn es die gewünschte Wirkung hatte, schließen Sie es ab, schreiben Sie es in Ihre Arbeitsweise und Definitionen von erledigt. Wenn es nicht funktioniert, denken Sie noch einmal darüber nach. Alle gewonnenen Erkenntnisse, die nicht in den bevorstehenden Sprint aufgenommen werden, können geparkt und für den nächsten Sprint priorisiert werden.

Passen Sie den Prozess an. Entfernen Sie alles, was nicht funktioniert. Beseitigen Sie Hindernisse. Ihre Reife als agiles Team wird keine Grenzen kennen, wenn Sie es zulassen.

Jenseits von agilem Projektmanagement

Es ist wichtig zu wissen, was passiert, nachdem das Projekt geliefert wurde. Support und Wartung sind der Schlüssel, um sicherzustellen, dass das Projekt, sobald es in den Händen des Kunden ist, leistungsfähig bleibt; Kundenfeedback kann in zukünftige Versionen einfließen; und Kundenanliegen angemessen behandelt werden. Ein Projekt ist ein einzigartiges, zeitlich begrenztes Unterfangen. Das gelieferte Produkt hat ein Leben nach der Auflösung des Projektteams. Stellen Sie sicher, dass Sie in der Lage sind, das Produkt zu unterstützen, sobald es live ist.

Agile Projekte koexistieren mit traditionelleren Ansätzen. Ausgleich der Anforderungen an Budgetkontrolle und Sichtbarkeit der Stakeholder mit den agilen Zielen Flexibilität und Reaktionsfähigkeit.

Ein Governance-Framework oder ein Agile-Governance-Modell wird in Verbindung mit agilen Standardprozessen wie Scrum verwendet. Sie arbeiten auf zwei Arten:

• Sie bieten einen Wrapper für ein agiles Projekt, indem sie die Prozesse verdeutlichen, die außerhalb von Entwicklungsiterationen (Sprints) auftreten. Dazu gehört die Bereitstellung klarer Kriterien für den erfolgreichen Abschluss der Projektinitiierung und die ordnungsgemäße Validierung der Entscheidungen und des Plans.
• Sie verlagern den Schwerpunkt auf bestimmte Teile des agilen Standardprozesses und heben bestimmte Prinzipien und Techniken hervor, die Governance erfordern oder Governance unterstützen.

In der sich ständig verändernden Welt von heute möchten Organisationen und Unternehmen einen flexibleren Ansatz für die Durchführung von Projekten verfolgen und agiler werden. Für Organisationen, die Projekte und Programme durchführen und in denen bereits formelle Projektmanagementprozesse existieren, ist die Formlosigkeit vieler agiler Ansätze jedoch entmutigend und wird manchmal als zu riskant empfunden. Diese projektorientierten Organisationen brauchen einen ausgereiften agilen Ansatz – Agilität innerhalb des Konzepts der Projektabwicklung – agiles Projektmanagement .

Lernen und wachsen Sie mit Ihrer Einführung von Agile. Tun Sie immer nur das, womit sich Ihr Team wohlfühlt, stellen Sie sicher, dass seine Stimme gehört wird, und handeln Sie nach seinen Wünschen. Ermutigen Sie Ihr Team, zum richtigen Zeitpunkt neue und wertvollere Techniken anzuwenden. Verhandeln Sie mit dem Unternehmen und ermutigen Sie es zu verstehen, was es bedeutet, eine agile Organisation zu sein.

Geniesse die Reise.