Agile Transformation Toolbox

Was ist eigentlich die Definition of Done?

Neulich habe ich ein Training für eine Firma gegeben und es wurde immer wieder der Begriff „Definition of Done“ falsch formuliert. Wenn du alles richtig machen möchtest, ist es allerdings sehr wichtig, dass du diese Definition genau verstehst. Deshalb möchte ich dir heute erklären, was wirklich dahintersteckt.

Was ist die Definition of Done?

Es handelt sich dabei um eine generische, generelle Beschreibung der Qualitätskriterien, die wir uns als Team auferlegt haben. Erst wenn diese Dinge erfüllt sind, kann ein Feature als erledigt abgelegt werden. 

Ein genaues Beispiel dafür bekommst du in der ganzen Podcast-Episode, also höre unbedingt rein, um das Thema noch besser zu verstehen. 

Die Definition of Done wird im Team gemeinsam mit dem Product Owner, dem Entwicklungsteam und dem Scrum Master festgelegt. Oft gibt es dafür genaue Checklisten, die dann abgehakt werden.

In einem guten Scrum-Team werden dann nicht nur die Akzeptanzkriterien erfüllt, sondern für diese Features sollte es beispielsweise auch automatisierte Test-Cases und weitere Dinge zu beachten geben. Eine Definition of Done beschreibt sozusagen, dass ein Feature dann erledigt ist, wenn alle Akzeptanzkriterien erfüllt sind und auch auf alle anderen Dinge auf der Checkliste geachtet wurde.

Ein häufiges Problem bei der Definition of Done

Oft stehen auf der Liste zu viele Dinge, auf die geachtet werden muss. Das Problem dabei ist, dass somit kaum geschafft werden kann, all das zu erfüllen. 

Definiere die Kriterien also am besten nicht zu streng und setze nicht übertrieben viele Dinge auf die Checkliste. Dann ist es wirklich ein sinnvolles Werkzeug, das dir und deinem Team dabei hilft, die gemeinsamen Qualitätskriterien zu definieren

Ein großes Missverständnis ist auch, dass es sich bei der Definition of Done nicht ausschließlich um die Akzeptanzkriterien handelt. Das ist nur eine Teilmenge davon, denn sie umfasst zusätzlich alle Dinge, die ihr selbst im Team definiert.

Wenn du noch Fragen zu diesem Thema hast, lass es mich gerne wissen und melde dich jederzeit.

Jurgen Appelo is a top keynote speaker and writer from the Netherlands. His new book “Start up, scale up, screw up” is a helpful tool book for a new generation of founders. It dives deep into the art of entrepreneurship and how to grow your business lean in an agile environment.

Why is being agile so important for a start up?

Jurgen says that, being agile is not a goal. It is a means to an end, for a world that is thriving constantly. As a founder and entrepreneur, you should always develop new ideas till they don’t work anymore. The book delivers some clarity through a holistic picture on lean entrepreneurship.

He also refers to the innovators dilemma and how whole industries get disrupted by new business models. The music industry for example was totally disrupted by the invention of Spotify and similar companies. Established businesses are often pinned down to just being profitable. They forget to invest in new business models and ideas to solve the same problem in a different way.

3 keys to solve the innovators dilemma

• A company should never associate with only one business model. Apple for example is always thriving. First, they got popular through the MacBook. Then the iPhone became even more successful. And recently, they are working on apple tv.

Your business should always be a family of business models. It is crucial to have different frameworks for different business models and each unit should have a different structure.

• Agile & Design thinking is most important. It means to always iterate the product. The risk of adult businesses is not to be profitable anymore. The risk for a start-up is, inventing something that nobody wants. Iterating is different for both, but you have to iterate constantly.
• Test and implement great ideas. Create an innovation funnel. Get rid of bad ideas and implement good ideas to raise the bar constantly.

What are your 3 favorite tools from your book?

