Jeder kennt die Situation, dass er etwas verändern möchte, dass er ziemlich genau weiß, wie es nicht sein sollte, eine vage Vorstellung davon hat, wo er hin möchte, wie er handeln müsste. Aber an der Umsetzung hapert es immer wieder. Man fühlt sich blockiert, ja sogar hilflos, bei manchen Themen über eine lange Zeit. Diese Situation kannte auch der große Cäsar, als er mit seinen Truppen am Rubikon, einem Fluss nördlich von Florenz stand und überlegte, ob er den römischen Senat in Rom angreifen und ihm damit den Krieg erklären sollte oder nicht. Sicher machte es sich Caesar nicht leicht mit seiner Entscheidung. Letztlich aber kam er ins Handeln, machte sich nach Rom auf und überschritt mit den berühmten Worten “alea iacta est”, “Der Würfel ist gefallen”, mit seinen Legionen den Rubikon in Richtung Süden. Dieser Ausspruch steht heute noch für Entscheidungen, die ein ganz bewusstes und konsequentes Handeln nach sich ziehen.

Das Rubikonmodell nach Grawe (Grawe, 1998, S. 71) gilt heute als wichtiges und funktionales Selbstmanagementmodell, das die Entstehung einer inneren Struktur von den Bedürfnissen bis hin zum konkreten Handeln aufzeigt und helfen kann, schwierige Entscheidungssituationen handlungsreif zu machen.

Bedürfnis: Unbewusste, vorbewusste Impulse

Motiv: Erfassen, bewusst werden, erkennen, wünschen, wägen

Intention: Bewusstes Wollen, Handlungsziel entwickeln, gezielte Entscheidung treffen

Präaktionale Vorbereitung: Planen, Ressourcen und Möglichkeiten eruieren

Handeln: Umsetzen, üben, sichern durch Wiederholen bis die Handlung stabilisiert ist

In der ersten Phase spürt man als Führungskraft oft ein meist noch unklares Bedürfnis im Hinblick auf eine Veränderung, zum Beispiel mit einem „schwierigen“ Mitarbeiter zu reden oder für die Meetings mehr Disziplin im Team zu fordern. Oft ist das Bedürfnis in dieser Phase noch nicht ganz klar oder auch noch nicht richtig bewusst.

Erst mit der Zeit bildet sich in der zweiten Phase daraus ein konkretes Motiv, z.B. ich will mehr Führung zeigen, eine nicht akzeptable Situation in Ordnung bringen. Oft weiß man aber in dieser Phase noch nicht, was genau man tun möchte. Außerdem gibt es immer mehrere Motive, die sich manchmal gegenseitig auszuschließen scheinen. Da stehen z.B. Motive wie Harmonie, die Mitarbeiter nicht zu demotivieren, Konflikten aus dem Weg zu gehen, im inneren Spannungsfeld. In dieser zweiten Phase sind die Menschen sehr mit dem Abwägen aller Motive beschäftigt. Mit Kopf und Bauch versucht man eine Entscheidung herbeizuführen. Manchmal dauert das Abwägen lange, aber irgendwann sind die Prioritäten dann klarer und es entsteht idealerweise ein Gefühl und eine Bewusstheit der Entschlossenheit: Ich tue jetzt etwas für mich und meine Führungsrolle und auch für die Verbesserung von Disziplin im Team und damit für eine bessere Teamleistung.

Dies ist der eigentliche Schritt über den Rubikon. Nach diesem Schritt liegt in der Phase drei das, was der Mensch gern tun möchte, in einem neuen Reifestadium vor, als Intention. Es wird nun ein konkretes Handlungsziel definiert. Jetzt wird nicht mehr abgewogen, sondern es wird nach einer Lösung und nach Maßnahmen gesucht: Wie, wann und wo kann ich mit dem Mitarbeiter Klartext reden? Wie bringe ich das Disziplinthema in mein Team ein?

In der vierten Phase geht es dann um „präaktionale Vorbereitung“ und die Entwicklung von konkreten Ausführungsmöglichkeiten: Ich werde einen Gesprächstermin mit dem Mitarbeiter in meinem Büro vorgeben und von Anfang an die Gesprächsregeln festlegen. Ich werde deutlich sagen, dass ich hier nicht als Kollege, sondern als Führungskraft rede. Ich achte bewusst darauf, dass ich die Steuerung des Gesprächs in meinen Händen behalte. Ich atme vor dem Gespräch tief durch und mache mir bewusst, dass es in Ordnung ist, das Gespräch so zu führen. Ich werde das Thema Disziplin ganz oben auf die Prioritätenliste des nächsten Meetings setzen. Ich werde die Zeit nehmen, die es braucht, damit alle sich äußern können und verstehen, worum es mir geht. Ich behalte die Moderation in meiner Hand und achte auf Regeln und Zeitmanagement. Ich werde konkrete Commitments am Flip Chart visualisieren.

Nun geht es an die gut vorbereitete, bewusste und gezielte Umsetzung, sprich konkrete Handlung, des Selbstmanagementvorhabens im Umgang mit dem Mitarbeiter oder dem Team. Je grundlegender ein Thema für das persönliche Selbstmanagement ist, z.B. eben mit schwierigen Personen oder Führungsautoritäten ist (siehe Beispiele), um so öfter ergeben sich Möglichkeiten, die gezeigten Handlungen auf andere Situationen zu übertragen und den Rubikon immer leichter zu überschreiten. Übung macht auch hier den Meister.

Der Rubikonprozess als Selbstmanagementtool unterstützt den bewussten Umgang mit sich selbst und den Situationen und Herausforderungen die oft scheinbar schwer zu bewältigen sind. Es ist immer auch gerade dann hilfreich, wenn es um Themen wie Unsicherheit, Souveränität, Auftreten, Durchsetzungsvermögen, Setzen von Prioritäten, Grenzen setzen, Verändern persönlicher hinderlicher Muster wie „Ich muss immer perfekt sein“ etc. geht. Im Sinne von Selbstcoaching ist die Reflektion des Rubikonmodells eine Chance, die persönliche Weiterentwicklung anzugehen. Caesar hats ja auch genutzt.

