Paul Watzlawick has written a couple of popular books. Ages ago I read »The Situation Is Hopeless, But Not Serious: The Pursuit of Unhappiness« (1983), and recently »How Real Is Real?« (1976). Actually I read the german language issue »Wie wirklich ist die Wirklichkeit?«, the first book for some time now I was reading in my mother tongue.

The book is a joy to read, and I finished it in a couple of evenings. It is divided into three parts, confusion, disinformation, and communication. In short, Paul states that reality is a result of communication and provides a couple of astounding examples.

The book is capable of changing your point of view about everyday’s things, regardless whether private or professional issues. After reading two thirds of the book, it already helped me better understand what is happening in my team the next day. In case your job includes managing humans, I can recommend this book – you won’t regret.

For quite a while now we are used to decompose the user stories into tickets daily rather than during a boring sprint planning II marathon. I knew other teams did it this way already, but I thought my team was not prepared for it yet. But as some team mates wanted to try it anyway, I didn’t object further. It turned out to be a very useful approach.

• The sprint planning II meeting is much shorter now, and we get some work done even on the very first day of each sprint. The saved time gets consumed anyway, as the daily ticket generation is done during the Daily Scrum, which now requires about 30 minutes instead of 15.
• The ticket generation is much more straightforward than during sprint planning II, as it is obvious which things need to be achieved next.
• During the Daily Scrum, the team members gain a better understanding of what will happen until the next Daily Scrum, since the ticket generation is more intense than each team mate just grabbing an existing ticket.
• We try to generate tickets which can be finished completely until the next Daily Scrum. Thus it is much easier to synchronize the work across the team members.
• It is much easier to respond to things which got known since the last Daily Scrum, and it’s much more “Inspect and Adapt” than the attempt to foresee everything at the beginning of the sprint.
• The Product Owner can review a small product increment almost every day, making it possible to apply adaptions earlier.

Apparently it is a bit more difficult for the team to track whether a story is progressing well, but frankly, this problem did exist beforehand also. Since we do agile software development, we accept that a story may become more complex than expected. As a consequence the Product Owner prioritizes the stories of each sprint so that the team members can finish the topmost stories first. In case complications occur, the stories of the lowest priority can be dropped in favor of more important ones, or the devlopment team can negotiate with the Product Owner how to cope with the situation at hand.

Due to a cool and windy easter monday, I had the occasion to start reading »The Skilled Facilitator« (Roger Schwarz 2002). As anticipated, some of the content is similar to other books concerning “servant leadership”, e.g. »Agile Coaching« (Rachel Davies and Liz Sedley 2009), »Coaching Agile Teams« (Lyssa Adkins 2010) or »Motivating Employees« (Anne Bruce, James S. Pepitone 1999).

It’s intentional that I started reading books which are not specialized in agile software development. It’s just to shed a little light on the work I do from a different point of view.

In case you are a Scrum Master who transmogrified into this role from a technical background (just like me) and who already knows how to live Scrum, this book is the right addition to your bookshelf. Though I just read a tenth of it, it is likely that it will already influence the work I’ll do tomorrow.

I’m just back from the bi-monthly meeting of the local Scrum User Group. The organisators prepared an exercise to rise the awareness of team information dynamics. The participants (including me :) ) learned a lot this evening, so thanks a bunch!

The rest of the evening was covered by the usual networking and discussing actual problem that we face in our everyday’s work as Scrum Masters and/or Product Owners.

As always, an excellent occasion to improve everyone’s skills and abilities. All credits to go-agile.de, the company who provides the propellerheads behind the local Scrum User Group.

A Product Owner is aware of a “Minimum Marketable Featureset”. The opposite would be a “Maximum Marketable Featureset” as mentioned by Willem van den Ende. Kathy Sierra blogs about the “Happy User Peak“.

To achieve this, you need an empowered Product Owner who is capable of developing a clear vision of the future product. In case a mass product is being developed, the most important thing is filtering the solution requests and to turn it into usable software. It is the Product Owner’s responsibility to maximize the work not being done. Quoting Kathy Sierra:

Give users what they actually want, not what they say they want. And whatever you do, don’t give them new features just because your competitors have them!

The key to success is focus.

For the last release of the product I’m currently responsible for, we developed a completely new feature and focussed on its easy of use. As a consequence, it misses a whole bunch of features we are aware of. Additionally, we dropped a fistful of legacy features in favour of the new one. And since the product was released, the market is honouring our efforts.

