Scrum und Skalierbarkeit für Ihren Businessnutzen!

Disziplin ist gefragt

Scrum ist für die Software-Entwicklung gedacht. Auch unterliegt das Scrummodell strengen Regeln mit nach Ihrem Business orientierten agilen Gestaltungsmöglichkeiten. Weiter ist Scrum ein empirisches, prozesskontrollierendes Framework. Ken Schwaber und Jeff Sutherland definieren Scrum im „The Scrum Guide™“ als „Lightweight„, „Simple to understand“ und „Difficult to master„.  Meiner Praxiserfahrung nach bringt das Scrumframework mit seinen Rollen, Prozessen und agilen Modalitäten bei hoher Scrum-Disziplin Ihren gewünschten Mehrwert zu 100%. „Difficult to master“ bezieht sich auf die notwendige Disziplin, die empirische Überprüfung des Value und der Selbstorganisation der Teams. Wo Menschen arbeiten menschelt es in der Regel. In Scrum menschelt es deutlich mehr. Die Teams, der Scrum Master, der Product Owner sind sehr eng miteinander verbunden. Daher sind Disziplin und klare Kommunikation wichtige Erfolgsfaktoren.

In den letzten fünf Jahren läutete bei meinen Scrum-Projekten während Scrum Backlocks genau einmal ein Smartphone! Mac’s oder Laptops wurden vom Scrumteam üblicherweise genauso wenig ins Meeting mitgenommen wie Smartphones. Jedoch aber, der gute alte Stift und ein Notizbuch. Das Telefon läutete damals, weil der werdende Vater weder seine Frau noch sein Team enttäuschen wollte. Er hatte seinen Scrummaster um Erlaubnis gebeten, sein Mobile Device ausnahmsweise ON lassen zu dürfen. Tatsächlich schaffte der Teammember fast den gesamten Backlock bevor er zur Geburt seiner Tochter abddüste. Dieses Beispiel zeigt uns welcher Teamspirit in Scrumteams vorherrscht.Weicht man davon jedoch ab, wird ein Scrum rasch zu einem

Scrum-Prozess: Kobald Agile Expert & IT-Projects, 2016

ScrumBut – ein agiles irgendetwas, ohne messbare Metriken, Teamfriktionen und unklaren Rollen. Nur wenn Scrum stringent entlang der vorgegebenen Rollen, Prozessen und Regeln eingesetzt wird, kann dieses Entwicklungsmodell Ihren Wertstromfluss für Ihre Businessziele effizient beeinflussen. Tatsächlich macht ein statisches Verständnis dieser Rahmenbedingungen den Scrumprozess erst zu Ihrem Erfolgsweg für Ihren Businessnutzen.

Einer allein macht keinen Tanz

Der Begriff „Scrum“ wurde aus dem Rugbysport übernommen. Mit dem „angeordneten Gedränge“ ist ein spezieller Spielzug gemeint. Die beiden gegnerischen Mannschaften stehen in drei Reihen verkeilt ineinander und müssen versuchen den Ball für sich zu erobern. Dies gelingt nur, wenn die Teams bestimmten Ordnungen folgen. Ähnlich funktioniert Scrum in IT-Softwarpojekten. Nicht weniger wichtig ist das Commitment. Scrum lebt von Commitments. Den Unterschied zwischen Commitment und Involvement zeigt dieses kleine Rätsel: Question: In a bacon-and-egg breakfast, what’s the difference between the Chicken and the Pig? Answer: The Chicken is involved, but the Pig is committed!

Scrum BBC
Rugby Scrum: BBC News, 2016

Ein Teil Ihrer Unternehmensaktivitäten unterstützt mit IT-Projekten Ihre Wertschöpfungsaktivitäten. Die Entwicklung und Implementierung von Softwarelösungen, Applikationen, Funktionalitäten, Automatisierungen usf. soll entweder Ihre betrieblichen Wertschöpfungsketten positiv beeinflussen, oder Sie haben beispielsweise regulatorische Vorgaben und möchten daher ökonomisch effizient entwickeln.

