SCRUM – Eine Erfolgsgeschichte bei softwareproduktiv

• 29. März 2018
• Frank Spiegelhoff
• 1 Kommentar

Vor 3 Jahren kam unser Entwickler Markus auf mich zu und sagte, dass wir die Organisation unserer Arbeit verbessern sollten. Er hat sich bereits mit SCRUM beschäftigt und sieht viele gute Ansätze.

Wir hatten bis dahin unsere Aufgaben, Projekte, Serviceanfragen mit Microsoft CRM verwaltet und damit war keiner wirklich zufrieden. Den Mitarbeitern wurde ein Haufen voller Aufgaben zugeordnet und sie wussten nicht, was Sie zuerst und was zuletzt erledigen sollten und der Chef hat sich geärgert über die zu geringe Produktivität. Es fehlte an Transparenz und bei Planungen hat man sich nur auf ein Projekt konzentriert und dabei passierte es oft, anderen wichtige  Aufgaben zu vernachlässigen.

Markus hatte sich bereits mit SCRUM beschäftigt. Nachdem wir uns ein paar Mal für ein paar Stunden eingeschlossen und gemeinsam geprüft haben, ob SCRUM etwas für softwareproduktiv sein konnte, entschieden wir uns einfach mit SCRUM zu starten. Das war einer der wichtigsten und besten Entscheidungen für softwareproduktiv! Das hat fast alles verändert. Die Qualität unserer Arbeit und damit die Zufriedenheit unserer Kunden hat deutlich zugenommen, die Arbeitskultur und Stimmung im Unternehmen wurde richtig gut und die Produktivität des gesamten Unternehmens hat sich locker verdoppelt.

In diesem Blogartikel beschreibe ich, wie heute softwareproduktiv basierend auf dem Vorgehensmodell SCRUM und mit der Software Jira die komplette Arbeit organisiert.

Wir erfassen und verwalten sämtliche Aufgaben in einem sogenannten Backlog. Tatsächlich sind das alle Aufgaben, also von der kritischen Systemstörung eines Kunden über einzelne Aufgaben eines Projektes zur Einführung eines neuen ERP Systems bis hin zur Organisation neuer Blumentöpfe für den Eingangsbereich. Diese Aufgaben werden im SCRUM Storys genannt und werden aus der Sicht des Anwenders formuliert. Im Wesentlichen bestehen diese Storys aus einem Titel und einer Beschreibung, wird einem Kunden und Autor zugeordnet und erhält eine Priorität.

Ruft nun ein Kunde an und meldet einen kritischen Fehler wird diese Story direkt mit der Priorität Kritisch angelegt und unser Supportmitarbeiter kümmert sich sofort darum, dass jemand aus unserem Team direkt dem Kunden hilft. Solche kritischen Vorgänge kommen aber zum Glück nur sehr selten vor und so reicht es in der Regel, dass neuen Serviceanfragen zunächst nur als Story angelegt werden.

Nach unserem Daily sind alle auf dem aktuellen Stand

Wir treffen uns jeden Tag um 12 Uhr zum Daily mit allen anwesenden Mitarbeitern. Dieser Termin sollte maximal 15 Minuten dauern und wird im Stehen durchgeführt. Wir besprechen zunächst alle neu aufgenommenen Storys. Dafür haben wir einen großen Touchmonitor in unserer Lounge aufgehängt und gehen alle neuen Vorgänge im Status der Vorqualifikation durch. Wir prüfen gemeinsam die eingetragene Priorität und weisen teilweise schon bestimmte Storys einen Bearbeiter zu.  Als Nächstes erzählt jeder, womit er seit dem letzten Daily beschäftigt war und welche Aufgaben anstehen. Sollte ein Mitarbeiter aktuell mit irgendwelchen Hindernissen zu kämpfen haben kann er direkt Hilfe bekommen. Unser SCRUM Master Markus achtet darauf, dass es in unserem Daily nicht zu ausufernden Vorträgen oder Diskussionen kommt und das die Zeit eingehalten wird.