Grawe K. (1998) Psychologische Psychotherapie, Hogrefe: Göttingen

Related posts:

1. Einzelkämpfer ScrumMaster? Herausforderungen als ScrumMaster Team gemeinsam meistern / Teil 2
2. Lernen ist Arbeitszeit – vom Erlernen der Scrum Praxis
3. Die bor!sgloger Methode

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 4)

Part 1: Does distance cancel out efficiency of internationally dispersed Teams?

Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts

Stephanie G.: You‘ve coincidentally already mentioned it in the previous round – the popular subject of whether electronic or physical Taskboards are better. Did you all use electronic tools or is there another probable option for internationally distributed Teams?!

Deborah W.: We used an electronic tool for the Product Backlog, but had a paper Taskboard hung up on the wall at the main location, which was filmed non-stop by a webcam. Thus, it was continuously displayed on a live-stream and gave the other Team members the possibility to keep the window open in the background of their computer screens at all times. Sadly, we never managed to put up a large screen on the wall. But by doing it this way, it meant that if one person moved a Task, it could be seen by everyone. In order for this to work, however, you need an excellent camera in a good position (best if screwed into the ceiling). In my case, it also only worked because the management really insisted on it – the Dev.Team had wished for  a digital Taskboard from the first Sprint onwards. However, the management had seen this as a measure for pushing its employees towards more communication.

Hélène V.: What works even better in terms of pushing employees to communicate, is to have a physical Taskboard at every location. Every task has an identification number, so that during the Daily (and outside of it, of course, too) the conversation goes a little bit like this, “Today, I am taking Task 162 on user documentation and I will need Peter’s assistance for it, as I’m not entirely sure about the necessary layout”. The number is just the reference, so that everyone at every location can synchronously move the identical Task. This way, whenever a Task is finished during the day and a new one is started, the necessary synchronisation forces the Team members to communicate immediately – in whichever way they like (chat, telephone etc.).

Ina K.: See, that‘s what I tried to introduce in my Team as well. However, it was certainly not easy trying to explain the necessity behind synchronising two manual Taskboards. In the end, we simply used the tool iceScrum and had the Taskboard depicted at all times on a large screen in both Scrum Spaces. Although the effect of pulling the Task to “done“ goes missing, it was pretty cool watching how – if someone at the other location moved a Task – it would show up simultaneously on our screen.

Stephanie G.: Your answers sound like distributed Teams still underestimate the effect of physically experiencing versus watching something move on a screen. I have heard of Teams using both types at the same time – has one of you ever worked with “double” Taskboards?

Bernd K.: Yes, I‘ve seen Teams that use physical Taskboards, and JIRA for documentation. Thus, they use both…In my opinion, one can certainly do that, but you should watch out that it doesn’t start creating an overhead. Like Ina, I also have some experience with iceScrum, which is an alright open-source tool. My Team members weren‘t keen on it, but decided to use it anyway, as they needed it for generating documentation.  In my opinion, electronic tools may be useful for Backlog grooming, generating Burn-Down Charts, providing immediate Sprint Documentation etc., but they will never fully replace the agility and motivation that a physical Taskboard can offer.

Kristina K.: I actually found the electronic Taskboard to be a nuisance. We used Urban Turtle, since the Dev.Team saw a Taskboard made out of paper as too much overhead for a distributed Team. It really was of no help during the Daily: it took long to create new Tasks, the wrong Stories were accidentally discussed, it took ages to scroll down etc. Also, the tool did not place a maximum limit on the amount of characters that could be typed within a Task. I sometimes felt as if the simplicity of Tasks was ruined and turned into electronic essays or lists of reminders. The size of a sticky note limits exactly that. Honestly, if I could build my own electronic Taskboard, I would have a very long list of requirements, such as being able to see the whole board at once, allowing the writing of dots on Tasks that were not finished on the previous day (exclamation marks just don’t do it for anyone), better print views, simplicity of moving Stories into a Sprint, being able to read the titles of User Stories immediately etc.

Christof B.: I agree with my colleagues, but in the end, I believe that it doesn’t really matter what tool you‘re using, as long as everyone in the Dev.Team can work with it at the same time. This means that i.e. physical Taskboards should really have cameras set on them at all times and electronic tools should allow all Team members to see the moving of a Task at all locations at the same time. In future, this should work much more easily, as high-quality video conference systems will become more readily available on the market. However, I also believe that the Team constellation should have an impact on the choice of tooling: if the Product Owner and maybe some consulting architects are placed at one location, and the ScrumMaster plus his Dev.Team at another, I would most certainly say that a Taskboard made out of paper suffices. A picture of the Daily can then be sent to the PO every now and again.

Stephanie G.: I believe I can sum up and prioritize your suggestions in the following way:

#1 choice: Separate Taskboards made out of paper and sticky notes hung up on the wall at each location.

#2 choice: Paper Taskboard at main location with constant live-stream to screens hung up in other locations.

#3 choice: Electronic Taskboard with instant synchronisation (no tool preference).

Related posts:

1. 5 min on Scrum | Tools
2. Should internationally distributed Teams be avoided?
3. Scrum Spaces of internationally distributed Teams – the Do’s and Dont’s

Viel Spaß mit meinem Agile-ABC:

1. Glaube nicht, dass ein Ort zu weit entfernt ist – gehe nur los und du wirst ankommen; denke nicht, es sei zu schwer – tu es einfach! (Dschingis Kahn)
2. Es ist ein großer Vorteil im Leben, die Fehler, aus denen man lernen kann, möglichst früh zu begehen. (Winston Churchill)
3. Man löst keine Probleme, indem man sie auf Eis legt. (Winston Churchill)
4. Denken ist interessanter als Wissen, aber nicht als Anschaun. (Johann Wolfgang von Goethe)
5. Kleine Taten, die man ausführt, sind besser als große, die man plant. (George Catlett Marshall jun.)
6. Einen Fehler machen und sich nicht bessern: Das erst heißt fehlen. (Konfuzius)
7. Man muss Unmögliches verlangen, um das Mögliche zu erreichen. (Otto von Bismarck)
8. Der Weg zum Ziel beginnt an dem Tag, an dem Sie die hundertprozentige Verantwortung für Ihr Tun übernehmen. (Dante Alighieri)
9. Zwischen einem der führt und einem der folgt, unterscheidet Innovation. (Steve Jobs)
10. Denken und Tun, Tun und Denken, das ist die Summe aller Weisheit, von jeher anerkannt, von jeher geübt, nicht eingesehen von einem jeden. (Johann Wolfgang von Goethe)
11. Eine Veränderung bewirkt stets eine weitere Veränderung. (Niccolo Machiavelli)
12. Wer darauf besteht, alle Faktoren zu überblicken, bevor er sich entscheidet, wird sich nie entscheiden. (Henri-Frédéric Amiel)
13. Alles auf einmal tun wollen zerstört alles auf einmal. (Georg Christoph Lichtenberg)
14. Wirklich innovativ ist man nur dann, wenn einmal etwas danebengegangen ist. (Woody Allen)
15. Denken ist wundervoll, aber noch wundervoller ist das Erlebnis. (Oscar Wilde)
16. Pläne sind nichts. Planung ist alles. (Dwight D. Eisenhower)
17. Der größte Feind der Qualität ist die Eile. (Henry Ford)
18. Lieber Fehler riskieren, als Initiative verhindern. (Reinhard Mohn)
19. Die Ablehnung eines Risikos ist für ein Unternehmen das größte Risiko. (Reinhard Mohn)
20. Du gewinnst nie allein. An dem Tag, an dem du was anderes glaubst, fängst du an zu verlieren. (Mika Pauli Häkkinen)
21. Wer nichts verändern will, wird auch das verlieren, was er bewahren möchte. (Gustav Heinemann)
22. Wir hatten eine sehr einfache Ausrüstung und sehr primitive Klettertechniken. Das Einzige, was wir wirklich gut konnten, war, eine Stufe nach der anderen in Schnee und Eis zu schneiden. In aller Bescheidenheit kann ich sagen, dass wir darin Weltmeister waren, einfach immer die nächste kleine Stufe zu schneiden, die uns erlaubte, den nächsten kleinen Schritt Richtung Ziel zu machen.” (Sir Edmond Hillary)
23. Wege entstehen dadurch, dass man sie geht. (Franz Kafka)
24. Gib mir 6 Stunden einen Baum zu fällen, und ich werde die ersten 4 mit dem Schärfen der Axt verbringen. (Abraham Lincoln)
25. Unmöglich vorher zu sehen, die Zukunft ist. (Yoda)
    

    by Gareth Simpson

26. Zwei Dinge sind zu unserer Arbeit nötig: Unermüdliche Ausdauer und die Bereitschaft, etwas, in das man viel Zeit und Arbeit gesteckt hat, wieder wegzuwerfen. (Albert Einstein)

Mein Lieblingszitat hier ist die Nummer 22 von Sir Edmund Hillary. Immer in kleinen Schritten unterwegs und durch das Beschreiten des Wegs ans Ziel kommen. Volle Konzentration im Hier und Jetzt, volle Hingabe, Commitment, ein Einsatz mit Beharrlichkeit, Disziplin und Selbstverantwortung oder auch wie Beppo der Straßenkehrer in Michael Endes “Momo” sagt:

“Siehst du, Momo”, sagte er dann zum Beispiel, “es ist so: Manchmal hat man eine sehr lange Straße vor sich. Man denkt, die ist so schrecklich lang; das kann man niemals schaffen, denkt man.” Er blickte eine Weile schweigend vor sich hin, dann fuhr er fort: ”Und dann fängt man an, sich zu beeilen. Und man eilt sich immer mehr. Jedes Mal, wenn man aufblickt, sieht man, dass es gar nicht weniger wird, was noch vor einem liegt. Und man strengt sich noch mehr an, man kriegt es mit der Angst, und zum Schluss ist man ganz außer Puste und kann nicht mehr. Und die Straße liegt immer noch vor einem. So darf man es nicht machen.” Er dachte einige Zeit nach. Dann sprach er weiter: ”Man darf nie an die ganze Straße auf einmal denken, verstehst du? Man muss nur an den nächsten Schritt denken, an den nächsten Atemzug, an den nächsten Besenstrich. Und immer wieder nur an den nächsten.” Wieder hielt er inne und überlegte, ehe er hinzufügte: ”Dann macht es Freude; das ist wichtig, dann macht man seine Sache gut. Und so soll es sein.” Und abermals nach einer langen Pause fuhr er fort: ”Auf einmal merkt man, dass man Schritt für Schritt die ganze Straße gemacht hat. Man hat gar nicht gemerkt wie, und man ist nicht außer Puste.” Er nickte vor sich hin und sagte abschließend: “Das ist wichtig.“

Welches ist euer Lieblingszitat in Bezug auf Agile und Co? Lasst es mich wissen, ich freu mich drauf! 

Related posts:

1. Volles Scrum ist gefragt!
2. Scrum Essentials – Scrum (k)eine Religion?!
3. Über das Schreiben | Schreibblockaden

Sonntagnachmittag bei uns zu Hause. Ein Haufen gewaschener Wäsche türmt sich auf dem Sofa. Jetzt nehmen wir uns die Socken vor. Mein Sohn weiß aus seinen eigenen Beobachtungen, wie das geht.

Er nimmt sich scheinbar willkürlich zwei Socken heraus, legt sie vergleichend übereinander, zerrt und zupft an ihnen, sagt dabei “rollen, rollen, rollen”, und wirft sie dann in die Wäschebox zurück.

Damit ist für ihn der Prozess abgeschlossen, und er sieht hochzufrieden aus.