• “The innovation vortex” – design thinking synthesis of lean start-ups. Design thinking is not sequential, it is a non-linear messy process. Focus on observing customers and create minimal viable products (MVPs)
• “10 lifecycle stages” - an overview of all stages of start-ups. It gives practical advice and it answers questions like: “In which stage is my company right now?” “What do I have to do next?” Then, apply something that works in each life cycle.
• “North star metric” – focus on different things in different life stages with a clear goal setting. For example, if you are in the seed stage, just focus on convincing investors.

What is your last advice for starting entrepreneurs?

Allow things to grow without all things working. He said that, “we moved from something small that didn’t work to something big that didn’t work by adding unnecessary features.” 

It is impossible to make a complex big system work in the beginning. Keep staying small and lean. When you have something small that works, keep growing it.

In dieser Folge beantworte ich die Frage, welche agilen Tools es eigentlich gibt. Dazu eines vorweg: Wenn Du mit Deinem Team in einem Raum sitzt, gibt es kein besseres Tools als Zettel (Post-Its) an der Wand. Hier die Liste der Tools:

Top 3

1. Targetprocess
2. Atlassian Jira
3. Vivify Scrum

Online Tools für Retrospektiven

1. Retrium
2. Parabol

Personal Kanban / Task Management und Co.

1. Trello
2. Meistertask

Mehr Infos zu den Tools gibt es im Podcast.

Wieder ist ein Jahr vergangen, mit vielen fantastischen Podcast-Folgen. Hier noch einmal die Top 10 zum nachhören:

1. Welche Skills brauchen Agile Coaches
2. Typische Fallstricke in der agilen Transformation
3. Das Geheimnis von OKRs
4. Interview mit Boris Gloger
5. Team Agility ist nicht Business Agility
6. Scrum ist nicht genug
7. Was sich in 10 Jahren Scrum Training geändert hat
8. Wie erstellt man eine Team Charta
9. Was macht ein Scrum Master den ganzen Tag
10. Modern Agile - Was ist das eigentlich?

Bis zum nächsten Jahr :)

Zur letzten Folge im Jahr 2019 darf ich Simon Harrer begrüßen. Er ist Berater bei Innoq und dort für Softwareentwicklung und Trainings zuständig. Sein Fokus liegt darauf, sich immer weiterzuentwickeln sowie immer mehr zu wachsen und zu lernen. Diese neuen Kenntnisse bringt er dann gerne anderen Menschen bei.

Simons Buch „Java by Comparison“ – so kam er zu dieser Idee

In Simons Buch geht es um Vorher-Nachher-Vergleiche wie schlecht geschriebene Codes lesbar gemacht werden können. Da er an der Uni in Bamberg den Studenten Java beigebracht hatte, stieß Simon immer wieder auf die gleichen Dinge, die einen Code schlechter lesbar machten.  

Diese Dinge hat er nun in einem Buch zusammengefasst, was sozusagen als Mentor in Buchform dient, um jeden Code schrittweise zu verbessern. 

Was genau ist Mob-Programming?

Die sogenannte Mob-Programmierung ist ein Ansatz zur Softwareentwicklung, wobei das ganze Team zur selben Zeit, am selben Ort sowie am selben Computer an ein und demselben Thema arbeitet. Das kannst du so verstehen, dass eine Person tippt, alle anderen sitzen drumherum und suchen gemeinsam die Lösung für ein Problem.

Das sind die Vorteile an dieser Art der Arbeit

Es geht einerseits um das gemeinsame Lernen, die Weiterentwicklung und Wissen wird sehr gut verteilt. Andererseits weiß das gesamte Team alles über das Projekt und es ist keine Urlaubsübergabe nötig. Zudem wird massiv Zeit gespart, da keiner warten muss, bis Zwischenschritte anderer Kollegen erledigt werden. 

Wie läuft ein Remote-Mob-Programming ab?

Anstatt in einem Meetingraum vor Ort sitzen alle Team-Mitglieder in einem virtuellen Raum wie beispielsweise über Zoom mit Video. Die Person an der Tastatur teilt immer ihren Bildschirm mit dem restlichen Team, um alle teilhaben zu lassen. 

