Vor einiger Zeit haben wir bei der openFORCE begonnen, unsere Projektstarts bewusst zu begleiten, um zu sehen, wo wir Dinge besser machen können. Das Ergebnis sind die folgenden 18 Tipps - unterteilt in 4 Kategorien.

Wie optimiert man die Startphase von agilen Projekten?

Wie immer... mit Iterationen und Feedbackschleifen ;)

Konkret begleiten wir alle gestarteten Projekte mit einem wöchentlichen Status Menti um zu messen, ob ein agiler Flow erreicht ist und die Startphase als beendet angesehen werden kann. Wird die direkte Frage, ob sich das Projekt noch in der Startphase befindet eindeutig negativ beantwortet, führen wir eine Startphasen-Retro durch. Die Ergebnisse der Retro werden dann in die bestehenden Empfehlungen eingearbeitet.

Um mit wenigen Fragen den agilen Flow bewerten zu können orientieren wir uns an den vier Bereichen des Heart of Agile.

Die folgenden Tipps wurden also nicht recherchiert oder aus Theorie rund um Agilität abgeleitet, sondern sind ausschließlich Ergebnisse aus Retrospektiven tatsächlich durchgeführter und erfolgreich abgeschlossener Projekte!

Begib dich gemeinsam mit deinem Kunden auf die Reise

Ein agil durchgeführtes Projekt kann keine reine Dienstleistung sein. Das iterative herantasten an ein Lösung muss in enger Zusammenarbeit mit dem Kunden passieren. Daher würde ich ein agiles Projekt immer als Partnerschaft bezeichnen. Hier ein paar Punkte die du beachten solltest.

1. Kenne den agilen Reifegrad deines Kunden und hilf ihm die Lücken zu füllen

Will man schnell in eine agile Zusammenarbeit mit einem Kunden kommen, sollte man von Beginn an darauf achten wie es um den agilen Reifegrad des Kunden steht. Nur wenn man weiß, wo es Lücken oder Potential für Reibungen gibt kann man auch darauf reagieren. Wichtig ist, dass beide Seiten verstehen was das Gegenüber leisten kann, dass man offen darüber spricht und einen gemeinsamen Weg findet. Dabei geht es aber nicht darum einen perfekten Prozess zu definieren, den kann es gar nicht geben, wenn die Zusammenarbeit noch nicht begonnen hat. Ein Fehler wäre auch, sich auf ein 'so machen wir das immer' zu versteifen, denn würden beide Seiten das tun, hätte man auf jeden Fall ein Problem!

2. Jeder ist für das Ergebnis veranwtortlich

Gerade am Anfang ist es wichtig, das Bewusstein zu schaffen, dass ALLE für das Endergebnis veranwtortlich sind. Wird die Verantwortung schon zu Beginn auf Rollen oder Personen aufgeteilt, kann es leicht passieren, dass man sich bald (spätestens wenn das erst Mal etwas schief geht) im guten alten "Blame Game" wiederfindet. Dort wieder heraus zu kommen und belastete Beziehungen zu reparieren ist schwieriger als von Anfang an eine geteilte Verantwortung zu etablieren, in der Fehler erlaubt sind und vom gesamten Team getragen werden.

3. Hol dir externe Hilfe wenn du sie brauchst

Es ist keine Schande, wenn man sich Hilfe holt! Erkennt man, dass Erwartungen nicht erfüllt werden können, weil zum Beispiel zu wenig Erfahrung oder Skills vorhanden sind, dann sollte man sich entsprechende Hilfe holen. Man muss ja nicht gleich einen Experten einstellen, nur weil man einmal Hilfe braucht. Es gibt viele Freelancer, die punktuell aushelfen können. Selbiges gilt für Know How. Schulungen, Trainings und Beratungen können Wissenlücken füllen. Natürlich ersetzt das nicht die eigenen Erfahrungen, aber es ist ein guter Startpunkt, um Wissen in neuen Themen zu generieren.

Kenne deine Vision und dein MVP

Egal wie gut dein Team ist, wenn es nicht weiß wo es hin soll, wird es nie dort ankommen. Hier ein paar Tipps um Klarheit bezüglich den Zielen zu erzeugen.

4. Veranstalte ein Kickoff und bring die Vision in die Köpfe der Leute

Einer der Knackpunkte jedes Vorhabens ist, dass alle Beteiligten dieselbe Vorstellung haben, wo die Reise hingeht. Jeder einzelne muss verstehen, welche Problemstellungen für welche Nutzergruppen gegeben sind und wie diese gelöst werden sollen. Ein gut vorbereitetes Kickoff Event in dem Vision, Mission und Strategie vom Auftraggeber klar dargelegt und diskutiert werden ist der Ideale Startpunkt eines Projektes und verhindert, dass in eine falsche Richtung gearbeitet und Zeit verschwendet wird.

