Henry Schaffner sagte einst: „Manche Praxis ist der Alptraum der Theorie“. Auch Scrum bleibt, wie sollte es anders sein, nicht von diesen Alpträumen verschont. Insbesondere dann, wenn Scrum in kleinen Projekten mit geringen Budgets und knappen Ressourcen eingesetzt werden soll, ist die Praxis oft nur ein armseliger Schatten der vielversprechenden Theorie von Scrum.
In diesem Artikel möchte ich eine Idee skizzieren, durch die kleine Projekte mit Scrum besser bearbeitet werden können.
Ist-Situation: Ein kleines Team pro Projekt
Seien wir ehrlich: Das Scrum in Projekten eingesetzt wird, die eigentlich viel zu klein dafür sind, ist Realität. In vielen Teams arbeiten nur zwei oder drei Entwickler. Projekte, in denen der Scrum Master kaum präsent ist, der Product Owner keine Zeit hat sein Backlog zu pflegen, und Zeremonien wegen des (vermeintlich) großen Overhead am Besten gleich ganz ausfallen.
Der Grund für so kleine Teams ist aus meiner Sicht häufig folgender: Im Projekt ist auf der Seite des Kunden zu wenig Dampf. Vielleicht liegt es am zu kleinen Budget, fehlender Entschlossenheit, oder knappen personellen Ressourcen. Letztlich ist es egal, denn auf all das haben wir keinen Einfluss, und wir müssen mit der daraus folgenden Symptomatik umgehen: Es herrscht so wenig Dampf, dass der Kunde nicht genug User Stories für einen Sprint liefern kann, damit ein großes Team daran effizient arbeiten könnte. Es ist einfach nicht genug Arbeit vorhanden, um mehr Entwickler mit Aufgaben zu versorgen. In solchen Projekten fehlt es an Druck.
Selbstredend fehlt es auch an Kapazitäten, um die Ergebnisse ausgiebig zu testen und das Feedback zu generieren, dass wir für ein agiles Vorgehen brauchen, wie die Luft zum Atmen.
Kleine Projekte ohne Druck sind erstmal kein Problem. Es ist eine Tatsache und Realität mit der wir als Dienstleister umgehen müssen. Es kann aber zu einem Problem werden, wenn wir damit falsch umgehen. Eine Reaktion, die ich oft beobachte, ist die Teamgröße auf das Zeit- und Personal-Budget des Kunden in dem Projekt anzupassen. Aber das hat Konsequenzen.
Probleme durch kleine Teams
Die Adaption der Größe des Teams an den „Projektbedarf“ klingt auf den ersten Blick vollkommen einleuchtend. Auch wir bei SALT AND PEPPER Software tun das, und wir haben ein ganze Menge dieser Teams. Ich würde das aber gerne ändern, denn ich sehe eine Reihe von Problemen, die sich durch diese Art der Arbeit ergeben und sowohl den Kunden als auch uns betreffen.
Mangelnde Teamentwicklung
Teamentwicklung kommt in diesen Teams oft zu kurz. Häufig gibt es nur einen Alibi-Scrum Master – gerne auch in Personalunion mit einem der Entwickler. Dieser verbringt kaum mehr Zeit in der Rolle des Scrum Master und seinen Aufgaben, als es für das Durchführen der Zeremonien in Scrum nötig ist. Zeit für die eigentliche Entwicklung des Team bleibt dann nicht. So haben Retrospektiven keinen Effekt und Laufen ins Leere. Als Folge werden diese Retrospektiven nach kurzer Zeit weiter gekürzt, oder ganz ausgelassen.
Geringe Verteilung von Wissen
Das Teilen von Wissen und Erfahrungen sind eine wichtige Aufgabe im Unternehmen. Die beste Form der Wissensverteilung ist die Zusammenarbeit. In kleinen Teams ist diese nur sehr eingeschränkt möglich. Zudem sind zu anderen Wissensträgern mehr Schnittstellen notwendig, an denen es zu Reibungsverlusten beim Transfer von Wissen kommen wird.
Risiko durch geringe Redundanz
In kleine Teams herrscht weniger Redundanz. Ein typisches Szenario: Ein Entwickler im Backend, ein Entwickler im Frontend. Aber was passiert, wenn einer von Beiden ausfällt? Der Bus-Faktor in diesem Teams ist sehr hoch, und das Projekt ist anfällig für Ausfälle. Zu diesem Problem habe ich bereits eine Retrospektive gemacht.
Fehlende Diversität
Fehlende Diversität führt zu schlechteren Lösungen. In komplexen Problemstellungen profitieren wir von hoher Diversität im Team, denn sie führt dazu, dass Probleme und Lösungen aus verschiedenen Perspektiven betrachtet und bewertet werden können.
Mehr Schnittstellen
Kleine Teams sind häufig nicht crossfunktional und können die Lösung nicht vollständig aus sich selbst heraus erstellen und liefern. Es muss Expertise von außen in das Team eingeholt werden, was die Abhängigkeiten erhöht. Die entstehenden Schnittstellen führen zu mehr Reibungsverlusten, die sich oft in Wartezeiten zeigen. Jeder hat sicher schon mal die Spalte „Warte auf Rückmeldung/Needs Info/Angefragt“ auf einem Sprint-Board gesehen. Häufige Kandidaten für externe Expertise sind UI/UX, Testing oder das Deployment.
Lange Laufzeiten
Kleine Projekte laufen unnötig lange. In diesen Projekten werden Mitarbeiter lange in den spezifischen Themen und Technologien des Projekts gebunden. Es wird die Chance verpasst, in gleicher Zeit mehr Erfahrungen in anderen Projekten zu machen.
Wie kann eine Alternative aussehen?
Nehmen wir an, dass die Ursache für die oben genannten Probleme tatsächlich in der Größe des Teams liegen. Dann ist die logische Folgerung stattdessen mit größeren Teams zu arbeiten.
Die Frage die sich dann stellt ist: Wie kann es ohne sinkende Zufriedenheit im Projekt gelingen, große Teams auch in solchen Projekten einzusetzen, die eigentlich zu wenig Druck haben, um diese mit ausreichen Arbeit zu versorgen?
Was ein Team mit einer Dampfmaschinen gemein hat
Nehmen wir zur Veranschaulichung das Bild einer Dampfmaschine, die einen Schmiedehammer antreibt.
In diesem Bild stellt die Dampfmaschine ein großes schlagkräftiges Team da. Das Team ist echt crossfunktional und hat die gewünschten Rollen und Expertise. Damit die Dampfmaschine effektiv arbeiten kann, benötigt sie einen gewissen Druck im Dampfkessel. Dieser Druck entsteht, indem Wasser unter der Hitze des Feuers zu Dampf verdunstet. Das Feuer muss durch ständiges Nachwerfen von Kohlen weiter befeuert werden. Die Kohlen unserer Dampfmaschine sind die Aufgaben und Anforderungen aus dem Projekt, die von dem Kunden in den Ofen der Dampfmaschine geworfen werden.
Das Bild zeigt wie der Druck über die Zeit solange steigt, bis der notwendige Druck entstanden ist, um den Hammer in Bewegung zu setzen und das Werkstück zu schmieden. Leider ist der Kunde nicht in der Lage die Maschine so schnell mit Kohlen zu versorgen, als dass diese über die gesamte Zeit schmieden könnte. Es entstehen so Leerzeiten.
Um diese Leerzeiten zu vermeiden sehe ich drei Optionen:
- Wir passen uns der Geschwindigkeit des Kunden an und nehmen eine kleinere Dampfmaschine. Das ist der oben beschriebene Fall mit all seinen Problemen. Genau das wollen wir nicht mehr.
- Wir sorgen dafür, dass der Kunde die Kohlen schneller in den Ofen schaufelt. Wenn das möglich ist, ist es eine gute Option. Allerdings haben wir darauf kaum Einfluss. Zusätzlich erzeugt dies ggf. Druck beim Kunden, was nicht meinem Verständnis einer Dienstleistung entspricht. Hier muss sich der Kunde dem Dienstleister anpassen. Weiter fürchte ich, dass der Kunde dann einfach minderwertige Kohlen in den Ofen wirft, wodurch unsere Maschine nicht gut arbeitet oder vielleicht Schaden nimmt.
- Die Kohlen werden von mehr als einem Kunden in die Maschine geworfen. Die Maschine arbeitet für mehrere Kunden.
Ein schlagkräftiges Team für mehrere Projekte
Die Maschine für mehrere Kunden arbeiten zu lassen löst dieses Problem elegant. Auf diese Weise können wir eine gute Auslastung der Maschine erreichen.
Das Bild zeigt wie die Leerzeiten der Maschine verschwinden. Mehrere Kunden versorgen die Maschine durchgehend mit ausreichend Kohlen, damit diese effektiv und effizient arbeitet. Die Maschine arbeitet abwechselnd nacheinander für die Kunden.
Übertragen auf die Fragestellung, wie wir es schaffen, große Teams auch in Projekten einzusetzen, die für diese nicht genug Arbeit generieren können, lautet meine Hypothese: Eine sequenzielle Bearbeitung alternierender Projekte ermöglicht, bei mindestens gleicher Zufriedenheit im Projekt, den Einsatz eines großen schlagkräftigen Teams.
Wie könnte dies in der Praxis in einem Vorgehen nach Scrum aussehen?
Das Team arbeitet in den Sprints wechselnd für unterschiedliche Projekte. In jedem dieser Sprints fokussiert sich das Team vollständig auf das jeweilige Projekt, und liefert an dessen Ende ein Inkrement an den Kunden.
Für den Kunden werden die Projekte in Schüben bearbeitet. Zwischen den Schüben ergeben sich Pausen, in denen das Team für andere Projekte arbeitet. Das Team ist während dieser Pause nicht, oder zumindest nur eingeschränkt für den Kunden verfügbar.
Zum Thema Auslastung
Ich möchte ein paar Worte zu dem Thema Auslastung schreiben, da ich fürchte, dass durch das Bild der Dampfmaschine der Eindruck entstehen kann, es ginge hier darum ein Team möglichst durchgehend zu beschäftigen.
Dem ist nicht so. Es geht mir nicht um die Frage wie ich ein Team möglichst durchgehend beschäftigen kann. Eine Vollauslastung wäre kontraproduktiv und schädlich. Das Team braucht Puffer und Slack-Time für Überraschungen und es wäre fatal diesen Freiraum nicht zu lassen.
Mit geht es um die Frage, wie es gelingen kann, für ein Team soviel Arbeit zu „generieren“, dass es in einer sinnvollen Größe daran arbeiten kann, und die beschriebenen Nachteile und Risiken vermeidet. Es geht darum, wie wir unsere Arbeitsweise auf eine andere Art an die Bedürfnisse des Kunden anpassen können und dabei letztlich mehr Zufriedenheit bei Kunde, Team und Unternehmung erreichen.
Pausenzeiten zur Vorbereitung nutzen
Für den Kunden soll durch die jetzt entstehende Wartezeit, in denen das Team für andere Projekte arbeitet, kein Nachteil entstehen. Im Gegenteil: Ich möchte diese Wartezeiten zum Vorteil des Teams und den Kunden nutzen, so dass für den Kunden insgesamt mehr Wert zu höherer Qualität geschaffen werden kann!
Wir nutzen die Pausenzeiten für eine bessere Vorbereitung des Sprints. Durch die Pausen erhält der Kunde Zeit, in der er, durch ausgiebige Tests des Inkrements, das Feedback generieren kann, welches in die Weiterentwicklung der Produktstrategie fließt. Der Kunde kann die Zeit nutzen, um gut aufbereitete User Stories zu formulieren, Ressourcen bereit zu stellen und alles Weitere zu tun, damit in der kommenden Iteration das Team optimal daran arbeiten kann, neuen Wert für den Kunden zu schaffen.
Wie wichtig ausreichend Zeit für die Vorbereitung der Umsetzung ist, lässt sich unter anderen auch in der Shapeup-Methode nachlesen. Diese sieht eine teils mehrwöchige explizite Shaping-Phase vor, in der die Arbeit so gut wie möglich vor der Übergabe an das Team vorbereitet wird.
Vorbereitung unterstützen
Eine gute Vorbereitung scheitert nicht nur aus zeitlichen Gründen. Oft fehlt dem Kunden Verständnis für das allgemeine Vorgehen nach Scrum und den Aufgaben der verschiedenen Rollen.
Ein echter Scrum Master mit genügend Zeit kann den Kunden in der Pause unterstützen und helfen. Er kann
- den Product Owner methodisch befähigen seine Aufgaben gut zu erfüllen.
- auf Impediments hinweisen und bei der Behebung unterstützen.
- zwischen dem Kunden und Team vermitteln, wenn es zu Problemen kommt.
Diese wichtige Unterstützung fehlt in kleinen Projekten, weil das Team zu klein ist, um sich eine spezielle Rollen zu leisten, die diese Aufgabe mit der nötigen Kontinuität und Intensität wahrnehmen könnte. Ein großes Team, welches mehrere Kunden bedient, kann den Einsatz eines solchen Scrum Master gut begründen!
Mehr Schaffen in weniger Zeit
Die grundlegende Annahme bei diesem Vorgehen ist: Ein großes schlagkräftiges Team schafft in einem Sprint mindestens soviel, wie ein kleines Team in mehreren Sprints schafft.
Die Annahme treffen ich aufgrund der folgenden Punkte:
- Zunächst entfallen durch den Einsatz eines großen Teams alle oben genannten Probleme bezüglich fehlender Diversität, Schnittstellen und mangelnder Team-Entwicklung, die sich in kleinen Teams ergeben. Allein schon aus diesem Grund glaube ich, dass das Ergebnis besser sein wird.
- Die Vorbereitung eines Sprints ist qualitativ besser. Das Ziel ist klarer und die User Stories besser ausgearbeitet. Auf dieser Basis kann das Team besser arbeiten.
- Es entsteht ein geschärftes Bewusstsein für die Wichtigkeit einer guten Vorbereitung und der disziplinierten Arbeit des Teams im Sprint. Wenn in der kurzen Entwicklungszeit nicht effektiv gearbeitet werden kann, kostet das wertvolle Zeit und Geld.
Offene Fragen
Ich habe mich zu diesem Vorgehen bereits mit einigen Kollegen ausgetauscht. Neben grundsätzlich guten Feedback sind aber auch einige Fragen aufgekommen. Für einige Fragen habe ich Ideen, aber wir konnten diese nicht in Gänze beantworten. Man wird es ausprobieren müssen, um zu sehen, was funktioniert und was nicht. Trotzdem möchte ich diese Fragen hier nennen, damit der Leser besser beurteilen kann, ob dieses Vorgehen für Ihn funktionieren kann.
Kanban statt Scrum
Ist Scrum wirklich das richtige Vorgehen? Vielleicht eignet sich ein Vorgehen nach Kanban eher an? Die Antwort auf die Frage sollte jedoch nicht von der Größe des Teams abhängen, sondern von der Art der zu erledigen Arbeit. Aber wenn die Arbeitsweise zu Kanban passt, kann es eine gute Alternative zu der hier beschriebenen Idee sein. Die Probleme von kleinen Teams werden zwar nicht adressiert, sind aber vielleicht in derartigen Projekten auch nicht so wichtig.
Regelmäßige Kontextwechsel
Das Team arbeitet in diesem Modell nicht exklusiv für ein Projekt. Es findet mit jeder Iteration ein Kontextwechesel statt, bei dem sich das Team wieder in eine andere Thematik eindenken muss. Wie wirkt sich dieser regelmäßige Wechsel auf das Team und den Mitarbeiter aus?
Kundenakzeptanz
Wie kann es gelingen, dieses geänderte Vorgehen dem Kunden zu verkaufen? Ich sehe viele Vorteile in diesem Vorgehen, aber ich fürchte, dass ein Kunde die entstehende Wartezeit nicht akzeptieren möchte, sondern immer schnelle Reaktionen fordert. Wie begründet sind die Vorbehalte wirklich?
Fehler in der Software
Wie gehen wir mit Fehlern in der Software um? Können wir sicher stellen, dass kritische Fehler schnell behoben werden können? Wie wahrscheinlich ist dieser Fall? Kann uns eine gute Testabdeckung helfen? Wäre eine Fast-Lane eine Option kritische Aufgaben unabhängig von Projekt zeitnah zu erledigen?
Nicht gelieferte User Stories im Sprint
Wie gehen wir damit um, wenn wir aus dem Sprint nicht alle User Stories abschließen und liefern können? Normalerweise könnte eine solche Story im nächsten Sprint zeitnah nachgeliefert werden. Jetzt ergeben sich mitunter längere Wartezeiten.
Betrieb der Software
Wie stelle ich einen einwandfreien Betrieb der Software in den Phasen sicher, in denen das Team eigentlich für ein andere Projekt arbeitet?