Weitere Vorteile und wie genau du einen erfolgreichen Remote-Mob starten kannst, erfährst du in der gesamten Episode. 

Simons Tipps, wie du mit einem Mob durchstarten kannst

Du solltest unbedingt das Buch von Marc Pearl „Code with the Wisdom oft he Crowd“ lesen, was aus eigener Erfahrung sehr hilfreich ist. Zudem ist einfach ausprobieren die beste Möglichkeit, um das Feeling dabei zu testen. Du wirst überrascht sein, was ihr gemeinsam alles erreichen könnt.

Heute möchte ich dich gerne an meiner persönlichen Meinung zur gewaltfreien Kommunikation teilhaben lassen. 

Meiner Ansicht nach macht gewaltfreie Kommunikation, wie sie in den meisten Fällen gelehrt wird, mehr kaputt, als dass es in irgendeiner Art und Weise hilft. Daher halte ich von gewaltfreier Kommunikation im herkömmlichen Sinne nur wenig. Das hat den Grund, dass dieses Thema leider mittlerweile total auf ein rein rhetorisches Tool reduziert wird. 

Haltung kommt in herkömmlichen Trainings zur gewaltfreien Kommunikation meist zu kurz

Wenn du zur gewaltfreien Kommunikation verschiedene Trainings besuchst, wirst du schnell feststellen, dass das Thema „Haltung“ umgangen wird und alles in den meisten Fällen auf die rhetorische Technik reduziert wird.

Es wird in Trainings oft von den 4 Elementen gesprochen. Hierbei spielt erst eine Rolle, was du beobachtest. Mache dir anschließend bewusst, welche Gefühle dabei hochkommen und welche Bedürfnisse sich entwickeln. Daraus kannst du dann eine Bitte an dein Gegenüber formulieren. 

Das führt allerdings schnell dazu, dass dabei sehr gestellt Sätze rauskommen und der andere merkt sofort, dass etwas nicht so gut zusammenpasst. Daher ist diese Art der Kommunikation nicht authentisch. Eine nicht authentische Kommunikation führt eher zu einer viel schlimmeren Gegenhaltung.

Gewaltfreie Kommunikation ist primär ein Tool zur Selbstreflektion 

Zunächst hat diese Thematik gar nicht so viel mit der Sprache selbst zu tun. Kommunizieren beschränkt sich ja nicht nur auf die Sprache. Mit den 4 Elementen solltest du vielmehr reflektieren, was aktuell mit dir selbst passiert und ob deine Beobachtung von dir selbst herausgetrieben ist oder außerhalb stattfindet.

Der Außenstehende wird nicht primär merken, dass sich etwas an deiner Sprache ändert. Um an deiner inneren Haltung zu arbeiten kann das teilweise Jahre dauern. Genau dieses Thema „Haltung“ wird dann in den Kursen meist umgangen, da es schwer ist, in Kürze daran zu arbeiten. 

Vor allem bei der agilen Arbeit spielt Empathie eine wichtige Rolle. Diese Empathie sollte unbedingt auch in die gewaltfreie Kommunikation mit einfließen.

Mehr zum Thema erfährst du in der kompletten Folge.

Sende mir jederzeit gerne deine Fragen zum agilen Arbeiten. Ich beantworte Fragen immer wieder in einer ganzen Podcast-Episode.

Was versteht man eigentlich unter New Work? Interview mit Nadja Petranovskaja

Nadja ist Psychologin, hat sogar schon Flugzeuge oder Rechenzentren gebaut und war bereits in vielen verschiedenen Bereichen Tätig. Vor allem steht sie aber „for more shiny eyes“, möchte die Augen der Menschen zum Leuchten bringen und ihnen zu mehr Freude an ihrer Arbeit verhelfen.  

So definiert Nadja das Thema New Work

Nadja unterscheidet gerne Work und Job. Job bedeutet für sie, nur Steine des Chefs zu schleppen, um damit Geld zu verdienen. Viele Menschen haben das richtige „Work“ in Hinsicht auf eine sinngebende Arbeit noch nie erlebt. 

