Partnership & Possibilities – Episode 4, Season 3

Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 4: THE STAR

“In a team situation, having a star performer becomes a threat and an opportunity. If a person is a star performer, their job is to spread their skills around to other members, to mentor and pair with people so other people’s skills are lifted up to where theirs are.”

Running time 40:50

Have you encountered a star performer in your organization? Was it a positive experience? How did your organization respond to the star performer?

Leave a comment on this blog or email us at leadershippodcast@gmail.com

Summary
Intro – Brief overview of a case study from the Harvard Business Review: the unmanageable star performer. How does an organization leverage a star performer for the benefit of all?
8:40 – Acknowledge the star performer’s achievement and introduce new opportunities to them to become even better.
13:05 – An organization should prepare itself for the potential exit of a star performer. There should be a succession plan in place to mitigate risks.
21:21 – Having a star performer can be a threat and an opportunity.
30:05 – Beyond generating revenue, star performers can possess rare skill sets that are in high demand and which can make the person indispensable.
38:37 – Star performers can enhance their standing in the organization and increase the knowledge base by sharing their skill set with others in the organization.

Resources
Case Study: The Unmanageable Star Performer, Harvard Business Review

Photo Credit: mj*laflaca via Compfight cc

Kennt ihr ihn auch? Den ausgepowerten Product Owner, der vor lauter Terminen seinen Tag doppelt bis dreifach verplant hat? Oder den eifrigen ScrumMaster, der noch abends im leeren Teamraum sitzt und die Retro für den nächsten Tag akribisch vorbereitet? Manche sagen dann: “Das kann nicht gut sein.” Und zitieren das Agile Manifest, das von “nachhaltiger Entwicklung” und von einem “gleichmäßigen Tempo” erzählt, das “auf unbegrenzte Zeit” haltbar sein soll. Häufig geistert dann noch dieses eine Wort herum: Burnout.

Ja, der gute Product Owner hat eine ganze Menge zu tun: Er soll möglichst nah an seinem Team sein, mit dem Kunden im ständigen Kontakt stehen, und darüber hinaus die gestalterische Gewalt über das Produkt haben. Für manchen klassischen Projektleiter bedeutet das ein deutliches Mehr an Aufgaben und an Verantwortung. Auch der ScrumMaster ist, wenn er für sein Team da sein und Scrum in die Organisation tragen soll, gut ausgelastet.

Am Ende eines langen Tages stellt sich dann der Frust über die vielen Stunden ein, die man wieder mit Meetings und Abstimmungen verbracht hat. Spannenderweise beziehen sich die Klagen, die mir zu Ohren kommen, fast immer auf die Quantität. Dabei scheint es eine fest verankerte Vorstellung von “Normalität” zu geben: Der Achtstundentag gilt als das gesunde Maß aller Dinge. Neun Stunden werden noch toleriert, zehn gelten vielerorts schon als grenzwertig – und bei allem, was darüber liegt, erntet man besorgte Blicke und gilt als ernstzunehmender Burnout-Kandidat.

