Warum wir für time cockpit nicht Scrum verwenden

Image source: https://flic.kr/p/8QjDJy, under Creative Commons License

Für die initiale Entwicklung von time cockpit vor einigen Jahren haben wir Scrum verwendet. Es gab Zeiten, in denen wir Scrum tatsächlich nahezu wie im Lehrbuch leben konnte, aber mit der Zeit wurden wir etwas nachlässig. Trotzdem funktionierte es ziemlich gut für uns. Jetzt verwenden wir Scrum nicht mehr. In diesem Blogartikel möchte ich beschreiben, warum wir uns davon abgewendet haben und wie wir unsere Entwicklungsprozesse heute managen. 

Wenn Scrum neu für Sie ist, empfehle ich Ihnen den kostenlos verfügbaren Scrum Guide.

Wofür Scrum gut ist

Oft fragen uns Kunden in der Softwarebranche nach Beratungstätigkeiten unabhängig von time cockpit. Manchmal brauchen sie technischen Rat und manchmal haben sie nur Probleme mit ihren Business-Prozessen. Über die Jahre habe ich Scrum sehr vielen Entwicklungsteams während solcher Beratungs-Workshops weiterempfohlen.

Scrum ist meiner Meinung nach eine großartige Lösung für Teams ist mit zumindest einigen der folgenden Probleme:

• Das Team baut unregelmäßig große Versionen. Diese auszurollen ist eine Qual.
• Entwickler tendieren dazu, viele verschiedene Themen anzufangen, kämpfen aber mit der Fertigstellung (und ich meine wirklich Fertigstellung inkl. Dokumentation, Tests, usw.).
• Entwickler verbringen mehr Zeit damit, Löcher in Spezifikationen zu füllen – wenn Spezifikationen überhaupt existieren – als mit Programmieren.
• Die Priorisierung von Features passiert durch Zufall oder basiert auf dem HiPPO Prinzip (Highest Paid Person’s Opinion). 
• Die Software hat Stabilitätsprobleme, da die Qualitätssicherung zugunsten neuer Features verliert. 
• Team-Mitglieder sind latent unglücklich wegen Hürden wie ungeeignete Entwicklungs-Tools, Organisations-Chaos, fehlender Erfolgserlebnisse, usw.

Scrum ist kein Chaos, es ist ein strikt definierter Prozess

Obwohl Scrum eine agile Entwicklungsmethode ist, definiert es ganz klar Prozessregeln und Verantwortlichkeiten die potentiell Probleme, wie die oben erwähnten, lösen können. Viele Teams die aus einem wasserfallartigem Prozess kommen glauben, dass sie mit Scrum alle Prozess-Richtlinien fallenlassen müssen.

Das Gegenteil ist der Fall. Nach meiner Erfahrung sind die Teams normalerweise überrascht von dem strikten Prozess den Scrum ihnen auferlegt.

Also, was ist das Problem mit Scrum?

Notwendigkeit einer geteilten Verantwortlichkeit

Bei software architects sind wir aktuell ein Team von sieben Personen. Klein zu sein gibt uns die Möglichkeit flexibler zu sein als unsere großen Mitbewerber. Anders würden wir keine Chance haben, erfolgreich zu sein. Eines unserer wichtigsten Prinzipien ist die geteilte Verantwortlichkeit nicht nur für Code (wie in XP’s Collective Code Ownership) sondern auch für Prozesse, Support, Kundenprojekte usw. Sätze wie "ich bin nicht für Support-Tickets zuständig, ich bin ein Entwickler" oder "meine Kollegen ertrinken in time cockpit Einführungsprojekten aber als Entwickler ist das nicht mein Problem" sind ein No-Go in unserem Team.

Die Entwicklungszeit ist schwer vorherzusagen

Ein Nebeneffekt dieses Anspruchs geteilter Verantwortlichkeit ist, dass die Planung verfügbarer Entwicklungszeit ziemlich schwer ist. In einer Woche kann ein dringender Support-Fall oder die Unterstützung in einem kritischen Kundenprojekt uns viele Tage kosten. In der nächsten Woche können wir überraschend viel Zeit für die Entwicklung haben. Natürlich wissen wir, dass diese Art von Mutli-Tasking nicht der effizienteste Weg ist.

Dennoch muss man Vielseitigkeit und Flexibilität begrüßen, da so die Praxis in kleinen Unternehmen aussieht. 

Die schwankende Entwicklungsgeschwindigkeit führt zu Problemen

