Dirk Theissen, Author at Binaris Informatik

Remote Retrospektiven

Dirk Theissen — Tue, 03 Nov 2020 14:43:37 +0000

Ein Praxisbericht

Remote Retrospektiven

Wie schnell sich doch manchmal die Dinge ändern. Nicht wenige kämpften jahrelang für eine ausgeprägtere remote Kultur in ihrem Unternehmen, scheiterten aber regelmäßig an manchmal sicherlich nachvollziehbaren, häufig aber eben nur fadenscheinigen Begründungen gegen Home Office. Nun, ein gutes halbes Jahr und ein Virus später, haben sich Dinge gravierend verändert. Remote Work ist für Unternehmen der unterschiedlichsten Branchen das Mittel der Stunde, um weiterhin produktiv zu sein. Doch die oftmals aus gegebenem Anlass unkoordinierte und überstürzte Flucht ganzer Abteilungen in ein remote Setting bringt ganz neue Herausforderungen für Unternehmen und Arbeitnehmer mit sich. Als Beratung für agile Projektmanagement Methoden mit Schwerpunkt auf Scrum, haben wir in diesem agilen Kontext, welcher so stark von Kommunikation und Transparenz lebt, so einige Erfahrungen sammeln können. In diesem Bericht konzentrieren wir uns dabei auf die Retrospektive. Als Scrum Event, welches im agilen Setting wohl am meisten für Feedbackkultur, Transparenz und Offenheit steht lassen sich hervorragend Herausforderungen und auch Handlungsmaßnahmen für Teams in remote Work ableiten. In diesem Artikel soll es nicht um die Theorie von Retrospektiven geben. Wer sich hier noch mal den offiziellen Scrum-Wortlaut in Erinnerung liefern will sei hier auf den offiziellen Scrum Guide verwiesen.

Punkt 1 – Rahmen schaffen

Klar, eine gute Vorbereitung (in den meisten Fällen durch den Scrum Master) ist immer eine Grundvoraussetzung. Allerdings wirft das remote Setup neue Fragen auf, die der Organisator einer Retrospektive von vorne weg klären sollte. Neben den klassischen Fragestellungen wie „Sind alle Teilnehmer informiert“ oder „ist der Raum gebucht“ erfordert eine remote Session eine gesonderte Vorbereitung. Anhand der folgenden beispielhaften „remote Checklist“ lassen sich diese Punkte und die daraus resultierenden Anforderungen darstellen.

Dabei sind es häufig die scheinbar banalen Punkte, die schon direkt einen reibungslosen Start in ein Online-Meeting verhindern und unnötig Zeit und Nerven für alle Beteiligten kosten. Hat jeder Zugang zu den eingesetzten technischen Tools wie Videokonferenzsysteme oder online Whiteboards? Werden Teilnehmer drauf hingewiesen VORHER einen Technikcheck zu machen? Existieren Fall Back Szenarien, sollte die Technik partout streiken, usw.? Eine eigens erstellte Checkliste kann hier Wunder bewirken, damit nicht schon der Start in eine Retrospektive oder sonstige Online Session stockt.

Punkt 2 – Working Agreements

Nutzen Sie die erste remote Retrospektive, um Arbeitsvereinbarungen zu treffen, die an das remote Setting angepasst sind. Remote Sessions erfordern eigene Regeln, welche die Teilnehmer gemeinsam entwickeln und dann auch entsprechend einhalten. Beispiele hierfür sind:

Hierbei gilt, übertreiben Sie es nicht mit den Regelungen. Als Faustformel kann man sagen, dass sie sich irgendwo zwischen 3 – 7 Regeln bewegen sollten, um die Klarheit solcher Regeln zu bewahren.

Punkt 3 – Remote Retrospektiven als Chance erkennen

Wie sehr hatten wir uns an den Anblick vollgekritzelter Whiteboards und mit Haftnotizen zugeklebten Fensterwänden gewöhnt. Nicht zu vergessen der persönliche Austausch samt der Registration von Emotionen und Reaktionen unserer Gesprächspartner. All dies ist jetzt nicht mehr möglich, oder? Doch ist es, nur eben anders, aber dadurch nicht weniger produktiv und erhellend.

Die technische Umsetzung

Kommen wir zum ersten Teil. Die technische Umsetzung einer Remote Retrospektive. Dank digitaler Tools lassen sich die klassischen Vor Ort Retrospektiven kreativ auf digitale Whiteboards übertragen. Durch völlig neue Möglichkeiten der parallelen Interaktion öffnen sich dabei neue kreative Wege, die buchstäblich nur einen Klick weit entfernt sind. Zahlreiche Artikel haben sich bereits mit den entsprechenden Tools beschäftigt, weshalb wir hier nicht in die Aufzählung einzelner Tools übergehen. Folgend geben wir Ihnen stattdessen ein Beispiel für ein technisches Retro Setting, welches sich bei uns bewährt hat:

Zoom als Videokonferenzlösung
Miro (miro.com) als digitales Whiteboard
Interner Kommunikationskanal wie Slack, Skype oder Rocketchat als „Fall-Back“ Kanal

Digitale Whiteboards wie das erwähnte Miro haben den Vorteil, dass man die „normalen“ bekannten Methodiken einer Retro entweder eins zu eins nachbauen kann oder aber auch Retrospektiven präsentiert, die so vor Ort nicht umsetzbar bzw. zu aufwändig wären.

So kann man zum Beispiel klassische Retro Methoden wie „Timeline“, „Wetterbericht“ oder „4L’s“ durchführen oder auch kreative neue Ideen verwirklichen. Dazu finden sich hier zum Beispiel Ideen.

Gerade Personen, die bislang wenig Erfahrung in der Vorbereitung von Remote Retrospektiven gesammelt haben, sollten sich zudem anfangs mehr Zeit als üblich für die Vorbereitung nehmen. Im Optimalfall geben Sie transparent weiter, dass es auch für Sie Neuland ist und daher noch nicht alles perfekt ist. Das nimmt Ihnen auch etwas den Druck eine tadellose Retro herzaubern zu müssen. So oder so helfen uns aber hier digitale Tools um auch im remote Setting technisch saubere Retrospektiven durchzuführen.

Der Faktor Mensch in der Retrospektive

Nachdem wir nun geklärt haben, dass die technische Umsetzung einer Remote Retrospektive durchaus möglich ist und sogar neue kreative Aspekte hervorbringen kann, soll es nun um den Faktor Mensch gehen. Einer unserer Erfahrung nach meist genannten Kritikpunkte an der Remote Arbeit ist die fehlende zwischenmenschliche Kommunikation. Man trifft sich eben mal nicht schnell in der Kaffeeküche oder spürt die aktuelle Stimmung im Büro. Dies betrifft speziell auch die Retrospektive, welche ja durchaus auch mal emotionaler und persönlicher sein kann, da hier Dinge offen angesprochen werden. Hier sind dem Remote Setup natürliche Grenzen gesetzt. Und dennoch verbergen sich auch hier ungeahnte Potenziale, die den fehlenden zwischenmenschlichen Faktor zwar nicht ersetzen können, aber auf eine andere Art Vorteile bringen.

So kann die räumliche Distanz einer digitalen Retrospektive auch förderlich sein. Bei bestimmten Personen können Hemmnisse ihre eigene Meinung zu äußern wegfallen, wenn man sich durch die räumliche Trennung weniger angreifbar fühlt. Hier ist der Moderator deutlich mehr gefragt. Zum einen muss er darauf achten jene mit einzubeziehen, welche das Home Office nutzen, um sich noch mehr aus Diskussionen zurückzuziehen. Zum anderen steigt insgesamt der Moderationsaufwand, da immer nur einer reden kann und es dadurch einen sehr strukturierten Ablauf bedarf. Heißt, hier sind die Skills des Moderators umso mehr gefragt. Durch die erzwungene größere Strukturiertheit (z.B. es redet immer nur einer) besteht die Chance, dass auch alle ausgeglichener zu Wort kommen.

Persönliches Fazit

Ja, Remote Retrospektiven können nicht eins zu eins die klassischen vor Ort Events ersetzen. Dafür fehlt es an der direkten Interaktion miteinander, das Gefühl für die Stimmung im Raum usw.. Akzeptiert man das und erkennt die digitalen Retrospektiven als Chance an, werden Sie von den Möglichkeiten überrascht sein. Das remote Setting erfordert zumindest anfangs mehr Planung und mündet damit auch fast automatisch in einer strukturierten Session. Klare Working Agreements erleichtern hingegen die Zusammenarbeit immens und technische Tools wie Miro lassen viel Spielraum die Retrospektive auch weiterhin individuell zu gestalten.

Autor: Dirk Theißen

Übrigens: Wir von binaris informatik unterstützen Sie gerne bei Ihrer Scrum Umsetzung und geben unser Wissen auch gerne in Schulungen weiter 😉

The post Remote Retrospektiven appeared first on Binaris Informatik.

Understanding Incremental Delivery

Dirk Theissen — Mon, 15 Jun 2020 15:51:42 +0000

The notion of incremental delivery is an essential feature of Scrum. It comes together with the concept of Sprint. In “The Scrum Guide,” its definition reads as follows: “An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.” As logical and straightforward it might sound, it is the most overlooked and misunderstood concepts of all, and the reason why most teams are not doing Scrum (and they should not!).

This topic has been commented on and explained in many other sites, but since it keeps on coming back, I will go ahead and try to offer one more explanation with the hope of helping the ones that still need aid getting into the idea.

What is an increment

Given that “the increment must be usable,” it follows that we do not have many choices when designing and planning our next delivery. For the outside observer, an increment could be a new or updated feature, whatever adds value to the product, but technically, since it must be in “usable condition” we can no longer consider as increments any pieces of code that will not provide stand-alone functionality by themselves.

