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

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

Auch in der Produktentwicklung werden gerne Ziele gesetzt. Bis Ende des Jahres soll der Gewinn um dreißig Prozent steigen, der Wartungsaufwand halbiert werden und die Anzahl zufriedener Kunden signifikant wachsen. Alles schön und gut.

Aber: Was passiert mit uns, wenn wir uns solche Ziele setzen? Wir bauen Brücken, um sie zu erreichen. Mary und Tom Poppendieck zählen drei Möglichkeiten auf, ein Ziel zu erreichen:

• Die Arbeit umgestalten
• Das System verzerren
• Tricksen

Gibt es eine Abkürzung zur Veränderung?

Ziele können also auch über Abkürzungen erreicht werden. Wir biegen dann die Verhältnisse so lange zurecht, bis sie auf das Ziel passen. Eine wirkliche Veränderung erreichen wir damit nicht – sondern bewirken mitunter etwas ganz anderes. Deshalb dürfen wir Ziele nicht mit Zwecken verwechseln: Mein Ziel ist, 100 Meter in 11 Sekunden zu laufen. Dabei verfolge ich den Zweck, etwas für meine Gesundheit und mein Selbstbewusstsein zu tun. Wenn ich dazu eine Abkürzung nehme und zu leistungssteigernde Drogen greife, mag ich mein Ziel zwar erreichen – den Zweck verfehle ich aber oder handle sogar konträr dazu.

Mary und Tom Poppendieck raten aus solchen Gründen davon ab, Ziele zu setzen. Und sie liefern ein weiteres Argument: Wer anderen Ziele setzt, bringt ein Defizit zum Ausdruck. Du bist noch nicht schnell genug. Das Unternehmen generiert noch zu wenig Gewinn. Das kann zu einer negativen Stimmung führen.

Sollen wir also besser gar keine Ziele setzen? Ich sehe das anders. Ziele haben einen großen Vorteil: Sie sind prinzipiell erreichbar. Das macht uns stark. Denn wir können auf sie hinarbeiten, uns ihnen Schritt für Schritt nähern. Und am Ende stolz sagen: Ich habs geschafft.

Sie zeigen, wo man gerade steht und was noch zu erreichen ist. Sie dürfen nicht utopisch sein, sondern müssen den Möglichkeiten des Systems entsprechen. Ich kann 100 Meter in 11 Sekunden laufen – 10 Sekunden sind für mich außer Reichweite. Unter dem Stichwort SMART verbergen sich fünf Eigenschaften guter Ziele: Spezifisch, messbar, erreichbar, relevant, zeitlich terminiert.

Und: Ziele dürfen nie isoliert formuliert werden. Sie ergeben nur dann Sinn, wenn sie mit einem Wozu, mit dem Zweck verbunden sind. Wer seinen Gewinn steigern möchte, um seine Quartalsziele nicht zu verfehlen, der mag mit Bilanzkosmetik genau das Richtige tun. Wer es aber tut, um die Produktivität zu erhöhen, der wird um Veränderungen in der Organisation nicht umhinkommen. Dabei sind Ziele nur Wegmarken, wie die Leuchtfeuer am Boden vor der Landepiste. Umso wichtiger ist es, ein scharfes Bild vom dem zu haben, was man erreichen möchte. Wir nennen das Vision. Erst eine gute Vision macht Ziele attraktiv, gibt ihnen Anziehungskraft. So kann aus dem mühsamen Abrackern eine spannende Herausforderung werden. John F. Kennedy hat es mit seiner Vision zur Mondlandung geschafft, die ganze Welt bei der Zielerreichung mitfiebern zu lassen.

Wie sieht es in deiner Organisation, in deinem Leben aus? Hast du Ziele, für deren Erreichung du arbeitest? Machen sie Sinn, steckt dahinter ein Zweck? Und welches Bild, welche Vision verbindest du damit?

Mary und Tom Poppendieck: Leading Lean Software Development: Results Are Not the Point. Addison-Wesley.

Related posts:

1. Was hat Fußball mit Zielen zu tun – und das alles mit Scrum?
2. Utopie – Quo Vadis?
3. Eine Erleuchtung: Scrum als Coaching-Tool!