Das Fehlen von vorhersagbarer Entwicklungszeit führt mit Scrum zu einem Problem. Wie soll das Team den Sprint-Backlog planen für z.B. einen 1-Monats-Horizont, wenn nicht feststeht wie viel Zeit die Teammitglieder haben werden?

• Sollte es eher konservativ sein um eine Chance zu haben, das Sprint-Ziel oft zu erreichen? Meiner Erfahrung nach führt dieser Ansatz zu einem Über-Engineering in Sprints mit freier Zeit.
• Oder sollten sich die Team-Mitglieder gewagte Ziele stecken, um sicherzugehen dass sie nicht in der Mitte des Sprints ohne Arbeit dastehen? Ich habe Teams gesehen, die ständig frustriert waren, da sie regelmäßig ihre Sprint-Ziele verfehlt haben.

Wir waren genau in dieser Situation, als wir mehr und mehr time cockpit Kunden bekamen. Also mussten wir einen anderen Ansatz finden.

Kanban

Wir haben entschieden, uns vom Korsett der Sprints (wie von Scrum definiert) zu befreien. Stattdessen haben wir uns für die Kanban Methode entschieden.

Wenn Kanban neu für Sie ist uns Sie mehr darüber wissen wollen, empfehlen wir Ihnen das Buch Kanban von David J. Anderson.

So haben wir Kanban für uns angepasst

Um Kanban für uns tauglich zu machen, haben wir folgende Basis-Prinzipien definiert:

1. Dem Kaizen Prinzip folgend, begrüßen wir Veränderungen und wollen kontinuierlich unser Produkt wie auch unsere Prozesse verbessern.
2. Wir limitieren die Task an denen wir gleichzeitig arbeiten. Wenn wir einen Task starten, schließen wir ihn so schnell wie möglich ab und liefern ihn an unsere Kunden, damit diese davon profitieren können.
3. Wir schätzen was wir in der Vergangenheit gebaut haben (Software, Prozesse) und streben große Ziele an, indem wir schrittweise vorgehen.
4. Als Unternehmer folgen wir der Servant Leadership Praxis. Wir spezifizieren nur die allgemeine Strategie und High-Level Ziele. Alle kleinen, notwendigen Verbesserungen um das Langzeit-Ziel zu erreichen werden im Team definiert und implementiert.
5. Wir laden Menschen innerhalb und außerhalb unserer Organisation (z.B. Partner, Lieferanten, Kunden usw.) ein, an unserem Entwicklungsprozess teilzunehmen.

Keine Sprints aber vorhersagbare Release-Zyklen

Für die Entwicklung von time cockpit arbeiten wir schon eine ziemlich lange Zeit ohne Sprints mit vordefinierter Länge und Struktur. Trotzdem brauchen wir für Kunden und Partner eine gewisse Vorhersagbarkeit. Dafür haben wir einen konstanten Rhythmus von einem Release pro Monat eingeführt. Außer der Reihe liefern wir nur Hotfixes und Preview-Versionen.

We cannot exactly predict the features that will make it into the next release. Durch Priorisieren stellen wir sicher, dass die für Kunden und für uns wichtigsten Dinge wahrscheinlich dabei sein werden. Aber es gibt keine Garantie.

Was drinnen ist, ist drinnen und was nicht, das nicht. Es kommt immer ein nächstes Monat mit dem nächsten Release, in dem wir weitere Verbesserungen ausliefern können.

Kanban Software

Für unsere tägliche Arbeit managen wir unseren Workflow indem wir JIRA Agile’s Kanban Board benutzen. Natürlich haben wir JIRA mit time cockpit integriert damit wir unsere Arbeitszeit pro Work Item aufzeichnen können. Zusätzlich haben wir JIRA mit Zendesk integriert, jener Software die wir für Kundenservice nutzen.

Wann Scrum, wann Kanban?

Meiner Erfahrung nach ist Scrum großartig, wenn agile Entwicklung für ein Team neu ist. Scrum stellt klare Prozesse und Verantwortlichkeiten bereit. Das ist eine große Hilfe beim Wechsel vom Wasserfall zu agilen Methoden. Scrum ist auch großartig, wenn Sie in einer größeren Organisation arbeiten und Ihr Team sich auf die Entwicklung konzentrieren kann.

Für uns passt der Kanban Ansatz viel besser zu unserer Arbeitsweise. Es ermöglicht uns, unseren Kunden konstante Innovationen zu liefern während es uns die notwendige Flexibilität gibt, die ein kleines Team wie unseres braucht.