Ich bin da mit meiner Definition of Done schon etwas weiter. Anders als bei meinem Sohn, ist bei mir in etwa 90% der Fälle der Vergleichstest erfolgreich: Ich erwische das richtige Paar Socken. Zugegeben: Meistens bleiben danach Einzelgänger übrig, aber da steckt der Wurm an anderer Stelle im Prozess. Nicht mein Problem. Außerdem schaffe ich es, die Sockenpaare so zusammenzurollen, dass sie miteinander verbunden bleiben. Letzer Arbeitschritt, bevor ich fertig bin: Der Transport der Sockenpaare in die Schublade des Kleiderschranks.

An einer Definition of Done können wir ablesen, wie viele nachgelagerte Schritte zwischen dem Produkt (Reinigungszyklus Socken) und seiner qualitativ einwandfreien Nutzung (dem Tragen) stehen.

Auf dem untersten (weil anfänglichen) Level steht die Sammlung, gefolgt vom Waschgang. Dann kommen das Aufhängen, das Trocknen, das Sortieren, und schließlich das Einräumen. Auf jedem dieser Level lassen sich unterschiedlich hohe Qualitätsansprüche festlegen. Wichtig ist für mich, dass die Socken sauber sind und einen angenehmen, unaufdringlichen Duft verbreiten, dass sie richtig trocken werden, und dass ich sie morgens mit minimalstem Aufwand und ohne böse Überraschungen wieder verwenden kann. Außerdem sollen sie möglichst geschmeidig sein.

Ginge es nach dem Qualitätsanspruch meines Sohnes, müsste ich jeden Morgen die passenden Sockenpaare selber ausfindig machen. Dieser Arbeitsschritt bleibt mir nach meiner Definition of Done erspart, denn ich habe das Level der Bündelung schon erreicht.

Ist damit das Ende der qualitativen Fahnenstange erreicht? Sicher nicht. Ich bin farbenblind und stehe morgens meist im Dunkeln auf. Da kann es durchaus passieren, dass die Sockenfarbe nicht zu der des Anzuges passt. Oder dass ich im Laufe des Tages ein Loch in der Socke entdecke. Beides ist unangenehm und vermeidbar. Ich könnte meine Definition of Done anheben und festlegen, dass die Sockenpaare, nach Farben gebündelt, in unterschiedlichen Schubladen landen. Ich könnte einen Qualitätstest verlangen, so dass vor der Bündelung meine Socken auf noch so kleine Perforationen untersucht werden.

Beides ist sicher machbar, aber nicht unbedingt sinnvoll. Ich bräuchte dann vielleicht einen größeren Kleiderschrank mit mehr Schubladen. Und für den Qualitätstest gingen dann vom Sonntag Nachmittag nicht dreißig, sondern sechzig Minuten drauf. Das will ich nicht, denn so wichtig ist mir der Reinigungszyklus meiner Socken dann auch wieder nicht.

Vielleicht lohnt es sich für mich, über Automatisierung nachzudenken. In vielen Ländern waschen die Menschen ihre Kleidung immer noch am Fluss, das ist mir erspart geblieben. Unsere Waschmaschine erledigt das fast von selber. Aber warum muss ich immer in den Keller runter, die Wäsche an die Leine hängen, um dann zwei Tage später wieder den umgekehrten Weg zu gehen? Da gehen insgesamt bestimmt 40 Minuten drauf und meinen Sohn kann ich nicht alleine oben lassen. Ich erkenne: Da habe ich technische Schulden akkumuliert. Einen eigenen Wäschetrockner kann ich mir nicht leisten (kein Platz), aber so ein kombinierter Wäsche-/Trockenautomat wäre schon toll. Das aber wäre keine kleine Investition, das Geld würde an anderer Stelle fehlen.

Also muss ich schnell entscheiden: Wäschereinigungszyklus verbessern? Pro: Mehr Zeit am Sonntag mit der Familie. Contra: So teuer, dass wir uns in den Urlaub in den Alpen nicht leisten könnten. Wie kann ich mich da entscheiden, ob ich unsere begrenzten Ressourcen dafür investieren soll?

Na klar! Ich muss priorisieren! Aber nach welchen Kriterien? Durch den Kauf des kombinierten Trockenautomaten verzichte ich auf den Urlaub und spare statt dessen manuellen Aufwand beim Waschen. In Scrum gesprochen: Meine Velocity sinkt (ich bekomme weniger Funktionalitäten in die Hand), dafür steigt die Qualität eines bestehenden Prozesses.

Welche Investition ist die bessere?

Ich nehme zur Berechnung mein kostbarstes Kriterium: Zeit. Wenn ich durch den kombinierten Trockenautomaten 15 Minuten pro Wochenende spare, dann macht das knappe 14 Stunden Zeiteinsparung pro Jahr aus. Verglichen mit fünf Tagen in den Alpen ist das lächerlich.

Es fällt mir diesmal leicht, eine Entscheidung zu treffen. Wenn ich aber morgen das teure Markenwaschmittel kaufe, wird mich wieder das schlechte Gewissen befallen. Sollte ich statt dessen nicht besser für eine neue Waschmaschine sparen, ehe die alte eines Tages für immer den Geist aufgibt und mich mit meiner schmutzigen Wäsche alleine lässt?

Meine Vision ist mir heute jedenfalls klar geworden: Einen Haushalt zu haben, den ich auf Knopfdruck bedienen kann, um mich danach entspannt zurückzulehnen und die schönen Dingen dieses Lebens zu tun. Vielleicht wurde auf der CEBIT ja was Spannendes präsentiert. Die müssen sich ja mitterweile schon Gedanken zum modernen Haushalt gemacht haben. Vielleicht hat das Web 3.0 Textilien sogar schon abgeschafft und mein Problem damit erledigt. Aber das ist ein anderes Thema.

Related posts:

1. Fussball EM und 3 Sprints | Scrum ist überall !
2. Präsentation | Angstfreies Sprechen
3. 5 min on Scrum | Es gibt noch viel zu tun