Based on the previous definition, is it possible to abstract the three properties of an increment:

It constitutes a fully functional unit with business value on its own.
It is a step forward towards the completion of the product (if “completion” is an applicable concept).
Its release can be omitted, its schedule advanced or delayed without affecting the actual (existing) product.

Bug fixing, code improvements, performance improvements, and libraries upgrades are entirely out of the question. By definition, they do not constitute an increment.

One more analogy: the cake

Let’s get out of software development for a moment and think about the cake analogy. Our project is a chocolate cake; we know it should look rounded, dark and delicious. But things could change; therefore we will work with “incremental delivery.” Should the requirements change, then we will inspect and adapt accordingly. Every increment must be an “eatable product.”

What do we need to do to deliver a chocolate cake?: Buy the ingredients, mixed them all, bake the cake. After that, cut into six pieces and serve to the customer. Each step is a “Sprint.”

In a traditional approach, tasks will be organized as stated above: ingredients, mix, baking, serving.

Notice three things: first, not every Sprint is delivering anything in an “eatable condition.” Second, every Sprint depends on the previous one; we cannot reshuffle, skip or postpone any step without failing to deliver the final product. And third, if you cancel (stop) the process at any Sprint except the last one, the customer gets nothing eatable. This approach is waterfall-like, and the Sprint’s schema is bringing no value whatsoever. The focus is on the sequential order, and essentially, it is delivering “parts” that may or may not bring any benefit. In our example, they do not.

Thinking incrementally

Remember: “usable.” Every Sprint has to deliver a working unit that has its value, it is a step forward the completion of the product, and its release could be ignored without affecting the existing product. That alone gives us enough means to outline our next increment.

Now let’s examine the following image. I got it in Linkedin.de some years ago. It was very popular and liked by many people in the Agile community:

The upper row shows a typical example of partial delivery. Every Sprint adds a component, in the end, we get the product. Clearly, not an incremental approach.

But what about the lower row? Every Sprint delivers something better, but also a different product, so you never build on top of what you already have. Every “stage” requires starting from scratch again. It does not qualify as incremental because it does not possess any of the three properties described above. It does not make any sense at all. Maybe the author was trying to communicate the idea of growth or increase, but it just did not work. This unfortunate example is still today being referenced by many enthusiastic Agile fans, but it is a false analogy and a big source of confusion and misunderstanding.

Back to our chocolate cake, if we were to deliver it incrementally, we would have to mix the ingredients, bake and serve one slice at the time. Now we have got ourselves real increments:

Every slice is a fully functional unit with its business value (you can eat it!).
Every slice is a step forward the completion of the product (five slices to go!).
The fate of any single slice will not affect the final product: we could skip, delay or reshuffle the baking order and still get a sweet cake.

But although the concept is simple, it is the most challenging obstacle when developing software with Scrum and it requires overcoming an immense mental gap between paradigms. It is not just a matter of practice; our culture is shaped by the concepts of planning, anticipation, and control. Our daily lives are a constant projection to the future, and so project managers are supposed to be thinking ahead of the events all the time; software developers should write code preventing “any” situation and so on.

The practice of “incremental delivery” is in frontal opposition to these notions and it demands an immense effort to be comprehended and master.

On the technical side of the issue, increments imply higher implementation costs and technical debt. Such a delivery technique means rewriting, adapting, expanding or deleting stuff that took you already a lot of time to develop. Programmers have less time and a reduced big-picture perspective, and quality suffers. Time and effort multiply by the number of times the customer changes his mind or the market shifts course, but that is the price of uncertainty and customer-driven development. Should you have a complete, well-defined product in a stable market, in a world that does not change, then incremental deliveries are not recommended.

Last but not least, it is imperative to understand that this approach is not suitable for every product, and that is why (almost all) airplanes, cars, houses, and still many software products cannot and are not built using Scrum. As I write, many companies are forcing their ways into Scrum or Kanban, based on the old (misguiding) strategy of “divide and conquer” when in fact, incremental delivery has little or no relation to it. The impact in the business is terrible because most teams and products will not fit into the idea of “minimum viable product.” The incremental method is especially convenient for complex, ever-changing environments where you cannot or will not commit far into the future. Tangible goods, heavily law-regulated products (banking, security, etc.) and fully specified software are usually not eligible for it.

Conclusion

In conclusion “incremental delivery” means delivering working software on every Sprint, but it is a concept hard to grasp. It can be beneficial and productive, but like any other tool, it has limitations and conditions. It is crucial to recognize the environment in which increments thrive and the scope of the approach. If your situation is stable, with low uncertainty and the product can be thoroughly specified, incremental delivery makes no sense for you and you should not force the existing production methods to fit into it. Under any other conditions, you should seriously consider how you could benefit from it.

The post Understanding Incremental Delivery appeared first on Binaris Informatik.