5. Starte mit einem klarem und erreichbaren Ziel

Die Vision zu verinnerlichen ist oft noch nicht genug, weil es auch mit Vision schwer sein kann, den Fokus auf ganz konkrete Schritte aufrecht zu erhalten. Daher sollte immer ein klares, greifbares und in angemessener Zeit erreichbares Ziel definiert sein. Das kann ein MVP (Minimum Viable Product), ein Walking Skeleton, ein PoC (Proof of Concept), ein Spike oder ähnliches sein. Hauptsache es ist so klar definiert, dass man konkret und fokussiert daran arbeiten kann.

Ein guter Weg um ein derartiges Ziel zu definieren ist das User Story Mapping. Mit dieser Methode beleuchtet das gesamte Team die beteiligten Personas und die wichtigsten Use Cases. Das Ergebnis sind im Idealfall schon die groben Überschriften der User Stories und Klarheit darüber welche Features notwendig sind und welche optional.

Ist das Thema sehr umfangreich oder komplex, eignet sich auch ein Design Sprint um ein MVP zu erarbeiten. Während ein User Story Mapping in maximal einem Tag erledigt ist, nutzt man im Design Sprint ganze 4 Tage um einen Prototypen zu erarbeiten und mit echten Usern zu validieren. Für uns bei der openFORCE hat sich die Methode als effektivste herauskristallisiert um erfolgreich in ein neues Thema zu starten.

An dieser Stelle fragt sich sicher der ein oder andere, wieso man bei der Definition des MVPs schon das gesamte Team involviert. Das kann man doch super vorbereiten und dann einfach präsentieren, oder? Genau hier liegt der Knackpunkt! Umso stärker man alle einbindet und umso intensiver alle beteiligt sind, desto mehr Klarheit besteht im Nachgang. Du willst, dass sich alle Beteiligten mit dem Vorhaben identifizieren, dass es IHR Produkt ist, dann werden sie Großartiges leisten!

6. Verschaffe dir Klarheit über den Umfang und die Funktionen des MVP

Es hat sich bewährt, das MVP grob zu schätzen. Die Wichtigkeit von Schätzungen kann man im agilen Kontext natürlich diskutieren, aber es hat sich für uns gezeigt, dass es Sinn macht. Zum einen geht man deutlich tiefer in die Details und findet dadurch noch viele Fragen und Doings, zum anderen ist es wichtig, Klarheit über den groben Zeithorizont zu haben um damit auch gut umgehen zu können. Je nachdem wie wichtig die Erreichung eines Termins ist, würde ich an dieser Stelle auch empfehlen den Fortschritt mittels BurnUp Chart zu tracken.

Trotzdem darf man nicht zu viel Aufwand mit der Schätzung betreiben! In den letzten Projekt haben wir uns in etwa 2 Stunden Zeit genommen. Wenn du deutlich länger brauchst, dann ist das zu erreichende Ziel vielleicht schon zu groß, oder du gehst einfach zu tief ins Detail.

7. Starte mit UI/UX, um deine User zu verstehen

Wirklich sehr geholfen hat bei den bisher beobachteten Projekten die frühe Auseinandersetzung mit dem Frontend. Mittels Klick-Prototypen, den wir mit Unterstützung eines UI/UX Experten erstellten, konnten wir das Verständnis für die User vertiefen und hatten früh eine Möglichkeit um Feedback einzuholen. Außerdem ist es immer praktisch etwas Sichtbares und Greifbares als Diskussionsgrundlage zu haben. Funktionalität zu beschreiben ist sooo viel schwieriger als sie zu zeigen!

Auch bei diesem Punkt hat sich der Design Sprint für uns bezahlt gemacht, weil das Ergebnis ein Prototyp ist, mit dem man großartig weiter arbeiten kann und auch Missverständnisse vermeiden kann.

Forme ein Team und richte es aus

Eine der größten Stärken der agilen Arbeitsweise ist der Fokus auf die Arbeit als Team. Gerade wenn ein Team neu gebildet wird, kann es aber schnell zu Reibungen kommen. Hier ein paar Tipps wie du das schon früh verhindern kannst.

8. Setze alle Strukturen auf, die du benötigst

Auch um ein agiles Projekt erfolgreich abwickeln zu können benötigt es Strukturen. Welche Rollen sind vorhanden und was sind die Erwartunghaltungen an die Rollen? Wo werden Dinge dokumentiert? Wo findet sich 'die Wahrheit'? Welche Kommunikations- und Kollaborationstools werden genutzt und wie? Haben wir alles was wir brauchen, oder fehlt etwas Wichtiges?