Tomas Chamorro-Premuzic hat im Harvard Business Review einen wunderbar provokanten Text geschrieben, der genau diese Korrelation zwischen Dauer und Last in Frage stellt. Seine Behauptung: Überarbeitung ist nur dann möglich, wenn du keinen Spaß bei der Arbeit hast (http://blogs.hbr.org/cs/2013/02/embrace_work-life_imbalan.html):

“Work is just like a relationship: Spending one week on a job you hate is as dreadful as spending a week with a person you don’t like. But when you find the right job, or the right person, no amount of time is enough. Do what you love and you will love what you do, which will also make you love working harder and longer. And if you don’t love what you are doing right now, you should try something else — it is never too late for a career change.”

Nehmen wir das Zitat ernst, sollten wir am Ende eines langen Tages Rückschau halten und für uns prüfen: Was habe ich heute alles gemacht? Was davon hat mir Spaß gemacht, was hat mich herausgefordert, wo ist die Zeit schnell vergangen? Und wo habe ich mich herumgequält, wo war es einfach nur mühsam und frustrierend? Am Ende eines ganztägigen Trainings bin ich manchmal so kaputt, dass ich kaum noch aufräumen und packen kann. Und trotzdem schwebe ich einen halben Zentimeter über dem Boden, halb euphorisiert und halb benommen von den vielen Eindrücken und Erlebnissen des Tages. Die Belastung eines solchen Tages ist enorm, aber sie macht mich nicht fertig. Es ist dann wie ein langer, langer Lauf, an dessen Ende man glücklich auf dem Rasen sitzt und keuchend grinst.

Wenn wir mit Scrum erreichen möchten, dass Menschen anders miteinander arbeiten und daran wachsen, dann können wir nicht einfach weitermachen. Wir müssen uns vielmehr überlegen, was von der bisherigen Arbeitsweise noch Sinn macht, und was komplett gestrichen werden muss.

Drei Vorschläge:

• Meetings auf maximal dreißig Minuten reduzieren und dadurch auf das wirklich Wichtige begrenzen. Eine gut vorbereitete Agenda, ein Moderator (der nur moderiert) und strenge Einhaltung der Timebox.
• In der Mitte des Meetings einen Energizer einbauen (ein kurzes Bewegungsspiel oder etwas mit Humor). So kommt einem die Zeit nur halb so lang vor, eine andere Hirnregion wird aktiviert, man kommt auf andere Gedanken und das Schwere wird etwas leichter.
• Meetings komplett abschaffen. Stattdessen ein Daily zur Synchronisation und dann Open Spaces: Jeder, der ein Anliegen hat, wirbt im Daily dafür, nennt Zeit und Ort. Und jeder, der mit dabei sein möchte, gesellt sich dann einfach dazu. Klingt radikal, ist aber einfach nur eine Umkehrung der Verhältnisse: Wer zuvor über einen “zugemüllten” Terminkalender geklagt hat, der ihm noch den letzten Atemraum genommen hat, darf nun den Luxus eines unbeschriebenen Blatts genießen, das er selber gestalten darf, indem er sich die Themen für den Tag aussucht. Auch das ist mehr Verantwortung, aber es macht den Getriebenen wieder zum Handelnden. Und das kann dazu führen, dass der Job wieder Spaß macht und die Zeit wie im Flug vergeht.

Tomas Chamorro-Premuzic: Embrace Work-Life Imbalance. HBR Blog Network. http://blogs.hbr.org/cs/2013/02/embrace_work-life_imbalan.html

Principles behind the Agile Manifesto: http://agilemanifesto.org/principles.html

Related posts:

1. Der ScrumMaster als Dienstleister
2. Volles Scrum ist gefragt!
3. Sie können abschalten, wir haben die Vision

The moments when excitement builds throughout the whole team at the delight of discovery and creativity are precious. These moments feel like play rather than work and they breed openness and courage. So what conditions must exist for these moments to happen? Here’s some ideas

• A shared competence – The feeling that the team has or has the ability to learn all the skills they need to build a good quality product without accumulating technical debt, gives the team the confidence and courage required to innovate.
• Freedom – Unconstrained by others,  a self organising, cross functional team has the ability to do whatever it takes to deliver solutions at pace that brings excitement. Where there are impediments a team needs the freedom to remove them before they cause frustration.
• Collaboration – The ability to create things as a team that you couldn’t do alone and the fellowship that this brings is exciting. The sharing of discoveries and achievements accelerates learning way beyond anything achievable alone.
• A good customer – nothing beats the instant feedback that a customer on the team brings. Sharing ideas, seeing the excitement as their expectations are surpassed is a fantastic motivator. A good customer is as committed as the developers and spend their day experimenting with whats being built, discussing options and sharing ideas with the team. The only thing better than a good customer on the team is 2 good customers on the team.
• Great technology – Working with great technology is standing on the shoulders of giants, working with elegant, fluid api’s that allow you to create with ease gives the whole team a boost.
• Surprises – Trawling through a long backlog tying to follow a plan is a very different experience to letting stories emerge from the collaboration of developers and customers. Working with only a loose plan but a strong purpose  means every day brings new and unexpected challenges.

The combination of a these factors allows a team to deliver any solution they can imagine rapidly. The consequence of this is they dare to imagine things that most teams won’t. This creativity is incredibly valuable and therefore precious. Just because its precious doesn’t mean we can’t attain this state more.

These moments are precious because, in most organisations, it’s not easy for all these factors to exist together and when it does happen it’s fragile. We must try though. None of these factors are impossible to achieve and even if you can’t achieve all, any of them will make work better. Perhaps if we can become more aware of them and track how well we are doing at achieving them we can do better . Should these factors be something we should try to measure?

Building a taskboard using a laser guide

Here’s a high tech and original way of building a physical taskboard. (source: Agilar team @ Belgacom)

 

Why firing brilliant assholes is required to build a great engineering culture

 

Mein Blog besteht dieses Mal mit Absicht nur aus dieser Frage. Ich möchte damit zum Nachdenken anregen: Was passiert, wenn man Konflikte oder andere Probleme einfach „beseitigt“, anstatt genauer hinzuschauen, was dahintersteckt?

Hätte es ipad, ipod und iphone gegeben, wenn der geniale, aber auch exzentrische Jobs seine Teams nicht zu Höchstleistungen getrieben hätte? Würde es heute Smartphones geben und Tablets? Ob wir das alles brauchen, ist eine andere Frage. Ich jedenfalls liebe mein ipad und ich bin keine Apple-Jüngerin. Es ist etwas Besonderes, es in der Hand zu haben, fast ein Handschmeichler. Auch mein iphone ist ein haptisches Vergnügen und die App Integration von Twitter, Facebook & Co macht richtig Spaß. Ich habe auch Android-Tablets und Smartphones, aber Apple ist irgendwie besonders.

Hätte jemand anderer Tablets und Smartphones erfunden? Ich weiß es nicht. Fakt ist, dass die Produkte von Apple zumindestens meine Welt verändert haben und ich mich frage, was gewesen wäre, wenn jemand das “Ekelpaket” Steve Jobs einfach rausgeworfen hätte.

Just think about it.

Related posts:

1. Über das Schreiben | Leidenschaft
2. Über das Schreiben | Schreibblockaden
3. Über das Schreiben

Over on projectmanagement.com, my article “Agile: What’s in it for the Project Manager?” has been posted in two installments: part 1 on gathering requirements and work breakdown, and part 2 on interpreting requirements and tracking progress. Projectmanagement.com requires free registration to access the full content.

„Wir wollen das Scrum of Scrums (SoS) anders gestalten – und zwar grundlegend. So, wie es jetzt gerade läuft, funktioniert es nicht.“

Mit diesen Worten begrüßte mich vor einiger Zeit ein Company ScrumMaster, den ich zurzeit coache. Er berichtete, dass das Scrum of Scrums seit einigen Wochen bei den Teams in der Kritik stehen würde, weil die dort besprochenen Inhalte den Teams wenig Mehrwert brächten und die dort investierten 15 Minuten Zeitverschwendung seien. Es sei vor allem herausgekommen, dass nicht jedes Team jedem anderen Team etwas zu sagen habe – und schon gar nicht jeden Tag. Vielmehr gäbe es Teams, die immer mit den gleichen Teams kommunizieren und genau das müsse man verstärken und statt einer großen Plattform mehrere kleinere Gelegenheiten schaffen, bei denen diese Themenverwandtschaften besprochen werden können. Man habe sogar schon einen Namen für diese neue Form der Zusammenarbeit gefunden: Meta-Scrums. Die ScrumMaster haben sich nach Rücksprache mit ihren Teams entschieden, das SoS- Setting mit „Meta-Scrums“ zu revolutionieren.

Ich lobte meinen Coachee für diese tolle Idee und unterstütze seine Ausführungen, indem ich auf seinen nachhaltigen Inspect-and-Adapt-Drang verwies. Ich schloss mein Lob mit einem nachdenklichen Seufzer. Leicht verunsicherte fragte mich der Company ScrumMaster, ob ich mit der Entscheidung nicht zufrieden sei.

Ich antwortete: „Ja und nein.“ Ich bestärkte ihn erneut darin, immer auf der Suche nach Verbesserungen bzw. Veränderungen zu bleiben und die Teams weiter als Meinungs- und Stimmungsbarometer zu nutzen (Ask the team). Ich erläuterte ihm aber, worin ich ein Problem erkannt habe. Meines Erachtens wäre eine Big-Bang-Lösung das falsche Signal an die Teams und würde der Reputation der ScrumMaster eher schaden. Warum? Der ScrumMaster hat die Verantwortung, den Scrum-Prozess zu bewahren und alles dafür zu tun, um die Produktivität seines Teams zu steigern. Mit der Meeting-Revolution würde jedoch der Prozess in Frage gestellt werden.

Wurde wirklich alles unternommen, um das kritikbehaftete SoS zu etablieren? Nein. Auf die Frage, ob alle ScrumMaster dafür gesorgt hätten, dass der Sinn des Scrum of Scrums in den Teams verstanden wurde und damit die (Selbst-) Verantwortung der einzelnen Teammitglieder geklärt sei, musste der Company ScrumMaster sich eingestehen, dass das „interne Marketing“ für das SoS Lücken aufwies. Seine Entscheidung für einen vollständig neu aufgesetzten Prozess kam noch stärker ins Wanken, als ich ihn bat, sich nochmal vollständig von seiner gefundenen Lösung zu entfernen und meine Fragen zu beantworten: Was war gut am alten SoS-Prozess? Was hatte das SoS bislang erfolgreich gemacht? Warum sollte man das SoS unbedingt behalten? Ich intensivierte meine Lösungsfokussierung, indem ich dem Company ScrumMaster riet, auch sein ScrumMaster-Team mit dieser Denkrichtung zu konfrontieren.

Alles anders

Gesagt, getan. Zwei Wochen später wurde ich bei meinem nächsten Besuch Zeuge eines lebhaften, gut besuchten, produktiven Scrum of Scrums. Am Ende gab es sogar Applaus! Die Teams applaudierten ihrer eigenen Performance. Verrückte Welt! Was ging hier vor sich? Wurde ich gerade Zeuge des ersten Scrum-Bestechungsskandals? Wurde verdeckt körperliche Gewalt an den Teams geübt?

Nein! Natürlich nicht. Aber wie war dann diese (Ver-)Wandlung zu erklären? Es klingt fast zu simpel, aber das ScrumMaster-Team hatte lediglich zwei klein(st)e Veränderungen vorgenommen:

• Das SoS wurde im Rahmen des Dailys wieder fokussiert thematisiert, indem die ScrumMaster ihre Teammitglieder fragten, ob es spannende Themen, wichtige Informationen (z.B. Abhängigkeiten), hilfreiche Neuerungen oder andere Exklusivitäten gibt, die sie im SoS vorstellen möchten.
• Den Teams wurde vollkommen frei gestellt, was und wie sie ihre Themen im SoS einbringen.

Durch eine Verstärkung der Team-Autonomie wurde erreicht, dass das SoS einen neuen Anstrich erhielt. Faktisch wurde an (nur) zwei kleinen Schrauben im Räderwerk des Meetings gedreht. Das Ergebnis: klein(st)e Veränderung, große Wirkung. Es ist immer wieder beeindruckend, was möglich ist, wann man Teams mit einem Mehr an Autonomie ausstattet. Genau so verstehe ich das Prinzip der Selbstorganisation. Das erste Setting des SoS hatte einen kleinen, engen Rahmen mit wenig Freiheitsgraden, wenig Spielraum für Fehler und klaren Grenzen. Mit der Zeit werden die Teams freier, sicherer im Prozess und wünschen sich mehr Gestaltungsspielraum. Agil sein bedeutet, diese Freiheit zu geben und die Voraussetzungen dafür zu schaffen, dass der Prozess weiter funktioniert.

Die agile Haltung „inspect and adapt“ hat nicht den Anspruch, im großen Stile gelebt zu werden. Viel wichtiger ist es, konsequent dafür zu sorgen, dass der Hunger nach Verbesserungen nie gestillt ist. Alles ist möglich, alles kann/darf, aber nichts muss. Entscheidungen sind immer in die Zukunft gerichtet und sind daher immer mit Unsicherheit behaftet. Sie sind jedoch genauso wenig in Stein gemeißelt und können jederzeit justiert werden – wenn wir uns den Handlungsspielraum für Veränderungen bewahren, agil bleiben. Bevor jedoch ein neuer Weg eingeschlagen wird, sollten wir innehalten und uns (retrospektiv) umschauen, um für uns festzuhalten, was gut an dem Weg war, den wir gegangen sind und was wir von dem, was gut war, behalten sollten – nutze, was existiert und, wenn es dich erfolgreich macht, dann mach es größer.

Related posts:

1. Die drei weiteren Rollen in Scrum
2. 5 min on Scrum | Es gibt noch viel zu tun
3. Skills | ScrumMaster | Führung

Auf der Suche nach Separators (Unterbrechern zwischen den Sequenzen “Was lief gut?” und “Was kann verbessert werden?”) für eine Retro bin ich auf drei ganz einfache und doch wirkungsvolle kurze Übungen gestoßen. Sie lassen sich ohne großartige Vorbereitung und Zeitaufwand durchführen und können je nach Retro-Ziel eingesetzt werden.

 

Variante 1 habe ich letzte Woche ausprobiert. Nach dem anfänglichen „Wie jetzt? Wir sollen bis 3 zählen? Ist das Dein Ernst?“, stellte sich schnell Überraschung ein. Es stellte sich nämlich heraus, dass es nicht so einfach ist, wie gedacht.

Durch die Kombination von kognitiver und physischer Aktivität verbinden sich unterschiedliche Bereiche im Gehirn. Dadurch wird auch das einfache Zählen bis 3 zu einer Herausforderung!

Variante 1: 1, 2 … 3

ca. 3-5 Minuten – mindestens 2 Personen

• Jeweils 2 Personen tun sich zusammen und zählen bis 3. Dabei wechseln sich die Personen immer ab (Person 1 zählt 1, Person 2 zählt 2, Person 1 zählt 3, Person 2 zählt 1, Person 1 zählt 2 usw.).
• Nach ca. 30-40 Sekunden hin und her zählen gibt es eine neue Vorgabe: Die Zahl 1 muss jedes Mal durch z.B. ein Klatschen ersetzt werden.
• Wieder 30-40 Sekunden später wird die 2 durch hüpfen, stampfen, Füße anheben etc. ersetzt. Als Beobachter und Spielanleiter ist es lustig, die Gesichter der Zähler zu beobachten – man kann ihnen die Konzentration quasi ansehen.
• Je nach Belieben kann man weitere 30-40 Sekunden später auch die 3 durch eine Geste ersetzen. Nicken, auf den Tisch klopfen, einmal in die Runde drehen etc. Vielleicht hat auch einer der Zähler eine gute Idee.

Nachher kurz fragen, was beobachtet wurde, bzw. wie man sich bei den Änderungen der Vorgaben gefühlt hat. Evtl. kann man die Brücke zur aktuellen Situation (Veränderung im Unternehmen, Scrum im Allgemeinen) schlagen: einfache Regeln können schwer zu befolgen sein, Koordination, zeitliche Abstimmung und Synchronisation sind nicht einfach. Bei Veränderungen braucht es immer wieder eine gewisse Zeit, bis man sich auf die neuen Rahmenbedingungen und das Gegenüber eingestellt hat.

Variante 2: 33 / 42

ca. 5 Minuten – mindestens 3 Personen

• Teilnehmer stehen im Kreis und rufen nacheinander (z.B. reihum) die Zahlen von 1 bis 33 (oder eine andere beliebige Nummer – je nachdem, wie lange es dauern soll).
• Immer wenn die Zahl durch 3 teilbar ist oder eine 3 enthält, wird ANSTATT die Zahl zu rufen, gemeinsam in die Hände geklatscht (oder eine andere Geste ausgeführt).
• Wird ein Fehler gemacht, fängt man wieder bei 1 an – bis die Gruppe es zu der vorgegebenen Zahl schafft.

Hier muss man mitdenken und den anderen zuhören. Man kann nur als Team liefern!

Variante 3: Blindes Zählen

ca. 10-15 Minuten – mindestens 5 Personen

• Die Teilnehmer stehen im Kreis und schließen ihre Augen.
• Es soll laut bis 10 gezählt werden. Jede Zahl darf aber nur von einer Person und einmal genannt werden.
• Wird eine Zahl von zwei oder mehr Personen laut genannt, fängt man von vorne an.

Hier ist Kollaboration gefragt. Möglicherweise kommt das Team drauf, dass eine Person komplett alleine zählt oder sie eine bestimmte Reihenfolge festlegen.

 

Wo ich das gefunden habe, gibt es noch mehr :-): http://agiletrail.com/2012/03/27/8-great-short-games-for-groups/ – vielen Dank fürs Teilen! Oder versucht das Linie-Überqueren von David aus.

