Category Archives: Scrum

The use of incentives

Luis Goncalves wrote a great posting concerning the consequences of incentives, regardless whether it was based on an individual’s or team’s level. The real world issues described by Jakob Carlsen’s comment may be familiar with some employees.

Once again I’d like to recommend »The surprising truth about what motivates us« by the Royal Society of Arts and Oscar Berg‘s marvellous »What makes knowledge workers productive?« venn diagram.

Scrum verstehen – mit Lego?!?

Am Donnerstag Abend hatte gut ein Drittel der Mitarbeiter eine Menge Spaß mit Lego-Scrum. Gleich nach dem Spaß kommt allerdings auch schon der Streß, denn in den drei Stunden, die das ganze in etwa dauert, läuft so gut wie alles in Zeitfenstern ab.

  • Zuerst wird ein Product Backlog erstellt und geschätzt.
  • Jetzt kann es auch schon in das erste Planning, den ersten Sprint (sieben Minuten), das erste Review und die erste Retrospektive gehen.
  • Das ganze wiederholt sich zwei bis vier mal.

Ich kenne kein besseres Mittel, um Gruppen von 10 bis 40 Personen in nur wenigen Stunden Scrum im Praxiseinsatz näherzubringen. Der Vorteil der Legosteine ist, dass man in sehr kurzer Zeit etwas bauen kann – würden wir mit dem Erstellen von Software üben, bräuchten wir deutlich mehr Zeit.

Scrum – The »Definition of Done«

Die Definition of Done ist vielleicht das Artefakt des Scrum Guide mit dem größten Klärungsbedarf. Nachdem ich am Mittwoch zusammen mit Joachim Weiß (danke, hat sehr viel Spaß gemacht) auf dem Treffen der Scrum User Group einen Abend zu diesem Thema moderiert hatte, ergab sich am gestrigen Samstag auf dem Open Space der Softwerkskammer in Bretten (danke an die Organisatoren und Sponsoren, hat ebenfalls sehr viel Spaß gemacht) erneut eine Session zum selben Thema.

Hier ein paar Punkte, was eine Definition of Done aus meiner Sicht ausmacht:

  • Sie ist so kurz wie möglich. Andernfalls steigt das Risiko, dass sie keine Anwendung findet.
  • Sie ist so einfach zu verstehen wie möglich, damit sich das geforderte »Shared understanding« einstellen kann.
  • Sie ist eine Vereinbarung des gesamten Scrum-Teams, nicht nur des Entwicklerteams. Es handelt sich andererseits auch nicht um “Gesetze”, die der Product Owner erlässt.
  • Es handelt sich auch nicht um ein detailliertes Lastenheft, anhand dessen der Product Owner das Team festnageln kann.
  • Überarbeitungen sollten nicht durch reines Hinzufügen von Punkten erfolgen, sondern wirklich eine Überarbeitung sein.
  • Überarbeitungen können als Ergebnis eine Retrospektive oder auch noch im Sprint Planning I erfolgen (»Der Kunde fordert ab sofort eine PDF-Dokumentation für neue Features«). Allerdings können es Anpassungen erfordern, dass Backlog Items neu Gegroomed (Agilist? Anglizist? Egal) und beschätzt werden müssen.
  • Die Definition of Done bleibt während eines Sprints stabil.
  • Der Product Owner steht und fällt mit dem Entwicklerteam. Wenn es im gesamten Scrum Team an Vertrauen mangelt, wird weder die Definition of Done als Artefakt noch Scrum als Framework helfen.

Was mir fehlt sind ein paar Beispiele für gute DoDs. Die Suchmaschine des Vertrauens wird leider etwas wortkarg, sobald es um das Thema geht. Ein Bekannter von mir erzählte jüngst von einem Bekannten, der jemanden kennt, der in einer Firma arbeitet, in der es gar keine DoD geben soll. Unvorstellbar, sowas. Eigentlich :) .

Scrum User Group Karlsruhe April 2013 – Definition of Done

Due to an initiative of Joachim, we moderated today’s meeting of the local Scrum User Group. The topic was »The Definition of Done«, one of the less popular Scrum artifacts.

Attendees told us about teams with no DoD present at all to teams with very detailed ones. We had some vivid discussion about several aspects of the DoD, and I learned a lot.

Credits go to all participants, to Joachim for the great support, and to Mentos who ensures that those meetings take place.

Once more – thanks guys and girls :) .

Getting things done – using Shuffle and Tracks

Though I read »Getting things done« by David Allen a couple of years ago, I never consistently used it. I was just comfortable with the tools I was used to, including notebooks.

Since I left my long time employer recently to start working as an “agile consultant”, things have changed. Though I’m still using plain old school paper, an Android powered handset became one of the most important tools (which can be read as »single point of failure«) to organise my activities.

Simple note taking applications, wich I used until now, just leave too much »noise« on the screen which does not fit the current context one is currently working on. As a consequence, I remembered David’s book. I started to search for a simple GTD application and stumbled upon several comparison lists like this one.


Astrid Tasks & To-do List seems to be pretty popular and syncs its data with or even Remember the Milk, though there seem to be some known issues. Since I was interested in a sync service I can control myself, I put it on the MaybeLater :) stack.


The next application that gained my interest was Shuffle. Though Andy Bryant seems to have retired concerning new features, I liked what it has to offer. The source code is publicly available, it’s features are limited to what you really need (e.g. no yagni), the user interface is kept tidy, and it provides sync with a Tracks server (see below). Additionally it provides a desktop widget which can display a configurable data set.

After the installation, Shuffle offers to create some example data. I didn’t use it but started to fill it with own content.

I’ll see during the next couple of days whether it will serve me well.


When reading Allen’s book I also experimented with Ruby on Rails. I remember I also played with Tracks, an RoR GTD application meanwhile hosted on Github. I tried the BitNami installer, but got some ASCII vs. Unicode error after logging in. Admittedly I was too lazy to debug the issue (I guess it came from the german locale present on my Mac OS X 10.7.5 machine). Instead of setting up my own server, I (ab)used one of the ready to use installations, namely Thanks for the great service, BTW.

A test sync with Shuffle worked immediately:

I’m pretty curious whether the sync with a privately set up Tracks server will show some quirks during daily use. Due to the fact that the source code is available, I’ll hopefully be able to write a patch by myself in case such issues occur.


None so far :) . I’ll first check whether Shuffle will serve me well as a standalone application. If so, I’ll set up a Tracks server on one of my machines so that I can sync my data with it. The main purpose is that it is a bit cumbersome to enter text with the on screen keyboard of a handset device. In case the sync works, one could keep the entries done on the phone brief and edit them as soon as a computer with an internet connection is available. Last but not least, I’m curious whether this combo can serve as an impediment backlog of a Scrum Master :) .

Scrumday Conference 2012 is past

The Scrumday conference 2012 is past. The first day opened with some Open-space discussion, followed by a fishbowl conversation with Ken Schwaber and Dean Leffingwell, and ended with a “get together” party.

Today was organized as a traditional conference providing keynotes (Ken Schwaber, Dean Leffingwell, Martin Fassunge & Tobias Hildenbrand) and talks. Once again, a great event to exchange ideas and to learn from other Scrum professionals. I’m glad I made it, despite a couple of impediments :) .

How Real Is Real?

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.

Scrum User Group Karlsruhe April 2012

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, the company who provides the propellerheads behind the local Scrum User Group.

User Stories Applied & Agile Estimating and Planning


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:

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

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