Deine Kollegen sagen nicht nein, aber vor Begeisterung sprühen sie auch nicht gerade. Und schon während der erste Sprint anläuft, merkst du: Verdammt. Wir bleiben im Sand stecken. Zu viele Kompromisse werden eingegangen, auf zu Vieles wird gleich von Anfang an verzichtet. Das Daily findet nicht täglich statt und dauert dann gleich eine halbe Stunde. Im Planning werden komplett neue Backlog Items vorgestellt. Das Team weiß nicht so recht, worauf es sich committen soll. Es ist selten zusammen zu sehen, weil jeder anderen Projekten nachlaufen muss. Und bei der Retro zur Scrum-Einführung heißt es dann: Scrum ist grundsätzlich gut, aber wohl nichts für unser Unternehmen. Wir brauchen einen weniger strengen Ansatz, der sich mit unserer Wirklichkeit besser verträgt.

So viel Respekt vor Scrum ist merkwürdig. Ich kann gar nicht oft genug betonen, dass Scrum nur ein Rahmenwerk zur Entwicklung von Produkten ist. Vieles, sehr vieles wird in Scrum offen gelassen – zur Enttäuschung all jener, die eine Schritt-für-Schritt-Anleitung erwarten.

Diese Offenheit hat einen großen Vorteil. Denn der Scrum Flow, so wie wir ihn kennen, ist hinreichend formal, um Vielfalt zuzulassen. Im Vergleich zu anderen Methoden wie beispielsweise dem RUP (Rational Unified Process) kommt Scrum mit einer handvoll Regeln und Rollen aus. Und selbst die Meetings, die gerne als Zeitfresser dargestellt werden, nehmen zusammen gerade einmal 12% der Gesamtzeit eines Sprints ein (zumal Scrum dafür sorgt, dass die restlichen 88% dann wirklich für die Produktentwicklung frei bleiben).

Scrum deckt auf – für manche zuviel

Nehmen wir zum Beispiel das Daily: Ich vergleiche es gerne mit einem gemeinsamen Frühstück am Familientisch. Man sitzt zusammen, um sich für den Tag vorzubereiten. Wer bringt die Kinder zur Schule, wer holt sie ab? Wer geht einkaufen? Was steht auf der Liste? Wann kommt der Babysitter? Wann ist Abfahrt für das Konzert am Abend? Am Ende eines solchen Dailies sollte jeder den Fahrplan für den Tag im Kopf haben und entsprechend koordiniert starten können.

Schreibt ein solches Daily der Familie vor, wie sie zu leben hat? Nein. Es schreibt inhaltlich rein gar nichts vor. Alles, was sich verändert hat, ist der Rahmen: Man verabredet eine feste Zeit und einen festen Treffpunkt. Man versieht das Treffen mit einem Zweck: dem der Synchronisation und Kooperation.

Vielleicht geht man sogar etwas weiter und bittet die Familie, das Frühstück im Stehen abzuhalten, damit alle mit Augen und Ohren dabei sind. Und – Achtung: Jetzt wird’s radikal! Man drückt jedem Familienmitglied einen Stapel gelber Post-Its in die Hand, verbunden mit der Bitte, die jeweiligen Aktivitäten schriftlich festzuhalten und für alle sichtbar an die Kühlschrankwand zu pinnen.

Is that too much to ask for? Für manche Familien sicherlich schon. Die empfinden ein solches Meeting als eine Zumutung und klagen, dass einmal täglich viel zu oft ist. Aber eine solche Überforderungssituation stellt nicht die Tauglichkeit von Scrum, sondern die Kommunikationsstruktur der Familie in Frage. Denn entweder ist die Familie schon so gut aufeinander abgestimmt, dass ein formales Treffen gar nicht mehr nötig ist. Das kann durchaus vorkommen – so wie es auch extrem gute Teams gibt, die sogar eine Retrospektive entbehren können, weil sie den Veränderungsprozess laufend gestalten und in die Alltagspraxis integriert gaben.