Viel Spaß beim Ausprobieren und Variieren!

Related posts:

1. Warum sind soziale Systeme so schwer steuerbar? Ein Erklärungsversuch.
2. Vorweihnachtsretro
3. ScrumMaster vs. ScrumMasterin

My friend and colleague, Gil Broza, is interviewing me for his Individuals and Interactions virtual training event. My topic? “Focus Keeps You Going.”

If you read my personal kanban series a couple of weeks ago, you saw how my focus kept me going. Even with a big interruption last week, due to a death in the family, I was able to maintain my focus, because I knew exactly what I had to do, to finish my work, to get ready for my trip today.

Gil has other great people in his event: Doc List, Ellen Gottesdiener, Mary Gorman, David Spann, Christopher Avery and Bob Schatz might be names you recognize. How about Rick Ross? David Spann? Caren DesBrisay? You might not recognize these names, and you should listen to what they have to say, too.

Check out Gil’s Individuals and Interactions training. Sign up. It’s a steal.

"Es sind nicht die Dinge, die uns beunruhigen, sondern unsere Sicht auf die Dinge." Seneca

Eine Szene aus einem Training für Manager im Scrum-Kontext. Auf der Themenliste aus der konkreten Führungspraxis stand der Satz: Wie motiviere ich mein überlastetes und gestresstes Team?