New Work bedeutet für Nadja, endlich in den Bereich zu kommen, in dem wir als Menschen unser volles Potenzial nutzen, nachdem wir sehr lange nur unseren Job gemacht haben. 

Das Wort „New“ heißt für Nadja, dass wir künftig so viel wie nur möglich wir selbst während der Arbeit sein können.

Was bedeutet sinngebende Arbeit und woran erkennen wir diese?

Frage dich einmal selbst, wer du eigentlich bist, was deine Qualitäten sind, was dir wichtig ist und welche Dinge du mit Leidenschaft tust. Wenn du herausfindest, was dich kennzeichnet und du dieser Arbeit nachgehst, handelt es sich um eine sinngebende Arbeit. 

Indikatoren dafür, um dies zu erkennen sind oft Dinge, die du schon als Kind gerne gemacht hast. 

Das gibt dir Nadja mit auf deinen Weg

Umarme dich selbst und erfreue dich daran, dass du da bist. Nimm dich so an, wie du im Moment bist und wachse aus deinem Ich für dich selbst und nicht für andere. Finde dich selbst wertvoll und sage dir, wie toll du bist. 

Wenn du mehr darüber erfahren möchtest, wie du eine für dich sinngebende Arbeit finden kannst, solltest du unbedingt in die komplette Podcast-Episode reinhören. Nadja gibt dir noch viele enorm hilfreiche Tipps. 

Was passiert im Scrum, wenn ein Sprint nicht geschafft wurde?

Diese Frage hatte mich neulich erreicht und ich möchte dir heute gerne einige Infos dazu mit auf den Weg geben.

Die Antwort darauf ist relativ simpel. Zuerst einmal solltest du einen Schritt zurück in den Product Backlog machen. Es gibt durchaus Teams, bei denen alles direkt durchgewunken wird und ein Thema kommt in den nächsten Sprint. Allerdings ist das nicht immer sinnvoll, denn als Product Owner kannst du auch während des Sprints herausfinden, dass andere Backlog Items wichtiger geworden sind. Daher ist es auch durchaus legitim, sich einzugestehen, dass der Sprint nicht geschafft wurde und ein Thema nach hinten geschoben wird. 

Dinge, die nicht geschafft wurden, müssen also nicht zwingend in den nächsten Sprint geschoben werden.

Was passiert, wenn ein Sprint mehrfach nicht geschafft wird?

Du hast immer die volle Transparenz und siehst spätestens im Review, dass der Sprint nicht geschafft wurde. Dann sollte spätestens in der Retrospektive darüber gesprochen und auch etwas geändert werden. Es ist sehr wichtig, dass genau nachgeforscht wird, warum die Situation nun so ist.

Es bietet sich auch eine themenbasierte Retrospektive an mit einer Ursachenforschung. 

Welche Gründe gibt es, um einen Sprint nicht zu schaffen?

Es könnten beispielsweise die Backlog Items nicht gut vorbereitet sein. Zudem könnte auch der Product Owner oder das Team keinen guten Job gemacht haben in der Sprintplanung. Dadurch werden dann häufig Dinge in den Sprint mit einbezogen, die hinterher aber gar nicht umgesetzt werden können. 

Hier kann eine sogenannte Definition of ready helfen. Diese definiert, unter welchen Umständen ein Sprint stattfinden soll. Hierzu zählen beispielsweise Dinge wie alle Fragen zu beantworten oder entsprechende Teammitglieder und nötige Hardware. Das ist ein guter Indikator, um festzustellen, ob ein Backlog Item in den Sprint kann.

Es kann aber auch sein, dass sich ein Team einfach überschätzt und vor allem junge Scrum Teams sich zu viel vornehmen. 

Welche weiteren Gründe es gibt, um einen Sprint nicht zu schaffen und wie du diese verhindern kannst, erfährst du in der gesamten Podcast-Episode.