Im Nebel, so fühlen sich viele Teams, wenn sie Anforderungen ohne Nutzen übergeben bekommen. Sie müssen anfangen die Schemen, die geschrieben stehen, zu interpretieren. Den Nutzen in den Sätzen, Zusammenhängen zu finden, die Schwaden zu durchtrennen und zu entwirren. Gelingt es, dann haben wir bestenfalls eine Funktion mit einer Interpretation des Nutzens und wir können hoffen, dass die Beteiligten miteinander reden, um zu validieren, ob die Funktion auch den gewünschten Nutzen erfüllt.

“Gib mir einen Nutzen und ich gebe dir die Funktion dazu, die Du dir wünscht.”

Das ist mein persönlicher Leitspruch und auch meine Empfehlung, wenn es darum geht, User Stories zu schreiben. Fangt mit den Fragen “Wer” und “Wozu” an und schreibt diese auf. Startet beispielsweise so:

“Als Stammkunde Ralf Müller möchte ich …, damit ich erkenne, ob meine Bestellung erfolgreich im System eingegangen ist.“

Wenn ihr eine gute Idee habt, dann schreibt noch die Frage nach dem “Was” dazu, also die Funktion:

“Als Stammkunde Ralf Müller möchte ich eine Benachrichtigung, damit ich erkenne, ob meine Bestellung erfolgreich im System eingegangen ist.“

Am besten ist es, wenn ihr das “Was” gemeinsam mit eurem Entwicklungsteam klärt. Verstehen sie den Nutzen, dann werden Sie eine Funktion finden, die den Nutzen erfüllt. Spätestens im Sprint Planning 1 sollten die Anforderungen dann geklärt werden. Vielleicht schlägt das Entwicklungsteam neben der E-Mail Benachrichtigung und der direkten Anzeige auf der Folgeseite noch das Versenden einer Benachrichtigung per Blumenstrauß vor – wer weiß.

Um der angesprochenen Funktion etwas mehr Gestalt zu geben, formuliert ihr noch Akzeptanzkritierien. Dadurch könnt ihr den Rahmen aufspannen und vorgeben, was minimal erfüllt werden muss – nicht mehr, aber auch nicht weniger. Auch diese Kriterien klärt ihr gemeinsam mit dem Entwicklungsteam und zwar im Dialog und zwar von Angesicht zu Angesicht. Vom Entwicklungsteam lasst ihr dann Akzeptanztests bzgl. der  Akzeptanzkritierien aufstellen. Ein Kriterium könnte in unserem Beispiel sein:

“Die Bestätigung erfolgt auf zwei Kommunikationskanälen. Ein Kommunikationskanal ist im System, der andere der Postweg.“

Warum sollte das Entwicklungsteam die Funktion ausformulieren?

Das ist für mich implizit eine Frage nach der Reife des Teams. Jedes Entwicklungsteam lernt am eigenen Produkt die Fachdomäne, in der es sich bewegt und wird über die Zeit zum Domänenspezialisten. Das ist jedoch nur ein Grund, ein wichtigerer ist der folgende: Jedes Team weiß am besten, wie sich der gewünschte Nutzen im System am besten abbilden lässt. Ein cross-funktionales Team zeigt hier seine Stärken, jedoch kennt jedes andere Entwicklungsteam es auch besser als der Kunde bzw. die meisten User. Man fragt sie nur zu selten.

Ein Grund hierfür ist sicherlich, dass die User sich nicht die Fragen stellen müssen, die ein Teammitglied sich stellt, zum Beispiel: “Wie passt die Funktion in das Konzept der Anwendung?”, “Muss ich hier auch die Funktionen A, B und C berücksichtigen?” Ein Entwicklungsteam hat einen ganz anderen Kontext zum Produkt, das es entwickelt. Dieser muss aufgebaut werden.

Was benötigt eine gute User Story jetzt noch?

Wir haben das normale Format mit Wer, Was, Wozu – also: Als <Persona> möchte ich <Funktion>, damit ich <Nutzen>. Wir haben Akzeptanzkritierien , die aufzeigen, was minimal geliefert werden muss. Akzeptanztests, die das Entwicklungsteam ausformuliert und die aufzeigen, dass die Akzeptanzkritierien erfüllt werden. Was fehlt?

Es ist der Nebel.

In unserem Beispiel ist der Nebel zuerst der leere Funktionsteil. Hier muss Kommunikation erfolgen, damit geklärt wird was selbst der Platzhalter Benachrichtigung später konkret heißen soll. Konkret gesagt ist der Nebel keine Worthülse, die beliebig interpretiert werden darf, trotzdem ist der Nebel die Unklarheit auf dem Weg zur Implementierung.

Eine User Story ist ein Anlass zur Konversation. Das bedeutet, wir benötigen eine gewisse Unstabilität in der User Story, damit eine Konversation, ein Dialog entstehen kann. Wir brauchen Unschärfe. Hier brauchen wir allerdings die Art von Nebel, die nicht verschleiert. Nicht der Nebel, der durch schöne Worte und vermeintliche Vollständigkeit und die stumpfe Präzision eines Löffels uns denken lässt: “Alles steht hier geschrieben, genau das brauchen wir so wie es formuliert wurde.” Nein, wir brauchen den Nebel, der uns fragen lässt: “Hey, sollen wir lieber links oder rechts gehen, ich bin mir gerade nicht ganz sicher.” Software-Entwicklung ist zu großen Teilen ein Kommunikationsproblem und zu genaue Anweisungen verstärken dieses Problem. Bei zu genauen Anweisungen fragen wir nicht mehr nach, die Kommunikation versiegt.

Für viele von Euch ist die Fahrt, der Spaziergang im Nebel erstmals ungewohnt, lasst ihn trotzdem zu und lasst Euch drauf ein. Es ist faszinierend, was nach kurzer Zeit vor einem auftaucht und welche Überraschungen und Details einem ins Auge fallen, die man aus der Ferne, selbst mit Weitblick, nicht hätte erkennen können.

Related posts:

1. Die drei weiteren Rollen in Scrum
2. Scrum Essentials: Die sieben Fragen der User Story
3. Das Burndown-Chart: Ein Anreizsystem

