My Management 3.0 Prezi (German slides)

From 12th to 13th of March I participated in a Management 3.0 workshop by Jürgen Dittmar in Munich. To present the highlights of the workshop to my workmates I decided to craft a Prezi. And here is the result of my first Prezi that finally made it onto a presentation screen (German slides):



The presentation went well (at least there was positive feedback). However I am still a novice Prezi craftsman and I welcome your feedback on my slides. Also feel free to reuse it for your purposes.

Better Feedback with a Happiness Door

My work as Agile coach includes regular training lessons with agile teams, product owners and other staff. Usually after a training or workshop I kindly ask the participants for their verbal feedback about the workshop, my moderation, the exercises, etc. A common practice that I just adapted from other trainers with the aim to improve my own training and moderation skills. Unfortunately the results of the verbal feedback rounds were not satisfying for me due to various problems:

  • Giving honest verbal feedback strait in the face seemed to be hard for my participants and therefore it was often omitted
  • Participants seemed to feel a barrier exposing their individual thoughts about the training in front of the group
  • Participants gave pseudo feedback by just repeating other’s feedback or giving hollow feedback
  • Only a few participants gave feedback at all
  • I hardly received constructive improvements (which is most interesting for me)
  • If there was plenty of verbal feedback after the training I often forgot most of it until I had time to reflect on it
  • Participants didn’t know how to express appropriate feedback

As a result I thought about alternative feedback mechanisms. I expected less problems with written feedback, which led to the idea to use a happiness door, a feedback mechanism created by Jurgen Appelo that I already knew from the management 3.0 workshop I attended some months ago.



Could the happiness door address my problems I had with verbal feedback rounds?

Yes. What has changed is that my participants felt safe to express their feedback semi-anonymously on sticky notes, which was not the case with the verbal feedback rounds. As a result I received more valuable feedback on my training lesson. Also everyone was willing to write at least one sticky note and because of less mutual influencing there was more individual feedback on the door. Finally seeing the feedback visually in front of me on the happiness scale was just great, because it gave me an instant feeling about my training performance and also helped me to remember a feeling of the training lesson. After the training I spent another 15 minutes to carefully read, interpret and summarize the feedback, which helped me to reflect. Last but not least due to sticky notes I didn’t miss any feedback, which happened quite often when doing verbal feedback rounds.

The only drawback I identified so far is that the written feedback can be easily misinterpreted and that there is no possibility to ask questions back. And of course you need to ask for a nice handwriting if you want to apply a happiness door.

Anyway, to put it in a nutshell the happiness door turned out to be a good feedback mechanism for me and there will be more happiness doors in my future training lessons for sure.

Why You Should Use a Definition of Ready in Your Projects

In my former blog post I introduced the concept of the “ready-ready backlog” for Agile teams. In this blog post I want to share some metrics about the effect of introducing a “Definition of Ready” (DoR) to industry projects.

I introduced the following DoR for an Agile team that has worked for 3 months together:

  • The business value of the user story is understood by the development team
  • The acceptance criteria are clearly defined and understood by the development team
  • Requirements on documentation, specification, configuration, test, regression tests and architecture are clarified
  • The development team has a concrete idea of demonstrating and testing the user story
  • The user story has been estimated by the team with a high confidence level

After introducing the DoR I gathered the following metrics from the following 7 sprints:

  • # of user stories committed for the sprint
  • # of user stories in the sprint backlog that did not fulfill the DoR
  • Velocity
  • Team happiness (1-10)
  • Fulfillment of sprint commitment (green = fulfilled, red = failed)

The results can be seen in the figure below:



By using the DoR in the backlog refinement meetings the behavior of the team changed perceptibly. Without the DoR it was sufficient for the team, if backlog items were shortly discussed and estimated. With the DoR the team focused much more on each backlog item and the discussions went deeper. More pitfalls were discovered upfront. Anyway it was hard to get each user story “ready” before sprint planning because of the high project pressure. After bumpy 4 sprints the ability of the team to analyze and refine backlog items improved significantly. For the following 3 sprints all committed user stories were “ready” according to the DoR and during the sprints less incidents happened due to overseen or miss-interpreted requirements. The DoR had a rather small impact on the ability to fulfill sprint commitments and velocity but by shifting the focus on getting backlog items “ready” it perceptibly improved the ability of the team to analyze and refine backlog items.

5 Tips on Getting Your Backlog Ready-Ready

Last year I worked with several teams on improving their development process by introducing a Definitions of Ready (DoR). Jeff Sutherland points out the importance of a DoR to achieve a “ready-ready” backlog in the following video:


Here are my six practical advices on getting a “ready-ready” backlog for  your projects:

Define your Definition of Ready:

Define your own Definition of Ready together with your team and product owner. The idealistic vision of a “ready-ready” user story is that the team can implement it without interruptions. Define your DoR according to this vision and your specific project needs. You can use the following list of questions as a guideline for your own DoR:

  • Does the user story meet the INVEST criteria?
  • Is the business value clear and understood by the team?
  • Are the acceptance criteria well-formulated and understood by the team?
  • Could everyone on the team test the user story?

Warning: I saw teams going way too far with their DoR, trying to lash requirements like in traditional design documents. Overcome the temptation to fall back in old habits.

Use your DoR for each user story:

Only the development team is allowed to call a user story “ready-ready”. Therefore the development team checks each user story, if it fulfills the criteria of your DoR or not. This can be done while backlog grooming or any time you prefer before sprint planning, but the product owner should be present.

Make “ready-ready” user stories visible:

It helps a lot if everyone can have a quick overview on how many user stories are “ready-ready” in the backlog. Use labels, coloring, traffic lights, prefixing or whatever you prefer to emphasize “ready-ready” user stories in your backlog. It doesn’t matter how you flag them as long as they are visible at one glance when looking at your backlog.

Make the sum of estimates of “ready-ready” user stories visible on your task board. Show the teams velocity next to it to signalize if you have enough user stories “ready-ready” for the next sprint planning. Having the figures prominent on the board makes everyone aware of the current backlog health and triggers action for backlog grooming.

Visualization of ready-ready backlog and velocity
Visualizing ready-ready backlog and team velocity on the task board

I also experimented visualizing “ready-ready” user stories on cards in a separate column on the task board but it was much more effort to maintain and update the column than just putting the sum of estimates on the board and the effect was the same.

Track open issues:

Make open issues (that prevent user stories from being “ready-ready”) transparent to everyone. It is crucial that open questions, unclear requirements, missing research or analysis, etc is visible to everyone, so that everyone knows what prevents a user story from being “ready-ready” and therefore needs to be resolved first. I my teams we keep track of open issues in a table that is attached to the user story like the one below:

Status Issue Responsible Solution
RESOLVED Is the address field mandatory for the user? PO Yes.
OPEN Check if email validation is already in place and working. Team

Live your DoR:

Make sure that the product owner and the development team understand the benefits of a “ready-ready” backlog. Provide your support whenever it is needed until the DoR flows through everyone’s veins. Live your DoR!


This Blog Will Change…

…to English!

I made this decision because I want to remove the nasty language barrier for all the potential international readers of my blog. I also hope to be able to reach more readers and trigger more discussions with this change.

No pros without cons…the drawbacks of writing in English (which is not my mother tongue) will be more mistakes (grammar, punctuation marks, prepositions,…) in my blog posts, but I promise that I will do my best to improve! 😉

Like always I welcome your feedback!

Stay tuned!


Meine erste Kudo Box

Eine der Ideen, die ich aus dem Management 3.0 Workshop mitgenommen habe, ist die Kudo Box. Ich habe vor zwei Wochen eine Kudo Box im Team-Büro aufgestellt und bereits erste Erfahrungen damit gesammelt.

In der letzten Sprint Retrospektive habe ich das Team gefragt, ob sie denn eine Kudo Box haben möchten – nach einer kurzen Erklärung lautete die Antwort kurz “JA”.

Ich habe die Box also an einem gut sichtbaren Ort neben dem Eingang aufgestellt, sodass jeder mehrmals pro Tag daran vorbei läuft. Die Kärtchen habe ich selbst ausgedruck und direkt neben die Box gelegt. Zum Selbstläufer wurde das Ganze allerdings anfangs nicht.

My First Kudo Box

Die ersten zwei Tage waren noch alle zurückhaltend mit den Kudos – ich habe dann begonnen die ersten zwei Kudo Karten einzuwerfen,  wodurch die initialen Hemmungen fielen und auch das restliche Team das “Tool” zu verwenden begann. Es folgten täglich weitere Kudos und es schien allen sichtlich Spass zu machen. Zeitweise war sogar ein echte “Kudo-Manie” ausgebrochen 😉

Kudo Card

In der folgenden Sprint Retrospektive habe ich die Kudos dann öffentlich verteilt. Es waren nach zwei Wochen über 20 Kudo Karten in der Box, was meine Erwartungen doch deutlich übertraf.

