Das Jahr 2013 ist noch frisch. Zeit, sich Gedanken über die Realisierung einiger guter Vorsätze zu machen. Zum Beispiel wie Sie Ihr Software-Projekt, das Sie gerade durchführen oder planen durchzuführen, noch besser aufgleisen können.
Sind Sie bereit für 11 Maßnahmen & Tipps, Ihr Projekt zu verbessern? Dann los:
1. „Sprint 0“ zum Aufsetzen des Projekts
Zu Projektbeginn ist es üblich, eine Art „Sprint 0“ zum Aufsetzen des Projekts durchzuführen. Was charakterisiert diesen „Sprint 0“?
Zunächst einmal hat der Sprint 0 eine feste Länge, zum Beispiel 14 Tage analog der weiteren rhythmischen folgenden Sprints. Es müssen nicht alle Mitglieder des Kernteams in diesem Sprint 0 mitarbeiten. Im Sprint 0 wird alles vorbereitet, was für einen gleitenden Start des Projekts wichtig ist:
- die ersten Anforderungen für die kommenden Sprints werden gemeinsam mit dem Kunden festgelegt und priorisiert. Hierzu dienen Anforderungsworkshops mit dem Kunden und seinen Stakeholdern
- in einem Projekt, das auf einem Framework oder einer Applikation aufsetzt, kann diese schon mal in einer Grundinstallation installiert und konfiguriert werden
- zur kontinuierlichen Einhaltung der Programmierstandards können Continuous Integration Systeme bereit gestellt und konfiguriert werden
- die virtuellen Maschinen der Entwickler werden vorbereitet und einsatzfertig gemacht
- mit dem Kunden wird bereits das Aufsetzen und die Installation einer Staging-/Test-Umgebung besprochen
- alle weitere beteiligten Projektpartner wie Designagentur, Hoster, ERP-Dienstleister etc. werden zu Beginn mit ins Boot geholt
- mit dem Kunden werden die Standards im Projekt erarbeitet und festgelegt: brauchen wir ein Betriebshandbuch? Auf welche Systeme brauchen Dienstleister & Kunde Zugriff? In welchem Rhythmus werden Reviews durchgeführt? Will der Kunde bei den Daily Standups mit dabei sein (telefonisch)?
Damit wird die Grundlage für eine erfolgreiche Projektdurchführung gelegt. Sicher gibt es noch weitere Punkte, auf die zu achten ist und die im Sprint 0 besprochen werden können. Wie sind Ihre Erfahrungen? Lassen Sie es mich in den Kommentaren wissen!
2. gleich bleibendes Kernteam im Projekt belassen
In Agenturen scheint es üblich zu sein, dass die beteiligten Entwickler von Kunde zu Kunde wechseln und häufig in mehreren Kundenprojekten gleichzeitig involviert sind. Dies ist schädlich – sowohl für die Agentur als auch für die beteiligten Kunden.
Warum? Zu häufige Kontextwechsel schaden beim effektiven Durchführen von Arbeiten. Als Entwickler muss ich dann zig mal meine Umgebung wechseln und mich in das Projekt neu hineindenken. In komplexen, für die Unternehmen wichtigen Projekten, geht so sehr viel Zeit verloren. Möglicherweise entstehen auch Fehler, weil der Entwickler in zu vielen Projekten gleichzeitig ist.
Achten Sie daher als Kunde darauf, dass Sie ein möglichst festes Team vom Dienstleister gestellt bekommen. Natürlich bedeutet dies auch, dass Sie dementsprechend mit gleich bleibenden Teamkosten pro Monat zu rechnen haben. Doch dies kann lohnenswert sein – schließlich wollen Sie nicht einfach nur Projektstunden verbrennen, sondern einen möglichst hohen Gegenwert bekommen.
Wie gehen Sie dann mit Schwankungen um? Es hat sich gezeigt, dass ein Team nicht zu groß sein sollte, um noch wendig genug zu sein. Die Formel heißt 5+-2, also zwischen 3 und 7 Team Mitglieder in einem Entwicklerteam. In größeren Teams sollte man die Gruppe splitten. Je nach Komplexität des Projekts kann es sinnvoll sein, lieber mit dauerhaft 3 (oder 5) Entwicklern zu arbeiten statt ständig Schwankungen zu produzieren.
ProTipp: Schwankungen entstehen oftmals dadurch, dass der Stream an Anforderungen unklar ist. Der Kunde kommt möglicherweise in der Erstellungen der Anforderungen nicht hinterher. Hier können Dienstleister unterstützen, indem sie kontinuierlich für und zusammen mit dem Kunden planen, und ggf. das Kernteam passend sizen.
Welche Erfahrungen haben Sie hierzu gemacht? Lassen Sie es mich in den Kommentaren wissen!
3. Daily Standups im Entwicklerteam (und mit dem Kunden)
Sind wir nicht alle ein bißchen Agil? Eines der Kernelemente agiler Teams ist das Daily Standup. In diesem, maximal 15 Minuten dauernden täglichen Standup Meeting (alle stehen) beantwortet man sich gegenseitig folgende Fragen:
- Was habe ich gestern erreicht?
- Was möchte ich heute erreichen?
- Was sind die Dinge, die mir im Weg stehen?
Der Coach des Teams (der sogenannte Scrum Master) kümmert sich darum, dass das Daily Standup stattfindet. Er kümmert sich auch darum, dass die Dinge, die den Team Mitgliedern im Weg stehen, festgehalten und zeitnah gelöst werden.
Welchen Nutzen ziehen Sie als Kunde und als Dienstleister daraus? Als Kunde, sofern Sie an dem Daily Standup teilnehmen können (telefonisch geht durchaus auch, hier haben wir gute Erfahrungen gemacht), bekommen Sie mit, an welchen Dingen das Team gerade arbeitet, welche Sachen beim Vorankommen der geplanten Anforderungen im Weg stehen und was für heute auf dem Programm steht. Sie bekommen transparente Einsicht in das Projektgeschehen. Da Sie nur an der Außenlinie stehen, sind Diskussionen im Daily Standup tabu.
Als Dienstleister und beteiligter Entwickler bekommen Sie ebenfalls Transparenz ins Projektgeschehen. An welcher Funktion arbeitet mein Kollege gerade? Hat er möglicherweise Schwierigkeiten in der Implementation, bei dem ich ihm mit meinem Wissen helfen kann? Wissen meine Kollegen, dass ich an der Schnittstelle XYZ arbeite, so dass sie darauf aufbauen und diese Schnittstelle nutzen können?
Durch das Mehr an Transparenz entsteht ein Informationsfluss, der einzigartig ist. Durch die Integration des Kunden im Daily Standup (der nicht notwendigerweise jeden Tag daran teilnehmen muss), passiert Informationsaustausch automatisch.
Vorbei sind also die Zeiten wöchentlicher „Status Telkos“ mit dem Kunden, um sich vom Projektstatus berichten zu lassen. Lassen Sie Ihren Kunden am Daily Standup teilnehmen!
Wie handhaben Sie dies in Ihren Projekten? Lassen Sie es mich in den Kommentaren wissen.
4. Retro und Maßnahmenboard
Wie im Artikel „Das Maßnahmenboard“ beschrieben, eignet sich solch ein Maßnahmenboard gut dazu, um aufgekommene Punkte aus den Team-Retrospektiven festzuhalten, sich daran zu erinnern und natürlich auch an den Maßnahmen zu arbeiten.
Häufig ist es so, dass man in einem Meeting Änderungen im Team bespricht, die Energie fliesst, alle sind motiviert. Doch wenn man aus dem Meeting kommt, bleibt häufig alles beim Alten. Damit es nicht dazu kommt, ist es hilfreich, sich die besprochenen Änderungspunkte auf einem Maßnahmenboard zu notieren und kontinuierlich abzuarbeiten.
Das vorgestellte Maßnahmenboard geht sogar einen Schritt weiter: bevor eine Maßnahme als „erledigt“ gilt, muss sie insgesamt vier Mal umgesetzt werden (und damit immer eine Spalte weiter nach rechts verschoben werden). Ist auch nur eine Person im Team der Meinung, dass die Maßnahme nicht/nicht gut umgesetzt wurde, kann sie nicht weiter geschoben oder sogar nach links zurück geschoben werden.
So erhalten Sie ein ideales Hilfsmittel, mit dem Sie Ihre Maßnahmen umgesetzt bekommen und dabei für alle Team-Mitglieder eine transparente Übersicht ermöglichen.
Haben Sie auch schon mal an den Einsatz eines Maßnahmenboards gedacht oder nutzen solch eins sogar? Lassen Sie mich in den Kommentaren wissen, wie Ihr Setup aussieht!
5. gleich bleibender Rhythmus/Takt
In der Maßnahme zur Größe des Teams habe ich davon geschrieben, wie wichtig es ist, dass die Teamgröße möglichst gleich bleibt. Wichtig ist dabei auch, dass ein möglichst gleicher Rhythmus/Takt in der Abarbeitung der Aufgaben existiert.
In Online-Projekten ist es mittlerweile üblich, dass es 14-tägige Rhythmen gibt. Für jedes dieser Rhythmen (Sprint genannt) wird vorab eine Planung mit dem gesamten Team gemacht, welche Funktionen in den kommenden 14-Tagen realisiert werden sollen. Damit stehen feste Aufgabenpakete für den immer gleichen Takt (14 Tage) zur Verfügung.
Mit dem festen Takt – ganz gleich ob eine, zwei oder drei Wochen – erreichen Sie einen kontinuierlichen Fluss in der Aufgabenbearbeitung. Das Team kann in den Flow kommen. Und damit die Aufgaben deutlich effektiver abarbeiten als ständig wechselnde Projektrhythmen.
Arbeiten Sie mit regelmäßigen Rhythmen? Wie lang sind diese Sprints? Lassen Sie es mich in den Kommentaren wissen.
6. kontinuierliche Planung statt großer Einmal-Planung
Die Literatur ist voll davon, dass eine „große Einmal-Planung“ in der Hauptsache dazu hilfreich ist, das Projekt zum Scheitern zu bringen oder eine Menge Papier für Ablage P zu produzieren, da sich die Anforderungen sowieso regelmäßig ändern. In Zeiten globaler Märkte und unsicherer Zeiten ist dies so. Deswegen sind agile Methoden hilfreich, um Projekte zum Erfolg zu bringen.
Doch wie können Sie Ihre Einmal-Planung durch etwas anderes, hilfreicheres ersetzen? Indem Sie kontinuierlich planen. Es ist nützlich, zu Beginn durchaus Arbeit in Konzeption, insbesondere auch die Vision Ihres Projekts/Produkts, zu stecken. Doch irgendwann erreichen Sie den Punkt des „just good enough“. Ab diesem Punkt ist es hilfreich, sich einen Dienstleister mit ins Boot zu nehmen, der mit Ihnen zusammen agile Funktionspakete schnürt. Idealerweise sollte das der Dienstleister sein, der die spätere Umsetzung übernimmt, denn während dieser kleinteiligen Planungsphase ist es bereits hilfreich zu verifizieren, inwieweit sich Ihre Wünsche technisch gut umsetzen lassen.
Auch diese „agilen Funktionspakete“ sollten nur insoweit reichen, als dass sich zwei oder 3 Sprints gut vorab überblicken lassen. Wir wissen, dass wir heute nicht wissen können, was in drei oder vier Monaten ist. Es ist vergebene Liebesmüh bestimmen zu wollen, wie Ihre Plattform in einem halben Jahr aussieht – mit Sicherheit werden sich über die Zeit Anforderungen ändern.
Und genau kommt hier der Dienstleister als „Projektassistent“ ins Spiel: er steht Ihnen zur Seite, um kontinuierlich mit Ihnen und Ihren Stakeholdern die Anforderungen zu planen und so in kleine Häppchen zu zerteilen, dass Sie vom Entwicklungsteam gut in einem Sprint-Rhythmus umsetzbar ist. Er wird dafür sorgen, dass die für Sie hochwertigsten Anforderungen zu Beginn umgesetzt werden und Sie somit einen hohen ROI und eine kurze Time-to-Market erreichen.
Binden Sie Ihren Dienstleister also frühzeitig in die Projektkonzeption mit ein. Während dieser Phase haben Sie auch bereits die Chance, Vertrauen für die Realisierung des Projekts weiter aufzubauen.
Wie gehen Sie mit Ihren Planungen um? Lassen Sie es mich in den Kommentaren wissen!
7. Expectation Management mit dem Kunden betreiben
Kennen Sie das? „Wann wird die Software fertig?“, „Können wir dieses Feature-Set bis Weihnachten bekommen?“ Wer das Video aus einem meiner letzten Beiträge zu den Aufgaben/der Verantwortung eines Product Owners gesehen hat, weiß worauf ich anspiele.
Auf Dienstleister-Seite ist es wichtig, kontinuierliches Expectation Management mit dem Kunden zu betreiben.
Doch vorab noch eine Information an die Kunden unter den Lesern: fixe Sicherheit mit Garantien gibt es nicht. Lösen Sie sich davon!
Was es stattdessen gibt, sind Korridore. Korridore von Zeit oder Feature-Sets, die mit Wahrscheinlichkeiten kleiner 100% eintreffen können.
Für uns als Dienstleister ist es hingegen wichtig,
- transparent diese Korridore zu kommunizieren
- die Korridore möglichst klein zu halten
- mit dem Kunden gegebenenfalls weitere Maßnahmen zu besprechen, zum Beispiel Repriorisierung von Funktionalitäten
Diese Aufgabe führen wir kontinuierlich durch. Bei einem eingeschwungenen Entwicklungsteam ist es daher möglich, vorauszusehen, wann welche Funktionalität in der Zukunft zur Verfügung stehen wird. Hier sollte man möglichst eine Vorausschau auf die kommenden 2-3 Sprints bieten.
8. regelmäßige Reviews der Funktionalitäten
Das Projekt wurde in kleine, rhythmische Einheiten (Sprints) eingeteilt. Vor Beginn einer neuen Einheit wurde mit dem Team geplant, was zu erledigen ist.
Doch wurde auch alles geschafft? Dazu dienen die regelmäßigen Reviews, bei denen Sie sich mit dem gesamten Team zusammensetzen und alle Anforderungen durchgehen, die im vergangenen Sprint geplant waren.
Idealerweise finden Sie sich im Konferenzraum zusammen. Ein Beamer steht bereit, das Team gibt Ihnen ein walk-through durch die realisierten Anforderungen. Es prüft mit Ihnen zusammen die Akzeptanzkriterien, die hinter jeder einzelnen Anforderung stehen. Nur Sie entscheiden, ob Sie eine realisierte Aufgabe akzeptieren oder nicht. Konnte sie nicht akzeptiert werden, so plant das Team idealerweise diese Aufgabe in den kommenden Sprint ein.
So sorgen Sie dafür, dass Sie Software von guter Qualität bekommen. Und in diesen regelmäßigen Meetings (also zum Beispiel alle 14 Tage) sehen Sie auch kontinuierlichen Fortschritt.
ProTipp: wenn Sie sich nicht mit dem Team treffen können, führen Sie stattdessen eine Videokonferenz durch. Lassen Sie solch ein Review Meeting nicht ausfallen. Bestimmen Sie ggf einen Vertreter, der Ihre Funktion wahrnimmt. So erhalten Sie sich einen kontinuierlichen Projektfluss.
ProTipp 2: machen Sie alle Informationen transparent. Idealerweise stellt Ihnen der Dienstleister Zugänge zu einem Wiki zur Verfügung, in das natürlich auch alle Informationen, Meeting Protokolle etc. landen.
9. regelmäßig technische Schulden abbauen
Schulden mögen wir alle nicht besonders gerne. Und dennoch entstehen sie auch in Software. Altern Teile der Software vor sich hin, entstehen technische Schulden. Wurde „auf die Schnelle“ eine Funktion reingehackt (aus welchen Gründen auch immer), so entstehen technische Schulden.
Technische Schulden bedeutet, dass das Verändern der Software, also zum Beispiel das Ändern von bestehender oder Hinzufügen neuer Funktionalität über die Zeit immer teurer wird. Irgendwann erreicht man den Punkt, an dem der Abriss der Software droht: Änderungen an der Software sind so teuer, dass es sich nicht mehr lohnt, hier rein zu investieren.
Lassen Sie es nicht dazu kommen. Planen Sie als Kunde (!) regelmäßig das Abarbeiten technischer Schulden in den Projektrhythmus ein. Immer einen kleinen Teil an Softwarewartung, so dass der Motor wieder wie geölt funktioniert. Das bedeutet nicht unbedingt, dass Ihr Dienstleister schlecht arbeitet. Software ist in der Regel komplex herzustellen und wenn man äußere Umstände (wenig Zeit/Budget, „machen wir später mal“, „da sieht der GF ja nix an neuen Features“) berücksichtigt, entstehen zwangsläufig technische Schulden.
Überlegen Sie zusammen mit Ihrem Dienstleister, wieviel Projektbudget es kontinuierlich braucht, um den regelmäßigen Frühjahrsputz durchzuführen. Belohnt werden Sie dadurch, dass Sie weiterhin eine Software haben, die gut funktioniert und Ihnen für Ihr Business weiterhin nützlich ist.
Wie häufig planen Sie den Frühjahrsputz in Projekten ein? Auf welche Schwierigkeiten stoßen Sie in der Planung und mit welchen Einwänden begegnen Sie diesen Widerständen? Ich freue mich, mehr darüber in den Kommentaren zu erfahren.
10. Team OffSite / Launch Party durchführen
Work hard, play hard. Das Team hat die letzten 9 Monate an der für Sie kritischen Software gearbeitet. Der große Launchtermin zur Messe naht, Sie sind mit den Features on time, Ihre Stakeholder im Unternehmen/Konzern sind zufrieden.
Es ist Zeit, den Kopf frei zu bekommen. Uns alle für die harte Arbeit der vergangenen 9 Monate zu belohnen. Glücklicherweise haben Sie im Gesamtbudget einen kleinen Teil reserviert, um mit allen beteiligten Parteien – alle Dienstleister, Stakeholder, Projektbeteiligte – eine Launch-Party zu feiern. Gönnen Sie es sich und Ihren Projektpartnern.
Ganz gleich wie groß oder klein das Budget ist (ideal ist, wenn Kunde und Dienstleister sich das Budget teilen): die Geste zählt. Auf solch einer Launch-Party wird neue Energie getankt. Man kommt ins Gespräch. Neue Ideen für coole, werthaltige Features werden geboren, auf die sonst niemand im Büro gekommen wäre.
Ist es nicht schön zu wissen, dass die beteiligten Partner für Ihr Projekt brennen? Ich freue mich auf Anekdoten Ihrer Launch-Parties in den Kommentaren.
11. Kanban für die Phase der Softwarepflege vorsehen
Der große Sturm ist vorbei, die ersten Releases sind gemacht. Ist Ihr Projekt damit zu Ende, so wie es die Definition von „Projekt“ uns glauben machen will? Nein. Software läuft weiter, wird jahrelang betrieben (10, 15 oder mehr Jahre sind keine Seltenheit, auch im schnellen Internet-Zeitalter). Hierbei wird natürlich auch weiter in die Software investiert, denn ohne Investition entstehen über die Zeit technische Schulden – ein sicherer Weg in das Ende eines Projekts, ein Ende mit Schrecken.
Wenn keine großen Funktionen mehr geplant sind, sondern nur noch Softwarepflege betrieben wird, so kann dies über Kanban organisiert werden. Im Wesentlichen besteht Kanban aus einem Board mit verschiedenen Spalten, die den „Value Stream“ im Projekt beschreiben. Typischerweise „TODO“, „Work in Progress“, „Done“.
Kanban wäre nicht Kanban, wenn eine wichtige Eigenschaft fehlen würde: „Limit Work in Progress“. Man definiert also für jede Spalte, wie viele Karten (Aufgaben) man gleichzeitig bearbeiten möchte.
Kanban wird nicht nur gerne in der Systemadministration eingesetzt, sondern eignet sich eben auch gut für Maintenance-Phasen in Projekten. Aufgaben kommen herein, werden priorisiert und geplant und entsprechend abgearbeitet. Währenddessen kann das Team parallel auch noch an anderen Projekten arbeiten.
Zusammenfassung
Waren die Tipps für Sie hilfreich? Welche Erfahrungen haben Sie in Ihren Projekten – ganz gleich ob auf Seite des Kunden oder des Dienstleisters – gemacht? Lassen Sie es mich und die Leser in den Kommentaren wissen!
Schreibe einen Kommentar