19 Eigenschaften, die Agile radikal anders machen als bisher

In einem früheren Beitrag habe ich festgestellt, dass ich in letzter Zeit ein wenig über die Einführung agiler Methoden in Organisationen nachgedacht habe, die nicht-agile Methoden wie PRINCE2 verwenden. Insbesondere habe ich festgestellt, dass:

Agile Arbeitsweisen unterscheiden sich radikal von den nicht-agilen Arbeitsweisen, die ihnen vorangegangen sind.

Das heißt, agile Methoden unterscheiden sich nicht nur ein bisschen von denen, die ihnen vorangegangen sind, sie unterscheiden sich grundlegend. Diese fundamentalen Unterschiede erfordern Anpassungen in den Unternehmensserviceprozessen (Finanzen, Governance, Beschaffung usw.), die es Lieferteams ermöglichen, Reibungsverluste zwischen Lieferteams und Unternehmensserviceteams zu vermeiden und gleichzeitig die Agilität aufrechtzuerhalten.

Was ist also radikal anders?

Im Folgenden sind einige Merkmale von Agile aufgeführt, die bedeuten, dass agile Teams unterschiedliche Anforderungen an die Unternehmensdienste stellen. Dies ist keine vollständige Liste, und ich begrüße weitere Beispiele. Mein Argument ist, dass die schiere Anzahl und Bandbreite der Unterschiede bedeutet, dass agile Teams als Benutzer von Unternehmensdiensten ganz andere Bedürfnisse haben:

1. In agilen Methoden ist eine Grundannahme verankert - dass die Bereitstellung am besten als Lernprozess betrachtet wird. Sie können nur lernen, was Sie erstellen, wie Sie es erstellen und wen Sie zum Erstellen benötigen, indem Sie versuchen, es zu erstellen und Teilen Sie Kunden / Benutzern regelmäßig mit, was Sie erstellt haben, um Feedback zu erhalten. Du lernst und änderst den Kurs, während du gehst.

Bei nicht agilen Methoden wird davon ausgegangen, dass Sie die meisten dieser Dinge herausfinden können, bevor Sie mit der Erstellung beginnen. Wenn Sie mit agilen Arbeitsweisen nicht vertraut sind, werden Sie frustriert sein, wenn agile Ihnen keine Sicherheit geben kann. Dies ist jedoch eine Folge neuartiger Liefertätigkeit - was die meisten Menschen tun, ob sie es realisieren oder nicht - und nicht agiler Arbeitsweisen.

Alles, was Sie tun, um diese Dinge herauszufinden, ohne etwas zu liefern, führt früher oder später zu Enttäuschungen.

2. Die Unsicherheit darüber, was durch wann und durch welche Größe und Form des Teams erreicht wird - was für neuartige Bereitstellungsarbeiten von Bedeutung ist - passt nicht gut zu detaillierten Business Case-Arbeiten, Prognosen der Belegschaft und anderen Vorplanungsprozessen, die diese Dinge voraussetzen kann im Voraus bekannt sein. Agile ist eine explorative Methode zum Umgang mit Unsicherheit.

3. Agile Teams können (und sollten) die Bereitstellung von Funktionen nicht bis zu einer Detailebene weiterleiten, die nicht bekannt ist. Ihre Roadmaps sollten, wenn sie überhaupt welche haben, notwendigerweise vage sein, da der Zeithorizont in der Ferne verschwindet. Dies kann für Stakeholder unangenehm sein, die daran gewöhnt sind, eine detaillierte Vorhersage darüber zu erhalten, was sie zu bestimmten Terminen erhalten werden. In einer vorab agilen Situation haben Stakeholder das, was ich als Kontrollillusion bezeichne - weil es ihnen ein warmes, verschwommenes Kontrollgefühl vermitteln kann - obwohl eine Roadmap für neuartige Arbeiten notwendigerweise eine Fiktion ist.

