Wir alle kennen das: Projekte laufen wie geschmiert, es gibt wenig bis nichts zu bemängeln. Der Auftraggeber ist glücklich, die Stakeholder haben genau das bekommen, was sie wollten, und das alles in Rekordzeit und ohne das Team zu verbrennen. Und wieder haben wir ein Projekt erfolgreich abgeschlossen. Check.
Aber mal unter uns: Das ist doch ziemlich langweilig, oder?
Weiterlesen
„Wir machen uns um Onkel Henry furchtbare Sorgen. Er denkt, er sei ein Huhn.“
„Na, warum schicken Sie ihn denn nicht zum Arzt?“
„Naja, das würden wir ja. Aber wir brauchen die Eier.“
— Douglas Adams: Der lange dunkle Fünfuhrtee der Seele: Dirk Gently’s Holistische Detektei
Agile Methoden setzen auf das Team, nicht auf die Individuen. Alles soll das Team entscheiden, alles soll das Team gemeinsam machen. Von Pair über Mob Programming, die meisten Dinge lasten auf mehr als einem paar Schultern. Als Metapher hat man sogar den Bus-Faktor gefunden: Wie viele Leute aus dem Team muss ich mit dem Bus überfahren, bis die Software nicht mehr weiterentwickelt werden kann?
Wirklich agil bedeutet doch auch, dass man alles ändern kann. Da ist auch Scrum schon zu dogmatisch, deshalb haben wir das abgeschafft und sind auf Kanban gewechselt. Wir releasen ohnehin die ganze Zeit, da ergeben die Iterationen keinen Sinn. Einen Product Owner haben wir ebenfalls nicht, das hat für uns irgendwie nicht gepasst. Scrum Master sind bei uns jetzt agile Coaches, aber davon brauchen wir auch nicht für jedes Team einen, wir haben jetzt praktisch für alle drei Teams einen.
Schon das agile Manifest hat eine klare Ansicht darüber, wo und wann Architektur entstehen sollte:
The best architectures, requirements, and designs emerge from self-organizing teams.
Also ist die Sache doch klar: Das Team entscheidet selbst über die Architektur, und die alten Mächte, die aus den Enterprise Architecture Boards die richtige Architektur aus der Ferne finden wollten, sind bezwungen. Endlich kann man selbst Hand anlegen und Architektur passiert dann, wenn sie gebraucht wird.
Weiterlesen
Wer schätzt, verliert. Entweder man hat genug Puffer mit drin und es ist zu aufwändig, oder er fehlt und es klappt nicht pünktlich. Externe Abhängigkeiten werden auf rauen Annahmen geplant, von denen man sich zwar wirklich wünscht, dass sie zutreffen würden, aber in Wahrheit selbst nicht daran glaubt. Und kurz vor dem Launch kommen dann die Überraschungen, mit denen man zwar gerechnet hat, jetzt aber keine Zeit mehr hat, mit ihnen umzugehen.
Also lieber nicht schätzen, sondern auf Business Value und Durchfluss optimieren. Wenn ich zu jedem Zeitpunkt das Nützlichste mache und meine Strecke auf dem Weg dazu kontinuierlich verbessere – was könnte ich mehr als Beitrag leisten?
Das Thema Arbeitnehmerüberlassung ist heiß diskutiert; schließlich hängt einiges davon ab: So besteht zum Beispiel die Gefahr, dass man sich als Konzernanwalt strafbar machen kann, wenn man zulässt, dass fremde Arbeiter im eigenen Unternehmen wie eigene Mitarbeiter eingebunden sind.
Doch wie genau geht man nun mit der Arbeitnehmerüberlassung um? Wie sehen (Team-)Konstellationen in agilen Projekten aus, mit denen man auf der sicheren Seite ist?
Alles wurde fertig entwickelt, und mit etwas abendlicher Arbeit und ein paar Kompromissen bei der Qualität konnte man tatsächlich alles liefern, was im Sprint enthalten war. Im Review stellt man die entwickelten Features vor, die Entwickler zeigen die Storys, an denen sie gearbeitet haben. Es werden die Akzeptanzkriterien durchgegangen und am Ende jeder Story wird gefragt, ob das so in Ordnung ist. Dann nimmt der Product Owner die Story ab, und damit ist bestätigt, dass sie umgesetzt wurde. Das Ganze wird formal dokumentiert – im Ticketing oder im Wiki – und am Ende gibt es ein Protokoll der Veranstaltung.
Das ist praktisch für das Team: Diese Stories sind fertig, bis auf Bugfixes und neue Features wird man von ihnen wenig hören. Endlich etwas geschafft.
Als Scrum Master habe ich schon an sehr vielen Sprint Reviews teilgenommen und mir dabei oft die Frage gestellt: „Wie bekomme ich mehr und brauchbareres Feedback im Review?“
In diesem Blogpost möchte ich meine Erfahrung teilen und zeigen, wie nützliches Feedback gefördert werden kann. Außerdem werde ich meine Fehler nennen, die dazu führten, dass kein brauchbares Feedback gegeben wurde.
Weiterlesen
Es haben sich grundlegende Rahmenbedingungen geändert. Das Team stellt überraschend fest, dass das Sprintziel bei näherer Ansicht nicht mehr zu erreichen ist. Drei Tage vor Ende des Sprints ist deutlich sichtbar, dass der Forecast nicht annähernd erreicht werden kann.
Für das Team ist die Sache klar: Unter diesen Bedingungen kann man nicht mehr die Verantwortung für den Sprint übernehmen. Ähnlich sieht es der Scrum Master – so ist es nicht möglich, den Sprint weiterzuführen, er muss abgebrochen werden. Also trifft man sich in der Mitte des Sprints in einer spontan einberufenen Retro und bricht den Sprint offiziell ab, weil es ja nicht anders geht.
Der Scrum Master muss das Team schützen! Deadlines erzeugen zu viel Druck für das Team! Und Überstunden darf es nicht geben!
Schaut man sich die Diskussionen in agilen Unternehmen an, entsteht schnell der Eindruck, dass die Entwickler-Teams sehr zart besaitet sind und es ihnen an Kraft und Resilienz fehlt, auch mit den kleinsten Störungen umzugehen.