Was macht agil nun anders? Agil stellt Risiken auf den Kopf – im wahrsten Sinne des Wortes. Jedes Risiko lässt sich als Chance formulieren, viele Risiken können als Eintrag im Product Backlog landen. Als Features, deren Nutzen es zu testen gilt, als minimal lieferfähiges Produkt (minimum viable product) über das sich der Mark testen lässt. Statt Risiken zu verwalten, tritt man dem Risiko entgegen, bereitet sich auf eine epische Schlacht mit ihm vor und begrüßt die Erkenntnisse, die auf dem Weg warten. Auf dem Weg heißt: nach dem Start.

Software-Anforderungen erfassen und weitergeben ist ein Kommunikationsproblem

Scrum ist ein Kommunikationsrahmen. Ein Rahmen, in dem mehr und mehr Beteiligte angehalten werden, miteinander zu sprechen und wertschätzend zu kommunizieren. Ein Rahmen, in dem ritualisiert alle relevanten Beteiligten eingebunden werden, damit ein gemeinsames Bild entstehen kann. Wir klären gemeinsam die Anforderungen. Angefangen im Sprint Planning 1: Hier holen wir uns die Personen hinzu, die uns genau sagen können, was gewünscht ist. Im Daily Scrum halten wir Kontakt mit ihnen und optimalerweise nutzen wir die Zeit nach dem Daily Scrum, um Rückfragen zu klären. Spätestens im Review zeigen wir, was umgesetzt wurde. An diesem Punkt kommt die Erkenntnis ins Spiel und wir können den Nutzen validieren. Wichtig ist jedenfalls: ”Die Personen, die eine Software wollen, müssen mit den Personen kommunizieren, die die Software bauen.” (Gojko Adzic)

Je weniger Kommunikation stattfindet, desto höher das Risiko, dass wir das Falsche liefern. Dass wir zwar technisch einwandfrei liefern, jedoch nicht das liefern, was der Kunde möchte. Oder in anderen Worten, wie Gojko Adzic es sagt: “I am getting more and more convinced every day that communication is, in fact, what makes or breaks software projects. Programming tools, practices and methods are important, but if the communication fails then the rest ist just painting the corpse.”

Also gehen Sie das größte Risiko “Kommunikation” an und starten Sie mit einem Prozess, der die Kommunikation in den Vordergrund rückt: Scrum!

Wie Scrum im Detail mit Risiken umgeht finden Sie unter anderem in diesem Artikel: Agiles Risikomanagement mit Scrum – empört Euch!

Related posts:

1. Entwickler für Frankfurter Unternehmen gesucht
2. Hey PO, estimate your roadmap!
3. Agiles Risikomanagement mit Scrum – empört euch!

Die Retrospektive gehört zu den Nachzügler-Meetings im Scrum-Flow. Erst 2004, auf dem Scrum Gathering in Wien (vgl. Gloger, 2011, S. 180f.), erlebte die Agile Community die eigentliche Geburtsstunde des Meetings und es etablierte sich fortan zum unverzichtbaren Bestandteil des Scrum-Prozesses, weil Retrospektiven, fragt man Esther Derby, vor allem eins mit Teams tun: „Keep improving“ (Derby & Larsen, 2006, S. 2).

Retrospektiven haben das Ziel, auf der Grundlage des Erlebten (des vergangenen Sprints), Maßnahmen für die Zukunft (den nächsten Sprint) zu generieren, die sowohl die Arbeitsabläufe verbessern sowie  störende Blockaden (Impediments) identifizieren, analysieren und beheben sollen. Um das zu erreichen, stehen zwei Fragen im Fokus der Betrachtung: „Was lief gut?“ und „Was könnte verbessert werden?“ – Erfolgsfaktoren und Potentiale.

In meinen täglichen Beobachtungen erkenne ich sowohl in der Moderation als auch in der methodisch, didaktischen Führung des Meetings jede Menge „Luft nach oben“. In diesem Beitrag möchte ich daher das Augenmerk auf die oben bereits erwähnten Schritte 3 (finde funktionierende Prozesse) und 4 (finde nicht-funktionierende Prozesse) (vgl. Gloger, 2011, S. 184ff.) richten. Hier offenbart sich leider ein Trend, den ich nicht nur nicht gutheißen kann, sondern der meines Erachtens auch für eine gewinnbringende Retrospektive kontraproduktiv ist.

Die sechs Schritte einer erfolgreichen Retrospektive setzen einen stringenten und lückenlosen Ablauf voraus:

Schritt 1: Schaffe Sicherheit

Schritt 2: Sammle Fakten

Schritt 3: Finde funktionierende Prozesse

Separator

Schritt 4: Finde nicht-funktionierende Prozesse

Schritt 5: Leite Veränderungen ein

Schritt 6: Entscheide über die Wichtigkeit

Zu diesem gehört, dass zwischen Schritt 3 und Schritt 4 ein Zwischenschritt, der sogenannte Separator, eingesetzt werden soll. Dieser hat den Zweck, den „gemeinsamen Denkraum“ (a.a.O, S. 188f.) kurz zu verlassen, um eine spürbare Trennung der beiden Teile „gut“ und „verbesserungswürdig“ zu erreichen. Boris Gloger empfiehlt dafür kreative Arbeitstechniken und betont, dass er mit dem Zwischenschritt „keine Kaffeepause“ meint. Leider ist es aber allzu häufig so, als würde man zu einem kleinen Kind mit erhobenem Zeigefinger sagen: „Fass die Herdplatte nicht an!“

Der Separator wird entweder für eine Kaffeepause genutzt oder es wird einfach darauf verzichtet. In beiden Fällen, im zweiten noch mehr als im ersten, verstärkt sich das Risiko, dass die positiven Effekte und Energien (rewards) aus Schritt 3 nicht konserviert werden und durch die nachfolgende Rückschau der nicht-funktionierenden Prozesse, also negative Erlebnisse (threats), sich sogar neutralisieren können. Daher lautet mein deutlicher Appell an alle ScrumMaster und Retrospektiven-Facilitator:

Baut in eure Retrospektiven einen Separator ein, der mehr als ein Durchlüften der Räumlichkeiten ist oder Zeit für einen Toilettengang lässt!

Ich möchte euch eine etablierte und gleichzeitige aufheiternde und alle Beteiligten aktivierende Kreativtechnik für euren nächsten Separator vorstellen: den Options Run.

Was brauchst du dafür?

• Einen 5 Meter langen Streifen aus Kreppband (auf dem Boden als Linie geklebt)

Was hast du als ScrumMaster zu tun?

• Alle Teammitglieder inkl. ScrumMaster stehen an einem Ende der Kreppbandlinie (Start). Die Linie versteht sich als Brücke über einen Fluss. Ziel ist es, ans andere Ende des Ufers zu gelangen. Allerdings gibt es für die Überquerung Constraints.

Constraints

• Der ScrumMaster muss als Letzter ans andere Ufer.
• Jedes Überqueren ist mit einem Lob (Applaus) zu versehen und verdient die Wertschätzung des gesamten Teams.
• Bei jeder weiteren Überquerung muss eine neue/andere/eigene Art der Überquerung gewählt werden.

Sinn und Zweck des Option Runs

• Wertschätzung der Leistung jedes Teammitglieds
• Jede (neue) Lösung ist gut, richtig, besonders. Es gibt kein Falsch!

Variante

• Das Team wählt die kreativste Form der Überquerung aus und der Sieger erhält einen kleinen Preis.

In Die Sprint Restrospektive – es kann noch viel verbessert werden (Teil 2) stelle ich euch noch andere kreative Ideen für energiereiche Separatoren vor und weise auf weitere typische Fallstricke in der Retrospektive hin. 

Literatur

Derby, E. und Larsen, D. (2006). Agile Retrospectives: Making good teams great. The Pragmatic Programmers.

Gloger, B. (2011). Scrum – Produkte verlässig und schnell entwicklen. Hanser.

Related posts:

1. Wir leiden an Selbstüberschätzung – und das ist auch gut so!
2. Sie können abschalten, wir haben die Vision
3. Hallo bor!sgloger community

Scrum ist dabei ein Gesamtkonstrukt, das uns hilft, diese herausfordernden Ziele zu erreichen. Cherrypicking ist dabei zwar wie in allen anderen Bereichen nett, wird aber nicht die vollumfängliche Verbesserung bringen, die man sich wünscht – leider oft mit dem Fazit, dass Scrum versagt hat. Der Umgang mit Bugs ist da nur ein Beispiel von vielen.

Daher hier – ganz in der gewohnten Scrum-Manier – ein paar ganz einfache Regeln!

Bugs

Bugs werden sofort gefixt!

1. Bugs sollten innerhalb von 24 Stunden gefixt sein! Ja, dafür muss im Zweifel ein bereits angefangener Task unterbrochen werden. Solange der Fehler nicht behoben ist, kann die Story nicht abgeschlossen werden. Das Gleiche gilt für Broken Builds, fehlgeschlagene Tests etc.
2. Häufiger Einwand: Was ist mit Bugs, bei denen das Fixing länger dauert? Zumindest innerhalb der ersten 24 Stunden anfangen und sich dann fragen, was im Vorfeld schiefgelaufen ist.

Ein Bug ist ein Bug ist ein Bug – und damit ein FEHLER!

1. Wir liefern fehlerfreie Software am Ende des Sprints!
2. Keine Klassifizierungen in major oder minor oder high, medium low (notwendig). Ist es ein Bug, dann siehe Regel 1. Ist es eine neue Funktionalität –> ins Backlog priorisieren! Es werden keine Bugs zurück ins Backlog geschoben und für spätere Sprints “aufgehoben”!
3. Häufiger Einwand: Nur Laien behaupten, dass es fehlerfreie Software gibt.
   • Mag sein, dass das Laien behaupten. Allerdings schließt das nicht aus, dass es das oberste, immer, ständig, absolut angestrebte Ziel ist, das es zu erreichen gilt. Und das sollte doch auch der Anspruch eines Teammitgliedes in einem Entwicklungsteams sein, oder? Lasst uns gute Arbeit machen und nicht Zeit mit Ausreden verschwenden!

Create a bug lane!

1. Fügt über der Taksboard-Lane für die erste Story eine Bug Lane ein. Nehmt für Bugs eine andere Post-it-Farbe (Rot bietet sich an).
2. Häufiger Einwand: Macht es nicht mehr Sinn, die Bugs den Stories zuzuordnen?
   • Die Arbeit in Scrum ist prioritätenbezogen: Was oben steht, wird zuerst bearbeitet. Außerdem sollte sowieso nur die oberste Story in progress sein, so dass die Zuordnung sowieso stimmt.

Das Team bekommt einmal so viel Zeit wie es braucht, um es richtig zu machen!

• Unter Berücksichtigung des Level und der Definition of Done kann das Team so viele Stories pullen, wie es glaubt fehlerfrei liefern zu können. Ist die Freiheit berücksichtigt, kann jedoch auch verlangt werden, dass fehlerfrei geliefert wird und man nicht zusätzlich zu so viel Zeit wie man braucht noch mehr Zeit braucht!

Calls / Hotfixes / Change Requests

Manche Teams, die auf Scrum umstellen, haben bereits produktive Systeme zu betreuen – sei es in Form von Maintenance, Calls, Hotfixes, vom Kunden entdeckte Bugs oder auch Change Requests. Dabei stellt sich immer wieder die Frage, wie man mit solchen Änderungen am besten umgeht.

Calls haben sich über Jahre angesammelt, der Überblick ist verloren gegangen? Der Call Stack kann nicht mehr abgearbeitet werden, sondern nimmt mit jedem Sprint zu?

1. Alle Calls löschen!
2. Mit der Einführung von Scrum sollten alle Calls gelöscht werden. Ab diesem Zeitpunkt werden alle neuen Calls konsequent sofort behoben (siehe Beschreibung oben). Dauert das Beheben, Ändern oder Hinzufügen von Funktionalität zu lange, muss das System neu geschrieben werden.

