Open Loops

Auf den DSAG Technologietagen mit dem Schwerpunkt “Komplexität - erkennen, beherrschen, vermeiden” waren wir in der letzten Woche sicherlich Exoten: Unser Vortrag “Komplexität beherrschen - Agil arbeiten” am 24.02.2010 war aber dennoch gut besucht. Es gibt offensichtlich ein starkes Interesse daran, auch in SAP-Projekten alternative Vorgehensmodelle auszuprobieren.

Die DSAG Technologietage werden seitens SAP genutzt, um technische Neuerungen vorzustellen und einen Ausblick auf zukünftige Entwicklungen zu geben. Als Kontrapunkt gibt es eine Vielzahl von Kundenvorträgen, die ihre jeweils ganz eigenen Erfahrungen mit SAP-Systemen und -Technologien präsentieren. Das inhaltliche Themenfeld umfasste dabei so unterschiedliche Bereiche wie Geschäftsprozessmanagement, Solution Manager, Identity Management, Application Integration und Master Data Management.

Im Rahmen der Arbeitsgruppe “SAP Netweaver Development - ABAP und Java” haben wir unsere Adaption agiler Methoden auf das SAP-Projektumfeld vorgestellt. Als besondere Herausforderung sehen wir im SAP Umfeld hierbei

• modulübergreifende und eigenverantwortlich arbeitende Projektteams,
• die Pflege eines integrierten Product-Backlogs mit fachlichen Anforderungen, die in einer Iteration umgesetzt werden können,
• häufige Releases und der damit u.a. verbundene Schulungsaufwand sowie
• Testautomatisierung.

In der Diskussion kristallisierten sich neben den “üblichen” Herausforderungen rund um Festpreisverträge und Skalierung von Scrum auch SAP-spezifische Stolpersteine heraus:

• Mangelnde Toolunterstützung für das Refactoring von ABAP-Code
• Wenig verbreitete Testautomatisierung
• Kaum ausgeprägte Integration der Fachabteilungen während der Umsetzung

Über Austausch zu diesen Themen würden wir uns sehr freuen. Wie sind Ihre Erfahrungen?

In letzter Zeit werde ich immer öfter gefragt, ob ich denn schon dieses oder jenes Scrum-Tool kennen würde. Natürlich ist mir das ein oder andere Tool bekannt, und einige halte ich auch für sehr nützlich. Ich rate allerdings dazu, den Einsatz eines solchen Tools genau zu prüfen.

Scrum-Tools dienen üblicherweise der digitalen Verwaltung des Product Backlogs. Außerdem bieten sie ein Taskboard an und generieren daraus automatisch ein Sprint Burndown Chart. Eigentlich ganz nützlich, oder? Man muss keine Task-Karten mehr schreiben und auch das lästige manuelle Aktualisieren des Sprint Burndown Charts entfällt. Echt praktisch! Allerdings hat diese Automatisierung aus meiner Sicht einen gravierenden Nachteil. Um sich den aktuellen Status des Sprints ansehen zu können, muss man explizit im Tool nachsehen. Meiner Erfahrung nach passiert genau das häufig nicht. In der Folge weiß das Team oft nicht, wie es um den aktuellen Sprint bestellt ist. Darüber hinaus ist mir aufgefallen, dass sich niemand mehr für den Fortschritt im aktuellen Sprint interessiert, sobald das Sprint Burndown Chart automatisch berechnet wird.

Ganz anders ist es bei Verwendung eines Whiteboards als Taskboard, wenn dieses für alle sichtbar und anfassbar im Teamraum hängt. Jedes Teammitglied hat ständig vor Augen, wie es um den aktuellen Sprint steht. Die manuelle Aktualisierung von Taskboard und Sprint Burndown Chart ist tägliche Aufgabe des Teams im Daily Scrum-Meeting. Der aktuelle Status des Sprints wird dadurch tief im Bewusstsein des Teams verankert und das Team auf diese Weise ständig an sein Commitment erinnert.

Meine Empfehlung ist der Einsatz eines Taskboards zum Anfassen in Form eines Whiteboards. Bei einem räumlich verteilten Team hat man allerdings oft keine andere Wahl als ein Tool einzusetzen.

Wie stehen Sie zur Verwendung von Scrum-Tools?