Nicht agile Arbeitsweisen erfordern häufig die Erstellung einer detaillierten Roadmap und eines Gantt-Diagramms, in denen festgehalten wird, was bis wann geliefert wird. Die Roadmap wird irgendwie in Stein gemeißelt. Übermäßig detaillierte Roadmaps wie diese verschlimmern diese Illusion der Kontrolle, da das Gefühl der Kontrolle dahinschmilzt, wenn sich herausstellt, dass die zugrunde liegenden Informationen in der Realität keine ausreichende Grundlage haben. In einer vorab agilen Welt besteht die übliche, aber fehlerhafte Reaktion der Stakeholder darin, die Zustellteams für das „Verstehen von Fehlern“ zu beschuldigen und sie zu verpflichten, die Roadmap noch weiter zu sperren. Das Problem liegt nicht in den Teams, sondern darin, dass die inhärente Unsicherheit der Zustellung nicht anerkannt und geeignete Methoden zur Bewältigung dieser Unsicherheit angewendet werden.

Agile Teams erkennen, dass eine detaillierte Roadmap unter unsicheren Bedingungen eine logische Unmöglichkeit darstellt. Einige Dinge können erkennbar sein; andere werden es nicht sein. Im Verlauf der Projekte machen agile Teams ihren Stakeholdern klar, was sie gelernt haben und worüber sie noch unsicher sind. Arbeit wird oft priorisiert, um die Unsicherheit zu verringern / das Lernen zu steigern. Beginnen Sie lieber mit einer spärlichen Roadmap und überarbeiten Sie sie regelmäßig, während Ihr Projekt voranschreitet. Je weniger Sie über bestimmte Teile Ihrer Reise wissen, desto weniger detailliert muss Ihre Karte sein.

4. Da die Bereitstellung ein Lernprozess ist, umfassen agile Methoden Veränderungen - das Warum, Was, Wie und Wer Ihrer Arbeit kann sich schnell ändern, wenn neue Erkenntnisse aufgedeckt werden. Nicht agile Ansätze verhindern häufig Änderungen oder gehen zumindest davon aus, dass Änderungen - d. H. Abweichungen von Ihren ursprünglichen Vorhersagen - selten oder langsam sind. Wechselbretter, die sich selten treffen und entscheiden, ob ein Wechsel zulässig ist, spiegeln diese Arbeitsweise wider. Es ist besser, die Entscheidungsfindung an Ihre Auslieferungsteams oder an diejenigen zu delegieren, die im gleichen Tempo wie Ihre Auslieferungsteams arbeiten. Wenn Sie sich dazu nicht in der Lage fühlen, stellen Sie zumindest sicher, dass Ihre Wechselkarten mit einer Geschwindigkeit arbeiten, die die Zustellungsarbeit nicht blockiert.

5. Agile Methoden liefern inkrementell und daher häufig - wir nennen dies Kleinserienlieferung. Nicht-agile Methoden liefern in Big-Bang-Releases (oder Big-Batch-Releases) und so selten. Corporate-Services-Prozesse, die für Big-Bang-Releases entwickelt wurden (die nur selten, aber mit erheblichen Änderungen verbunden sind), sind für Agile-Delivery-Releases (die mit kleinen, aber häufigen Änderungen verbunden sind) überproportional schwergewichtig.

6. Da agile Teams in kleinen Mengen liefern, müssen Kunden (oder Produktbesitzer) und Stakeholder in geringem Umfang häufig Input und Feedback geben. Mit jedem Schritt (oder noch häufiger) müssen sie wissen, worauf sie sich als nächstes konzentrieren sollten und wie das, was sie geliefert haben, die Bedürfnisse der Menschen erfüllt.

Lieferteams benötigen häufige und schnelle Entscheidungen, um effizient und effektiv zu sein. Bei der Lieferung großer Chargen wird Kunden- und Stakeholder-Feedback seltener benötigt - da Änderungen so weit wie möglich verhindert werden -, aber jedes Mal, wenn sie mehr Zeit in Anspruch nehmen. Dies kann zu mehreren Reibungspunkten führen: Zum Beispiel kann es sein, dass die unterschiedliche Einstellung zum Engagement nicht gut kommuniziert oder verstanden wird oder dass es Koordinationsprobleme gibt. Stakeholder können Entscheidungen auch auf eine für sie bequeme Weise zusammenfassen, die jedoch die Bereitstellungsarbeit blockiert oder verlangsamt (z. B. monatliche (oder sogar weniger häufige) Kontrollgremien).