Oder aber – und das ist der weitaus häufigere Fall – die Familie hat schlicht und einfach keine Lust mehr, zu kommunizieren. Und auch das mag eine legitime Entscheidung sein, die es zu respektieren gilt. Allerdings ist es dann blauäugig, das Rahmenwerk (Scrum) für das Scheitern verantwortlich zu machen und zu behaupten: Scrum passt hier einfach nicht zu uns. Ehrlicherweise müsste die Antwort lauten: Wir möchten uns nicht so oft ins Gesicht schauen müssen.

Related posts:

1. Eine Erleuchtung: Scrum als Coaching-Tool!
2. Ich bin aus jenem Holze
3. 10 gute Gründe, warum Sie € 99.- und einen interessanten Tag in Ihre Zukunft investieren sollten

Wer nur an der lokalen Optimierungen arbeitet und versucht, Scrum-Teams zu hochmotorisierten Produktionsstätten zu machen, wird eines Tages frustriert das Handtuch werfen. Denn ein Team kann nur so gut sein wie die Organisation, in der es funktioniert.

Deshalb setzen wir mittlerweile in jedem Scrum-Implementierungsprojekt ein Transition Team auf. Es besteht meist neben Product Ownern und ScrumMastern aus dem mittleren und höheren Management. Es soll eine Koalition darstellen, die Veränderungen in der Organisation anstoßen und durchsetzen kann. Wir nennen es Transition, um zu zeigen, dass wir noch nicht dort sind, wo wir sein möchten, uns aber auf dem Weg dorthin befinden.

Transition Teams können aus vielen Gründen scheitern. John P. Kotter benennt in seinem Buch Leading Change einige Ursachen, die sich auch mit unserer Erfahrung decken.

Schwaches Problembewusstsein

Ein Transition Team ist immer eine Zumutung, denn es erfordert von seinen Mitgliedern eine Menge Zeit. In meinem Transition Team gehen pro Person mindestens sieben Stunde pro Woche drauf – häufig deutlich mehr. Der Terminkalender meiner Teammitglieder ist natürlich immer überfüllt. Zusammenarbeit wäre nicht möglich, wenn nicht allen klar wäre, dass die Arbeit im Transition Team Priorität über andere Termine hat. Dazu muss allen Teammitgliedern klar sein, dass Veränderungen dringend und wichtig sind, und dass das Transition Team das Mittel der Wahl zum Erreichen dieser Veränderungen ist.

Tipp: Stellt Eurem Transition Team folgende Frage: Woran werden wir scheitern? Wer in den Abgrund blicken kann, der entwickelt ungeheure Energien.

Falsche Besetzung

Ein Transition Team muss Mitglieder mit genügend Entscheidungskompetenzen haben, um die Veränderungen auch durchsetzen zu können. Es gibt nichts Frustrierenderes als ein hoch engagiertes Transition Team, das stundenlang die schönsten Konzepte und Szenarien ausarbeitet, um dann an irgendeinem Entscheidungsgremium zu scheitern. Manche Transition Teams sind so groß, dass keine gute Diskussion mehr möglich ist. Anderen fehlt es schlichtweg an einem ScrumMaster, der sich um ihre Produktivität kümmert.

Tipp: Orientiert Euch bei der Größe an Scrum-Teams! Diese sollten nicht mehr als neun Mitglieder haben, darunter ein Product Owner und ein ScrumMaster als dedizierte Rollen.

Unangemessene Zielvorstellung

Was wollen wir mit dem Transition Team eigentlich erreichen? Ich erlebe häufig zwei Extreme. Das eine Extrem besteht aus Transition Teams, die hauptsächlich an Verwaltungsaufgaben arbeiten. Ein Beispiel hierfür ist der Einsatz neuer Tools oder die Beschreibung bzw. Ausgestaltung von Abläufen. Das sind Aufgaben, die keiner großen Veränderung bedürfen und entsprechend bescheidene Ziele nach sich ziehen. Das andere Extrem besteht aus Transition Teams, die an Zielen arbeiten, die so monumental sind, dass sie sie aus eigener Kraft gar nicht erreichen können. In meinem derzeitigen Transition Team wollten wir ganz zu Beginn die agile Organisation konzipieren – bis wir dann merkten, dass das Aufsetzen von Scrum-Teams zu jenem Zeitpunkt unsere eigentliche Aufgabe war.