Die agile Softwareentwicklung ist in aller Munde. So Erfolg versprechend Agilität sein mag, ihre Einführung gestaltet sich oftmals schwierig. Ein häufig auftretendes Problem sind Rollenkonflikte, die sich daraus ergeben, die Rollen “Product Owner”, “ScrumMaster” und “Team” geeignet zu besetzen. Der Einfachheit halber wird also unter Umständen ein und dieselbe Person zum Teammitglied, Product Owner und Scrum Master ernannt.

Kann Agilität mit dieser Rollenverteilung überhaupt funktionieren? Sehen wir uns die Aufgaben der Person an, die die drei Scrum-Rollen auf sich vereint: Als Product Owner ist sie für den Produkterfolg verantwortlich und muss sich um Sammlung und Priorisierung von Anforderungen kümmern. Als Scrum Master schützt sie das Team vor Störungen von außen und räumt dem Team Hindernisse beiseite. In ihrer Rolle als Teammitglied fühlt sie sich für die erfolgreiche Umsetzung der Anforderungen des aktuellen Sprints verantwortlich. Alles in allem also eine Menge von Aufgaben, die diese Person bewältigen muss. Noch schlimmer ist, dass sich die Wahrnehmung all dieser Aufgaben zumindest in Teilen gegenseitig ausschließt.

Wie soll es funktionieren, wenn man als Teammitglied fokussiert Anforderungen umsetzen soll und gleichzeitig das zeitaufwändige Anforderungsmanagement bewältigen soll? Die einzig denkbare Lösung wäre ein Timeboxing des Anforderungsmanagements, um trotz Doppelrolle ein Commitment für den aktuellen Sprint abgeben zu können. Ich kann mir allerdings nicht vorstellen, wie so etwas funktionieren soll. Das Anforderungsmanagement ist essentiell und sollte nicht mit niedriger Priorität behandelt werden. Gleichzeitig stellt sich die Frage, ob ein Product Owner als Teammitglied nicht dazu neigen wird, seine Vorstellung von der Realisierung der Anforderungen durchzusetzen. Damit wäre dann die Selbstorganisation des Teams behindert. Auch der Abnahmeprozess ist problematisch. Wie kann ein Product Owner die selbst implementierte Software abnehmen?

In seiner Rolle als Scrum Master muss dieses Super-Talent obendrein dafür sorgen, dass das Team vor Störungen von außen geschützt wird. Diese Schutzfunktion wird das Super-Talent nur bedingt ausüben können, da es als Product Owner die Verantwortung für den Produkterfolg trägt. Wenn es also eine dringende Aufgabe gibt, die für das Produkt mal eben erledigt werden muss, wird die Schutzfunktion im Zweifel zurückstehen müssen, um die Erledigung der Aufgabe im Team zu initiieren. Das Commitment des Teams für den aktuellen Sprint wäre gefährdet.

Ich kann demnach nicht empfehlen, die Rollen Scrum Master, Product Owner und Teammitglied in einer Person zu vereinen. Diese Person wäre nicht nur hoffnungslos überlastet, sondern würde auch den Erfolg des Produkts gefährden, da Commitments nicht eingehalten werden können oder das Anforderungsmanagement zu kurz kommt.

Eine andere nicht ganz so glückliche Konstellation ist die Vereinigung von Scrum Master und Teammitglied in einer Person. Zumindest in einer frühen Projektphase wird es Probleme geben, da die Scrum Master-Tätigkeit einen verhältnismäßig hohen Zeitaufwand in Anspruch nimmt. Für das Team ist es problematisch, ein Commitment für den aktuellen Sprint zu geben, wenn nicht prognostizierbar ist, in welchem Umfang der Scrum Master für die Umsetzung zur Verfügung stehen wird. Typischerweise jedoch nimmt der zeitliche Aufwand für die Scrum Master-Tätigkeit im Projektverlauf deutlich ab, so dass es durchaus funktionieren kann, beide Rollen miteinander zu kombinieren. Nichtsdestotrotz wird es immer wieder zu Konflikten kommen, wenn es um Hindernisse im Team geht. Der Scrum Master kann schließlich keine neutrale Position einnehmen, da er ja selbst ein Teammitglied mit eigenen Interessen ist.