Einer der wichtigsten Aspekte von Scrum ist die Ordnung. Ordnung ergibt sich durch Time Boxing, der Definition of Done (Fertig ist fertig!), dem Prinzip „Avoid Waste!“, Entscheidungen auf Basis des momentanen Ist-Stands oder passenden User Stories. Persönlich plädiere ich dafür, dass die User STories der Entwicklungsmethode des Entwicklungsteam angepasst werden. Wird beispielsweise die Methode Behaviour Driven Development angewandt, dann werden Szenarios benötigt.

Scrumen Sie schon Value Driven?

Wenn Sie zur Entscheidung kommen, dass das Scrum Modell für Ihre derzeitige Entwicklung im Unternehmen der erfolgsversprechende Ansatz ist, dann bedeutet diese Entscheidung eiserne Disziplin. Agiles Arbeiten mit dem Scrum Entwicklungs-Modell bedeutet keinesfalls Entwickeln auf Zuruf! Bei Einhaltung der Scrumprozesse (Product Backlog Flow Framework) ernten Sie jedenfalls rasch nutzbare Features als Früchte für Ihren Tagesbetrieb.

Meiner Meinung nach ist die Kommunikation der alles umfassende Trigger in der agilen – also in der menschenzentrierten – Arbeitsweise. Um den Kommunikationsmechanismus, wie wir ihn alle kennen (vgl. Bild), aber auch um Human Biases (z. B. yesterdays weather principle) auszuschalten, ist klare, zirkuläre Kommunikation im Team, zum Product Owner und zu den Stakeholdern erforderlich.

Es hat seinen guten Grund, warum zu kleinen Development Teams geraten wird. Mit zunehmender Größe von Scrum Teams steigt die Anzahl der Kommunikationspfade expotentiell an. Die Anzahl lässt sich leicht errechnen: n*(n-1)/2. „n“ steht für die Personenanzahl im Team. So hat ein Team mit 10 Personen 45 Kommunikationspfade. Das ist 4.5 mal so viel, wie ein Team mit 5 Personen. Kommunikationsaufwände sind teuer, fressen Zeit und sind daher unbedingt dem Projektaufwand zuzurechnen. Scrum rät daher zur Stringenz in der Kommunikation: Einhaltung der notwendigen Meetings, lightweight documentations (on demand, just in time) oder zu wenig Emailerei.

scotty-syndrom
Zuruf Mechanismus: Kobald Agile Expert & IT-Projects, 2016

Egal welche agile Herangehensweise Sie wählen, ein Prinzip ist allen gleich: Requirements werden dokumentiert, auf Ihren Business Value hin geschätzt und Sie priorisieren, ob eine Komponente entwickelt wird, oder nicht. Eine Anforderung ist immer Ihre Aussage über eine gewünschte Eigenschaft und Leistung eines zu entwickelnden Produkts. Und nur Sie können entscheiden, ob eine Komponente für Sie wichtig ist, oder weniger wichtig, oder nicht ganz so wichtig.

Backlog grooming und die drei Amigos des Product Owner

Jeff Patton der Chef Requirements Engineer des Online Auftritts zur Obama Wahl war, spricht von den drei Amigos des Product Owner. Diese Sichtweise habe ich mir angeeignet. Um tatsächlich den Backlog priorisieren und mit diesem Vorschlag zum Customer gehen zu können, benötigt er Unterstützung eines Testers, eines Entwicklers und des Business Analysten. Die irgendwo mit Sticky Notes bestückte und aufgepinnte Kano Analyse kann der gemeinsame Bezugspunkt sein. Hilfreich ist auch das so genannte Purpose Alignment Modell. Dieses spannt sich über die Achsen „Erfolgskritisch“ und „Marktdifferenzierung“ auf. Je nach Softwareentwicklung können die Achsen angepasst werden.

Die Product Vision Box des Scrum Master

Sehr gerne wird der Scrum Master als Servant Leader bezeichnet. Manchmal aber auch als Teamleader im Sinne einer organisatorischen Hierarchie missinterpretiert. Ich als Scrum Master sehe mich natürlich als Servant Leader, der Road Blocks für das Team aus dem Weg räumt. Darüber hinaus aber auch die Stärken und Schwächen des Teams und der Teammembers kennt. Diese optimal zu steuern, um die Velocity, die Story Points usf. zu erreichen, bleibt wohl oberste Priorität. Oft wird der Scrum Master auch als Administrator etwa von Atlassian JIRA Scrum Board verstanden. Zweifellos ist die genau Steuerung des Scrum Boards eine wesentliche Aufgabe. Aber natürlich kann man sich darin auch zu Tode administrieren.

