Scrum in der Praxis: Teil 2, das Sprintende

In unserer Rubrik Tech Talk stellen wir euch heute wieder Situationen aus dem agilen Umfeld vor. Ihr habt noch nie in der agilen Entwicklung gearbeitet? Dann folgt aufmerksam unserer Reihe „Scrum in der Praxis“.

Agile Softwareentwicklung ist der neuste Schrei. Nicht selten kommt es in der Industrie vor, dass sich Unternehmen mit dem Label „Agile Softwareentwicklung“ schmücken wollen. Gerade im Bereich Scrum wird viel Schindluder getrieben. Ob dies nun aus Unkenntnis oder Täuschung gemacht wird, möchte ich an dieser Stelle nicht bewerten.

Daher verwundert es auch nicht, dass man auf Portalen, wie http://thedailywtf.com oder https://www.reddit.com/ oder auch den zahlreichen kleinen Blogs viele negative Erfahrungsberichte zum Thema Agile Entwicklung liest. Agiles Entwickeln ist eine Idee. Scrum ist ein konkretes Rahmenwerk, dass der agilen Idee folgt und Scrum wird in diesem Beitrag auch im Zentrum stehen.

Dieser Beitrag wird exemplarisch ein Review am Ende eines Entwicklungszyklus (Sprint) beschreiben. Alle Elemente darin habe ich persönlich regelmäßig in Projekten erlebt und stufe sie als ganz normale Ereignisse im Leben eines Scrum-Teams ein. Dieses konkrete Meeting ist jedoch fiktiv.


Alex, Barbara, Carlo, Diana: Softwareentwickler
Masami: Scrum-Master
Polly: Product Owner


 

Im Büro.

Masami: Alex, kommst du, das Review fängt gleich an. Wir sind heute im Raum 2.02.

Alex: Ich habe gerade noch einen Bug gefunden, der sich bei unseren Tests versteckt hatte. Wenn ich das jetzt nicht noch schnell behebe, können wir diese Anforderung nicht abgeben.

Masami: Das ist ärgerlich. Komm jetzt aber ruhig trotzdem mit ins Meeting. Polly soll dann entscheiden, ob sie die Story annimmt oder nicht. In zwei Minuten geht es schon los.

Alex: So ein blöder Fehler! Ja, ich komme.

Im Meetingraum, zum Sprint Review.

Masami: Willkommen beim Review von Sprint 15. Die letzten zwei Wochen haben wir an einigen neuen Features und Bugfixes gearbeitet. Alex, würdest du gleich anfangen?

Alex: *nickt* Ich habe die Story NPE-1232 bearbeitet. Dafür sollten wir einen Loginbildschirm für die Applikation schreiben. Aktuell kann jeder die Applikation benutzen. In Zukunft muss man sich mit Nutzer und Passwort einloggen um den Zugriff mit der steigenden Mitarbeiterzahl besser kontrollieren zu können. Ich demonstriere das mal kurz auf dem Beamer. Leider ist uns aber noch ein Sonderfall erst kurz vor dem Review aufgefallen. Wenn im Nutzernamen oder Passwort ein Sonderzeichen ist, wird es in einer falschen Kodierung ans Backend geschickt und der Loginversuch schlägt fehl. Das kann im schlimmsten Fall zur Accountsperrung führen.

Polly: Dass wir den Login ändern, ist sehr zeitkritisch. Eigentlich wollten wir die Änderungen kommende Woche schon ausrollen. Bis zum Ende des kommenden Sprints können wir nicht warten.

Alex: Das Problem zu beheben ist kein großer Aufwand. Ich gehe davon aus, dass ich das bis zum Ende des Tages abgeschlossen habe.

Polly: Sehr gut, so lange du die Version bis Freitag auslieferst, reicht mir das.

Masami: Einen Moment, lasst uns das lieber nachher im Planning besprechen. Wenn das Team dem zustimmt, schieben wir gerne noch eine Zwischenlieferung ein. Wir sollten uns jetzt aber erst einmal auf die Stories des vergangenen Sprints konzentrieren.

Polly: Das ist in Ordnung. Da die Anforderungen nicht vollständig umgesetzt sind, nehme ich die Story nicht ab und wir schauen dann nachher beim Planning weiter.

Barbara: Dann mache ich einmal weiter. Ich habe die Story NPE-1233 bearbeitet. Da ging es darum, einen Report von allen Nutzern zu erzeugen, die aktuell Zugriff auf die Applikation haben und ein Datenbankscript anzulegen, welches all diesen Nutzern Accounts für das neue Login anlegt. Ich habe das Script auch schon an das Betriebsteam übergeben und sie waren zufrieden. Ich hatte dich bei der Mail auch in den CC gesetzt, Polly.

Polly: Ja, die Mail hatte ich gesehen. Die Story ist abgenommen.

Carlo: Dann mache ich direkt weiter. In NPE-1256 ging es darum, den Bug im Detailreiter zu beheben, dass lange Titel rechts aus dem Bildschirm rausragen und somit abgeschnitten sind. Auf dem Beamer ist gerade unsere alte Version zu sehen. Ich gehe mal zur Detailseite. Hier sieht man den abgeschnittenen Titel. Jetzt öffne ich die neue Version und gehe zur gleichen Detailseite. Hier sieht man jetzt, dass der Titel umgebrochen ist.