Im Fallgespräch erzählt der Teamleiter, der mit seinen vier Mitarbeitern für die Qualitätssicherung im Unternehmen zuständig ist, dass seine Mitarbeiter von den ständigen Unterbrechungen bei ihren täglichen Vorhaben genervt und immer mehr demotiviert sind. “Kaum eine Aufgabe können wir kontinuierlich zu Ende führen, immer gibt es höhere Prioritäten, durch Kunden, Management oder den Product Owner. Die Tage sind zerrissen durch spontane, unvorhergesehene Situationen, die es uns schwer machen, gute Arbeit abzuliefern. Der Druck ist groß und die Ressourcen sind knapp. Veränderungen aus dem Umfeld sind in absehbarer Zeit keine möglich. Und so quälen wir uns über die Runden und sehen irgendwie kein Land. Trotzdem machen wir immer noch einen guten Job, aber wie lange noch? Wie halte ich in so einer Situation meine qualifizierten und guten Leute bei der Stange, wie motiviere ich sie?“

Während er mir und den anderen Teilnehmern seine Geschichte erzählt, wirkt auch der Teamleiter selbst gestresst, hilflos und deprimiert. Mehrere Kollegen kennen das Erzählte aus ihrer Praxis und bestätigen ihn verständnisvoll in seiner Not.

Ein Bild sagt mehr als tausend Worte

Ich fordere ihn auf, sich mal ein Bild, eine Metapher für sich und sein Team zu überlegen. Er braucht nicht lange und bringt als sein Teambild den Notarzt. Er beschreibt das Bild: „Wie wir muss der Notarzt permanent ohne Vorwarnung zum Einsatz. Manchmal von einem direkt zum anderen. Er hat immer Probleme vor sich, wenn er ausrücken muss. Trotz hoher Kompetenz sterben ihm oft die Leute unter den Händen weg, weil er nicht genug Zeit hat. Oder sie sterben trotz aller Bemühungen später im Krankenhaus. Irgendwie ist seine Arbeit doch meist Stückwerk. Dann muss er auch noch ellenlange Berichte schreiben und ist im schlimmsten Fall an allem Schuld. Das ist doch deprimierend und total unbefriedigend und genauso geht es uns“.

Immer noch ist er deutlich wahrnehmbar in seinem Defizitzustand, es geht ihm nicht gut, er wirkt ratlos und resignativ.

Ich bitte ihn nun, sich doch mal ein positives Bild zu seinem Team und der Arbeitssituation zu machen. Er überlegt lange hin und her, es arbeitet in ihm, aber er kann keine positive Bildmetapher entwickeln. „Mit fällt da wirklich nichts ein, ich bin völlig blockiert. Da gibts anscheinend einfach nichts Gutes bei uns“, ist sein Fazit.

Nun frage ich ihn, ob ich ihm ein positives Bild anbieten darf, das aus meiner Sicht auch eine Möglichkeit sein könnte seine Teamsituation zu betrachten und einzuordnen. Er stimmt, leicht skeptisch, zu.

Ich entwickle folgendes Bild für den Teamleiter:

„Stell Dir vor, Dein Team ist eine hochprofessionelle Bergführermannschaft, deren tägliche Aufgabe es ist, Menschen aller Art sicher auf hohe, steile, ja auch gefährliche Bergriesen aller Höhengrade zu begleiten. Alle Deine Spezialisten beherrschen ihr „Handwerk“ perfekt, sind optimal als Team aufeinander eingespielt und kennen ihren Job genau. Ihr liebt eure Aufgabe und eure Kunden. Gut vorbereitet und hoch motiviert beginnt ihr den Aufstieg. Ihr kennt die Routen genau und arbeitet routiniert. Trotzdem ereignet sich immer wieder Unvorhergesehenes. Das Wetter wechselt plötzlich und zwingt zum Biwak, gefährliche Gerölllawinen erfordern Routenwechsel, Kunden verletzen sich und müssen ins Tal zurückgebracht werden, oder sie geraten in Panik, sind unzufrieden und belasten die Gruppe, usw. Die geplanten Zeiten können nicht immer eingehalten werden. Manchmal kommt es zum Abbruch und es muss ganz neu gestartet werden. Dein Bergführerteam löst die Probleme kompetent und gelassen unter Deiner engagierten Leitung. Bei allen Hindernissen erreichst Du mit Deinem Team und den Kunden (fast) immer die Gipfel. Dann genießt ihr den „Sieg“, freut Euch über die Anerkennung der Kunden und seid immer aufs Neue begeistert vom herrlichen Ausblick auf all die Gipfel, die ihr in Zukunft noch bezwingen werdet. Ihr wisst, dass es kaum eine Situation gibt, die ihr nicht engagiert angehen und lösen könnt, wenn es darauf ankommt. Das zeichnet Euch als Spezialteam aus, das ist Eure Mission und darauf seid ihr auch richtig stolz. Ihr freut Euch auf die nächsten, sicher nicht einfacheren Aufgaben und gebt Euch untereinander Feedback, was läuft und was man verbessern könnte, um Euch als Team zu optimieren.”

Schon bei den letzten Worten meiner Bildbeschreibung wirkt der Teamleiter deutlich entspannter und kommt aus seiner negativen Haltung heraus. Folgender Dialog entsteht (leicht gekürzt):

Frage: „Wie ist das jetzt im Moment für Dich“?

Antwort (mit fester Stimme): „Das klingt ganz  gut, so kann man mein Team und seine Arbeitssituation tatsächlich auch sehen. Und vieles stimmt tatsächlich, wenn ich es genau betrachte.”

Frage: “Wie geht es Dir denn jetzt mit dem neuen Bild?”

Antwort: „Prima, ich fühle mich optimistischer und gestärkt, irgendwie ein ganz positives Gefühl.“

