Nicht nur Multitasking ist eine Utopie, auch das effiziente Verfolgen mehrerer paralleler Ziele führt nur in den seltensten Fällen zum Erfolg. Zu häufig sind die Wege zur Erreichung unterschiedlicher Ziele eben nicht komplett isoliert, sondern haben Abhängigkeiten. Dies führt dazu, dass Probleme bei Erreichung des einen Ziels das andere ebenfalls ausbremsen und im Extremfall bleiben beide bei „fast fertig“ stehen, ohne dass eines komplett fertig wird. Neben dieser Effektivitätseinschränkung gibt es aber noch den Aspekt der Effizienz: Zielgerichtetes und effizientes Arbeiten an einer kostenoptimalen Lösung ist auch nur dann möglich, wenn man ein klares Ziel vor Augen hat. In Projekten scheint dies vermeintlich völlig klar, so heißt es häufig in Bezug auf die zu entwickelnde Software, alle Beteiligten wissen doch, was am Ende der Entwicklung heraus kommen soll. Betrachtet man die Anforderungen dann aber im Detail, werden unterschiedliche und konkurrierende Zielsetzungen schnell deutlich. In der agilen Softwareentwicklung haben wir diese Problemstellung sowohl im Großen (Projekt- und Planungsebene) als auch im Kleinen (Team- und operative Ebene):

Das Thema im Großen

Stakeholder kommen in der Regel aus verschiedenen Fachbereichen und haben individuelle Anforderungen, also quasi ihr eigenes Backlog. Da diese aber in der Regel in ein und derselben Software abgebildet werden sollen und häufig auch vom selben Entwicklerteam umgesetzt werden müssen, ist hier ein gemeinsames, bereichsübergreifendes Backlog notwendig.

Der Product Owner kümmert sich darum, dieses zentrale Backlog in eine eindeutige Reihenfolge zu bringen. Um das sinnvoll tun zu können, müssen die unterschiedlichen Fachbereiche die Prioritäten ihrer Anforderungen kenntlich machen – dies geht beispielsweise mit der MoSCoW-Priorisierung: Hier definiert man für jede Anforderung, ob sie das Attribut Must, Should, Could oder Won’t bekommt. Hier sollte man tunlichst jeder Ausprägung eine genauere Definition spendieren (Must = zwingend erforderlich, kein Workaround vorhanden), um die Zuordnung zu erleichtern und den Interpretationsspielraum so gering wie möglich zu halten.

Auch sollte man diese Attribute immer auf ein konkretes Ereignis beziehen, beispielsweise auf das nächste Release oder auf den Go-Live. Denn ein Won’t in diesem Release muss kein Won’t im nächsten sein. In der Regel empfinden Fachbereiche alle ihre Anforderungen als wichtig (Must, real Must etc…), allerdings muss klar sein, dass es in der Regel nicht möglich sein wird, alle Musts umzusetzen und dass bei Nichtbeachtung einer strikten Reihenfolge die Umsetzung aller Must-Themen im Zweifel beliebig ist – damit stellen sie sich selber ein Bein.

Haben die Fachbereiche ihre Anforderungen priorisiert, stellt sich das nächste Problem: In welcher Reihenfolge bekommt nun welcher Bereich seine wichtigsten Themen umgesetzt? Reihum zu gehen ist sicher möglich, aber selten sinnvoll. Viel mehr gilt es hier, übergreifende Ziele in die Bewertung einfließen zu lassen. So ist es beispielsweise häufig sinnvoller, erst den nächsten Bereich an die Software anzubinden, bevor man einem bereits angebundenen Bereich sein nächstes, auch wichtiges Komfortfeature implementiert. Hier hat der PO nun mit Erwartungsmanagement alle Hände voll zu tun. Das kann er mit dem Vorschlaghammer tun („Wir machen das jetzt so, weil ich es sage“) oder aber auf Transparenz setzen und das übergeordnete Ziel der bereichsübergreifenden Zusammenarbeit hervorheben.

Besonders in großen Projekten ist ein Product Owner schnell damit überfordert, alle seiner Rolle anhaftenden Tätigkeiten hinreichend auszuüben, daher wird sich bei der Skalierung häufig Teil-POs, übergeordneten POs und weiteren abgestuften Rollen bedient. Dies kann durchaus sinnvoll sein, es muss allerdings aufgepasst werden, dass diese Aufteilung der Zuständigkeiten der eindeutigen Reihenfolge des zentralen Backlogs nicht im Wege stehen. Ob man nun einen „Super-PO“ als Institution verankert, oder ob man in einem Team von POs auf Konsens setzt, ist sicher vom Einzelfall abhängig, jedoch nicht, dass es dabei eine Vision und ein Ziel geben muss. Und egal, wie groß das PO-Team auch immer sein mag: es muss am Ende immer einen geben, der die letzte Entscheidung trifft (Highlander-Prinzip).

Das Thema im Kleinen

Nachdem der PO nun so viel Aufwand in die Erstellung eines eindeutigen Backlogs und in das Erwartungsmanagement mit den Stakeholdern gesteckt hat, sollte natürlich das Team diese Ziele in der täglichen Umsetzung ebenfalls verfolgen. Um dies auch effektiv tun zu können, sollte der Fokus immer auf der Implementierung der nächsten, wichtigsten Anforderung liegen.