Polly: Hmm, aktuell ist der Titel mitten im Satz umgebrochen. Kann man das nicht so machen, dass zuerst versucht wird nur bei einem Satzende umzubrechen? Das würde es etwas lesbarer machen.

Carlo: Das war in diesem Sprint nicht Teil der Anforderungen. Das können wir aber gerne mit einer neuen Story noch umsetzen.

Polly: Gut, dann lege ich dafür einen neuen Eintrag im Ticketsystem an.

Masami: Da die Anforderungen für diese Story umgesetzt sind, nimmst du die Story ab, Polly?

Polly: Ja, ist abgenommen.

Diana: Ich stelle NPE-1244 vor. Ich hatte dir ja gestern schon geschrieben, dass wir den Aufwand leider unterschätzt hatten und daher nicht fertig geworden sind. Hier sind auch noch größere Restaufwände zu leisten.

Polly: Woran hing es denn?

Diana: Ich kann ja mal kurz den Code an die Wand werfen. Die Klasse ist unglaublich lang und allein die Methode „perform“…

Masami: Ich glaube das führt jetzt gerade etwas zu weit. Kannst du das Problem kurz zusammenfassen? Polly, falls du darüber hinaus noch mehr Details möchtest, kannst du im Nachgang noch mit den Leuten reden, die an der Story gearbeitet haben. Dann kann der Rest des Teams schon weiterarbeiten.

Diana: Die Komponente, die wir dafür anfassen mussten, ist sehr fragiler Legacy-Code. Wir haben ein paar kleine Änderungen gemacht und plötzlich ging die halbe Applikation nicht mehr. Umbaumaßnamen und Tests sind fertig aber die eigentliche Arbeit haben wir noch nicht begonnen.

Polly: Hättet ihr es nicht ohne die Umbaumaßnamen geschafft?

Carlo: Das war uns zu riskant. Ich habe auch mit draufgeguckt und der Umbau war längst überfällig.

Polly: Na gut, zumindest ist mir dieses Szenario lieber, als wenn die Probleme erst in der Produktion auftauchen.

Masami: Gut, die halbe Stunde für unser Meeting ist auch gleich rum. Falls es keine weiteren Punkt gibt, gehen wir jetzt etwas früher in die Mittagspause und treffen uns anschließend zur Retrospektive um 13:30 Uhr wieder hier.


 

Maximiere die Arbeit, die nicht getan wird, ist Teil des agilen Manifests. Das bedeutet, überflüssige Meetings und Arbeiten, die dem Projekt keinen Mehrwert bringen zu streichen. Das bedeutet auch, dass bei den notwendigen Meetings nur die Personen anwesend sind, die benötigt werden. Bei agiler Entwicklung dreht sich daher viel um die Eigenverantwortlichkeit des Teams und seiner einzelnen Mitglieder. In der Konsequenz bedeutet das, dass das ganze Team engen Kontakt zu Polly hat, die selbst zur Organisation des Kunden gehört. Spätestens alle zwei Wochen sieht Polly also live die Arbeitsergebnisse des Teams. So kann sie frühzeitig erkennen, ob der Umbruch des Titels passt oder ob in den Anforderungen, die sie geschrieben hat, noch ein Detail fehlte. Als Product Owner kann sie sich jetzt überlegen, wie hoch sie die Änderung priorisiert um den Mehrwert der Applikation zu maximieren. Von der Priorität hängt dann ab, ob die neuen Anforderungen in den kommenden zwei Wochen umgesetzt werden, oder erst in einem späteren Zyklus – oder ob sich bis dahin vielleicht zeigt, dass diese Umsetzung sich nicht lohnt.

Sie hat die Finger am Puls des Projekts und da sie selbst zum Kunden gehört, sind keine überschweifenden Reports notwendig was den Fortschritt des Teams angeht. Mit jeder abgenommenen Story ist messbar wieviel näher man dem nächsten Meilenstein gekommen ist. Scrum ist dabei jedoch keine Anarchie. Wir als Entwickler übernehmen Verantwortung für die Anforderungen, die wir einmal in einen Sprint aufgenommen haben. Wie wir diese Anforderungen konkret umsetzen, entscheiden wir dann jedoch eigenständig. Diese Freiheit weiß ich sehr zu schätzen. Die Meetings im Rahmen von Scrum sind überschaubar und Masami achtet darauf, dass der Prozess nicht ausartet und hält externe Störungen und Produktivitätskiller fern.

Wenige, kurze, sinnstiftende Meetings, viel Eigenverantwortlichkeit, häufig Feedback zur eigenen Arbeit und kontrollierte, kleine Kurskorrekturen seitens des Kunden sind es, die für mich Scrum ausmachen und mir einen angenehmen Arbeitsalltag verschaffen.

Werbeanzeigen

2 Gedanken zu „Scrum in der Praxis: Teil 2, das Sprintende

  1. Pingback: Scrum in der Praxis: Teil 4, a day in the life …Scrum Developer | My Magdeburg Experience

  2. Pingback: „Scrum in der Praxis“ ist nicht leicht – Zertifizierung zum Professional Scrum Master | My Magdeburg Experience

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.