Auf den ersten Blick scheinbar nicht viel. Auf den zweiten Blick aber doch, zumindest mit Jazz, wie folgender Artikel aus der Computerwoche beschreibt. Nach fünf Jahren Erfahrung mit agilen Projekten kann ich die beschriebenen Gegebenheiten gut nachvollziehen.

Was kommt nach der Agilität?

Tags:Scrum

IT-Spezialisten sind gefragt wie nie. Die Digitalisierungswelle rollt und benötigt Manpower und Know-How zur Umsetzung. Welches Know-How wird benötigt? Big Data, Internet-of-Things, Mobile Computing, etc. sind in aller Munde und setzt einiges an fachlichem Spezialwissen voraus. Es bedarf unterschiedlicher Rollen wie Entwickler, Architekten, Tester, etc. Aber wie sieht es neben den fachlichen Expertisen mit Methodenkenntnissen aus? Gibt es einen gemeinsamen Nenner an methodischem Basiswissen, welches alle beteiligten Spezialisten aufweisen sollten? Auf jeden Fall.
Da mittlerweile die überwiegende Zahl von Software-Projekten agil umgesetzt wird, sind Grundkenntnisse in agilen Methoden (v.a. Scrum) sehr hilfreich. Alle Teammitglieder, nicht nur Product Owner und Scrum Master, sollten das gleiche Mindset haben und wissen wie das Arbeiten in Sprints funktioniert.

Überblick Scrum

Ähnliches gilt aus meiner Sicht auch für das Thema Design Thinking. Auch hier bietet ein Grundwissen über die Herangehensweise und die Methoden Vorteile bei der Projektarbeit. Erfunden wurde die Methodik vom Hasso-Plattner-Institut in Zusammenarbeit mit der Stanford University.

Überblick Design Thinking

Im Grunde geht es nicht darum, den Spezialisten (z.B. Scrum Professionals oder Design Thinking Profis) die Arbeit abzunehmen, sondern sich vielmehr die Grundeinstellung bzw. Denkweise zu eigen zu machen, die diesen Methoden zu Grunde liegt.

- Versuche die Probleme bzw. Wünsche deiner Kunden/Nutzer zielgerichtet zu verstehen.
- Suche nach passenden, kreativen Lösungen.
- Setze die angedachte Lösung in kleinen, sinnvollen Schritten um und hole dir laufend Feedback vom Kunden/Nutzer ab.
- Korrigiere so schnell wie möglich den eingeschlagenen Weg, wenn er als falsch erkannt wird.

Ich bin überzeugt davon, dass sich ein gewisses Basis Know-How in Scrum bzw. agilem Vorgehen und in Design Thinking bei jedem IT-Spezialisten, unabhängig von seiner Fachrichtung, insgesamt sehr positiv auf die Projektkultur und auf die Erfolgswahrscheinlichkeit von Digitalisierungsprojekten auswirken kann. Insbesondere gilt das natürlich auch für Stakeholder bzw. Auftraggeber, diese Herangehensweise vorbehaltlos unterstützen müssen, damit sie funktionieren kann.

Tags:Scrum Design Thinking

In Scrum ist das Product Backlog der User Stories der zentrale Ort für Priorisierung und Umsetzung von Anforderungen. Die Qualität der User Stories ist somit ein wesentlicher Erfolgsfaktor für ein agiles Projekt. Für erfahrene Business Analysten aus traditionellen Projekten, welche möglicherweise die Rolle des Product Owner übernehmen, ist die Umstellung vom Schreiben klassischer Konzepte hin zum Verfassen von User Stories nicht immer ganz einfach. Während ein Softwarekonzept natürlich auch sukzessive entstehen kann aber letztendlich doch vollumfänglich alle notwendigen Funktionen beschreiben sollte, bevor eine Zeile Code umgesetzt wird, „lebt“ das Product Backlog parallel zur Entwicklung. Auch der Stil der User Stories unterscheidet sich fundamental von einem herkömmlichen Konzept. Wie man grundsätzlich an das Thema Agiles Requirement Engineering herangeht ist in der Fachliteratur hinlänglich beschrieben. In der Praxis zeigt sich oft, dass es einer gewissen Erfahrung und Lernkurve beim Schreiben von User Stories bedarf. Deshalb ist es sinnvoll, jedem „neuen“ Product Owner (PO) oder einem PO-Team einen erfahrenen PO zur Seite zu stellen, um folgende konkreten Risiken zu minimieren.

• Falsche Priorisierung der Stories: Was benötigt man, um möglichst schnell einen „Durchstich“ zu bekommen, d.h. ein lauffähiges System? „Schöner machen“ kann man anschließend.
  

• Definition of Ready wird nicht erreicht: Sind alle Aspekte inkl. der Akzeptanzkriterien enthalten und verstehen die Entwickler, was sie zu tun haben? Falls nicht, besteht die Gefahr, dass Funktionen mit nachfolgenden Stories mehrfach überarbeitet werden müssen, was den Aufwand in die Höhe treibt.
  

Was hier so banal klingt, kann in der Praxis sehr negative Konsequenzen haben. Scrum lebt davon, dass ein interdisziplinäres Team möglichst zu 100% für das Projekt abgestellt ist und zielgerichtet an einem Vorhaben arbeitet. Das bedeutet aber auch, dass dieses Scrum Team permanent zu 100% vom Projektbudget lebt, was die anfänglichen Kosten des Projekts im Vergleich zu einem klassischen Wasserfall-Projekt oft höher erscheinen lässt. Insofern ist es klar, dass dieses Budget möglichst zielgerichtet eingesetzt werden muss. Es sollte so schnell wie möglich ein Nutzen für den Endanwender ersichtlich sein. Auch wenn die finalen Gesamtkosten eines agilen Projekts meist positiver ausfallen als bei klassischen Projekten, besteht eben die Gefahr, dass Stakeholder auf „halber Wegstrecke“ die Notbremse ziehen, wenn das Kosten-Nutzen-Verhältnis aus ihrer Sicht nicht stimmt und sie das Gesamtzielbild nicht sehen. Genau aus diesem Grund ist das Schreiben der User Stories, die entsprechende Priorisierung und Strukturierung in sinnvolle und nachvollziehbare Epics und Releases ein wesentlicher Erfolgsfaktor.