Ein vielgehörter Kritikpunkt an klassischer Projektorganisation ist, dass zu viele unnötige Strukturen vorhanden sind. Wie passt das jetzt zusammen? Ich denke, den größten Fehler macht man, wenn Strukturen vereinheitlicht und allen aufgezwungen werden. Es braucht ein gewisses Maß an Strukturen, aber diese müssen von den Beteiligten geowned werden um effektiv zu funktionieren. Daher macht es Sinn, die Strukturen gemeinsam zu erarbeiten und individuell an das Projekt anzupassen. Wenn es schon Best Practice Beispiele im Unternehmen gibt, kann man sich daran orientieren. Jedoch ein aufgezwungenes Standard Dokument, an das niemand glaubt, wird nicht den erwarteten Effekt bringen (z. B. Reports, Architekturdokumente, Boards usw.). Viel eher sollte man sich fragen, was der Zweck dahinter ist und prüfen, ob dieser Zweck relevant und wenn ja auch erfüllt wird.

9. Wende erstmal Scrum nach Lehrbuch an, du kannst es später deinen Bedürfnissen anpassen

In der openFORCE ist Scrum nicht per se vorgegeben, aber die Elemente aus Scrum existieren hier nicht zufällig. Jedes Meeting und jede Rolle erfüllt im Entwicklungsprozess seinen Zweck. Daher haben wir entschieden, dass Projekte grundsätzlich sauber nach Scrum gestartet werden. Das fällt uns leicht, weil wir damit vertraut sind und die wichtigsten Bereiche damit auch abgedeckt sind. Gerade am Anfang halten wir die Iterationen kurz und beobachten, ob Scrum wirklich geeignet ist. Wenn es dann Anpassungen oder ein anderes Vorgehen braucht, kann man das im zweiten Schritt immer noch ändern.

10. Vereinheitliche den Entwicklungs Prozess

'It works on my machine' ist ein berühmt-berüchtigter Satz den man immer wieder von Entwicklern hört. Will man diese Aussage vermeiden, empfiehlt es sich eine einheitliche Entwicklungsumgebung zu nutzen, welche auch nahe an der Produktionsmgebung ist. Auch der Einsatz von Docker und Infrastructure as Code tragen hier zur Klarheit und effektivem Arbeiten bei.

11. Definiere und lebe deinen Build Prozess

Dasselbe gilt für den Build Prozess. Wenn jedes Teammitglied seinen eigenen Weg hat, Code in eine Umgebung zu deployen, dann sind Fehler garantiert. In einem modernen Setup müssen Build und Deployment Prozesse hoch automatisiert sein und einfach funktionieren. Das ist zwar auch mit initialem Aufwand verbunden, dieser macht sich auf jeden Fall bezahlt und ist ein grundlegender Enabler für iteratives Arbeiten.

12. Schaffe Verständnis für die Architektur

Genau wie die fachliche Vision des Produktes muss auch die technische Vision in die Köpfe der Leute. Alle müssen dasselbe Zielbild für die Architektur haben und dieses auch leben. Das schönste Architekturdokument hilft nichts, wenn es nicht verinnerlicht wurde! Das arc42 Framework ist hier definitiv ein guter Startpunkt. Es wirft Fragen auf deren Beantwortung sinnvoll ist und Mehrwert bringt. Doch auch hier gilt wieder, dass man niemanden zwingen sollte, alles vollumfänglich zu beantworten und zu dokumentieren. Viel besser ist, sich im Team bewusst und bezogen auf das Projekt zu einigen was gebraucht wird und was nicht.

13. Etablieren eine gute Fehlerkultur

Nur wenn Fehler erlaubt und sogar willkommen sind, werden Menschen mutig agieren und über ihre Grenzen hinauswachsen. Aus Fehlern kann man so viel lernen und am meisten lernt man, wenn man den Fehler selbst gemacht hat! Natürlich ärgert man sich auch mal, aber wenn man sie gänzlich verhindern will kommt man nicht vom Fleck. Schlimmer noch sind Kulturen in denen Fehler bestraft werden. Schnell werden sich alle auf Rollen, Prozesse und Verantwortungen zurückziehen und Dienst nach Vorschrift machen. Emotionale Sicherheit ist hier ein Schlüsselfaktor für motivierte Teams die gerne auch Verantwortung übernehmen und über sich hinauswachsen.

Klingt ja irgendwie einleuchtend, aber wie geht das konkret? Hier ein paar Tipps die du seeeeehr einfach ausprobieren kannst:

  • verschwende keine Zeit damit den Schuldigen zu identifizieren, sondern frage, wie WIR in Zukunft GEMEINSAM verhindern, dass der Fehler wieder passiert
  • mach dir selbst bewusst, dass es vollkommen OKAY ist Fehler zu machen!
  • schiebe die Schuld für deine Fehler nicht auf andere oder das System, sondern übernimm die Verantwortung dafür und stehe dazu
  • stehe nach außen zu den Fehlern deines Teams und teile die Verantwortung --> nicht der konkrete Kollege hat den Fehler gemacht, sondern WIR haben als Team den Fehler gemacht!
  • fokussiere dich immer auf die Lösung des Problems und halte dich nicht zu sehr mit der Analyse auf