Für mich ist eine der zentralsten Aufgaben als Scrum Master mit dem Scrumteam eine Product Vision Box zu erarbeiten. Persönlich finde ich die Personas nicht so passend. Die Product Vision Box steht dann bei jedem Meeting im Raum oder am Tisch. Erstens ist die Erarbeitung für mich ein wichtiger Teambuildingfaktor. Zweitens ein wichtiger Fokus für den gesamten SDLC. Ich bin davon überzeugt, dass diese Methode essentiell ist, damit das Team effektiv starten kann und mit Zug entlang der Product Vision Box die Estimations optimaler hinbekommt. Allenthalben hat bisher jeder Product Owner die Product Vision Box als wichtiges Hilfsmittel für sich selbst gesehen.

Der Backlog Eisberg 

iceberg-cohn-2008
Product Backlog Iceberg: Cohn, 2008

Studien zu IT-(Individual-) Softwareprojekten belegen, dass ca. 65% der schwerwiegenden Fehler in Programmen auf Fehler bei der Analyse zurückzuführen sind. Gleichzeitig kommen im Projektverlauf bis zu 50% neuer Anforderungen hinzu. Dieser Requirements Growth bedeutet sowohl in Waterfall, als auch in Scrum grundsätzlich ein Projektrisiko. Positiv betrachtet, bedeutet der Requiremnts Growth jedoch auch eine potentielle Chance Begeisterungsfaktoren für Ihre Kunden zu generieren. Der Product Backlog bleibt dabei immer der zentrale Orientierungspunkt. Nur wenn die zusätzlichen Anforderungen (User Stories) verstanden, geschätzt auf Ihren Business Value und durch Sie priorisiert sind, können Sie, je nach Priorisierung, in Sprints aufgenommen werden, oder nicht. Der positive Umgang mit „Unwissen“ (Future Releases) und das Backlog grooming vermeiden ein weiterer, für mich sehr risikobehafteter,  Einflussfaktor – das Gold Plating. Gold Plating findet immer dann statt, wenn der Ressourceneinsatz oder die Zeitplanung Spielraum für individuelle Entfaltung bietet. Individuelle Entfaltung ist qualitativ etwas ganz anderes als Eigenverantwortung. Die individuelle Entfaltung verleitet Coder oft dazu, das perfekte Stück Software zu programmieren – obwohl die Features gar nicht in der breite angefordert waren – eben Gold Plating. Backlogmanagement, Teamspirit und Estimations steuern dem entgegen und bringen Gold Platting auf 0%.

Product Backlog Priorisierung mittels Kano Modell

Das Kano Modell ist eine perfekte Lösung um die User Story Prioritization für den Product Backlog vorzunehmen. Ein Vorteil dieser Analyse ist, dass sie  geschätzte Kernaussagen darüber zulässt, welche Funktionen eine Applikation mit welcher Wichtigkeit enthalten sollte. Im jeweiligen Scrum werden die Story Point Estimations über Planning Poker im Scrumteam geschätzt. Dieser Prozess bestimmt den gesamten Sprint und Reports wie die Burndown Charts oder das Cummulative Flow Diagram.

Kano Modell, Kobald Agile Expert & IT Projects, 2017

Scrum ist hartes messen, um Ihre Businessziele exakt umzusetzen und um vorallem auch die so genannte Velocity sicherzustellen. Zeit, Kosten, Budget werden in einer Scrum Software Entwicklung niemals verändert. Die einzige Möglichkeit die drei Faktoren einzuhalten ist die Priorisierung des Product Backlog. Weswegen wiederum die SRS, versehen mit Estimations so extrem wichtig sind – und zwar vor dem Start!

Allerdings sind auch ein paar Hürden zu nehmen, um erfolgreich zu scrumen. Eines ist sicher – ein bisschen Scrum geht nicht. Dazu ist meiner Meinung nach folgendes organisatorische Verständnis unerlässlich, denn Scrum verlangt