Frage: „Stell Dir vor, Du gehst mit diesem positiven „Bildgefühl“ an Deine Arbeit, was würde evtl. anders sein als vorher?“

Antwort: „Das hätte sicher einen gute Wirkung auf meine Mannschaft, ich lass mich immer wieder zu sehr runterziehen.

Frage: „Nimmst Du das Bild mit, und probierst mal aus, ob Deine neue Haltung tatsächlich seine Wirkung tut?“

Antwort: „Ganz sicher, ich denke ich hab was begriffen, was für mich als Führungskraft ganz wichtig ist. Und ich werde mir ein tolles „Bergbild“ als Merker besorgen.”

Innere Bilder – das sind all die Vorstellungen und Szenen, die wir biographisch (von Kindheit an) gespeichert haben und die unser Denken, Fühlen und bewusstes/unbewusstes Handeln in hohem Maße mitbestimmen. Wenn sich Menschen bildlich etwas vorstellen, sind die gleichen Hirnbereiche aktiv, wie wenn sie es tatsächlich tun. Im Sport wird das seit langem erfolgreich be- und genutzt. Innere Bilder sind im Gehirn abgespeicherte Muster, die wir meist unbewusst benutzen, um uns zu orientieren, Situationen zu analysieren, zu bewerten und unsere Handlungsimpulse danach auszurichten. Je länger sich Menschen z.B. in für sie negativen Bildervorstellungen aufhalten, umso mehr verfestigt sich dieses Bild und seine Auswirkung auf Denken, Fühlen und Handeln. Innere Bilder können uns blockieren, oder aktivieren, können uns ängstigen oder Mut machen und motivieren. Bilderprozesse sind auf alle Fälle eine wesentliche menschliche Ressource, um das Leben und seine Anforderungen zu gestalten.

In Anlehnung an einen Blogbeitrag von Boris Gloger vom 18. Februar 2013 kann gesagt werden: „Führungskräfte sind konstruktiv, nicht destruktiv.” Sie müssen um ihre besondere Wirkung auf ihr Team wissen und durch Selbstwahrnehmung, Selbstreflexion und ihre mentale Einstellung ihren Mitarbeitern gute, positive, stärkende „Bilder“ vermitteln, auch wenn es manchmal schwer fällt. Den Einfluss, den die mentale Verfassung von Führung auf Teams hat, wird in der Regel unterschätzt. Für Motivation, Engagement und Arbeitszufriedenheit, besonders in schwierigen Situationen, ist dies zweifellos oft entscheidend. Dieser Beitrag soll Mut machen, „das eigene Bild“ einer schwierigen Situation zu erkunden, dessen evtl. kritische Wirkung wahrzunehmen und sich ein neues, unterstützendes Bild zu gestalten und den Unterschied zu testen.

Übrigens: Der Teamleiter überlegte zum Ende des Trainings, dieses Bild mit seinem Team im nächsten Meeting zu besprechen. Er kann sich gut vorstellen, dass auch seine Kollegen eine neue Perspektive gewinnen und so mit einer anderen, lockeren Einstellung an die Arbeit herangehen.

Tipp: An der eigenen Einstellung arbeiten und mit dem Team zu neuen Erfolgen aufbrechen – Scrum Supplements sind die Krafttrainings für die Veränderungsarbeit mit Scrum. Nähere Infos und alle Termine gibt es hier.

Related posts:

1. Führung in Scrum | der Manager | Verhalten | Teil 2
2. Führung in Scrum | Manager | Teil 4
3. Einzelkämpfer ScrumMaster? Herausforderungen als ScrumMaster Team gemeinsam meistern Teil 4

Experimentation is a powerful learning tool. When I was young, I performed scientific experiments by mixing chemicals together to see what they would do. I learned that most random concoctions from my chemistry set would make a brown liquid that was often hard to clean out of a test tube. I learned that sometimes they would create very smelly brown liquids. These were not really experiments, however, and I didn’t really learn from them. Instead, these were activities and I collected anecdotes and experiences from them.

The scientific method rests on the performance of experiments to confirm or deny a proposed hypothesis. Unless you can propose a hypothesis in advance, you cannot design an experiment to test it. Until you test the hypothesis, you haven’t really learned anything.

“In general, we look for a new law by the following process: First we guess it; then we compute the consequences of the guess to see what would be implied if this law that we guessed is right; then we compare the result of the computation to nature, with experiment or experience, compare it directly with observation, to see if it works. If it disagrees with experiment, it is wrong. In that simple statement is the key to science. It does not make any difference how beautiful your guess is, it does not make any difference how smart you are, who made the guess, or what his name is — if it disagrees with experiment, it is wrong.” — Richard Feynman, The Character of Physical Law

When we estimate how long it will take, or how much it will cost, to implement a desired amount of software functionality, we create a hypothesis that we can test. Our hypothesis may not be of enduring and universal value as a hypothesis that predicting physical laws, but it may still be extremely valuable to us.

For example, suppose we have a number of features we’d like to get into our next software release. And suppose we have a date in mind for that release, and a team ready to work on it. We could then ask that team to estimate the features relative to each other, bucketing them into groups of similar sizes. We could also ask them to estimate how much bigger (or smaller) are the features in one size group than the features of another. If this team has previous experience working together, they might be able to guess how long one feature might take to implement. Otherwise, they might just take a guess at it.

I would expect these numbers to be simple, with only one or two significant digits. After all, we don’t have much data to base them on. Their precision should not pretend that we do.

If we were practicing a plan-driven serial software development cycle, we might treat these estimates as promises and try to manage the work to meet them. In such case, I would expect them to have padding for the unknown, and higher precision to hide the fact that they’re padded guesses.

Using an empirical software development approach, we’ll instead treat this projection as a first hypothesis. When we finish the first feature, we’ll have some better data on the rate at which we’re progressing, and can project into the future with a bit more confidence. Does this data confirm our hypothesis of when we’ll be done?

This experiment helps us make decisions. If completing the features by the target date looks unlikely, we’ll want to take drastic action. Perhaps we’ll eliminate some features, or make them all simpler, in order to trim scope and achieve some success. Perhaps we’ll decide to cancel the project altogether, cutting our losses with only a fraction of the budget spent.

If the target still looks feasible, we can continue the experiment. We’ll still have uncertainty about both the rate of progress and the size of the work, but we can reason about those uncertainties. Are our errors in sizing likely to be additive, or random? Is the current rate of progress sustainable? Is it depressed because of one-time startup work? Or is it optimistic because we’ve been cutting corners?

Poorly handled estimation is a means to fool ourselves, but handled with care, it gives us tools to experiment and learn.

The Hokey Pokey — by William Shakespeare

O proud left foot, that ventures quick within
Then soon upon a backward journey lithe.
Anon, once more the gesture, then begin:
Command sinistral pedestal to writhe.
Commence thou then the fervid Hokey-Poke,
A mad gyration, hips in wanton swirl.
To spin! A wilde release from Heavens yoke.
Blessed dervish! Surely canst go, girl.
The Hoke, the poke — banish now thy doubt
Verily, I say, 'tis what it's all about.