Kunden bezahlen einen fixen Betrag zur Wartung der Software und erwarten daher sofortige Änderungen!

1. Der PO entscheidet über Priorisierung und Funktionalität!
2. In diesem Fall muss oft zuerst genau definiert werden, was unter Maintenance fällt und in welchem Zeitraum diese abgearbeitet werden müssen (sofern es vertraglich festgelegt ist). Oft versucht der Kunde, neue Funktionalität und Change Requests als Maintenance einzubringen. Hier muss der PO die notwendigen Abgrenzungen und Entscheidungen treffen. Auf jeden Fall sollte Transparenz darüber geschaffen werden, wie viele Ressourcen und wie viel Zeit durch die Maintenance-Zahlungen des Kunden zur Verfügung stehen würden. Danach kann sich die Zeit richten, die das Team pro Sprint für Maintenance-Aufgaben nutzen kann (z.B. immer an den ersten oder letzten zwei Tagen eines Sprints). Hier sollte aber wieder darauf geachtet werden, dass es eine Teamleistung ist und diese timeboxed abläuft.

Der Kunde meldet Fehler im Live-System, die seine Arbeitsfähigkeit beeinträchtigen und verlangt sofortiges Hotfixing!

1. Für den Fehler entschuldigen und sofort beheben!
2. Halten sich diese Hotfixes im Rahmen, können sie vom Team im laufenden Sprint bearbeitet werden. Umgang wie mit neu entdeckten Fehlern (siehe oben). Nimmt das Hotfixing die gesamte Zeit in Anspruch, sollte eine grundlegende Überarbeitung angestoßen werden.

Es gibt eine überschaubare Menge an Bugs, diese können jedoch nicht in einem Sprint abgearbeitet werden. Das Team, das die Bugs fixen muss, ist nicht für die Produktion der Fehler verantwortlich.

1. Mit dem Product Owner ein Bug-Burn-Down vereinbaren!
2. Wie viele offene Defects gibt es und bis wann will man sie gelöst haben? Beispiel: 100 Bugs in 10 Sprints -> 10 Bugs pro Sprint werden gefixt. In der restlichen Zeit wird Funktionalität entwickelt. So schafft man einen Übergang zu einer fehlerfreien Software und bestraft das Scrum-Team nicht damit, ausschließlich die Fehler der anderen beheben zu müssen.

Um diesen Umgang mit Fehlern zu ermöglichen und Fehler möglichst früh zu erkennen, gehört daher das nötige Handwerkzeug zur Basisausrüstung eines Entwicklungsteams:

• Continuous Integration
• Den eigenen Code in der eigenen Entwicklungsumgebung fehlerfrei laufen lassen
• Absichern des Codes durch automatisierte Unit-Tests
• Systematische Integration des unit-getesteten Codes in die Teamumgebung und Systemintegrationsumgebung – sofortige Behebung von entstehenden Fehlern

Erst hier ist die Entwicklungsphase abgeschlossen. Erst dann bekommt der (interne oder externe) Kunde die Software.

• Laufen des Codes auf der User Acceptance Test Umgebung

Und immer dran denken: weniger diskutieren, mehr fixen 

Related posts:

1. Bug Fixing
2. Definition “Done” | Was ist “potential shippable code”?
3. Agile Estimation | Grundlagen

1. Es zeigt die Leistung eines Teams innerhalb eines Sprints. D. h. es zeigt an, wie viel Funktionalität bereits fertiggestellt und lieferfähig ist.
2. Es hilft dem Team, den inneren Schweinehund zu überwinden, indem das Team täglich angespornt wird, die Funktion fertigzustellen. Es setzt täglich einen Reflektionspunkt für das Team und fördert den Fokus auf das zu Liefernde.
3. Es verstärkt das Anreizsystem der Lieferung, da nur fertiggestellte Funktionen gemessen und dadurch belohnt werden.
4. Es dient der Transparenz gegenüber dem Management. Das Management kann jederzeit ablesen, ob und wie viel ein Team liefern wird.
5. Es bringt Teams dazu, offen mit der eigenen Arbeit umzugehen. Hier dient es als wichtiges Startsignal, um Offenheit im Unternehmen zu fördern. Wer transparent mit seinem Arbeitsfortschritt umgeht, der fördert auch die Kooperationsbereitschaft zwischen Teams und Abteilungen.
6. Es zeigt an, dass ein Team unter Last steht und nicht gestört werden darf. Dabei hilft es vor allem, den Sprint stabil zu halten und keine Ad-Hoc-Anforderungen mit aufzunehmen.
7. Es zeigt auf, wenn an zu vielen Dingen parallel gearbeitet wird.
8. Es lässt das Team den eigenen Erfolg feiern. Täglich einmal auf dem Burndown-Chart nach unten oder ab unter die Solllinie – einfach ein tolles Gefühl.
9. Es dient als Diagnosemittel, bspw. zeigt es Verzug auf. Wenn es hakt, dann sieht man es hier. Das Burndown-Chart bringt Verzug symptomatisch ans Licht, egal ob es an Impediments liegt, das Team parallel an mehreren Geschichten gleichzeitig arbeitet oder gar etwas komplett anderes macht.
10. Es zeigt auf, wenn Stories zu groß geschnitten sind. Eine weitere Ursache, die das Burndown-Chart zu Tage fördert, sind überdimensionierte User Stories. Ist eine Story zu groß, so erkennt man das auch an der Flatline auf dem Burndown-Chart.

Das Burndown-Chart lässt sich auch sehr gut in Retrospektiven und Reviews einsetzen. Hier dient es als Anstoß für Diskussionen. Nutzt das Burndown-Chart dafür, euren Blick kurz aus dem Tagesgeschäfts zu heben, durchzuatmen und euren Blick auf das Produkt und die versprochene Lieferung schweifen zu lassen. In diesem Sinne: Burn it down baby!

Related posts:

1. Das Burndown-Chart: Ein Anreizsystem
2. Was macht Scrum Teams eigentlich hyperproduktiv?
3. Scrum Tools | Scrumy Pro | Review Update