Effizienzseitig bietet es sich an, „work in progress“ zu limitieren, um den Durchsatz der umgesetzten Anforderungen möglichst hoch zu halten. In Scrum limitiert beispielsweise der geschützte Sprint über zwei bis vier Wochen (je nach Projekt) bereits die Anzahl der Stories, die parallel bearbeitet werden können. Auch das zeitliche Ziel ist hier völlig klar: Am Ende der zwei Wochen sollen die Stories fertig sein. Alle? Wenn möglich ja, gibt es hier aber doch unerwartete Hindernisse, ist es sinnvoll, den Fokus noch genauer auf das so genannte Sprintziel zu setzen.

Im Sprint Planning stellt der PO die Inhalte vor, die vom Team in den kommenden Sprint gezogen werden können. Die Stories des resultierenden Sprint Backlogs sollten sich möglichst einem inhaltlichen Sprintziel zuordnen lassen. Dies gibt dem Sprint einen übergeordneten Fokus und damit den Entwicklern bei täglichen Priorisierungs- und Entscheidungsfragen auf Story- und Task-Ebene Hilfestellung.

Auch auf Story-Ebene finden sich Prinzipien zum besseren Fokus und zur effektiven Zielerreichung: Anstatt jede zu entwickelnde Story bis zur Perfektion im Code immer und immer wieder zu refactorn und immer elegantere Möglichkeiten zu finden, die Anforderung umzusetzen, sollten Entwickler nach dem KISS-Prinzip (Keep it short and simple) arbeiten. Danach ist es völlig hinreichend, die Akzeptanzkriterien der Story sowie die Definition of Done zu erfüllen, um eine Story abschließen zu können. Alles andere wäre im Zweifel Verschwendung – und die wollen wir im Agilen ja bekanntlich vermeiden.

Bei all den Methoden und Werkzeugen, die einem helfen, die Anforderung zielgerichtet fertig zu machen, ist besonders eine wichtig: Done! Mach die Story fertig! Für Entwickler in der täglichen Arbeit ist das das höchste Ziel: Halte die vereinbarten Qualitätskriterien ein, achte auf die Akzeptanzkriterien, aber mach die Story fertig. Fast fertig gibt es bei einer Story nicht. Die Punkte für eine Story im Burndown werden erst dann abgetragen, wenn sie fertig ist.

Über die Eigenschaften des geschützten Sprints und des geschützten Teams hier noch ausführlicher zu schreiben, würde zu weit führen. Klar ist aber in jedem Fall: Es gibt keine neuen Inhalte während des laufenden Sprints! Man kann sich natürlich Kapazitäten für die Betriebsunterstützung frei halten und diese separat tracken. Oder man kann eine Story aus dem Sprint entfernen und gegen eine andere (gleich große) tauschen, solange ihr Ausfall nicht das Sprintziel gefährdet, wenn diese trotz gründlicher Konzeption doch nicht umsetzbar ist. Aber den Fokus eines Sprints während seiner Laufzeit zu erweitern, führt ganz sicher zu Verzögerungen. Und dass das Team sich um die Inhalte des Sprints kümmert und keine einzelnen Entwickler neben dem Sprint sich um bestimmte Anforderungen eines ranghohen Managers oder eines anderen Kollegen außerhalb des Teams kümmern, ist ebenfalls Grundvoraussetzung. Hier ist der Scrum Master in der Pflicht, das Team gegen alle Eingriffe von außen zu schützen.

Tipps & Tricks

• Eine Vision, ein Ziel, eine Laufrichtung durch den oder die POs
• Fachbereiche priorisieren ihre Anforderungen nach MoSCoW
• Ein streng geordnetes Backlog über alle Anforderungen
• Der PO kümmert sich um die Erwartungshaltungen der Stakeholder und Fachbereiche und macht die übergeordnete Zielsetzung transparent
• Der PO definiert für jeden Sprint ein Sprintziel, an dem sich die Entwickler orientieren können
• Die Entwicklung limitiert work in progress, um den Durchsatz der umgesetzten Anforderungen so hoch wie möglich zu halten
• Done! – Stories werden nach dem KISS-Prinzip abgeschlossen, wenn sie alle Akzeptanzkriterien und die Definition of Done erfüllen
• Fast fertig gibt es nicht, die Story Points für eine Story werden erst dann im Burndown abgetragen, wenn sie komplett fertig ist
• Sprints und das Team sind geschützt

Fazit

Von der Priorisierung der Anforderungen der unterschiedlichen Stakeholder bis hin zur Umsetzung jeder einzelnen Story durch die Entwicklung ist es wichtig, fokussiert zu bleiben. Dies kann man nur, wenn ein eindeutiges Ziel verfolgt wird. Mehrere Ziele parallel und Interpretationsspielraum bei der Definition von Zielen sind hier absolut hinderlich. Das agile Vorgehen mit seinen Methoden und Werkzeugen bietet hier hervorragende Hilfestellung. Softwareentwicklung ist ein komplexes Problem und eindeutige Ziele für jeden kleinen Schritt ermöglichen seine Lösung.