7. Agile Teams setzen sich in der Regel aus der richtigen Mischung funktionsübergreifender Teammitglieder zusammen, um ein funktionierendes Produkt zu liefern. Die Zustellung obliegt dem Team. Bei der etablierten Arbeitsweise arbeiten mehrere separate Spezialistenteams, indem sie Dokumente und Zwischenergebnisse (z. B. Anforderungsspezifikationen oder nicht getestete Software) entlang einer Kette weiterleiten. Die Zustellungsverantwortung erstreckt sich über die gesamte Kette oder befindet sich in einer Ebene oberhalb der Kette, beispielsweise in einem Programmverwaltungsbüro, das einen Schritt von einer Lieferung entfernt ist.

8. Agile Projekte sind möglicherweise relativ klein und es gibt möglicherweise noch viele weitere. Diese Projekte beginnen oft mit kurzen Entdeckungs- und Alpha-Phasen. Die Arbeit an einem Projekt wird möglicherweise nach einer Entdeckung oder einem Alpha oder sogar während dieser Phasen angehalten. Dies bedeutet, dass es typischerweise viel mehr, aber kürzere, agile Projekte gibt. In einer voragilen Welt ist es üblicher, weniger, aber größere Arbeitsprogramme zu haben. Nicht agile Projektgenehmigungsprozesse werden in der Regel auf der Grundlage optimiert, dass dies der Fall ist.

Wenn Sie auf Agile umsteigen, kann eine Zunahme der Anzahl der ausgeführten Projekte, auch wenn sie einzeln kleiner sind, eine voraussichtliche zusätzliche Belastung für Portfolio-Teams, Programm-Management-Büros und Einzelpersonen in Finanz-, Handels- und HR-Teams bedeuten, die mit Bereitstellungsteams zusammenarbeiten. Diese Last wird so lange anhalten, bis diese Teams ihre Prozesse an die neue Art von Anforderungen anpassen, die an sie gestellt werden.

9. Wie oben erwähnt, beginnen agile Teams die Bereitstellung häufig mit einer kurzen Erkennungsphase, in der sie die Hauptnutzeranforderungen für einen Service untersuchen, Optionen für die Bereitstellung ausloten und im Allgemeinen ein Gefühl dafür bekommen, ob es sich lohnt, einen Service zu erstellen.

Die Idee einer Entdeckungsphase ist, dass das Team in jedem Schritt neues Lernen liefert. Gute agile Teams wissen, dass ihre Entdeckungsarbeit dazu führen kann, dass das Projekt nicht weiter voranschreitet. In der Tat ist es ein großer Gewinn für die Organisation, wenn das Projekt nach der Ermittlung gestoppt werden kann, da sie die Kosten für die Entwicklung eines nicht erfolgreichen Dienstes einspart.

In nicht agilen Teams geschieht das Nachdenken, bevor die Zustellung und Änderung so weit wie möglich verhindert wird. Es wird davon ausgegangen, dass die Zustellung nach dem Start bis zum Ende fortgesetzt wird. Dies ist teuer und peinlich, wenn später festgestellt wird, dass der Service nicht die erwarteten Ergebnisse liefert, wenn er mit der Realität in Kontakt kommt.

10. Agile Teams können sehr schnell auf- und abschwenken, insbesondere in Discovery und Alpha, wenn Sie nicht genau wissen, was Sie aufbauen möchten. Möglicherweise benötigen Sie mehr oder weniger Personen ohne vorherige Ankündigung. Nicht agile Methoden setzen voraus, dass Teamgröße und Zusammensetzung im Voraus erarbeitet werden können. Beschaffungsmethoden müssen daher nicht reagieren. Die Lieferung großer Chargen führt auch zu einer Beschaffung großer Chargen, was zeitaufwendig ist und häufig mehr Kontrolle und eine längere Liste von Genehmigenden erfordert, was die Lieferung verlangsamt.