14. Nutze Technologien, mit denen du vertraut bist

Die meisten Entwickler freuen sich, die neuesten Technologien einsetzen zu können. Eine neue Technologie zu beherrschen ist unter Umständen aufwändig und kann daher ineffizient sein. Nutzt man hingegen immer nur dieselbe Technologien, kann das zwar sehr effizient sein, man verpasst aber auch schnell Chancen und wird auf lange sicht erst wieder ineffizient. :-D

Man muss auch hier eine Balance finden und sich an den Anforderungen der zu bauenden Software orientieren. Es zahlt sich auf jeden Fall aus zu recherchieren, ob es zur Lösung eines bestimmten Problems eine optimale Technologie gibt. Es gilt abzuwägen, ob der Vorteil dann auch die Einarbeitung wert ist oder ob an anderen Stellen Probleme entstehen können. Bewährt hat sich für uns eine gesunde Mischung aus gut Bekanntem und Neuem.

15. Nutze Spikes, um die Technologien und die Lösung zu erkunden

Wenn man eine neue Technologie oder Architektur nutzen will, sollte man so schnell wie möglich die kritischsten Problemstellungen mit Spikes oder PoCs erkunden und validieren, ob der erwartete Nutzen auch wirklich gegeben ist. Je länger man damit wartet, desto teurer kann ein Umstieg werden!

Plane im richtigen Ausmaß

Planen, das ist doch was für den Wasserfall, oder? So ganz ohne Vorbereitung und Planung wirst du dir auch mit agilen Methoden schwer tun. Die Kunst ist das optimale Maß zu finden. Hier sind 3 Tipps dazu.

16. Finde die Balance zwischen Planung und Abarbeitung

Ich habe Projekte erlebt, in denen man zu blauäugig in die Umsetzung gegangen ist, zu wenig vorbereitet hat und sich dann gewundert hat, dass man sich im Kreis dreht. Andere Projekte kommen nicht vom Fleck, weil man erst beginnen will, wenn alles perfekt ausdefiniert ist.

Leider habe ich an dieser Stelle aber auch keine pauschale, praktische Antwort wie man die richtige Balance findet, denn es ist stark vom Projekt bzw. dem Produkt abhängig wie viel man im Voraus planen sollte. An der Stelle ein Verweis auf Tipp 5. und ein paar Fragen, die man sich stellen kann:

  • Kann ich mit dem was ich jetzt weiß ein MVP planen?
  • Wo geht die Reise langfristig hin?
  • Kann ich nächste Schritte auf dem MVP aufsetzen ohne alles umwerfen zu müssen?

Hat man ein klares MVP vor Augen und ist das Team im Stande, eine Grobschätzung dafür abzugeben, sind das schon einmal gute Zeichen. Dass man genug hat, um loszulegen. Die Details kann man sich meistens unterwegs ansehen. Es macht auf jeden Fall Sinn, schon bei der Grobschätzung abzufragen, welche die kritischen Anforderungen sind und diese dann auch zu priorisieren. Bewährt hat sich auch ein UI/UX Prototyp, denn der kann sehr schnell vermitteln, worum es eigentlich geht!

17. Beschäftige dich im richtigen Ausmaß mit Architektur und Datenstrukturen

Ähnlich verhält es sich mit der Architektur und den Datenstrukturen. Diese auf Punkt und Komma vorzudefinieren ist meistens nicht praktikabel. In kleinen Projekten hat sich das aber auch schon bewährt. Wichtig ist vor allem, dass allen die Idee und die Struktur hinter der Architektur und den Datenstrukturen klar ist, dann wird es auch im Umgang damit zu keinen Problemen kommen.

18. Achte darauf, zumindest für den nächsten Sprint klare und abgestimmte Anforderungen zu haben

Um es auch mal ganz konkret zu machen: Zumindest für den nächsten Sprint solltest du immer genug fertige Anforderungen haben, weil du sonst Gefahr läufst, keine Arbeit für deine Entwickler zu haben! Das führt dann schnell zu Chaos und überhasteten Abstimmungen, die keine guten Anforderungen zur Folge haben.

Fazit

Die Startphase ist richtungsweisend für das gesamte Projekt. der Grundstein für eine partnerschaftliche Beziehung zum Kunden wird gelegt und gegenseitiges Vertrauen aufgebaut. Wenn man es schafft, alle Beteiligten auf das gemeinsame Ziel auszurichten, gemeinsame Strukturen zu schaffen und eine gute Balance zwischen Planung und Umsetzung zu finden, dann steht einem erfolgreichem agilen Projekt nichts mehr im Weg. ;-)