Archiv der Kategorie: Release Planung

Komplexität von Projekten beurteilen

Ist ihr Projekt zu spät dran? Dann haben Sie wohl ein Versprechen gemacht, dass Sie nicht halten konnten.

Fixe Kosten bei fixer Qualität, fixem Umfang und fixem Termin kann funktionieren, wenn das Projekt oder Produkt einfach genug ist. Leider machen wir es uns oft zu einfach: Wir scheren Projekte unterschiedlicher Komplexität über einen Kamm. Nach Schema F machen wir eine Analyse, wägen Optionen ab, entscheiden uns für die passendste Lösung und setzen sie dann um.

Dave Snowden liefert mit dem Cynefin Framework ein Modell, mit dem man über die Einordnung von Projekten differenziert nachdenken kann. Es kennt folgende Bereiche:

path828Einfach: Die Milch kocht über? Ich schalte den Herd aus und nehme den Topf von der heißen Platte. Über einfache Probleme muss man nicht lange nachdenken. Man erkennt das Problem, beurteilt es und reagiert. Es gibt in der Regel nur eine beste Lösung, die sogenannte Best Practice.

Kompliziert: Befindet man sich in einem komplizierten System, braucht man einen Experten. Springt mein Auto nicht an, lasse ich den Kfz-Mechaniker anrollen. Der gelangt mit oben genanntem Schema zum Erfolg: Er analysiert das Problem, wählt die passendste Lösung aus und setzt sie um. Schon hier gibt es keine Best Practice mehr, sondern nur noch Good Practices, Optionen die jeweils Vor- und Nachteile haben.

Komplex: Leider starten gerade viele große und innovative Softwareneuentwicklungs-Projekte in einem komplexen System. Es ist unvorhersehbar und instabil. Es gibt keinen Experten, der mit einer einfachen Analyse zum Erfolg kommt. Bewegt man sich in komplexer Umgebung, muss man Dinge ausprobieren, Experimente machen.

Chaotisch: Die Cynefin-Beispiele für den chaotischen Bereich sind bürgerkriegsähnliche Zustände oder Natur-Katastrophen. Erfolgreiches Vorgehen besteht in diesen Situationen im Stillen der Blutung durch klare Führung, also z.B. Ausgangssperren oder großflächige Evakuationen.

Selbstzufriedenheit: Manchmal wägt man sich im einfachen Bereich, in dem man alles unter Kontrolle hat und dann fliegt einem das System um die Ohren. Die Fukushima-Katastrophe wird hier als Beispiel genannt.

Unklarheit: Wenn man nicht weiß in welchem der Bereiche man ist, läuft man Gefahr die falsche Vorgehensweise zu wählen.

Die folgende Übung hilft, die Diskussion zu eröffnen, in welchen Systemen man sich bewegt. Ich führe sie mit meinen Kunden z.B. bei der Vorstellung von agilen Frameworks durch.

Als Basis für die Übung dient die Stacey Landscape Matrix, welche die vier Bereiche einfach, kompliziert, komplex und chaotisch anhand von zwei Achsen aufteilt, wie in der Abbildung gezeigt.

stacey

Die X-Achse beschreibt den Grad der Unsicherheit bei der Lösung, also z.B. inwieweit technische Herausforderungen bestehen, die so noch nie gelöst wurden. Die Y-Achse beschreibt den Grad der Uneinigkeit im Projekt darüber was umgesetzt werden soll. Je mehr Stakeholder und je größer die Meinungsverschiedenheiten, umso weiter verschiebt sich das Projekt nach oben.

Nun versucht man (z.B. in Kleingruppenarbeit) die laufenden und anstehenden Projekte oder Produkt-Entwicklungsvorhaben auf der Matrix zu verorten. Anschließend diskutiert man das Ergebnis. Im Bild habe ich vier Beispiele aufgezeigt.

Projekt IO könnte z.B. der Bau einer Elb-Philharmonie sein: Was am Ende herauskommen soll ist relativ klar, aber die bautechnischen Herausforderungen sind völlig neu. Landet das Projekt wie abgebildet im komplexen (roten) Bereich sind also keine genauen Voraussagen möglich, solange bis die Herausforderungen durch safe-to-fail Experimente gemeistert sind und der Rest des Projekts dann nur noch kompliziert ist.