This posting about means of communication, accuracy, and aesthetics, appears in german language only due to german language references. International readers, I apologize.

Kommunikationsmittel

Die Sprache, die Schrift, eine technische Zeichnung oder ein Blatt Noten sind »Kommunikationsmittel[…], mit deren Hilfe sich Menschen untereinander verständigen können.«. Ein Architekt vermittelt mit einer Zeichnung anderen, wie das geplante Gebäude aussehen soll, während ein Komponist durch Noten ausdrückt, welches Musikstück sich in seiner Vorstellung entwickelt hat. Damit das Ganze funktioniert, bedarf es einer Konvention – beide müssen “die gleiche Sprache” sprechen.

Interpretationsspielräume in der Kommunikation

Trotz der Konvention gibt es Interpretationsspielräume durch Unschärfen im Kommunikationsmedium. Ein Notenblatt beispielsweise kann weder Tonhöhen noch Rhythmus beliebig fein auflösen. Kommunikation enthält außerdem auch unbewusste Komponenten, die vom Empfänger in seiner Vorstellung in einen entsprechenden Kontext gesetzt werden. Speziell in der schriftlichen Kommunikation kann man zudem gelegentlich feststellen, dass der eine sich präziser artikulieren kann und dabei auch Wert auf ästhetische Gesichtspunkte legt, während der andere wesentlich pragmatischer zu Werke geht. Wer ein Bild malt wird bezüglich der Ästhetik andere Maßstäbe anlegen als jemand, der eine Einkaufsliste verfasst.

Was aber hat das mit agiler Softwareentwicklung zu tun?!?

Code ist ein Kommunikationsmittel

Wie eine technische Zeichnung ist ein Stück Code in der Softwareentwicklung auch die Repräsentation der Gedanken desjenigen, der ein bestimmtes Problem lösen möchte. Mit dem Code, den er schreibt, teilt er nicht nur der Maschine, sondern auch seiner Nachwelt mit, was er dabei erreichen wollte – der Code ist also ein Kommunikationsmittel. Die Wahrscheinlichkeit, dass später entweder der Autor selbst oder ein anderer Fehler beheben, Verbesserungen oder gar neue Funktionalität hinzufügen möchte, ist groß. Sofern der Code bestimmten Konventionen folgt, präzise formuliert und gut strukturiert ist, wird es in einem halben Jahr deutlich einfacher sein, die dann anstehenden Änderungen vorzunehmen.

Wer agile Softwareentwicklung als Profession betreibt wird vielleicht sogar auf testgetriebene Entwicklung setzen, in der die Tests zum Ausdruck bringen, welches Bild der Programmierer beim Schreiben des Codes im Kopf hatte.

Der Softwarearchäologe

Boris Gloger hat vorgestern in seinem Posting Agile Architektur ist änderbar! das Problem beschrieben und ein paar nette Metaphern genutzt. Das Verstehen und effiziente Ändern von Code, den man nicht selbst geschrieben hat, ist für alle Mitglieder eines ScrumTeams ein wichtiger Baustein zum Erfolg.

Boris schreibt:

Lesbarkeit: Der Code sollte so strukturiert und geschrieben sein, dass er leicht verständlich und lesbar ist.

Eigentlich sollte das eine Selbstverständlichkeit sein. Allerdings erfordert das Disziplin. Es ist einfach, Code zu schreiben, der etwas Nützliches tut. Es ist aber aufwändiger ihn so zu schreiben, dass die Gedankengänge auch später noch nachvollziehbar sind – sei es für den Autoren selbst oder für andere. Und nicht zuletzt spart lesbarer Code, der in »Usable Software« mündet, eine Menge Dokumentationsarbeit ein.

Doch halt – was ist mit Kommentaren? Boris schreibt weiter:

Inline-Dokumentation der Entscheidungen: Es sollte im Code erklärt sein, warum gewisse Entscheidungen so getroffen wurden, wie sie getroffen wurden. Der Code selbst ist ja die Dokumentation dessen, was der Code macht. Nur wieso man die Dinge so angegangen ist, wie sie vorliegen, wäre wichtig zu wissen.

Kommentare sollten nur dort zum Einsatz kommen, wo der Code nicht mehr selbsterklärend geschrieben werden kann. Beispielsweise weil man um eine Unzulänglichkeit des Betriebssystemes (»Was macht er denn da?!?«) herumkommen musste.

Kommentare wie