11. Agile Teams arbeiten häufig eher auf Ergebnisse als auf Ergebnisse und Funktionen hin. Wenn Sie ein nicht agiler Projekt-Tracker sind, ist eine Anpassung Ihres Ansatzes erforderlich. Sie werden den Fortschritt nicht anhand der geplanten Ergebnisse und des geschätzten Aufwands verfolgen, sondern regelmäßig mit dem Zustellteam zusammenarbeiten, um zu vereinbaren, wie viel Geld Sie ausgeben möchten, um welche Ergebnisse zu erzielen. Sie werden wahrscheinlich auch feststellen, dass Stakeholder geschult werden müssen, um den Fortschritt anders zu überwachen.

12. Agile braucht Vertrauen und Eigenverantwortung, um arbeiten zu können. Diejenigen, die der Arbeit am nächsten sind, müssen Entscheidungen darüber treffen können, was gebaut werden soll und wie die Arbeit funktioniert. Teams kommunizieren sehr offen, was dieses Vertrauen stärken soll. Agile bringt auch eine Reihe von Artefakten und Besprechungen mit, wie das tägliche Aufstehen an der Teamwand und regelmäßige Shows, die die Offenheit erhöhen. Die Teams kommunizieren jeden Tag von Angesicht zu Angesicht und teilen ihre Arbeit untereinander und mit denen außerhalb des Teams, einschließlich der Interessengruppen und anderer Personen in Führungspositionen. Nicht agile Arbeitsweisen erfordern häufig die Kommunikation über Dokumente und Verträge. Dies schafft kein gegenseitiges Vertrauen. Außerdem sind diese Artefakte häufig nicht für diejenigen außerhalb des Projekts verfügbar.

13. Spontane Interaktion ist wichtig in agilen Situationen. Die Teams könnten zusammenscharen, um ein bestimmtes Feature zu liefern, und der beste Weg, dies zu tun, ist die Kollokation. Dies bedeutet nicht nur, dass sich das Team im selben Gebäude befindet - die Mitglieder sitzen auch zusammen. Wenn eine gemeinsame Suche nicht möglich ist, werden Tools benötigt, die die sofortige Interaktion unterstützen. Das Zusammensitzen funktioniert jedoch etwa doppelt so gut wie das Arbeiten per Fernzugriff, da häufig teaminterne Kommunikation erforderlich ist.

14. Informationsstrahler sind in Agile unverzichtbar. Diese Anzeigen (handschriftlich, gedruckt oder elektronisch) sind an einer prominenten Stelle in der Nähe des Teams angebracht, sodass alle für die Arbeit relevanten Informationen auf einen Blick sichtbar und nachvollziehbar sind. Dies ist auch Teil der Offenheit und Transparenz, die Agile bietet. Passanten können diese Informationen sowie das Team sehen. In etablierten Arbeitsweisen werden Informationen normalerweise innerhalb des Projektteams oder mit denen, die es leiten, aufbewahrt. Eine erhöhte Transparenz kann für einige unangenehm sein. In einigen Organisationen kann die Verwendung von Wänden als Teil des Teamarbeitsbereichs explizit verboten werden.

15. Hotdesking - bei dem Teams gemischt und vermischt werden und Einzelpersonen häufig alleine arbeiten - funktioniert nicht mit Agile, da davon ausgegangen wird, dass Sie nicht neben Ihren Teammitgliedern (oder in der Nähe Ihrer Teamwand) sitzen müssen ) effektiv sein. Agile Teams interagieren den größten Teil des Tages und müssen nah beieinander sein, ebenso wie die Informationsstrahler, die ihre Arbeit verwalten. Agile Teams haben unterschiedliche Arbeitsweisen und daher unterschiedliche Raumbedürfnisse - es kann schwierig sein, in einem ruhigen, offenen Raum zu arbeiten - sowohl für das Team als auch für die anderen Teams im Raum, da agile Teams den ganzen Tag miteinander und miteinander sprechen Meetings in ihrem Teamraum haben müssen.

16. Führungskräfte müssen sich in agilen Meetings wie der Show und dem Tell wohlfühlen, was bedeutet, an den Ort zu gehen, an dem die Arbeit erledigt wird. Ein direkter Einblick in diese Arbeit ist der beste Weg, um zu verstehen, was das Team tut, und dieser proaktive Ansatz unterscheidet sich stark von der nicht agilen Fortschrittsberichterstattung (unter Verwendung von Dokumenten), an die Stakeholder gewöhnt sind, wenn das Team häufig nicht anwesend ist. Mit einem Bericht, der von einem Projektmanagementbüro erstellt wurde, ist es einfacher, den tatsächlichen Status der Lieferarbeit zu verbergen, als wenn der Stakeholder die Arbeit sehen und das Lieferteam direkt befragen kann.