spezielle Unternehmenskultur u. Mitarbeiter voraus (Transparenz + Eigenverantwortung der Teams) und bricht mit klassischen Rollen (Vertrauen in die Selbstorganisation), aber benötigt entsprechende Skillsets in den neuen Rollen, weiter sind  „gute“ Spezifikationen das Um und Auf und Scrum verlangt das Verständnis, dass ein Inkrement nur zu 100% fertig übergeben wird.

Natürlich muss in Scrum genauso wie bei anderen Softwareentwicklungsmethoden die  Software,- und Systemarchitektur vor dem Umsetzungsbeginn festgelegt sein. Diese „unterwegs“ sozusagen generisch zu entwickeln, funkt in Scrum genauso wenig wie bei anderen Herangehensweisen.

Die „richtige“ Priorisierung ist ebenfalls unerlässlich. Der Prozess zuerst mit den komplexesten, riskantesten und wichtigsten User Stories des Product Backlog zu starten ist unerlässlich für den Erfolg. Allerdings erfolgt diese Priorisierung über den Product Owner, wobei jeder PO gut beraten ist, das Development Team zu rate zu ziehen.

Ihr Mehrwert steht im Vordergrund

Die erste und wichtigste gemeinsame Aktivität – egal ob als Ihr Product Owner oder als Ihr Scrum Master – ist es, Ihre Produktvision zu verstehen. Darauf aufbauend werden die Srum-Prozesse entwickelt. Zu entwickelnde funktionale Services werden in der Scrumsprache als Product Items bezeichnet, die im Product Backlog der SRS (Software Requirement Specifications), priorisiert durch Sie, entwickelt werden.

verschiedene-ansatze
Value Driven Development:  Lacey, 2016

Parallel dazu ist ein Value Stream Mapping (oder Story Boarding) essentiell. Diese rasch fertigzustellen, so dass die Services bereits im Projektverlauf Nutzen für Sie bringen, hat oberste Priorität. Überbordende Dokumentation und Administration ist nicht gefragt. Viel mehr zählen Ihre Anforderungsliste (Product Backlog) sowie exakte Messung der Entwicklungsfortschritte. Ganz im Sinne unseres Dichterfürsten, Johann Wolfgang von Goethe, der einmal meinte:

Es ist nicht genug zu wissen, man muss es auch anwenden. Es ist nicht genug zu wollen, man muss es auch tun.

Scrum mit mehreren Teams

Natürlich wird Scrum gerne auch in größeren IT-Projekten mit mehreren Teams eingesetzt. Oft wird mit mehreren Teams in verschiedenen Städten oder Länder gearbeitet. Um diese zu unterscheiden, habe ich für mich den Begriff Scrumfactory eingeführt.

cohn_scrumofscrums452
Scrum of Scrums: Mike Cohn, 2007

So konnte ich die Scrumfactories funktional einordnern – etwa eine Factory für Operations-Themen, eine Factory für Web-App-Entwicklung, eine Factory für UX usf. Klassisch werden mehrere Scrumorganisationen über den so genannten Scrum of Scrums gesteuert, um die Skalierbarkeit zu gewährleisten. An sich kann jeder Scrummaster im Scrum of Scrums der so genannte Ambassador sein. Empfehlenswert ist eher ein technischer Teammember oder der Scrum Master – so er technischen Background hat.

Die vier wichtigsten Säulen für Ihren Erfolg

Scrum regt tatsächlich alle Teammember dazu an, in der Kausalkette Problem – Produkt – Kosten – Businessnutzen lösungsorientiert zu denken. In der Phase der sogenannten Product Backlog Specification kann die Unsicherheit über Anforderungen dramatisch reduziert werden. Ihre Anforderungen sind die Ausgangsbasis für die User Stories. Die User Stories werden geschätzt. Nach dem Schätzen werden diese priorisiert und in zeitlich begrenzten Sprints entwickelt. Nur wenn allen Beteiligten diese Kausalkette „in Fleisch und Blut“ übergegangen ist, können die vier wichtigsten Säulen einer Scrum-Entwicklung für Ihren Mehrwert angewandt werden:

  1. Real time return of investment (Echtzeit-Nutzen)
  2. Demand on need (bedarfsorientierte Lieferung)
  3. Real time scaling (Echtzeit-Skalierung)
  4. Cost, time and quality controlling