// Traversing the list
for ( int i = 0; i < lst.size(); i++ )

oder

// Checking whether we can open the file
if ( !f.open() )

sollten gelöscht, dafür die Bezeichner etwas sprechender gewählt werden.

Vor ein paar Tagen habe ich eine Codestelle geändert. Gestern bemerkte ich, dass ich vergessen hatte, den darüberstehenden Kommentar zu ändern. Den Bug habe ich gefixt. Indem ich den Code so umgeschrieben habe, dass der Kommentar überflüssig wurde.

Interlude

Goke hält mit ausgestreckten Armen ein iPad so vor sich, dass er die Noten gut lesen kann. Mit spitzen Lippen pfeift er die Melodie. Nach wenigen Sekunden stimmt Peek mit ein.

Schlussfolgerung

Jedes Mitglied eines ScrumTeams, das vom Erfolgsfaktor der kollektiven Codeverantwortlichkeit in der agilen Softwareentwicklung überzeugt ist, wird darauf drängen, dass der Code als Kommunikationsmittel lesbar geschrieben wird. Jeder kann damit aus dem Stand gleich morgen anfangen. Wichtig ist nämlich nicht das Wollen, sondern das Tun in kleinen Schritten.

Wenn sich später noch die Lektüre von Büchern wie Agile Developer Skills (ISBN 3868020608) von Christoph Mathis und Andreas Wintersteiger oder Clean Code (ISBN 3826655486) von Robert C. Martin anschließt - umso besser.

Overview

Though we introduced two physical boards for managing the product and the sprint backlogs, I’m still searching for a method to organize their items in a manner that fits our needs best. There are two books sitting on my couch which I hope to read during the Xmas break. Both are written by Mike Cohn and seem to be standard works for agile addicts (and even recommended by Ken Schwaber).

User Stories Applied

Here’s just a short citation of its¹ back cover:

Thoroughly reviewed and eagerly anticipated by the agile community, User Stories Applied offers a requirements process that saves time, eliminates rework, and leads directly to better software.

Of course the book is not only about user stories, but also about all of the adjacent topics.

Agile Estimating and Planning

Again a short citation of its² back cover:

Using the techniques in Agile Estimating and Planning, you can stay agile from start to finish, saving time, conserving resources, and accomplishing more.

Again, this book is about management of agile software projects in common and not only about estimating and planning. I hope to learn a lot by reading them.

¹ Mike Cohn, »User Stories Applied« 2004, ISBN 0-321-20568-5

² Mike Cohn, »Agile Estimating and Planning« 2006, ISBN 0-13-147941-5

Today the local Scrum User Group met at the usual location. Thomas Spielhofer came from Vienna to gather feedback concerning the study »Successful agile leadership« (German Tongue PDF). Subsequently we discussed the points presented by Thomas.

I’ll not post more details as it’s late already and other things on today’s to-do-list are still open. In case you are living nearby, feel free to visit the next meeting in two months.

The first portable synthesizer, the Minimoog

The Scrum Guide 2011 states:

The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current Definition of “Done.”

and

This Increment is useable, so a Product Owner may choose to immediately release it.

Using Scrum, we intend to create a »potentially releasable« and »useable« piece of product increment which is completely »Done« during each sprint, which means there’s nothing left to do. For example, the software behaves performant under real usage conditions and the end user documentation is written completely.

The Definition of Done is a kind of contract between the Product Development Team and the Product Owner. Together with a Product Backlog Item, it defines whether a product increment is »done«. Only »Done« product increments will be accepted by the Product Owner, otherwise the increment will be rejected.

My team currently struggles with performance issues which need to be addressed prior to releasing the product. The issue exists for quite some while now. It happened since performance was not listed in the Definition of Done yet and the team did only test with a small amount of data. Additionally the Definition of Done was neither respected on a regular basis nor was it maintained or emergent. Now it triggers stress, as improving the performance requires heavy changes under the hood while the planned release date is approaching.

During the last retrospective I grabbed the occasion to point out that the Definition of Done is a major key to success and that we need to learn how to cope with it properly. Unfortunately my team mates still did not understand the sense and purpose of the document. Is it their fault? No. It’s mine as their coach. I’ll try to communicate it once again tomorrow.

Before gaining the Professional Scrum Master I certification two days ago, I gained the Certified Scrum Product Owner certificate after a training with Roman Pichler in february. I’m currently listed as CSPO at scrumalliance.org.