From a Washington Post Style Invitational contest, that asked readers to submit instructions for something (anything), but written in the style of a famous person. The winning entry was The Hokey Pokey (as written by Shakespeare), written by Jeff Brechlin, of Potomac Falls, Maryland.  Source.

A rehab center with a mission.
David Koontz - CHPI

Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 3: KNOW THYSELF

“Using self-awareness and self-knowledge for self-management seems to be key in becoming an effective leader.”

Running time 26:38

What instruments have you experienced that have been helpful to you? When has really good self-awareness and self-knowledge helped you self-manage as a leader? If you’ve experienced the Hogan, tell us about it. We’d love to hear your stories.

Leave a comment on this blog or email us at leadershippodcast@gmail.com

Summary
Intro – Using assessments in organizations to develop self-awareness and self-knowledge to become effective leaders.
1:55 – Introducing the Hogan assessment – richer, more subtle and provides more nuanced information.
5:56 – The Hogan assessment considers three parts: individual values, leadership potential and challenges or derailers.
13:12 – Comparing the Hogan assessment with the Strengthsfinder by Gallup.
19:54 – One differential aspect of the Hogan assessment – it can be used to map teams.
23:50 – Assimilating assessments like the Hogan in academic programs.

Resources
Hogan Assessment
Myers-Briggs
StrengthsFinder

Photo Credit: Werner Kunz via Compfight cc

The classic tale of a year-long project finally being delivered only to discover it doesn’t meet the needs of the customer sounds ridiculous in the days of short iterations and customer collaboration but I’m guessing we are still a long way from delivering what’s really needed effectively. So what’s stopping us?

1. Is it the fear of feedback that stops us showing work in progress
2. Is it the fear of admitting that we need to abandon the plan when we discover something new
3. Is it the fear of throwing away work done when people tell us it’s not what they need
4. Is it the fear of what others will say when we admit our assumptions were wrong
5. Is it the fear of embarrassment when we discover what was really needed was much simpler
6. Is it the fear of punishment when our boss discovers the work we did will not be useful to the customer (even though it created insight into what was needed)
7. Is it the fear of people questioning our competence
8. Is it the fear of what people say if we don’t look busy, when we are thinking about a different approach
9. Is it the fear of what people say if we don’t look busy when discussing ideas with others
10. Or are we just conditioned (by fear) not to think differently and to take the safest path

Finding the best solution to the problem takes courage, courage needs support – support through collaboration which needs openness. We are fearful because we are not open and openness takes courage.

Fear creates fear.

If we want to build the right thing we must start with a workplace without fear.

Building the right thing requires listening, patience, empathy and imagination

(resources that are scarce in the prevalent business mindset)

Hey everyone… I’m out in Vegas this week at the Scrum Gathering. Got invited to speak… which was really cool (thanks Daniel Gullo)… and did the most recent iteration of my Agile Program and Portfolio Management deck. Take a look and let me know what you think!

The post Scrum Gathering Las Vegas – Large Scale Program and Portfolio Management with Scrum appeared first on LeadingAgile.

There have been some web posts and twitter comments lately that suggest some people have a very narrow view of what techniques constitute an estimate. I take a larger view, that any projection of human work into the future is necessarily an approximation, and therefore an estimate.

I often tell people that the abbreviation of “estimate” is “guess.” I do this to remind people that they’re just estimates, not data. When observations and estimates disagree, you’d be prudent to trust the observations. When you don’t yet have any confirming or disproving observations, you should think about how much trust you put into the estimate. And think about how much risk you have if the estimate does not predict reality.

This does not mean, however, that you have to estimate by guessing. There are lots of ways to make an estimate more trustworthy.

Using more people to independently estimate is one common technique and provides a reasonableness check on the result. Wideband delphi techniques further this by then re-estimating until the predictions converge (or stalemate). People have widely adapted James Grenning’s “planning poker” to perform this procedure. In theory, having multiple independent estimates misses fewer important points and gives us a more trustworthy result.

In practice, the various estimates are often less independent than we think. A group that works closely together can often guess what each other are thinking about the kind of work they commonly do. In addition, many times some of the participants telegraph their estimates before others have decided, soiling the independence. A further problem is that variations in skills and abilities give some people an advantage in estimating work aligned to their strengths, but the estimates of those more ignorant in the work are often given equal weight, skewing the results. This is especially true when estimating things that have been broken down to small amounts of work.

Estimating relative to other work is easier for people, and therefore more reliable than estimating in absolute terms. I can look at two similar rocks and guess which one is heavier, or if they’re about the same, without knowing what either one weighs. This is the genesis of “story points.” Once we’ve assigned a value to one piece of work, then we can estimate others as multiples or fractions of that reference. Using affinity grouping, we can gather together all the work items that seem about the same size.

Unfortunately, we often have a harder time seeing the size of development project work than we do of rocks. Using the rock metaphor, we might be trying to compare a chunk of talc with a piece of uranium ore. Apparent size is sometimes deceiving. People also have a tendency to hold onto absolute references. They want their story points to be comparable from team to team, or from year to year. They want to adjust their estimates after the fact so that items that took about the same amount of time are given similar values. “We estimated that as a 2 but it turned out to be a 5.” They try to fix the story points to an absolute time or work reference, and in the process they make them less trustworthy by damaging the reliance on relative estimation.

Estimating based on recent history is an excellent way to improve the reliability of estimates, especially for the short term. The XP practice of Yesterday’s Weather is one example of this. “If we completed 24 story points last iteration, we’ll probably complete about 24 story points this iteration.” Bob Payne and I took a look at some data we had from teams with whom we’d worked and found that we could generally do as well, or better, by just counting the stories instead of estimating them in points. In other words, saying “If we completed 8 stories last iteration so we’ll probably complete about 8 stories this iteration” had about the same predictive power as using story points, and was a lot quicker to calculate. This was true even when the story estimates varied by about an order of magnitude. Others, such as Vasco Duarte, have noticed the same phenomena. Taking the story points out of the equation seems to remove some of the noise in the data, and certainly removes some of the effort required. If you want to get better, use what I call the Abbreviated Fibonnaci Series which has the values of “1″ and “too big.” Split the stories considered too big. You’ll accrue benefits beyond better estimates.

If velocity gives us a frequency measurement in stories per iteration, then it’s inverse is cycle time. Cycle time is the time it takes to complete one story–equivalent to a wavelength measurement. Once a team has some track record, then you can generally expect the these numbers to settle down into something fairly predictable. Because these estimates are based on data, many people are tempted to treat them as data, themselves. Remember, though, the disclaimer of investment managers, “Past performance is no guarantee of future results.” Even if the team has a consistent track record, there may be a black swan or three right around the corner.

Of course, all things are not always equal. Organizations have a distressing tendency to change the makeup of teams, which changes the rate at which the team accomplishes work. The work itself may change, and so may the team’s skill at dealing with the work.

This is just three categories for improving the trustworthiness of estimation. There are many other techniques for estimating. Most have advantages, and all have disadvantages. Even with our best attempts at improving estimates, the true goal is accomplishing the work. Ultimately it’s better to apply energy to that goal rather than chasing after ever better estimation.