Projekt Babylon ist von der Umsetzung und Technologie-Seite keine große Herausforderung, aber es gibt so viele Meinungsverschiedenheiten, dass diese soziale Komponente das ganze Projekt in den komplexen Bereich verschiebt. Auch hier sollte man nicht einfach durch-implementieren, sondern durch Prototypen Konsens über die gewünschte Art der Lösung herstellen.

Projekt OPUS („Ohne Plan und Sachverstand“) ist ein gigantisches Projekt mit immensen sozialen und technischen Herausforderungen. Es ist so unüberschaubar, dass es ans chaotische grenzt. Ehe man Millionen hinein versenkt, ist es wahrscheinlich besser das ganze in mehrere kleine Projekte zu zerschneiden bzw. sich auf einen kleinen Bestandteil zu fokussieren.

Manche Projekte sind gar nicht so kompliziert. Projekt 08-15 wurde schon tausendmal durchgeführt und birgt keine Überraschungen. Führt man hier aufwändig eine agile Vorgehensweise ein, schießt man wahrscheinlich mit Raketen auf Spatzen.

Die Diskussion ergibt oft, dass die Teilnehmer je nach Sichtweise die Projekte unterschiedlich einordnen. Das ist oft sehr lehrreich. Business Analysten unter- oder überschätzen technische Herausforderungen, Techniker unterschätzen Uneinigkeit und Unklarheit auf Anforderungsseite.

Wenn man regelmäßig vorab seine Projekte klassifiziert kann man nicht nur die richtige Vorgehensweise wählen, sondern auch versuchen die Projekte bewusst in bestimmte Bereiche zu verschieben. Z.B. könnte man im 08-15-Projekt eine neue Technologie ausprobieren, um das System zu erneuern oder auch um es für die gelangweilten Entwickler interessanter zu machen. Umgekehrt könnte man bei Projekten mit großen Herausforderungen auf Anforderungsseite darauf verzichten auch noch eine völlig unerprobte Technologie zu benutzen.

holger

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Synchronisation von Scrum Teams mit Boundary Stories (Teil1)

Bei der Skalierung von Scrum wird von der Literatur häufig empfohlen, ein großes Team, das an einem gemeinsamen Projekt arbeitet, in mehrere kleinere Teams aufzuspalten, die dann als Feature Teams unterwegs sind und über ein Scrum of Scrums koordiniert werden.
Leider lässt sich dieser Optimalfall nicht immer so einfach umsetzen. Es kann durchaus sein, dass die Komplexität eines Software-Produkts es den Entwicklungsteams sehr schwer macht, einzelne Features durch verschiedene Module bzw. Komponenten hindurch zu implementieren. In diesen Fällen macht es dann, wie zum Beispiel bei CoreMedia, mehr Sinn, dass Scrum Teams einzelne Komponenten weiterentwickeln.

Schwierig wird es dann, wenn die einzelnen Komponenten nicht unabhängig voneinander sind. In diesem Fall ist auch die Arbeit der einzelnen Teams nicht unabhängig voneinander. Da Scrum-Teams ihrer Arbeit über die User-Stories planen, kann es Abhängigkeiten zwischen den Stories einzelner Teams geben. Diese Abhängigkeiten können uni- oder bidirektional sein. Unidirektional bedeutet, dass ein Team an einer Story arbeitet, bzw. arbeiten muss, auf die ein anderes Team wartet. Bei der bidirektionalen Abhängigkeit zwischen Stories arbeitet ein Team A an einer Story, die von einem anderen Team B benötigt wird. Gleichzeitig benötigt Team A auch die Implementierung einer anderen Story von Team B.

So entsteht ein Geflecht von Abhängigkeiten zwischen den Stories unterschiedlicher Teams, welches die Releaseplanung für ein Gesamtprodukt beeinflusst. Gerade Ketten von Abhängigkeiten sind dabei interessant. Nehmen wir als Beispiel ein Team A, dass eine Funktion bauen soll, für die erst ein Team B eine API in seiner Komponente ändern muss. Wenn nun für die Story von Team B weitere Funktionalität von einem Team C benötigt wird, entsteht eine Kette von Abhängigkeiten. Diese Kette ist bei der übergeordneten Releaseplanung für das Produkt zu berücksichtigen, da Verzögerungen bei den einzelnen Stories von Team B und Team C dazu führen, dass sich entweder das Release verzögert, oder aber Features der Story von Team A nicht im Release des Gesamtprodukts enthalten sind.