Unsere Sprints

Elementar ist im SCRUM die Fokussierung auf das Wesentliche und das schaffen wir durch die absolute Transparenz in unserem Backlog. Lars, unser SCRUM Product Owner, trägt dafür die Verantwortung und überwacht und sortiert stetig unseren Backlog. Er bereitet sorgfältig unser wöchentlich, stattfindendes Sprintmeeting vor. Ein Sprint umfasst eine Menge an Storys, bei der das Team überzeugt ist, dass diese Arbeit innerhalb einer Woche erledigt werden kann. Lars plant nun im Vorfeld den nächsten Sprint vor, indem er die nächsten, wichtigen Storys dem Sprint  zuordnet.

Am Dienstag ist es dann soweit, das komplette Team trifft sich in unserem Besprechungsraum und wir gehen zunächst zusammen unseren letzten Sprint durch. Gerne präsentiert natürlich jeder seine erledigten Aufgaben, aber natürlich kommt es vor, dass unser Plan nicht komplett aufgegangen ist und einzelne Storys noch in Arbeit oder sogar noch komplett offen sind. Dann besprechen wir woran es lag, prüfen welche Konsequenzen das hat und wie wir die Aufgabe gemeinsam lösen können. Nach unserem Review schließen wir unseren Sprint und planen den nächsten Sprint.

Wir ordnen bereits jede Storys einen Bearbeiter zu und bemessen den Aufwand mit Storypunkten. Anhand dieser Punkte können wir gemeinsam besser abschätzen, ob diese Arbeit im nächsten Sprint auch erledigt werden kann. Erst wenn alle Mitarbeiter das bestätigen, wird der nächste Sprint gestartet.

Während des Sprints kann sich i.d.R. jeder Mitarbeiter seine Arbeit frei einteilen. Natürlich müssen mit Kunden abgesprochene Termine eingehalten werden. Unsere Software Jira stellt uns ein KANBAN Board zur Verfügung auf dem in 3 Spalten übersichtlich dargestellt wird, welche Storys noch offen, in Arbeit und erledigt sind. Es ist ein wirklich ein gutes Gefühl Storys nach rechts zu ziehen, da man bei unserer Arbeit häufig erst mit so einem Board sehen kann, was man alles am Tag geschafft hat.

Diese Arbeitsorganisation hat zu sehr positiven Änderungen geführt.

Die Emailflut wurde radikal eingedämmt. Wir kommunizieren mit den Storys. Kommt der Bearbeiter an irgendeiner Stelle nicht mehr weiter, kann er diese Story jemanden anderen zuordnen. Dabei kann er alle wichtigen Informationen direkt der Story als Kommentare oder Dateianhang hinterlegen. Wir haben auch ein Outlook-Addin entwickelt, so dass wir Emails auch direkt als Kommentar in einer Story zentral archivieren können. Jeder kann sich so schnell in einen Vorgang rein denken und mit der Bearbeitung starten.

Wir erfassen auch unsere Arbeitszeit zu jeder Story. Dank unserer Schnittstelle zu eEvolution können wir so unsere Dienstleistung auch einfach berechnen.

Projekte oder komplexe Aufgaben müssen für diese Arbeitsorganisation in kleine Einheiten unterteilt werden. Wir schreiben also viele Storys und fassen diese in einem Epos zusammen. Die Komplexität großer Projekte bekommen wir so gemeinsam in den Griff. Wir starten in solchen Projekten immer mit dem Wichtigsten und binden unsere Kunden möglichst früh ein. So erstellen wir z.B. Mockups (Bilder der zu erstellenden Software) und Prototypen und diskutieren diese mit dem Kunden. Wir erhalten so sehr früh wertvolles Feedback und vermeiden auf diese Weise in die falsche Richtung zu rennen.

Auf unserem Monitor in unsere Lounge können wir ständig verfolgen, wie aktuell der Fortschritt in unserem Sprint ist. So werden wir automatisch an unseren Plan erinnert, wenn wir uns einen Kaffee holen.