Wisst ihr was Parabeln  sind? Ich musste selbst nachschlagen und habe das dazu gefunden:

 

Die Parabel ist

„eine lehrhafte und kurze Erzählung. Sie wirft Fragen über die Moral und ethische Grundsätze auf, welche durch Übertragung in einen anderen Vorstellungsbereich begreifbar werden. Das im Vordergrund stehende Geschehen (Bildebene) hat eine symbolische Bedeutung für den Leser. Die Parabel bringt den Leser zum Nachdenken und zum Erkennen eines richtigen Lebens durch die Herleitung des gemeinten Allgemeinen (Sachebene). Eine Parabel enthält meist zwei Lehren: Zum einen eine im engeren Sinn, zum anderen eine Lehre im weiteren Sinn. Sie kann sowohl explizit als auch implizit enthalten sein.“ (Wikipedia)

 

Beim Lesen eines wunderbaren Buches von Stefanie Widmann und Andreas Wenzlau bin ich auf eine Parabel gestoßen, die jeder ScrumMaster kennen sollte und deren Lehren fester Bestandteil im Handlungsportfolio eines Change Agents sein sollten. Ich möchte euch den wirklich lehrreichen, inspirierenden Text nicht vorenthalten. Sinngemäß geht die Parabel so (vgl. Widmann und Wenzlau, 2008, S. 47):

 

Ein Teammitglied, das die nicht enden wollenden Diskussionen und Streitereien mit einem seiner Teammitglieder nicht länger aushielt, bat seinen ScrumMaster um Rat und erzählte ihm von seinem Kummer:

„Kaum macht einer von uns einen Kommentar, wird er vom anderen schon unterbrochen. Es reicht ein falsches Wort und wir streiten wieder miteinander. Danach ist jeder schlecht gelaunt und überträgt die miese Stimmung auf den Rest des Teams. Eigentlich kann ich ihn doch ganz gut leiden und er ist ein wirklich toller Entwickler. Ich weiß einfach nicht mehr weiter. Was soll ich deiner Meinung nach machen?“

 

Der ScrumMaster antwortete ruhig:

„Du musst lernen, ihm zuzuhören. Und wenn du denkst, dass du dir ganz sicher bist, dass du das kannst, dann komm wieder zu mir.“

 

Nach zwei Sprints sprach das Teammitglied wieder mit dem ScrumMaster. Der junge Mann berichtete, dass er sich sicher sei gelernt zu haben, auf jedes Wort zu hören, das sein Teamkollege zu ihm sagte.

„Prima“, sagte der ScrumMaster lächelnd. „Wenn du jetzt dafür sorgen möchtest, dass ihr miteinander auskommt, euch respektiert und eine gemeinsame Sprache findet, musst du jetzt noch lernen, auf jedes der Worte zu hören, die dein Kollege nicht sagt.“

Das Spannende steht zwischen den Zeilen

Die gesprochene Sprache ist und bleibt nur ein Element unserer Kommunikation bzw. des gegenseitigen Verständnisses und der damit einhergehenden Zusammenarbeit. Sie dominiert unser Tun, weil sie vordergründig das ist, was unserem Bewusstsein klar ist. Man kann es sehen, man kann es hören. Unser Fokus beschränkt sich hierauf. Dinge, die nicht gesagt werden, sind ein wichtiger Bestandteil, um zu verstehen und verstanden zu werden. Nonverbale Kommunikation (z.B. Gestik, Körpersprache) ist nur ein Aspekt, der aus einem einfach ”Ja, ich verstehe dich” (und gleichzeitig geht beispielsweise der Blickkontakt verloren oder es ist ein kaum wahrnehmbares Kopfschütteln zu bemerken) eine ganz andere Reaktion werden lässt. Auch unser Mienenspiel, sogenannte Mimikexpressionen (=kurze Veränderungen in unserem Gesicht aufgrund einer Gefühlslage), verraten dem guten Zuhörer oder in diesem Fall Beobachter, dass es nicht nur auf die gehörten Worte ankommt, sondern auf ebenso auf das, was zwischen den Zeilen steht. Wir können nun mal keine Gedanken lesen. Das ist Fakt. Nichtsdestotrotz sind wir mit Fähigkeiten in uns ausgestattet, die uns mehr erlauben, als nur zu hören, was ein Gegenüber sagt. Es bedarf hierzu auch ein anderen (inneren) Haltung. Empathie (=Einfühlvermögen) ist nicht genetisch bedingt. Es ist Übungssache und es hat etwas mit einer Fähigkeit zu tun, die wir zwar in uns tragen, die wir aber aufgrund von unserer Getriebenheit im Alltag nur mangelhaft zum Einsatz bringen: der Neugierde.

 

Seid neugierig auf das, was ihr hört und seid noch neugieriger auf das, was ihr nicht hört, meint zu verstehen und hinterfragt es – beim anderen, aber auch bei euch selbst, wenn ihr einfach mal euer Bauchgefühl “sprechen” lasst.

 

 Die Definition, was eine Parabel ist, beinhaltet, dass es meist zwei Lehren in ihr gibt – eine implizite und eine explizite. Was sind eure Lehren aus dieser Parabel?

 

Literatur

Widmann, S. & Wenzlau, A. (2008). Moderne Parabeln. Eine Fundgrube für Trainer, Coachs und Manager. Publics.

 

Übrigens: Haltet in den nächsten Wochen die Augen offen. Vielleicht bekommt ihr bald die Gelegenheit, richtig gute Zwischenzeilenleserinnen und -leser zu werden!

 

Related posts:

1. Prioritäten | Product Owners Tools
2. Scrum Alliance mal wieder führungslos – Donna Farmer geht
3. Schuldzuweisungen verhindern Lernen

For me the most fundamental principle in Agile Development is to reduce feedback time in everything you do. This helps us do the right thing more often and waste less time doing the wrong thing. It’s not just the feedback time that matters, it’s the quality of that feedback and when it comes to building the right thing the best feedback comes from real users using the real product in the real world. We (and our customers) all to easily ignore this because we don’t know what we don’t know and assume that we know what to build.

Whilst being close to your customer and having conversations helps, nothing beats getting the software out there and having people scream about what is missing. Having a process that allows you to quickly respond to those screams, and we are talking hours not weeks or months, is by far the most effective way to build the right thing.

Now this isn’t rocket science, I think it’s widely accepted in the Agile community but perhaps not so much in the business community. The business needs numbers to be convinced, so lately I’ve been thinking about what is the real cost of not using a continuous deployment process.

Building a product with and without continuous delivery requires a strikingly different mindset:

1. Build the simplest thing possible that satisfies the story, deliver it to the customer and discover what’s missing. We make as few assumptions as possible and test them as early as possible
2. Consider all possible permutations of what the customer might need to deliver the story and ensure that they are all covered, because once it’s out there it will take too long to react to problems. Talking to the customer about what they need helps, but they won’t really know till it’s built.