Services, Funktionalitäten, Objekte, usf. sind ein Set von potentiellen Nutzeneffekten. Diese Nutzeneffekte sind Effizienzsteigerungen beispielsweise durch Rationalisierung, Strukturierung, Automatisierung oder Standardisierung. Ein Scrumprojekt ist nur dann erfolgreich, wenn es effizienzgetrieben ist. Alles andere ist kein Scrumansatz!

Der Konus der Ungewissheit im Zusammenhang mit dem SDLC

In Scrum ist der Product Backlog das Lasten- u. Pflichtenheft der Softwarentwicklung in einem. Je besser die Requirements, d. h. die User Stories, im Backlog geschätzt werden, um so besser verläuft der Scrumprozess. In diesem Zusammenhang ist der spannende Aspekt des Konus der Ungwissheit die Eindeutigkeit der Wichtigkeit der ersten 30% eines SDLC.  In dieser frühen Phase des Projekts werden wenige, jedoch sehr entscheidende Fragen mit großem Einfluss auf den SDLC  analysiert und beantwortet, oder die noch unklar sind, definiert werden.

konus-der-ungewissheit
Konus der Ungewissheit: Schweiger, 2016

Das statistische Gesetz der großen Zahlen besagt, dass sich die relative Häufigkeit eines Zufallsergebnisses immer weiter an die theoretische Wahrscheinlichkeit für dieses Ergebnis annähert, je häufiger das Zufallsexperiment durchgeführt wird. Genau dieser Effekt ergibt sich bei guten Estimations in der frühen Phase eines SDLC. Je größer die Zahl der guten Schätzung ist, desto geringer wird die Wahrscheinlichkeit für teure fall backs im weiteren SDLC Verlauf.

Die Unsicherheit über Kenngrößen reduziert sich in den ersten 30% des SDLC von einem Faktor 4 auf einen Faktor 1,25, was anders ausgedrückt bedeutet, dass dieser Effekt den möglichen Fehler-Bereich von 16-fach auf 1,56-fach reduziert! Natürlich entstehen in jedem, aber insbesondere im Scrum-SDLC-Verlauf ständig neue Fragen und Probleme, deren Auswirkung jedoch weit weniger Kostenauswirkung haben als jene, die unzureichenden Schätzungen zu Beginn des SDLC, zu grunde liegen – beruhend auf dem Gesetz der großen Zahl.

Mein Selbstmanagement

Ich predige nicht Wasser und trinke selbst Wein. Ein zentraler Faktor für Ihren Projekterfolg ist natürlich auch mein Selbstmanagement. Dwight D. Eisenhower verfolgte ein unschlagbares Selbstmanagementkonzept, welches eine wichtige Säule für mich ist.

  1. Dringliche und wichtige Aufgaben selbst und sofort tun!
  2. Wichtige, aber nicht dringliche Aufgaben für die Erledigung terminieren!
  3. Aufgaben, die weder dringlich noch wichtig sind, streichen!

Mir ist effizientes Arbeiten sehr wichtig. Deswegen vermeide ich Zeitdiebe (unproduktive Arbeiten). Persönlich glaube ich nicht, dass Multitasking eine positive Fähigkeit ist. Sie kennen vielleicht den Sägeblatteffekt? Störungen behindern den Gedanken- und Arbeitsfluß und führen zu erneuten Anlauf- und Einarbeitungszeiten. Schätzungen gehen davon aus, dass bis zu 28% unserer Zeit durch Störungen „verloren“ gehen. Störungen sind etwa, ständig Emails in Echtzeit zu beantworten. Aber auch zu viele Unterbrechungstelefonate. Gerne arbeite ich selbst mit Scrums. Ich konzentriere mich 90 Minuten auf eine Aufgabe – und vermeide den Badewanneneffekt. Vormittags bevorzuge ich eher kreative Arbeiten. Nachmittags gerne Routinetätigkeiten, wie beispielsweise Emailverkehr und wichtige Telefonate.

 

Sie haben weitere Fragen? Ich kann Sie bei einer Problemlösung unterstützen? Dann kontaktieren Sie mich bitte!

 

 

Roland Konrad Kobald

IREB CPRE (Certified Professional for Requirements Engineering, Lizenz 1369)

SMC (Scrum Master Certified, Lizenz 102837)

SFC (Scrum Fundamentals Certified, Lizenz 99274)

ITIL v.3 (Foundation Level, Lizenz 5558492.20481540)