Um schnell reagieren zu können, muss den Vertretern der jeweiligen Teams für das Scrum of Scrums die Abhängigkeiten zwischen den Stories der Teams bewusst sein. Die Verantwortung solche übergreifenden Stories zu koordinieren liegt letztlich bei der Gruppe der Product Owner bzw., wenn diese Rolle vorhanden ist, bei einem Chief Product Owner.
Es gibt also eine Reihe von Personen, die sich über diese Art von Stories verständigen müssen. Bei der Diskussion der betroffenen Teams untereinander (genauso wie für die Beschreibung in einem Blog-Beitrag) ist es extrem hilfreich, wenn sie sich von der Bezeichnung her von „normalen“ User-Stories unterscheiden lassen. Die Bezeichnung sollte

  • kurz, prägnant und damit einprägsam sein,
  • widerspiegeln, dass es sich um eine Klasse von User Stories handelt, und
  • noch nicht anderweitig belegt sein.

Als Lösung dafür bin ich auf den Gedanken gekommen, Stories, die einen Einfluss auf Stories anderer Teams haben oder von anderen beeinflusst werden, als Boundary Stories zu bezeichnen.
Der Begriff hat meines Erachtens nach alle Merkmale, die oben gefordert sind.

Das „Stories“ in Boundary Stories macht zunächst klar, dass es sich um eine Story im Sinne von Scrum handelt. „Boundary“ hat zwei Aspekte, die die Verwendung rechtfertigen; eine Boundary ist gleichzeitig eine Verbindung und Grenze.

Stories versprechen die Umsetzung einer vom Kunden gewünschten Funktionalität. Ist der Kunde direkt oder indirekt ein Team, das für eine andere Komponente zuständig ist, so stellt die Story die Verbindung zwischen den Teams dar.

Gleichzeitig ist es in Scrum den Teams überlassen, wie und mit welchen Mitteln, sie Stories umsetzen. Damit stellen Stories generell auch eine Grenze dar, nämlich die zwischen dem Implementierungsteam und dem Product Owner. Etwas weiter gefasst stellen sie damit eine Grenze zwischen den Teams dar.

Zusätzlich wurde der Begriff von mir bewusst in Anlehnung an den Begriff Boundary Object aus der Soziologie gewählt. Das Konzept der Boundary Objects wurde von Susan Leigh Star und James R. Griesemer 1989 publiziert:

„Boundary objects are both plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites. They are weakly structured in common use, and become strongly structured in individual-site use. They may be abstract or concrete. They have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable means of translation. The creation and management of boundary objects is key in developing and maintaining coherence across intersecting social worlds.“

Quelle: Star SL & Griesemer JR (1989). „Institutional Ecology, ‚Translations‘ and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39“. Social Studies of Science 19 (4): 387–420.

Sicherlich lässt sich das Konzept nicht eins zu eins in die Welt der Software-Entwicklung übertragen, es gibt aber einige Parallelen, die so groß sind, dass sie den Vergleich von User Stories mit Boundary Objekten zulassen.

Wie bereits erwähnt, sind bei CoreMedia einzelne Teams für bestimmte Komponenten zuständig, d.h. es gibt keine Feature Teams. Auch wenn sich die Teams in der Zusammensetzung ähneln und die Teammitglieder in der Regel einen ähnlichen Ausbildungshintergrund (meistens Softwareentwickler) haben, gibt es trotzdem in jedem Team eine leicht unterschiedliche (Team-) Kultur.
So haben die einzelnen Teams beispielsweise unterschiedliche Strategien zur Erledigung der täglichen Arbeit entwickelt. Einige Teams malen Burn-Down-Charts, andere Burn-Up-Charts und wiederum andere machen nichts dergleichen. Auch die Meeting Kultur ist ganz unterschiedlich geprägt. Einige haben spezielle Architektur-Meetings, andere nicht.
Eine besondere Ausprägung der unterschiedlichen Team-Kultur spiegelt sich in der Weise wieder, in der die einzelnen Teams auf Task-Karten die jeweiligen aktuellen Bearbeiter vermerken: Einige schreiben Kürzel an die Task-Karten an den Scrum Boards, andere wiederum verwenden dazu Magnete, die sie mit Bildern oder kleinen Lego-Figuren (bzw. „Lego-Avataren“) beklebt haben.
Auch beim Schätzen von Stories und Tasks werden teilweise unterschiedliche Techniken verwendet, so dass man durchaus von Unterschieden in den Teamkulturen sprechen kann.
Star und Griesemer sprechen davon, dass Boundary Objekte dazu dienen, die kulturellen Barrieren zu überwinden. In unserem Fall ist die Barriere zwar recht klein, trotzdem machen sich auch kleine Unterschiede schon bei Personalwechseln zwischen Teams bemerkbar. Es gibt demnach aus Sicht der Team-Kultur durchaus eine kleine Grenze zwischen den Teams.