Auf gar keinen Fall sollte eine Person alle drei Scrum-Rollen in sich vereinen. Genau so wenig sollte eine Person gleichzeitig Scrum Master und Product Owner sein. Ich halte es jedoch für vertretbar, wenn eine Person sowohl Teammitglied als auch Scrum Master ist. Ebenfalls denkbar ist die Kombination von Product Owner und Teammitglied. Man müsste sich in einem solchen Fall jedoch überlegen, wie die Abnahme der Implementierung gestaltet werden kann.

Optimal ist einzig die Verteilung von Scrum Master, Produkt Owner und Team auf unterschiedliche Personen.

Das Genchi Genbutsu-Prinzip ist eine der 5 Säulen des Toyota Managementsystems. Es bedeutet soviel wie “Geh und sieh selbst” und lässt sich hervorragend auf die Softwareentwicklung übertragen.

Ein weit verbreitetes Problem bei der Entwicklung von Software-Produkten sind Missverständnisse zwischen Kunde und Softwareentwicklung durch unklare, teilweise widersprüchliche Anforderungen. Diese kommunikative Lücke zwischen Kunde und Softwareentwicklungsteam lässt sich durch Anwendung von Genchi Genbutsu überwinden.

Scrum kennt die Rolle des Product Owners, der als Kundenrepräsentant für die Menge der Anforderungen verantwortlich ist. Seine Aufgabe besteht darin, in enger Zusammenarbeit mit dem Team die Anforderungen zu klären und das Team bei der Umsetzung zu unterstützen. Dieser lebhafte Austausch zwischen Product Owner und Team stellt sicher, dass das Team die Anforderungen des Product Owners ganz genau so programmieren kann, wie es der Vorstellung des Product Owners entspricht. Umgekehrt ist der Product Owner umgehend in der Lage korrigierend einzugreifen, wenn es Probleme mit der Implementierung gibt.

Genchi Genbutsu hilft dem Team und dem Product Owner. Das Team ist bei der Umsetzung von Anforderungen nicht mehr auf lange Requirements-Dokumente angewiesen, da diese mit dem Product Owner im Dialog missverständnisfrei geklärt werden können. Gleichzeitig werden keine ausführlichen Projektstatusberichte mehr benötigt, da der Product Owner den Projektstatus direkt vor Ort “miterlebt”.

Mein letztes Projekt hat von Genchi Genbutsu massiv profitiert. Welche Erfahrungen haben Sie gemacht?

Wer hat es in seinem Projektmanagerleben noch nicht erlebt: Ein Ergebnis war zu 99% fertig und die letzten Tasks zum “wirklichen Fertig” sollten noch zwei Wochen dauern. Nach zwei Monaten standen wir immer noch bei 99% und die Lösung der neu hinzugekommen Probleme sollte 5 Wochen dauern.

Gelernt habe ich daraus, dass nur die 100% -Lösung als wirklich fertig bezeichnet werden kann. Auf eine Restaufwandschätzung kann man sich nicht verlassen, und man sollte in keinem Fall seine Statusmessung darauf aufbauen.

Gemessen werden kann nur:

• was auf einem produktionsnahen System deployed ist
• was voll lauffähig vom Endanwender bis zur Datenspeicherung oder dem Aufruf externer Systeme (Durchstich) ist
• was getestet und ohne Fehler ist
• was voll dokumentiert wurde

Dies entspricht der Definition von “Done” aus dem agilen Projektmanagement. “Done” bedeutet, das wirklich keine Restarbeiten mehr versteckt sind, die noch unabschätzbare Aufwände in sich bergen.

Denn:

• nicht getestet bedeutet potenziell verborgene Qualitätsprobleme
• nicht lauffähig von Anfang bis Ende (Durchstich) bedeutet verborgene Integrationsaufwände
• nicht deployed bedeutet verborgene Konfigurations- und Systemintegrationsaufwände
• nicht dokumentiert bedeutet einen Berg von geschobenen Dokumentationsaufwänden.

Ich bin ein Freund der “Definition of Done” geworden. Ich messe nur noch, was wirklich fertig ist. Sonst würde ich einen vermuteten Status reporten, mit vielen Unbekannten, also nichts wirklich Belastbares.