Tipp: Gebt Euch zuerst eine Vision, die das Zielbild darstellt. Gebt Euch dann eine Mission, die den Weg dorthin beschreibt.

Keine Führung

Welche Menschen sitzen in deinem Transition Team? Sind es Verwalter und Optimierer? Oder gibt es auch Menschen, die den Status Quo in Frage und die Organisation vor echte Herausforderungen stellen können? Manchmal reicht auch schon eine Person mit Führungsanspruch in einem Transition Team – solange sie als Visionär alle anderen Mitglieder für den Change begeistern kann.

Tipp: Prüft bei jeder Story, inwiefern sie dem Geiste der Vision entspricht. Vieles wird sich dann als nebensächlich entpuppen.

Wenn man so viel falsch machen kann, warum machen wir uns dann überhaupt die Mühe, Transition Teams aufzusetzen? Weil wir Scrum als Vehikel zu einer Veränderung nutzen möchten, die zwar in den Scrum-Teams ihren Dreh- und Angelpunkt hat (wir machen Produkt-, nicht Organisationsentwicklung), aber ohne gescheite Rahmenbedingungen früher oder später verkümmert.

Woran merken wir, ob ein Transition Team seine Arbeit gut verrichtet? Indem es sich nach und nach überflüssig macht. Denn eine Organisation mit hinreichend starken ScrumMaster- und Product Owner-Teams kann mehr und mehr Veränderungen von selbst anstoßen und durchsetzen. Aber dahin zu kommen, das ist der eigentliche Weg einer jeden Transition. Es lohnt sich.

