INSIGHTS Same same but different — unsere Interpretation agiler Entwicklung

Der folgende Beitrag basiert auf dem Vortrag von Carina Bittihn und Linda Dettmann bei der code.talks 2015.

Agile Development ist mittlerweile nichts Neues mehr. Immer mehr Unternehmen lassen ihre Produkte im Scrum oder Kanban entwickeln. So auch wir. Doch Agile Development wäre nicht “agile”, wenn wir den Prozess nicht stetig hinterfragen und weiterentwickeln und den Workflow an die spezifischen Bedürfnisse unseres Teams anpassen würden. Wir — das sind verschiedene Köpfe aus Development, Konzeption, Design und Marketing — die zusammen an der Entwicklung und Optimierung von EDITED.de arbeiten. Was also sind unsere Learnings? Inwiefern weichen wir ab vom Lehrbuch?

In der Anfangsphase unseres Online Shops zogen wir das Projekt in zweiwöchigen Sprints hoch, immer beginnend mit dem Planning, darauf folgend Development, Testingphase, Deployment, Review, Retro und natürlich dem täglichen Standup. Soweit, so unspektakulär. Jetzt steht der Shop. Features wollen ausgebaut oder neu erschaffen, Bugs gefixt werden. Der Zweiwochenrythmus erweist sich nun eher als hinderlich, denn entweder ist am Ende des Sprints mega der Endstress, weil man sich doch auf diese und jene Story committed hat. Oder man liest das Internet leer, da die neuen Stories noch nicht «ready for dev» sind. Da hilft auch keine einjährige Planning-Erfahrung, denn irgendwas ist ja immer. Daher haben wir gemeinschaftlich im Team beschlossen: Kanban soll es nun sein, aber mit den Vorzügen von Scrum. Heißt, kein Festlegen mehr auf das Fertigstellen bestimmter Stories. Stattdessen werden die vorhandenen Stories nach Priorität abgearbeitet und anschließend deployed. Die anstehenden Tickets werden in einer Art Planningmeeting zu Beginn jeder Woche besprochen. Auch die anderen Meetings wie Review und Retro haben wir beibehalten, denn was gibt es Schöneres, als sich alle zwei Wochen mal Luft bei den Kollegen zu machen oder dem Chef zu zeigen, was man so erreicht hat. Oder andersherum.

Das zu den Rahmenbedingungen. Doch darüber hinaus gibt es in der Zusammenarbeit unterschiedlicher Gewerke immer mal wieder das eine oder andere Reibungsmoment. Um den Workflow in Zukunft zu verbessern, haben wir unseren Arbeitsalltag unter die Lupe genommen. Dabei konnten wir gewisse Situationen herausfiltern, die typischerweise spannungsgeladen waren.

SITUATION 1

Product Owner zum Developer: “Können wir nicht mal eben einfach schnell {{dies.das.ananas}}?”

Im Ohr eines Developers klingeln sämtliche Alarmglocken. Denn {{dies.das.ananas}} ist weder einfach, noch mal eben und schon gar nicht schnell umzusetzen. Und weil der Developer um die Komplexität der Aufgabe weiß, erwidert er reflexartig, energisch mit dem Kopf schüttelnd: “Das geht nicht!!” und denkt dabei außerdem “Was soll das überhaupt?”.

Gedanken eines Developers bei einer “Eben mal einfach schnell”-Anfrage

Die Stimmung kippt. Die Fronten sind verhärtet. Keine gute Grundlage für eine Diskussion. Doch Moment mal. Was ist hier gerade schiefgelaufen? Offensichtlich verfügt der Developer über Informationen, die der Product Owner nicht hat. Das WIE. Der Product Owner wiederum kennt das Motiv hinter der Anforderung. Er hat ein bestimmtes Ziel vor Augen. Das WARUM. Jetzt gilt es, dieses Wissen auszutauschen und dem Gegenüber den eigenen Standpunkt zu erklären. Der Developer erfährt die Hintergründe der Anforderung, was zudem zur Motivation beiträgt. Der Product Owner erkennt die Dimension des Aufwands und dessen Ursprung. Gemeinsam kann nun nach einer Lösung gesucht werden, die bereits mit weniger Aufwand einen messbaren Nutzen erzeugt. Also statt in Schnappatmung bei den Worten “mal eben schnell” zu verfallen, wissen wir, es ist Zeit für:

“Create Awareness”

SITUATION 2

Developer zu Product Owner: “Wir sollten den Mobile Stack auf ES6 migrieren.”

Zu den Aufgaben eines Product Owners gehört unter anderem das Priorisieren von Features. Dazu ist es natürlich hilfreich, die einzelnen Anforderungen zu verstehen und dementsprechend einzuordnen. Doch hin und wieder kann es seitens der Developer zu sehr fachspezifischen Anfragen kommen, die nicht selten folgende Reaktion auslösen:

Quelle: http://memegenerator.net/
Reaktion eines P.O. während eine sehr technischen Exkurses seiner Developer

Lächelnd und zustimmend nickend fragt sich der Product Owner auch noch während der anschließenden Erklärungsversuche, wovon die da eigentlich reden. Es bleibt beim Erklärungsversuch. So wurden in der Vergangenheit die Anforderungen eher technischer Natur kaum oder nur mit geringer Priorität umgesetzt. Doch auch diese Themen haben ihre Berechtigung, denn hier steht ebenfalls die stete Optimierung und Weiterentwicklung des Produkts im Fokus. So ist es nicht unbedingt notwendig, sämtliche Details bis in die Tiefe zu verstehen. Relevant ist jedoch der Mehrwert, der durch die Umsetzung von Tickets dieser Art für die Zukunft geschaffen wird. Daher

“Trust your Techie”

SITUATION 3

Product Owner zum Developer: “Kann man schon was sehen?”

Die Story ist bereit zur Entwicklung. Der Developer nimmt sich das Ticket. Jira bestätigt den Status auch gerne noch einmal per Mail: “Changed to in Development”. Nach einigen Tagen steht der Product Owner nervös neben dem Developer. Wann denn wohl {{dies.das.ananas}} endlich fertig sein würde.

Quelle: http://memegenerator.net/instance/64772860/
Developer auf die Frage, ob man schon was sehen kann

Der Entwickler reagiert verhalten. “Es gäbe da noch diese und jene kleine Komplikation. Und diese andere Sache sollte auch noch erledigt werden. Gib mir noch ein, zwei Stündchen.” Zeit vergeht. Und so kann es passieren, dass man sich als Developer mal an größeren, mal an kleineren Problemen regelrecht festbeißt. Um diesem Festbeißen vorzubeugen, haben wir ein Zeitlimit für die Bearbeitung von Tickets bestimmt. Dieses liegt aktuell bei 5 Tagen, dargestellt durch einen Punkt pro Tag auf dem Ticket an der analogen Wall. Erreicht ein Ticket diesen Wert, ist spätestens jetzt eine Lagebesprechung mit den Kollegen notwendig. Denn möglicherweise ist die Story zu umfangreich und es können Teilaufgaben extrahiert werden. Oder die aktuelle Implementierung hat eventuell schon jetzt das Ziel erreicht und kann eigentlich beendet werden. Oder die Kollegen können bei der Problemlösung helfen. Deshalb gilt bei uns in jedem Daily Standup:

“Mach mal ‘n Punkt” und zwar für jeden Tag, den sich ein Ticket in Development befindet.

SITUATION 4

Product Owner zu sich selbst: “Ein Techie ist ein Techie ist ein Techie”

Klassischerweise gibt es in jedem Unternehmen klare Rollen und Verantwortungsverteilung. Ein Product Owner kümmert sich um Konzepte und Schnittstellen, holt die Stakeholder ab und überlegt sich, welches Projekt den höchsten Business Value hat. Die Developer sind am Ende der Konzeptions- und Designphase für die Implementierung der Anforderungen zuständig, von denen sie meist erst im Planningmeeting erfahren. Das ist viel zu spät, wie wir finden. Denn auch wenn jemand laut seiner Berufsbezeichnung nicht “Product”- oder “Design”-Irgendwas ist, vermag er mit vielen guten Ideen und nützlichem Feedback zur Verbesserung und Weiterentwicklung des Produkts beizutragen.

Quelle: http://memegenerator.net/instance/64768623/
Developer, der auch Photoshop kann

Daher haben wir beschlossen, unsere Entwickler möglichst früh in vorgelagerte Prozesse einzuspannen. Dies verhindert einerseits Fehlkalkulationen in Bezug auf Machbarkeit und andererseits ermöglicht es einen ganz anderen Blickwinkel und fördert so neue Lösungsansätze. Aber auch in Sachen Kreativität sollten Developer nicht unterschätzt werden. In regelmäßigen Abständen versuchen wir, das kreative Potential in so genannten “Free Sprints” für unser Produkt zu nutzen. Dabei haben die Entwickler zwei Wochen lang Zeit, irgendetwas ihrer Wahl umzusetzen, auszuprobieren, zu entwickeln. Einzige Bedingung: Es muss relevant für unser Produkt sein. Alle — unabhängig ihrer offiziellen Profession — sind deshalb aufgefordert:

“Get involved!”

Doch das allerwichtigste kommt natürlich zum Schluss. Wir haben in unserem Team eine Kennzahl entwickelt, die auf gar keinen Fall unter 0.25 im Monatsdurchschnitt liegen sollte. Den sogenannten PpD-Index. Die Empfehlung lautet deshalb: Arbeitet in eurem Team hart am #PartyPerDeploy.

PpD als wichtige Kennzahl