17. In Agile ist Governance integriert. Agile Teams berichten mit Ansätzen wie dem Show and Tell, A3-Berichten, Informationsradiatoren und Team-Dashboards für Governance. An den Ort zu gehen, an dem die Arbeit erledigt wird, z. B. an einem Show & Tell teilzunehmen, ist die beste Möglichkeit für die Stakeholder, sich zu vergewissern, dass das Zustellungsrisiko effektiv gemanagt wird.

Die nicht agilen Projektverfolgungsmethoden konzentrieren sich auf Berichte, in denen die geschätzte Anzahl der Features, die die Teams vor Beginn der Bereitstellungsarbeiten angekündigt haben, mit den tatsächlichen Features verglichen werden. Dies ist kein geeigneter Ansatz für neuartige Bereitstellungsarbeiten, bei denen nicht im Voraus bekannt ist, welche Funktionen geliefert werden und wie lange dies dauern wird.

18. Große, nicht agile Programmteams enthalten häufig Rollen, die Sie in einem agilen Team nicht sehen würden - Finanzverfolger, Beschaffungsspezialisten, HR-Assistenten und administrative Unterstützungsrollen. Diese werden benötigt, um die hohe Governance zu unterstützen, die für nicht agile Programme erforderlich ist.

In einer agilen Arbeitsweise ist ein Teil dieser Arbeit noch erforderlich - ein gutes Finanz- und Beschaffungsmanagement und eine gute Personalentwicklung sind in jedem Lieferumfeld erforderlich. Aber in einer agilen Welt wären diese Leute nah dran, aber nicht im Team.

19. Agile verfügt über ein integriertes Risikomanagement. Der effektivste Risikomanagementansatz für neuartige Arbeiten besteht darin, einen explorativen Ansatz für die Erbringung von Leistungen zu verfolgen, indem die Leistungen in kleinen Schritten erbracht werden und Anpassungen auf der Grundlage neuer Erkenntnisse vorgenommen werden. Wie bereits erwähnt, priorisieren agile Teams häufig Arbeiten, die die Unsicherheit verringern. Die schrittweise Zustellung ist eine Bestätigung, dass Sie zu Beginn der Arbeit am wenigsten über die Arbeit Bescheid wissen.

Was bedeutet das alles?

Wie bereits in meinem früheren Beitrag zu Agile erwähnt, können die unterschiedlichen Anforderungen von agilen Bereitstellungsteams und die für nicht agile Arbeitsweisen optimierten Dienste von Unternehmensserviceteams zu Schmerzen führen, wenn Agile eingeführt wird . Dies ist nicht jedermanns Schuld, es liegt lediglich daran, dass die Anforderungen von agilen Teams und Unternehmensdiensten, die für unterschiedliche Anforderungen optimiert wurden, nicht übereinstimmen.

Organisationen haben 3 Lösungen dafür:

  1. Nehmen Sie den Schmerz in Kauf, während Sie sich darüber im Klaren sind, dass dies schlimmer wird, wenn Ihre Organisation agiler agiert.
  2. Fügen Sie Brückenbauer hinzu, die sowohl die agile als auch die nicht-agile Welt als Adapter zwischen den beiden Welten verstehen können. Dies ist teuer, und die Kosten steigen, wenn Ihre Organisation flexiblere Bereitstellungen durchführt.
  3. Richten Sie Unternehmensdienste und agile Bereitstellung enger aus, indem Sie alle Beteiligten zusammenbringen, um angepasste Prozesse basierend auf den Benutzeranforderungen der agilen Bereitstellungsteams und der Organisation gemeinsam zu gestalten. Durchlaufen Sie diese Prozesse, wenn Sie mehr über die Funktionsweise von Agile in Ihrer Organisation erfahren.

Viel Glück!

-

Vielen Dank an Beck Thompson für die Unterstützung beim Entwerfen von Inhalten für diesen Artikel.