John P. Kotter (1996): Leading Change. Harvard Business Review Press. (http://astore.amazon.de/borisgloger-21/detail/0875847471)

Siehe auch: Bitte geben Sie Ihr Ziel ein! Tipps für das Transition Team

Related posts:

1. Bitte geben Sie Ihr Ziel ein! Tipps für das Transition Team
2. Warum keine Tasks im Backlog?
3. Scaling Scrum is simple but very hard | 10 Tipps

Am Wochenende hielt ich die iPad-App der Süddeutschen Zeitung in meinen Händen und spürte: Das ist es.

Ich weiß noch genau, wie ich vor zwanzig Jahren die allererste Internet-Verbindung mit meinem Telefon-Modem und einer lokalen Einwahlnummer aufbaute. Die erste Seite, die ich damals im Web aufrief, war: http://www.spiegel.de. Texte und Bilder bauten sich langsam, Zeile für Zeile auf, und in dieser einfachen HTML-Sprache gab es nicht viel mehr außer Texte, Bilder, und klobige Frames. Die Seite war etwa zur Hälfte aufgebaut, dann brach die Verbindung ab. Ich bewahre den Screenshot von meinem ersten Mal noch heute auf. Als Dreizehnjähriger konnte ich damals kaum schlafen vor Aufregung, war ich doch in das World Wide Web vorgedrungen.

Was damals für die Verlage als einfache Web-Präsenz mit minimaler Investition anfing, ist heute nicht mehr wegzudenken. Weil viele Printmedien immer härter um ihre Leser kämpfen müssen, ist das Online-Geschäft zum Hoffnungsträger mutiert. Dass sich mit Online-Anzeigen nicht viel Geld verdienen lässt, ist keine Neuigkeit. Ebenso wenig scheinen Leser in der Masse bereit zu sein, für den Aufruf einzelner Nachrichten im Web Geld zu bezahlen. Dafür sind Nachrichten allgegenwärtig, der Zugang zu ihnen bietet keine privilegierte Erfahrung mehr.

Was waren das noch für Zeiten, als man seine Zeitung im Kiosk kaufen musste (allein schon der Weg dorthin eine Investition!) und man sie dann, das Papier unterm Arm eingerollt, in Cafés und auf der Straße zur Schau stellen durfte. Als man die Seiten genüsslich, fast theatralisch aufspannen konnte. Im vollen Bewusstsein darüber, dass dieser Text, diese gedruckten Buchstaber, Bilder und Wörter, nur auf dem Zeitungspapier Sinn und Form ergaben.

Den Zauber zurückbringen – mit gutem Design

Vor diesem Hintergrund muss die Entwurzelungen des Wortes vom Papier hin zur neonkalten Web-Seite ein Sündenfall gewesen sein: Mit dem Verlust des Papier-Privileges waren Zauber und Einzigartigkeit der Printmedien vorüber. Umso erstaunlicher nun die Renaissance: Eine gut gemachte Zeitung wirkt auf dem iPad nicht nur schick, sondern begehrenswert. Schriften, Bilder und Layout fügen sich zwanglos in den formvollendeten Rahmen. Die Navigation ist leicht und intuitiv. Das Scrollen mit dem Finger macht Spaß. Und die Interaktivität (Video, Audio, Bildergalerien) wirkt nicht aufgedrängt, sondern wie natürliche Verlängerungen. Auf dem hauchdünnen Touchscreen aus Glas sieht die Zeitung – ich traue mich fast nicht, es zu sagen – lebendiger, ja wirklichker aus als auf Papier.

Offenbar wird die Bedeutung von Design noch immer unterschätzt. Auf Projekten erlebe ich irritierte Product Owner, die nicht verstehen können, warum die Benutzer ihrer Software zur Konkurrenz wechseln wollen, weil sie deren GUI „schöner“ fänden. Aber geht es wirklich um Kosmetik, um das pure Aufhübschen und Aufbauschen? Könnte es nicht vielmehr sein, dass sich gerade dort, in ganz prosaischen Tätigkeitsfeldern wie etwa Kundenmanagement oder Abrechnung, der müde Sachbearbeiter nach einer übersichtlichen, leicht zu bedienenden und schicken Bedienung sehnt? Vielleicht könnten wir das Leben überall verbessern, wenn wir uns nur etwas mehr um besseres Design kümmern würden.

"Design is a plan for arranging elements in such a way as best to accomplish a particular purpose." Charles Eames

Related posts:

1. 5 min on Scrum | Scrum and Design
2. Design by commetee
3. Design eines großen Systems – Tom DeMarco

Scrum ist keine Rollenevolution

Die Antwort dazu muss zwangsläufig ernüchternd ausfallen. Scrum wurde nicht erfunden, um das klassischen Projektmanagement weiter zu entwickeln. Scrum versucht daher erst gar nicht, eine Kontinuität oder eine Evolution herzustellen. Von Anfang an ist Scrum als Alternative angetreten, die nicht ein UND oder ein ZUDEM, sondern ein ODER im Angebot hat. Folglich gibt es in Scrum keine natürlichen Zuordnungsmöglichkeiten: Wer behauptet, dass ein Projektleiter “am ehesten” Product Owner wird, der unterschätzt die Radikalität der Scrum-Rollen.

Manche pendeln dann direkt ins andere Extrem und behaupten, für die klassischen Rollen gäbe es in Scrum gar keine Verwendung mehr. Wer so denkt, der ist noch nicht in der Wirklichkeit angekommen: In jedem Projekt geht es doch darum, Scrum unter den jeweils aktuellen Bedingungen zu implementieren. Und diese Bedingungen sind nur im Lehrbuch die einer grünen Wiese.

EIn Beispiel

Ich habe vor kurzem mit einem Projektleiter zusammengearbeitet, der Scrum für sein Projekt einführte. Nach einigen Sprints übernahm er die Rolle des ScrumMasters. Der Product Owner kam wiederum aus dem Fachbereich. Beide Scrum-Rollen haben nie ganz richtig gesessen: Der Product Owner hatte zu wenig Produktkenntnis und konnte daher mit dem Team nicht auf der Ebene eines zweiwöchigen Sprints planen. Er hat sich mit der Zeit in die Rolle des Kunden zurückgezogen – und fühlt sich nun dort besser aufgehoben. Der ScrumMaster war anfangs sehr ungeduldig und versuchte in seiner Projektleiterrolle zunächst, das Team mit Vorschriften und Arbeitszuweisungen zu führen.

Wir haben solche Momente kritisch reflektiert. Über die Sprints gelang es dem ScrumMaster, in die Rolle des Teamsponsors zu wechseln, der nicht nur das Team beschützt (das tat er schon immer), sondern auch Freiräume ermöglicht und Entscheidungen respektiert. Als klar wurde, dass der Product Owner seine Rolle nicht ausüben konnte, spielte der ScrumMaster mit dem Gedanken, dorthin zu wechseln. Wir empfahlen ihm, ScrumMaster zu bleiben. Er hatte genügend Produktkenntnisse und wäre vermutlich ein guter Product Owner geworden. Aber sein Interesse um das Wohl und Gedeihen des Teams war bei ihm so stark ausgeprägt, dass er letztendlich selber entschied, ScrumMaster zu bleiben.

Wichtig: Perspektiven

Das oben genannte Fallbeispiel soll eines zeigen: Ob jemand für eine Scrum-Rolle geeignet ist, hängt einerseits davon ab, wie klassische Rollen gelebt werden. Ein Fachbereich mit wenig Produktkenntnis wird es schwer haben, in die Rolle des Product Owners zu kommen (was nicht heißen muss, dass man ihn nicht dorthin entwickeln kann). Und ein Projektleiter mit viel besserer Produktkenntnis ist nicht unbedingt der bessere Product Owner – entscheidend sind dann nämlich auch die Persönlichkeit und die sonstigen Fähigkeiten der einzelnen Person.

Zu Beginn spricht auch in der Tat nichts dagegen, Rollenfragen – wie hier beschrieben – pragmatisch zu lösen.  Entscheidet sich das Unternehmen jedoch, Scrum auszurollen, dann brauchen wir bessere Antworten auf die Rollenfrage. Denn die Mitarbeiter werden sich in jedem Fall die Frage stellen, wie es mit ihnen weitergeht und manche werden sich in Scrum nicht wiederfinden. Aber auch ein ScrumMaster braucht eine Perspektive: Was bedeutet meine Rolle im Unternehmen, welche Entwicklungs- und Aufstiegsmöglichkeiten habe ich? Auch formelle Strukturen wie Rollenbeschreibungen, Einstufungen und Karrierepfade sind wichtig für die Mitarbeiter, bevor sie sich langfristig für eine solche Rolle entscheiden.

Sind die Perspektiven erstmal da, kann man mit den Mitarbeitern gemeinsam herausfinden, wo sie sich am ehesten sehen und ihnen auch klar machen, wo die Organisation sie am ehesten sieht. Scrum hat enormes Begeisterungspotenzial, weil es für viele Unternehmen einen frischen, unverkrampften und oftmals subversiven Neuanfang bedeutet. Gerade in größeren Unternehmen kann Karriere jedoch nur über formale Pfade gemacht werden. Damit die Begeisterung für Scrum anhält und auch über die Pioniere hinaus wirken kann, braucht es die Anerkennung und Ausgestaltung der Scrum-Rollen im Unternehmen.

Danke an Kristina Klessmann, die mich beim Verfassen dieses Artikels unterstützt hat!

Related posts:

1. 3 + 3 Rollen in Scrum Oder doch nur 3 +1?
2. Die drei weiteren Rollen in Scrum
3. ScrumMaster can not be the Product Owner | 10 reasons

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

Unsere Mission: Ein Spiel zu entwickeln, das die Fertigungsstraße der Modellfabrik als Referenz nimmt, um agiles Arbeiten deutlich zu machen.

Probieren geht über Studieren!

Doch zuvor standen wir vor einer weit größeren Herausforderung: Die Fertigung eines Lasters  durchzuspielen, und so die Logik von strikter Arbeitsteilung, Push- und Pull-Prinzipien sowie Just-inTime-Lieferung am eigenen Leib zu erleben. Es dauerte nicht lange, da war das System schon mächtig unter Druck: Drei Fertigungsstände meldeten per Kanban-Signalkarten gleichzeitig Bedarf an Steckteilen und überforderten damit den Teilebeschaffer gnadenlos. Da hatten wir ihn: Den klassichen Bottleneck. Dass nach zehn Minuten die drei bestellten Laster im Wert mehrerer hunderttausend Euro dennoch ausgeliefert werden konnten, grenzt da schon fast an ein Wunder. Die Modellfabrik war vorerst vor dem Bankrott gerettet.

Aber zurück zur Mission. Wir hatten knappe sechs Stunden, um unser agiles Spiel vom Reißbrett auf zu entwerfen. Wir teilten uns initial in vier Gruppen auf. Der Vormittag bestand aus zwei Brainstorming-Sessions, an dessen Ende 16 Spielideen standen. Leicht entmutigt gingen wir in die Mittagspause: Wie sollte aus so vielen Ideen ein praktikables Konzept werden?

Dass wir am Ende doch noch die Kurve kriegten, verdanken wir einer Erkenntnis, die wir unseren Kunden gegenüber oft genug wiederholen: Probieren geht über Studieren! Als wir zur fortgeschrittenen Stunde dann endlich zum Spielen kamen und die Reaktionen von Teilnehmern und Beobachtern in Echtzeit sehen konnten, stieg das Vertrauen in das eigene Konzept sprunghaft an. Jetzt ging es noch um das Feintuning und die Optimierung.

Die drei Spiele, die es bis zum Schluss geschafft haben, könnten kaum verschiedener sein. Das eine Spiel heißt “Handicap” und setzt auf “blinde” und “einarmige” Teilnehmer, die nur über Kooperation einen Laster erfolgreich bauen können. Das zweite Spiel ist eine Abwandlung des Ball Point Games, in dem die Teilnehmer in Iterationen mit variabler Taktung und klarer Arbeitsteilung ausprobieren müssen, wie sie möglichst viele Laster zusammenschrauben. Das dritte Spiel schließlich setzt auf die Unterschiede zwischen Einzelgänger und Team: Lasse vier verschiedene Produkte von jeweils vier Personen alleine bauen – und mach dann das Gleiche in einem Team.

Zugegeben: Die Phase des friendly test haben unsere Spiele noch nicht überwunden. Aber Professor Komus hat seine Studenten – und wir haben unsere Scrum-Teams. Ihr dürft also auf den nächsten Beitrag gespannt sein, in dem wir Euch erzählen, wie die Spiele bei unseren ersten Probanden angekommen sind. Beim nächsten Besuch Anfang April bringen wir übrigens noch etwas mit: Wir geben dort ein ScrumMaster Advanced-Training, um den Studenten die Rolle des ScrumMasters näher zu bringen. Denn was heute noch gespielt wird, kann morgen schon berufliche Selbstverständlichkeit werden.

Related posts:

1. Fussball EM und 3 Sprints | Scrum ist überall !
2. Website | Der Wandel wird sichtbar, Notizen inklusive
3. Die Sicherheitsfrage in der Retrospektive oder der Wert eines klaren Neins

Was aber ist Führung?

Reinhard K. Sprenger zeigt in seinem Buch Radikal führen, dass Führung zum Lösen von Konflikten da ist. Was tun, wenn zwei oder mehr Handlungsalternativen da sind – und keine sich auf den ersten, zweiten oder gar dritten Blick als die eindeutig bessere entpuppt? Oft muss eine Entscheidung her. Und genau das – die Fähigkeit, in solchen Momenten Entscheidungen zu treffen und durchzusetzen – macht Führung aus.

Sprenger unterscheidet zwischen Wahl und Entscheidung. Bei einer Wahl können wir die verschiedenen Optionen auf die Waagschale legen. Wir können dann sehen, welche schwerer wiegt – wo die besseren Argumente sind. Bei einer Entscheidung ist die Ausgangslage komplett anders: Es gibt für jede Handlungsoption Argumente, aber keine Option sticht deutlich genug hervor, um die Situation entscheidbar zu machen.

Entscheiden in einer unentscheidbaren Situation: Wie lösen wir die Paradoxie?

Stellen wir uns folgende Situation vor: Ein Scrum-Team möchte nach sechs Monaten die Länge des Sprints von zwei auf drei Wochen verlängern. Es hat diesen Wunsch nun schon in mehreren Retrospektiven thematisiert und verschiedene Argumente dafür vorgebracht. Das Meinungsbild im Team ist seit mehreren Wochen unverändert geblieben.

Der ScrumMaster dieses Teams hat zumindest zwei Möglichkeiten:

• Er kann sich vor sein Team stellen, die Argumente dafür und dagegen nochmal gemeinsam reflektieren, und das Team dann entscheiden lassen. Dann spielt er die Rolle des Moderators.
• Oder er kann vorher Position beziehen und für diese in seinem Team gerade stehen. Dann übernimmt  er eine laterale Führungsrolle.

Angenommen, der ScrumMaster wählt den zweiten Weg. Seine Position ist für die Beibehaltung der zweiwöchigen Sprints – damit geht er in das Team. Da der ScrumMaster keine disziplinarische Führungkraft ist, darf er seine Entscheidung dem Team nicht einfach vorschreiben. Er muss es dazu bringen, seine Entscheidung mitzutragen.

Wichtig sind hier vor allem zwei Dinge:

1. Der ScrumMaster muss dem Team deutlich machen, warum ihm seine Position wichtig ist. Ansonsten wird das Team nicht verstehen, warum es ihm folgen soll. Das heißt im Umkehrschluss, dass ein ScrumMaster sich überlegen muss, wo er seinen Führungsanspruch geltend machen muss und wo das Team besser selber entscheidet.
2. Der ScrumMaster muss dem Team deutlich machen, dass er nicht bereit ist, ohne Weiteres von seiner Position abzuweichen. Fängt er nämlich an, beim ersten Gegenargument ins Zweifeln zu geraten und seine Meinung zu revidieren, lässt er seine Führungsrolle fallen und wird zum Mitdiskutierer auf gleicher Ebene. Das Team merkt dann, dass es sich nicht wirklich an seinem ScrumMaster reiben kann. Standhaftigkeit ist aber nicht mit Sturheit zu verwechseln. Deshalb sollte der ScrumMaster seine Position so vermitteln, dass sie dem Team zugleich eine Perspektive bietet: Was muss alles getan werden, damit zweiwöchige Sprints besser werden? Damit die Skepsis des Teams verschwindet? Und wie kann der ScrumMaster als Servant Leader dabei helfen? Eventuell ergibt sich dann sogar eine Kompromisslösung. Zum Beispiel: Zweiwöchige Sprints ja, aber dafür Commitment auf weniger Stories, die dann dafür wirklich fertiggestellt werden.

Für den ScrumMaster ist die Situation eine Probe seiner Autorität: Wenn das Team seine laterale Führungsrolle anerkennt, wird es ihm letztlich folgen. Wenn es das nicht tut, wird es seiner ursprünglichen Überzeugung folgen und damit dem ScrumMaster signalisieren: “Du gibst uns nicht den Weg vor.”

So gesehen hat der ScrumMaster für sein Team eine Ankerfunktion: Er markiert Positionen als unverrückbar und setzt damit dem Team Handlungsgrenzen. Diese Grenzsetzung darf ruhig Irritation auslösen und konträr zum Team stehen. Negativ wird Führung erst dann, wenn sie die Entwicklung des Team einschränkt. Dann wird der ScrumMaster zum Impediment – und sollte besser gehen.

Keine Führung  (und das ist unter ScrumMaster die weitaus häufigere Situation) kann aber ebenso verheerend sein. Denn ein ScrumMaster, der immer nur sein Team entscheiden lässt, mag zwar jede Menge von Scrum verstehen – sein Team wird er damit nicht wirklich befruchten können. Denn Meister kann nur sein, wer die Gefolgschaft eines Lehrlings für sich gewinnen kann.

Reinhard K. Sprenger 2012: Radikal führen. Campus Verlag.

Siehe auch:

Der ScrumMaster, der besser keiner sein sollte

Führung selbstorganisierter Teams – alte Theorie vs. Scrum

Related posts:

1. Führung in Scrum | Manager | Teil 4
2. Führung in Scrum | der Manager | Teil 1
3. Führung in Scrum | der Manager | Verhalten | Teil 2