Wichtiger noch mit Blick auf Barrieren ist die Tatsache, dass einzelne Teams Experten für bestimmte Komponenten sind. Dadurch arbeiten sie teilweise sogar mit unterschiedlichen Basistechnologien (etwa auch unterschiedlichen Programmiersprachen). Selbst wenn Entwickler aus anderen Teams mit den verwendeten Basistechnologien sowie den groben Architekturentscheidungen vertraut sind, werden sie in anderen Teams in der Regel bei der Architektur im Kleinen bzw. bei einzelnen Tasks wenig Überblick haben. Wenn sich Entwickler Taskboards anderer Teams ansehen, können sie daher in der Regel nicht bei jeder Task sofort erkennen, was genau damit gemeint ist. Das wird dadurch verstärkt, dass sich in den Teams teilweise unterschiedliche Standards etabliert haben, was das Formulieren von Task-Karten angeht. Dies macht es Personen von außerhalb des Teams zusätzlich schwerer, die Tasks zu verstehen.
Es gibt also zwischen den Teams Barrieren, die auf einem unterschiedlichen Vokabular (induziert durch die verwendeten Basistechnologien sowie den Formulierungsstandards von Tasks) und unterschiedlichen Normen bezüglich der Task-Karten basieren.

Viele Scrum Teams haben physikalische Task Boards, auf denen sie Story Karten aufkleben oder anpinnen. Aufgrund der physikalischen Story Karten passt auch die Aussage von Star und Griesemer, dass es sich bei Boundary Objekten um Objekte aus der physikalischen Welt handelt. Das ist für das Konzept von Boundary Stories allerdings nicht ausschlaggebend.

Insgesamt sind die Parallelen zwischen Boundary Stories und Boundary Objects nicht so abwegig, so dass die Begriffsähnlichkeit aus meiner Sicht legitim ist.

Boundary Stories fallen nicht vom Himmel; sie müssen in der Menge der User Stories in den Backlogs der einzelnen Product Owner gefunden und als solche markiert werden. Im einfachsten Fall passiert das in den Schätzklausuren und Sprintplanungen, in denen einzelne Teams überlegen müssen, ob eine Story bereits Ready ist, also alle Voraussetzungen für ihre Abarbeitung gegeben sind, oder nicht. Werden für die Umsetzung von Funktionalität erst Arbeiten von einem anderen Team benötigt, so ist die Story automatisch eine Boundary Story. Gleichzeitig muß der Product Owner die gewünschte Funktionalität über den Product Owner des anderen Teams anfordern. Die dazugehörige User-Story ist in dem anderen Team automatisch eine Boundary Story.

Schwieriger ist es mit Stories, die andere Teams eher ungeplant betreffen, etwa weil durch sie Funktionalität geändert wird. In diesem Fall müssen die Entwickler und der Product Owner gemeinsam überlegen, ob Stories andere Teams betreffen werden oder nicht. Die POs müssen dieses Thema ebenfalls diskutieren und entsprechende Stories als Boundary Stories markieren. Das wichtigste ist, dass in den Teams Bewusstsein für Boundary Stories geschaffen wird, damit die einzelnen Scrum Teams besser zusammenarbeiten und so Risiken in der übergeordneten Releaseplanung verringern.

Boundary Stories werden bei uns mit einem Look-ahead von 12 Wochen in den Backlogs der Product Owner markiert (also in der Regel 6 Sprints). Dazu wurde eigens eine neue Spalte in den Execl Standard-Vorlagen der Product Owner eingeführt.

In dem nächsten Blog Beitrag werden Holger und ich schildern, wie wir mit den Boundary-Stories bei CoreMedia umgehen und wie wir sie zur einfacheren Koordination visualisieren.