In my experience of working the second way I think you usually end up building at least twice as much as is used. I think many will argue the figure is much higher. But the cost of delivering twice as much is more than  twice the cost. As software becomes more complex and each area of functionality needs to work with other areas the cost of adding new features grows. You also need to spend more time maintaining the features. Good design and engineering practices can help with this but it’s unavoidable that the cost of adding each new story will grow exponentially. If the growth is exponential, and the product lasts long enough, I assume that at some point in its lifecycle the cost of adding a new feature will be 5 times as much as if you were using continuous delivery.

Now that’s the kind of figure that I think could convince organisations to reconsider the way they are working, and treat continuous delivery as essential rather than something just the cool kids do. But is my assumption correct?

Wozu Scrum? Die Antwort auf diese Frage variiert von Unternehmen zu Unternehmen – und dennoch geht es meistens um schnellere Auslieferungen, bessere Qualität, stärkere Kundeneinbindung, zufriedene Mitarbeiter.

 

All das ist wichtig und gut, doch beantwortet es nicht die Frage nach dem Wozu. Denn ich kann großartigen Code schreiben, alle zwei Wochen releasen, meine Kunden ständig dabeihaben und immer noch nicht wissen, welchen Zweck ich damit verfolge. Solange die Geschäftszahlen stimmen, mag das nicht weiter schlimm erscheinen. Gewinn ist ein täuschend echter Unternehmenszweck.

 

Verändern sich aber die Marktbedingungen (und das ist heute eher die Regel als die Ausnahme), ist die eigene Ausrichtung zu überprüfen: Ist das, was sich bisher blendend verkauft hat, auch heute noch das Richtige? Und spätestens da stellt sich die Frage nach dem Wozu. Um sie zu beantworten, muss ich erstmal verstehen, wie mein Produkt aussehen könnte und was es zum Produkt macht. Wir haben dafür eine eigene Rolle in Scrum: Den Product Owner. Ohne die Frage nach dem “Wozu” wären Product Owner überflüssig: Die Entwicklungsteams könnten direkt mit Kunden und Benutzer sprechen, seine Anforderungen aufnehmen und dann umsetzen.

Was ist das denn: ein Produkt?

Laut Wikipedia ist es das Ergebnis eines vom Menschen bewirkten Transformationsprozesses, in dem Produktionsfaktoren wie Güter und Dienstleistungen in einen Output umgewandelt werden. Das ist sicher nicht falsch, aber es zieht am Wesentlichen vorbei.

 

Ein Produkt ist für mich so etwas wie ein Leuchtturm in der Beziehung des Menschen zu seiner Umwelt. Ein Anker, eine feste Referenz, die unser Leben besser, schöner, einfacher, anspruchsvoller macht.

Ein Kunstwerk, ein Schlüssel, ein Zug, ein Studium, ein Hut, eine Tasse Kaffee. Das alles sind Produkte – feste Bestandteile des menschlichen Lebens, milliardenfach produziert und in Anspruch genommen, weil sie nützlich sind.

Ein gutes Produkt fügt sich ungezwungen in die Interaktion zwischen Mensch und Umwelt. Es wird nicht als Last oder Hindernis, sondern als Stärkung empfunden. Als etwas, das man gerne in die Hand nimmt, trägt, bedient, in Anspruch nimmt.

 

In der Softwareentwicklung fällt der Bau guter Produkte nicht leicht. Mit Software lässt sich sehr viel sehr schnell bauen. Diese Fülle an Möglichkeiten, die ja die Kraft von Software ausmacht, ist zugleich ihre Achillesferse. Benutzer wollen einfache, intuitiv bedienbare, gut aussehende und zugleich leistungsstarke Software. Zu oft fühlen sie sich jedoch überfordert und frustriert, haben eine vorbelastete Beziehung zu Software und würden am liebsten ohne sie auskommen, wenn sie die Wahl hätten. Da sie diese Wahl nicht haben, werden sie bisweilen stiefmütterlich behandelt. Es sollte niemanden verwundern, wenn die gleichen Benutzer bei der erstbesten Gelegenheit dem Konkurrenten in die Arme laufen und dem alten Produkt keine Träne nachweinen.

 

An welchem Produkt arbeitest du mit? Was macht es stark? Wie beeinflusst es die Interaktion zwischen Mensch und Umwelt? Wer sind diese Menschen? Die Antwort auf diese Fragen nennen wir Produktvision. Es lohnt sich, Zeit dafür zu investieren. Denn nur die Produktvision kann die Frage nach dem Wozu beantworten. Software wird nicht entwickelt, um fehlerlos zu laufen. Oder um möglichst viel Abfragen in möglichst geringer Zeit zu bearbeiten. Sie ist da, um Spuren im Alltag der Menschen zu hinterlassen. Du kannst bei dem, was du entwickelst, beim besten Willen keine Produkteigenschaften feststellen? Dann versuche es mit folgenden Fragen:

• Wer sind deine Kunden? Was haben sie davon, dass es euch gibt?
• Welcher Bedarf deines Kunden wird durch euer Produkt erfüllt?
• Welche sind die vier bis fünf kritischen Funktionalitäten, die den Erfolg des Produktes ausmachen?
• Wie wird das Unternehmen vom Produkt profitieren?

Nimm dir zum Schluss noch zehn Minuten, um deine Erkenntnisse in einen “Elevator Pitch” zusammenzufassen – einem Statement, das so knapp und prägnant ist, dass während einer Fahrt im Aufzug die Vision kommuniziert werden kann.

 

Unsere Produktvision bei bor!sgloger lautet übrigens wie folgt: Nach ihrem Arbeitstag sollen unsere Kunden nach Hause gehen und dorthin die Energie und Zufriedenheit mitnehmen, um mit ihren Kindern zu spielen.

Related posts:

1. Scrum Essentials: Die sieben Fragen der User Story
2. Warum wir eigentlich alle Freelancer sind
3. ScrumMaster vs. ScrumMasterin

The software industry has created a knowledge and expectation of product versions.  Previously the closest industry to create this mindset was the automotive industry - they had the model year concept.  Typically they added nice to have "bells or whistles", but rarely added true features each iteration of the auto model year.

Software was a new paradigm, back in the 1980s, this industry started using a version numbering scheme (major dot minor). For example, Windows 3.1, the first version to truly work and deliver value to the customer.

What happens when a company moves back to the model year concept of versioning in the software industry?  Does it help customer to understand the expectations of value being delivered?  Does it create more cognitive load for decision makers?

Here's an example, you tell me; it is May of 2013, is this the best move for Company X.

Coming Soon: SharePoint 2010
The long-awaited upgrade to SharePoint 2010 will soon roll out in phases across Company X, beginning in May. The full upgrade should be complete by the end of August, with some employees beginning to see changes to their SharePoint in the coming weeks.By my quick use of higher math (2013 - 2010 = 3 years), this is a very long awaited upgrade!  Perhaps so long as to just say, F*** IT, let's wait for SharePoint 2015.  The beta version should be out this summer.

Can someone please tell me how this version scheme helps our customers, users, purchasers, anyone?  What scheme do you use?  Does it set the expectation you desire with your customers?