Wie groß der Impact der Kudo Box auf die “Team-Happiness” im letzten Sprint war läßt sich natürlich nicht eindeutig sagen. Subjektiv konnte ich aber eine sehr gute Stimmung im Team wahrnehmen. Die Ergebnisse der Sprint Retrospektive bestätigten dies auch:


Die Kudo Box ist bei uns nun ein fixer Bestandteil und ich bin überzeugt, dass sie zur Team-Kultur bereits einen positiven Beitrag geleistet hat und noch leisten wird – bei uns war der positive Spirit und der Spass im letzten Sprint auf jeden Fall deutlich spührbar.

Es ist erstaunlich, aber als ich meine Kudo Karte(n) entgegennahm hatte ich tatsächlich dieses Gefühl der inneren Zufriedenheit. Meine Motivation wurde dadurch merklich positiv beeinflusst und ich denke da ging es nicht nur mir so. Ich finde die Kudo Box ist eine genial einfache Idee, die mir jetzt bereits ihre Praxistauglichkeit bewiesen hat.

Trotz aller positiven Effekte möchte ich natürlich kritisch bleiben und den Effekt der Kudo Box noch auf längere Sicht betrachten. Für die weitere Beobachtung finde ich vor allem die folgenden Fragen spannend:

  • Wie ist der Effekt auf das Team, wenn nicht immer jeder Kudos erhält, also manche Personen leer ausgehen?
  • Kann im Team ein Wettbewerb um Kudos entstehen?
  • Kommt es über die Zeit zu einer Kudo Inflation?

Habt ihr schon mehr Erfahrungen gemacht als ich und vielleicht schon Antworten auf die obigen Fragen gefunden?

ReConf 2014

Von 12.-15. März war ich auf der ReConf in München und habe im Rahmen der Konferenz den 2-tägigen Management 3.0 Workshop bei Jürgen Dittmar besucht. In diesem Blogpost möchte ich meine Eindrücke von der ReConf Konferenz zusammenfassen, meine Take-aways aus dem Management 3.0 Workshop werde ich in einem seperatem Blogpost behandeln.


Ich war am 2. Konferenztag auf der ReConf und habe die unten gelisteten Sessions besucht und für den Blog erwähnenwert befunden. In Klammer neben den Vortragstiteln habe ich meine persönliche Five-Star-Bewertung vergeben.

Key-Note: Let’s Help Melly (*****)
Jurgen Appelo

Sehr inspirierender Vortrag vom Author des Buches “Management 3.0“. Inhaltlich war für mich viel Neues und manches Bekanntes dabei. Es wurden alle im Vortrag angesprochenen Themen im 2-tägigen Management 3.0 Workshop von Jürgen Dittmar tiefer behandelt, wofür ich einen eigenen Blogpost schreiben werde – bitte um etwas Geduld.

Anforderungsmanagement & Gamification (*)
Stefan Schuck, Polarion Software GmbH

Wenig überzeugender Vortrag, der sehr oberflächlich gehalten war und eigentlich für mich nichts neues gebracht hat. Das “Highlight” waren die beiden lustigen YouTube Videos zum Thema Gamification, die allerdings auch nicht mehr gerade neu sind (vgl. mein Blogpost aus dem Jahr 2009):

PO als Brückenbauer Business – IT (**)
Alex Rachmann & Frank Engel, Anforderungsfabrik GmbH & Co. KG

Guter Vortrag im Dialog-Stil. Inhaltlich sehr auf die “Basics” beschränkt und daher wenig interessantes dabei. Interessant war:

  • Wenn über Scrum gesprochen wird, dann wird wenig über den Product Owner geredet, viel über den Scrum Master
  • Google AdWords Statistiken zeigen, dass nach “Scrum Master” wesentlich häufiger gesucht wird als nach “Product Owner”

Management neu denken – Zusammenarbeit neu definieren (****)
Björn Schotte, Mayflower GmbH

Sehr spannender, praxisbezogener Vortrag mit vielen neuen Impulsen zu Teamzusammenstellung, Management, Innovationskultur, gutes Arbeitsklima, etc. Björn Schotte experiment anscheined sehr viel in seiner Firma, was mir persönlich sehr gut gefällt. Die Ergebnisser seiner Experimente und Erfahrungen hat er in seinem Vortrag gepackt.