Tags:Scrum

Agile Methoden (v.a. Scrum) sind in der Software-Entwicklung in vielen Unternehmen fest etabliert. Zunehmend breitet sich die Philosophie auch auf klassische Industrieunternehmen und auf allgemeine Produktentwicklungen aus. Ein klassisches Unternehmen mit einer gewachsenen Struktur hat natürlich nicht die Rahmenbedingungen wie ein neu gegründetes Startup. Wie können agile Methoden schrittweise etabliert werden ohne ein Unternehmen zu überfordern?
Zunächst gilt es diejenigen Projekte zu identifizieren, die sich für eine agile Umsetzung besonders eignen. Hier hängt es im Wesentlichen davon ab, wie klar die Anforderungen zu Beginn bereits definiert sind und wie hoch der Bezug zu einem konkreten Endanwender bzw. zum Kunden ist. Mandatorische/organisatorische Anpassungen sind im Gegensatz zu neuen strategischen Endkunden-Anwendungen bzw. -Produkten sicher weniger geeignet. Lieber ein strategisches Vorhaben gezielt auswählen und dieses dann konsequent agil angehen und unterstützen. Ein wesentlicher Erfolgsfaktor bei agilen Projekten ist ein autarkes, interdisziplinär besetztes Team (z.B. Marketing/Vertrieb, Entwicklung, Qualitätssicherung, Betrieb, etc.). Alle beteiligten Personen sollten für das Projekt im Idealfall zu 100% abgestellt sein und räumlich eng zusammen arbeiten. Dass dies in einer klassischen Organisation nicht beliebig skaliert werden kann, liegt auf der Hand. Deshalb ist die Konzentration auf strategisch wichtige Projekte notwendig.
Ausgehend von der Rahmenbedingung, dass das Projekt erfolgreich verläuft, steht irgendwann das Projektende und der Übergang in die Linie an, d.h. viele Projektmitarbeiter gehen i.d. R. wieder zurück in ihre Abteilung. Aber eine Produktentwicklung hört nie auf. Der nächste Schritt zu einer agilen Organisation könnte somit die organisatorische Zusammenfassung der beteiligten Personen sein. D.h. aus einem Projekt-Team wird ein Produkt-Team, welches zukünftig alle Anforderungen zu diesem Produkt eigenständig priorisieren und gemäß einem Releaseplan umsetzen kann. Würde dies konsequent umgesetzt, so wird eine klassische Organisation mit Abteilungen stufenweise in eine neue Organisation, ausgerichtet nach den Kernprodukten bzw. –services des Unternehmens, transformiert werden. In der Realität benötigt man vermutlich beide Welten. Große Organisationen gehen deshalb manchmal noch einen Schritt weiter und gründen eine Tochterfirma mit einer agilen Organisation, um neue Services und Produkte testen, pilotieren und letztendlich etablieren zu können.

Tags:Scrum

In der agilen Welt nach Scrum gibt es offiziell nur die Rollen Product Owner, Scrum Master und das Team. Ein klassischer Projektleiter ist nicht vorgesehen und auch nicht notwendig. Warum gibt es in der Praxis dennoch oft einen Projektleiter in agilen Projekten?
Es kommt darauf an, wie stark das Unternehmen nach einer agilen Organisation ausgerichtet ist. Das hängt sicher von der Größe, Historie und Branche ab. In klassischen Unternehmen, die agile Arbeitsweisen gestartet haben, gibt es neben agilen Projekten noch viele parallele „Wasserfall-Projekte“. Bei diesen Rahmenbedingungen kann es durchaus Sinn machen, dass es einen übergeordneten Projektleiter oder Projektkoordinator gibt. Die Aufgaben des Projektleiters unterscheiden sich allerdings von denjenigen aus traditionellen Projekten. Viele Tätigkeiten werden vom Product Owner (z.B. Stakeholder-Management) und vom Scrum Master (z.B. Organisation Entwicklung) übernommen.
Was ist also die Aufgabe? In gewachsenen Organisationsstrukturen ist es meistens nicht möglich, agilen Projekten ein autarkes interdisziplinäres Team zur Verfügung zu stellen. Es ergeben sich Abhängigkeiten in die Organisation, die den Projektfortschritt beeinflussen. Insbesondere Querschnitts-Funktionen wie Architektur/Infrastruktur, Qualitätssicherung, Betriebsübergabe werden oft in einer Linienfunktion verantwortet und müssen von allen Projekten berücksichtigt und eingeplant werden. Hier ist klassische Kapazitätsplanung bzw. Ressourcen-Steuerung notwendig, welche in Einklang mit der Sprint-Planung zu bringen ist. Hier kann die Verantwortung eines separaten Projektkoordinators liegen, diese Schnittstellenfunktion in die Organisation wahrzunehmen, um mit seinen Projektleiter-Kollegen einen insgesamt reibungsarmen Projektbetrieb im Unternehmen zu gewährleisten.
Generell sollte allerdings darauf geachtet werden, dass nicht zu viele Projekte parallel geplant werden. Es ist immer von Vorteil, seriell auf Basis der vorhandenen Kapazitäten aus den betroffenen Abteilungen bzw. der bekannten Engpässe zu planen.

Tags:Projektmanagement Scrum