Björn Schotte sprach zu Beginn seines Vortrages von der Wichtigkeit “Accidential Conversations” zu unterstützen um informellen Austausch der Mitarbeiter zu stimulieren und in Folge Ideen entstehen zu lassen. Er erzählte dann, dass er Persönlichkeitstests mit seinen Teams macht um ein Klima der Offenheit zu erzeugen und somit die Teamarbeit zu optimieren. Er nannte folgende Tests, die er als geeignet ansieht:

  • MBTI
  • HBTI
  • DISC
  • Big Five

Als weitere Methode nannte er Personality Poker (von Stephen Shapiro) um spielerischdie Zusammenstellung von innovativen Teams zu unterstützen.

Danach stellte er Marc Hedlund’s (VP SW-Engineering @ Etsy) Methode um Change im Unternehmen voranzutreiben vor: Marc bloggt im internen Abteiltungsblog über Dinge die er verändern möchte und wartet auf das Echo der Mitarbeiter. Die Mitarbeiter entscheiden letztlich über die Umsetzung. Wenn die Idee initial nicht gut ankommt betreibt er aktiv lobbying indem er gezielt mit Mitarbeitern darüber redet. Wenn das auch nicht hilft ist für ihn die Idee gestorben und er bloggt die nächste Idee.

Björn Schotte nannte nannte auch die Wichtigkeit “Danke” zu sagen und Mitarbeiter dazu zu inspireren das auch zu tun (z.B. mit der einer Kudo Box).

Er gibt seinen Mitarbeitern auch 10% Slacktime, in der die Mitarbeiter an beliebigen Dingen arbeiten könnenEinzige Bedingung: Es muss Teamarbeit sein. Der Ablauf eines Slackdays ist wie folgt:

  1. Ideen Pitch in der Früh und Teamfindung
  2. Vorgegebene Zeit für die Umsetzung der Ideen (12-24h)
  3. Präsentation der Ergebnisse vor allen Mitarbeitern

Björn Schotte macht auch eine Firmen- bzw. Bereichsretro 2x im Jahr mit allen Mitarbeitern des Bereichs / Firma. Das Streichen von Jobtiteln wird in seiner Firma derzeit noch kontrovers diskutiert. Open Salary (Offenlegung der Gehälter) wurde von der Mehrheit im Unternehmen abgelehnt und daher nicht umgesetzt.

Zum Ende sprach er noch 2 Empfehlungen aus:

  1. Macht ein Barcamp mit eurem Konkurrenten: Das gibt einen enormen Innovations-Drive und wertvollen Informationsaustausch. Das erste Barcamp war ein voller Erfolgt weshalb er es nun regelmäßig macht.
  2. Bloggt in eurem Corporate Wiki

Key-Note: Bridging the Gap Between RE, Process Definition and Successful Iterative Roll-out (***)
Colin Hood, Colin Hood Systems Engineering

Für mich passt der Titel nicht wirklich zum Inhalt Vortrag, der gut und unterhaltsam war, allerdings inhaltlich nichts neues bot. Colin Hood hat sich in seiner Key-Note ganz dem Thema “Organizational Change” gewidmet. Eine seiner ersten markanten Aussagen war: “You have to put people in the middle of your change initiative!” Weiters sprach Colin: “Humans are great at ignoring information when change happens” und untermauerte diese Aussage mit einem eingängigem Beispiel – einer wahren Geschichte oder eine Studie – ich weiß es leider nicht mehr. Soweit ich mich erinnere ging das Beispiel etwa so: Autofahrer sind es gewöhnt mit dem Lenkrad das Fahrzeug zu lenken. Wird während dem Autofahren der Zündschlüssel wird die Lenkradsperre aktiv und macht das Lenken unmöglich. Um das Lenken wieder möglich zu machen muss der Zündschlüssel wieder angesteckt werden. Menschen, denen das passiert, versuchen allerdings mit aller Gewalt zu lenken anstatt den Zündschlüssel wieder anzustecken, obwohl sie wissen, dass der Zündschlüssel das Problem beheben würde. Laut Colins zeigt das Beispiel, dass wir in veränderten Situationen nicht immer rational handeln und das Handeln nach alten Gewohnheiten (das Lenkrad lässt sich nach Links und Rechts drehen) bestimmend ist.

Laut Colins braucht es die folgenden 3 Dinge für organisatorischen Wandel:

  • Manager müssen den Mitarbeitern das Gefühl von Sicherheit geben (Fehler müssen erlaubt sein)
  • Es muss eine Chance auf Erfolg geben
  • Das “WARUM” muss klar sein

Abschließend kam Colins noch auf den Deming Cycle zu sprechen, den er als Modell für kontinuierlichen Change sieht.