Video: Große Projekte mit Scrum?

Lassen sich große Projekte mit Scrum verwirklichen? Natürlich. Beweise und Case Studies dazu gibt es mittlerweile genug. Aber einen Framework zu nutzen und als “scaled” oder “skaliert” zu bezeichnen, ist nicht genug. Es mag zwar ein guter Marketing-Schachzug sein, ich halte es jedoch einfach für unlauter, zu behaupten, dass es einen skalierten Management-Framework geben könnte. Skalierung braucht mehr.
In diesem Video erkläre ich euch in groben Zügen, was notwendig ist, um das große Projekte oder die große Organisation agil zu führen und erfolgreich ein Produkt zu liefern. Mehr dazu findet ihr in meinem neuen Buch “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen”
 
Viel Spaß beim Anschauen – Boris
 

5 min on Scaling – Vorsicht vor standardisierenden Modellen

In seiner wundervollen Präsentation „Why is Agile failing in large enterprises“ zeigt Mike Cottmeyer, dass drei Grundannahmen dabei helfen, die agile Enterprise zu etablieren:

Damit man diese Hypothesen umsetzen kann, definiert er dann im Anschluss eine agile Organisation, die im Kern aus Teams auf vier Ebenen besteht:

Ja, ich teile die Behauptung, dass man Service Teams und Product Teams in großen Organisationen unterscheiden sollte. Die Product Teams sind dann die Stakeholder der Service Teams. Je mehr ich darüber nachdenke, werden bei mir aus den “!” aber einige große “?”. Mikes Framework mit Program Teams und Portfolio Teams muss ich entgegenhalten, dass hier eine hierarchische und von oben nach unten tröpfelnde Kette von Inhalten (Anforderungen, Constraints) etabliert wird.
Der beschriebene Ansatz, der auch Kern des Scaled Agile Framework ist, ist auf den ersten Blick erfolgreich. Doch macht er aus sich selbst organisierenden, eigenverantwortlich arbeitenden Teams eine Scrum-Maschine. Scrum-Teams waren anders gemeint: Sie stellen eine Organisation dar, die ähnlich wie eine Verbindung aus Business Units funktioniert. Die agile Organisation so wie beschrieben zu strukturieren, zerstört den Kern von Scrum und Agilität.
Es hat mit dem, was hinter Scrum steckt und mit dem Agile Manifesto einmal definiert wurde, leider nicht mehr viel zu tun. Nonaka, Ken, Jeff und ich – wir gingen davon aus, dass die Product Teams (so wie schon bei Skunk Works und im berühmten Artikel von Nonaka – “The New New Product Development Game” beschrieben) selbständig darüber nachdenken, was sie liefern. Das führt zur Schlussfolgerung, dass die Product Scrum Teams tatsächlich selbst die Anforderungen definieren. Selbständig, weil sie cross-funktional Lösungen für die Probleme der Kunden/User liefern. Die Scrum-Teams schaffen also eigenverantwortlich einen Wert für ein Unternehmen.
Ich verstehe den Impuls, dass man von oben her denken will. Aber Scrum war und ist immer von der Kernidee der eigenverantwortlichen und sich selbst auf das Ziel ausrichtenden, cross-funktionalen Teams getrieben, denen man einen Management-Framework zur Unterstützung gibt. 
Skalierung so verstanden lässt den Teams den Raum, sich zu organisieren – sogar wenn es um 300 oder 1000 Teammitglieder gibt. Modelle wie dieses finden sich NICHT in den Büchern der derzeit modernen agilen Coaches, sondern in den Ideen aus der Organisationsentwicklung der letzen 20 Jahre. Es gibt Modelle wie die Open Space Technologie, die viel besser geeignet sind, wirklich große Projekte zu steuern, wie z.B. Harrison Owen schon mehrfach bewiesen hat. Mit diesen Management-Methoden, die man um Scrum herum aufstellen kann, lassen sich große Organisationen steuern – dann sind große SAP-Implementierungen, Data-Warehouse-Entwicklungen, medizintechnische Produkte oder andere Hardware-Entwicklungen genauso einfach mit agilen Methoden umzusetzen, wie es heute schon bei großen Software-Development-Projekten passiert.
Wer darüber mehr wissen will – wir haben ein neues Training dazu:
Scrum international – verteilt, skaliert und multikulti

How to organise a ScrumMaster Team in a large-scale environment?!

Late in the evening at the XP2013 in Vienna, I hosted an open space session under this title and am still surprised at how many participants actually joined me in discussion. It seems that I was not the only one faced with this question. While the session did not provide me with the sought-after perfect solution, it did give me an insight into how other companies structure the collaboration between individual ScrumMasters in order to act as a singular, strong force of change agents.
 
Here are some of the options that came up in conversation and that I can relate to due to having experienced them myself. Of course, these options may vary accordingly.
 

  • Meet on a weekly basis to talk about lessons learned when solving impediments and best practices in Scrum.
  • Meet on a daily basis in front of a ScrumMaster Taskboard (Impediment Backlog) to talk about current impediments and their progress.
  • Form a Scrum-Team and work in Sprints. If necessary, appoint your own ScrumMaster and Product Owner. Hold Backlog Groomings for identifying and prioritising general organisational impediments, Sprint Planning meetings for discussing the ‘What‘ followed by the ‘How‘, and Daily Scrums for synchronising your work. Make sure to finish each Sprint with a public Review and a Retrospective. Hint: Facilitating these meetings in a rotating manner can offer the ScrumMasters a chance to practice and learn new facilitation methods in a safe environment (i.e. different Sprint Retrospective styles).

 
In the end, however, I do not think that there is a right or a wrong answer. The only question that really matters is whether the Scrum-Teams are delivering valuable features or not. And if they aren‘t, the impediments hindering their productivity must be addressed and solved as quickly as possible. I do believe that a Team of like-minded persons with the same mission can achieve more than singular change agents. Once the ScrumMasters understand this for themselves, I am convinced that the right ‘how to‘ will come automatically. And this will probably differ depending on the persons involved and their specific system.

ScrumMaster schützen den Prozess oder warum klein(st)e Veränderungen Applaus bekommen

„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:

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.

Can't get there from here: Stolpersteine in Transition Teams

Wer glaubt, Scrum zu machen, steht gerade erst am Anfang. Früher sind Scrum-Implementierungen mit dem erfolgreichen Aufsetzen von Teams zu Ende gegangen. Dieser Ansatz griff allerdings zu kurz. Denn Scrum erzeugt Transparenz. Und die Probleme, die einer besseren Produktentwicklung im Wege stehen, sind selten den Scrum-Teams alleine geschuldet.
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

Sagen Sie jetzt nichts: Ich bin Company ScrumMaster

Seit mehr als einem Jahr setzt der E-Postbrief Scrum ein, verteilt auf die zwei Standorte Bonn und Berlin. Ich spreche heute mit Jens. Jens hat nach einem Jahr als ScrumMaster die Rolle des CompanyScrumMasters am Standort Bonn übernommen. Er steht uns gerne für die Schilderungen seiner Erfahrungen mit Scrum zur Verfügung, bevor es wieder heißt: Sagen Sie jetzt nichts.


Hallo Jens, wie ist es dazu gekommen, dass du die Rolle des Company ScrumMasters ausführst?
Als die Rolle durch den Weggang eines Kollegen frei wurde, war mir zunächst nur klar, dass jemand aus dem Kreis der ScrumMaster diese Rolle nachbesetzen sollte. Dann wurde ich mir allmählich der großartigen Möglichkeiten bewusst, die die Rolle bietet, und wollte selbst Company ScrumMaster werden.
 
Was sind deine Verantwortungen als Company ScrumMaster?
Ich fühle mich für ein funktionierendes ScrumMaster-Team und eine sich stetig verbessernde agile Produktentwicklung verantwortlich.
 
Warum braucht es überhaupt einen Company ScrumMaster?
So wie ein Team von einem ScrumMaster profitiert, der unterstützt und beschützt, moderiert und hilft, die Produktivität zu verbessern, so kann eine Scrum-Organisation auch von einem Company ScrumMaster profitieren.
 

Nehmen dich die Menschen anders wahr, seitdem du Company ScrumMaster bist? Und wenn ja, wie und woran machst du das fest?
Ja, ich habe den Eindruck anders wahrgenommen zu werden. Scherzhaft sieht man das zum Beispiel an der einen oder andere Andeutung eines militärischen Grußes auf unseren Fluren. Ich wurde auch in Reviews schon mit Adelstiteln und Vergleichbarem begrüßt. Auf der ernsten Seite stelle ich aber auch fest, dass mich die Kollegen in der neuen Rolle mehr in Anspruch nehmen und bereits angefangen haben, mich beispielsweise als Schnittstelle zu begreifen.
 
Wie nimmst du dich selber seither wahr? Hat sich in deinem Denken und Handeln etwas verändert?
Meine Wahrnehmung und mein Gesamtblick haben sich geweitet. Ich spüre eine größere Verantwortung für die Entwicklung unserer Organisation. Es geht mir immer noch darum, dass das Team Performance abliefert und sich stetig verbessert. Aber “das Team” ist jetzt das ScrumMaster-Team und somit geht es mir nun auch um die gesamte agile Produktentwicklung.
 
Was ist grundsätzlich anders als vorher als ScrumMaster? Musst du jetzt z. B. länger/kürzer arbeiten?
Ich arbeite länger, weil es soooo viel zu tun gibt. Bisher habe ich aber auch noch ein Scrum-Team betreut – was ein schlechter Kompromiss zu Lasten des Scrum-Teams war. Fortan wird sich ein anderer Kollege um das Team kümmern, sodass ich mich vollends der neuen Rolle und somit dem ScrumMaster-Team sowie der Verbesserung der agilen Organisation widmen kann. Zusammen mit der reifenden Klarheit über meine Handlungsfelder und Prioritäten will ich auf diesem Wege wieder zu verträglichen Arbeitszeiten zurückkehren.
 
Was ist dein derzeit größtes Impediment?
Ein ScrumMaster-Team, das auf zwei Standorte verteilt und noch kein echtes Team ist. Ich habe den Eindruck, dass wir uns in der Kommunikation untereinander schwer tun und unsere Diversität noch nicht nutzbringend einsetzen.
 
Was hat dir besser gefallen: ScrumMaster sein oder Company ScrumMaster sein?
Am ScrumMaster-Dasein gefielen mir die Nähe zum Team und die kurzen Feedbackzyklen, die schnell zeigten, ob etwas funktioniert oder nicht. Als Company ScrumMaster hingegen haben sich nun Team, Aufgaben und damit Verantwortungen signifikant verändert. Der Einflussbereich ist größer geworden und der Feedbackzyklus wurde dadurch auch (zumindest gefühlt) länger. Aber die neuen Möglichkeiten, die ich nun habe und die Dinge, die ich dazulernen kann, begeistern mich auf jeden Fall noch mehr.
 
Was kannst du durch deine neue Rolle jetzt besser beeinflussen, um die Organisation besser, produktiver, agiler zu machen?
Ich kann die Meinung und Ansichten des ScrumMaster-Teams in Gremien vertreten, die nicht gewohnt oder in der Lage sind, mit einem Team von Change Agents zusammenzuarbeiten. Kollegen, die eher mit hierarchischen Strukturen vertraut sind, kann ich als “Chef” der ScrumMaster besser erreichen, auch wenn ich gar kein Chef bin. Durch diese Schnittstellenfunktion kann ich auch meine ScrumMaster-Kollegen entlasten.
 
Wo siehst du bei dir die größten Potentiale auf dem Weg noch besser zu werden?
Ich strebe danach, dass es mir noch besser gelingt, einen Status Quo zu hinterfragen und eine Gruppe so zu Verbesserungen anzuregen. Dabei wünsche ich mir auch eine bessere Fähigkeit, durch Moderation Gruppen schnell zu guten Ergebnissen zu führen.
 
Als Company ScrumMaster bist du fester Bestandteil des ScrumMaster-Teams. Du führst es. Wie machst du das? Wie führst du? Bist du so etwas wie ein „Primus inter pares“ (Erster unter Gleichen)?
Da wir ein Team von Kollegen mit zum Teil sehr unterschiedlichen Hintergründen und Erfahrung sind, fokussiere ich mich darauf, die Kommunikation untereinander zu fördern und gemeinsame Sichten auf Dinge herzustellen. Dabei versuche ich meine Ansichten so oft wie möglich als Gleicher unter Gleichen einzubringen.
 
Quis custodiet custodes – wer bewacht die Wächter? Wachst du über die ScrumMaster? Und wer bewacht dich?
Ich hoffe, dass ich von allen Kollegen um mich herum offenes und ehrliches Feedback zu meiner Arbeit erhalte, das mich dann in die Lage versetzt, mein Handeln auch mit Hilfe externer Eindrücke zu reflektieren, zu verändern und hoffentlich dann auch im Sinne der Organisation zu verbessern.
 
Angenommen, du hättest einen Wunsch frei für dein Tun als Company ScrumMaster? Was wünschst du dir am allermeisten?
Ich wünsche mir mehr Geschlossenheit und Einigkeit im ScrumMaster-Team, sodass man uns auch als die wirkungsvolle Einheit wahrnimmt, die wir sein wollen. Damit meine ich nicht die Einigkeit mit totalitären Zügen, die man von einer kommunistischen Partei erwartet, sondern regen und offenen Austausch untereinander und die Bildung einer Teammeinung zu Themen, die uns umtreiben.
 
 
1. Company ScrumMaster sein: Ist das stressig?
 

 
 
2. Deine Antwort auf: “Früher war alles besser!”
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
3. Scrum finde ich …
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4. Der E-Postbrief ist …
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
5. Wenn du einen Company ScrumMaster malen müsstest, wie würde er aussehen?
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
6. Dein Anti-Stress-Rezept?
 

 
 
 

Sed quis custodiet ipsos custodes oder braucht es einen Company ScrumMaster?

Die lateinische Frage “Sed quis custodiet ipsos custodes” heißt übersetzt: “Aber wer bewacht die Wächter?” Die von Juvenal, einem römischen Satiriker (58 – 140), aufgeworfene Frage trifft den Nagel auf den Kopf, wenn man nach der Berechtigung der Rolle des Company ScrumMasters (CSM) fragt. Aber was ist ein Company ScrumMaster überhaupt? Was unterscheidet ihn von einem ScrumMaster? Wann braucht es ihn? Wie wird man CSM? Was sind seine Aufgaben, welche Verantwortung trägt er? Fragen über Fragen zu einer Rolle, die auf dem Weg zu einer agilen Organisation eine wegweisende Handschrift zu hinterlassen vermag.
 
Der Company ScrumMaster, der ScrumMaster der ScrumMaster, füllt eine Rolle aus, die im skalierten Scrum-Umfeld eine Schlüsselfigur ist, wenn man sich entscheidet, sie zu etablieren. Einen Company ScrumMaster einzusetzen ist kein Muss. Steigt jedoch die Anzahl der Scrum-Teams und damit auch die der ScrumMaster, dann wird nicht nur ein regelmäßiger Informationsaustausch zu Abhängigkeiten und Impediments nötig, sondern die steigende Komplexität der Themen verlangt nach Struktur und einer Sicht von “oben”. Der CSM ist demnach eine logische Konsequenz und ein Instrument, Komplexität zielgerichtet und werteorientiert zu reduzieren.

Die Verantwortung des Company ScrumMasters

Ein Company ScrumMaster führt die ScrumMaster. Idealerweise tut er dies genauso wie ScrumMaster ihre Entwicklungsteams führen, nämlich lateral, also ohne Befehlsgewalt und mit der klaren Verantwortung, die Produktivität seines Teams kontinuierlich zu steigern. Unter der Produktivität des ScrumMaster-Teams verstehe ich, dass die ScrumMaster im Verbund agieren und auf der Grundlage gemeinsamer Ziele und Werte das agile Mindset in ihre Teams tragen und die Organisationskultur nachhaltig beeinflussen. In seiner Verantwortung tritt der CSM wie ein Nant`an auf. Er ist der kulturelle Führer der ScrumMaster, dem die ScrumMaster folgen, weil sie es von sich aus wollen, nicht weil man es ihnen vorschreibt. Bei den Apachen war dies ähnlich. Jeder traf die Entscheidung für sich selbst, dem Nant‘an zu folgen oder auch nicht. Interessanterweise gibt es in der Sprache der Apachen nicht einmal ein sprachliches Äquivalent zu „du musst“. Zwang ist in der Kultur der Apachen ein unbekanntes Handlungskonzept.
 
Ein Company ScrumMaster sollte, nicht zuletzt aus besagter Verantwortung, wenn möglich kein ehemaliger Vorgesetzter aus einer Linienverantwortung sein. Vielmehr sollte er sich aus der Gruppe der ScrumMaster aufgrund seiner Leistung, seines Ansehens, seiner Erfahrung, seines Einflusses herausheben. Es sollte auf der Hand liegen, wer für diese Rolle in Frage kommt und die ScrumMaster sollten ihn wählen oder zumindest ein Mitspracherecht dabei haben, wer zukünftig diese Verantwortung tragen soll. Gegen die Variante, dass der Company ScrumMaster aus den eigenen Reihen kommt, spräche, dass er dann der Prophet im eigenen Haus ist. Das kann ein Hindernis sein, muss aber nicht. Was ich empfehle ist, die Rolle des CSM keinem Rotationsmodus zu unterwerfen, d.h. jeder darf mal Company ScrumMaster sein.
Noch ein weiterer Aspekt ist mir im Zusammenhang mit der Verantwortung des CSM wichtig: Sollte es sich die Organisation leisten können und eine ausreichende Anzahl an ScrumMastern verfügbar haben, dann empfehle ich, dass der Company ScrumMaster (nur) die Verantwortung über ein Team hat, nämlich über das Team der ScrumMaster.

Was macht ein Company ScrumMaster den lieben langen Tag?

Eine wesentliche Herausforderung des Company ScrumMasters ist es, dafür Sorge zu tragen, dass die ScrumMaster motiviert sind, weil ihre Arbeit wichtig und sinnvoll ist. Ihr fragt euch jetzt vielleicht, was wichtiger als wichtig sein kann. Ich möchte hier als Antwort Ken Blanchards und Sheldon Bowles Gedanken aus ihrem Buch Gung Ho! anführen. Die beiden Autoren sehen dreierlei als beachtenswert:

  • Die zu erledigende Arbeit muss als wichtig empfunden werden.
  • Sie muss zu einem gemeinsamen Ziel führen, das für alle verständlich ist.
  • Bestimmte Wertvorstellungen müssen das Fundament aller Pläne, Entscheidungen und daraus resultierender Handlungen sein.

Kommen diese drei Aspekte zusammen, dann kann man von einer Arbeit sprechen, die das Prädikat “sinnvoll” verdient (vgl. Blanchard & Bowles, S. 40). Damit der Company ScrumMaster diesbezüglich seine Handschrift hinterlassen kann, sollte er herausfinden, in welche Richtung seine ScrumMaster (mit ihren eigenen Zielen und Werten) tendieren und sich dann an ihre Spitze setzen, um gemeinsam auf zwei Zielvorstellungen hinzuarbeiten:

  1. Es muss klar sein, was das ScrumMaster-Team erreichen will (angestrebte Ergebnisse).
  2. Es muss klar sein, was das ScrumMaster-Team für die Entwicklungsteams und die Organisation erreichen will (angestrebte Werte).

Der Company ScrumMaster schafft hierfür die Voraussetzungen und ist Navigator für die ScrumMaster. Er lenkt, er moderiert, er regt an, er hinterfragt, er führt (lateral). Dies tut er auf zwei Ebenen, mit jedem einzelnen ScrumMaster und mit dem ScrumMaster-Team.

Company ScrumMaster ist ScrumMaster auf zwei Ebenen

Im Verhältnis Company ScrumMaster – ScrumMaster agiert der CSM als Mentor. Er ist Ansprechpartner auf Augenhöhe. Er coacht den ScrumMaster und dient ihm als Sparringpartner, als Spiegel, als schlechtes Gewissen, als Challenger. Er entwickelt den ScrumMaster in seinen Fähigkeiten als Meeting Facilitator und Servant Leader. Hierbei zeichnet sich der CSM besonders dadurch aus, dass er durch sein Handeln in der Lage ist, den Unterschied zu machen. Im Verhältnis Company ScrumMaster – ScrumMaster-Team versteht sich die Rolle des CSM als ScrumMaster. Er führt sein Team ohne den Anspruch auf Autorität. Der Fokus seines Tuns liegt hierbei auf der Wertearbeit (Werte dienen meines Erachtens dazu, eigenes Handeln zu bestimmen und nicht, Handeln dogmatisch vorzuschreiben). Auf dieser Grundlage sollen Ideen umgesetzt werde, die u.a. die Reputation der Rolle “ScrumMaster” in der Organisation stärken, damit diese einen wesentlichen Beitrag leisten kann, die Kultur des Unternehmens beeinflussen zu können. Darüber hinaus ist der CSM kontinuierlich darum bemüht, zu den übrigen Keyplayern im agilen Miteinander, Product Owner (Team) und Management, einen engen Kontakt zu pflegen. Er ist in seiner Rolle der Anführer der Change Agents und setzt sich für die agilen Werte in der Organisation ein.

Braucht es einen Company ScrumMaster wirklich? Und wenn ja, ab wann?

Auf diese Fragen gibt es keine richtigen oder falschen Antworten. Es kommt vielmehr auf die jeweilige Situation an. Ab einem bestimmten Grad an Komplexität halte ich eine laterale Führung der ScrumMaster für essentiell. Hierbei geht es mir weniger um Kontrolle oder, wie es der Titel verstehen lassen könnte, Überwachung. Vielmehr soll die Instanz eines Company ScrumMasters die Chance bieten, aus den Ressourcen einer Adlerperspektive das eigene Handeln anders, neu zu betrachten – eine zweite Meinung zu erhalten. Bei zwei ScrumMastern braucht es sicher noch keinen CSM. Da lassen sich Prozesse etablieren, die ein regelmäßiges und gegenseitiges Feedback mit sich bringen. Sobald ein dritter ScrumMaster auf die Bühne tritt, sollte man zumindest die Optionen “Wer bewacht die Wächter” oder “bewachen wir uns untereinander” gegeneinander abwägen und/oder beide Varianten über einige Sprints ausprobieren.
 
Aber vielleicht fragen wir einfach einen aktiven Company ScrumMaster nach seiner Meinung.
Beim nächsten Mal: Interview mit einem Company ScrumMaster.
 
Literatur
K. Blanchard & S. Bowles (2012). Gung Ho! Wie Sie jedes Team in Höchstform bringen. rororo.

Dealing with organizational debt

In a blog post he wrote last year on “The organizational debt“, Fabian Schiller discusses the flaws in organizations. He reasons from an interesting point of view, as he compares organizational debt to technical debt.
Technical debt is something done wrong within an application – at the start, it might only seem like a small issue, but this problem will in fact continue creeping deeper into the system, while the negative impact will slowly but gradually start surfacing. Fabian Schiller believes that organizational debt, such as bad rules, wrong decision-making or a warped strategic direction could lead to similar kinds of problems on an organizational level. In this case, even small decisions that point in the wrong direction could turn into a reinforcing system that will collect a rapidly increasing amount of debt. This may lead to a situation where – over time – the impact of small decisions could overrule that of more important decisions.
Now, some people in the organization might react by saying, “This sounds like the time for drastic change – with a few good, but strong decisions we might be able to fix our organizational debt.” Sorry, but I don’t think that this is a good idea. I generally don’t doubt that drastic decisions can succeed, but I do believe that there is a better way for tackling this issue.
I want to stick to Schiller’s comparison with technical debt. In big legacy systems, we are very concerned about change, as we fear not being able to foresee the outcome. We never know the system as a whole and often we can’t even begin to imagine what kind of errors might be introduced with change. A very simple and effective way of changing something in this case is to test the waters step by step – making small changes on the way, improving things a little, and then re-visiting them every time. With that sort of discipline, we might not change the world within a few days, but we keep improving on a daily basis. Plan, Do, Check, Adapt. At the beginning, such small steps might drive you mad – the reason for that being that most people are so impatient. But from the bottom of my heart, I do believe that persistency can succeed.
As I’m thinking about small and big changes, I have another point in mind: What if our changes for the better actually lead us in the wrong direction. Well, we won’t know until we try and then prove it. In software development, we often only make small changes, so we are aware of the cause of change. When I said “until we prove it”, I meant that we have to check our results. We have to check whether our initiated change actually led to the intended result or not. In order to be able to check the result, we need something that will show the new, emerging effects. Furthermore, we need something which will enable us to get an overall picture of the coherences. This is exactly what we do in software development. Here, we simply call it Scrum!
If you want to let yourself be inspired by one aspect from this blog to ponder about for the next 30 days, please let it be this: “Make everything a little bit better, over and over again”.

Einen Schritt aus dem Moloch heraus

Hochproduktive Teams

Das Ziel von Scrum sind hochproduktive Teams. Doch wie sieht ein hochproduktives Team aus? Wie wird es zusammengestellt, und wie organisiert es sich selbst? Welche Verantwortlichkeiten hat es, und woran erkennt man ein erfolgreiches Scrum-Team? Und ist Scrum möglicherweise der Anfang vom Ende der Arbeitsteilung in Software-Entwicklungsteams?
Ein Scrum-Team ist ein Produkt-Entwicklungsteam. Es hat die Aufgabe, ein Produkt zu liefern, nicht nur Code. Natürlich liefert das Team auch die Software. In den meisten Fällen benötigt man aber weit mehr für die Erstellung eines Produktes als nur die Software. Die Teammitglieder sind in Scrum im Rahmen ihrer Möglichkeiten für alles, was für die Produkterstellung zu tun ist, selbst verantwortlich. Ein Scrum-Team besteht also aus den Personen, die die Kenntnisse haben, um das Produkt in seiner Gesamtheit zu liefern. Jedes Mitglied eines hochproduktiven Teams übernimmt die Verantwortung für das Gelingen des Projektes. Teams haben die Verpflichtung zu liefern, was sie sich selbst vornehmen. Jedes einzelne Teammitglied ist für seine Leistung im Team verantwortlich, und gemeinsam sind alle dafür verantwortlich, das Versprechen, das sie als Team gegeben haben, zu halten.
Zusammenarbeit in einem Scrum-Team ist nicht das Ende der Arbeitsteilung, sondern bringt zusammen, was zusammengehört. Statt entlang der Aufbauorganisation arbeiten Menschen in Scrum horizontal entlang der Wertschöpfungskette des Unternehmens. Sie arbeiten mit ihren Fähigkeiten als Spezialisten zusammen und über ihre enge Zusammenarbeit entwickeln sie gemeinsam Talente im Team, auch außerhalb ihrer Spezialfähigkeit.

System Teams versus Feature Teams

Teams sollten immer nach Funktionalitäten oder Produktteilen aufgestellt werden. Scrum-Teams sollten Produkte oder Applikationen liefern, nicht nur sogenannte Basis-Komponenten (technisch notwendige Aspekte des Systems, die nur für andere Entwickler bedeutsam ist). Wenn wir gewachsene Unternehmen betrachten, stoßen wir immer wieder auf Systemlandschaften, die sich entlang ihrer Aufbauorganisation entwickelt haben. Hier ist die Suche nach einem Produkt mitunter nicht ganz so einfach.
Ein Tipp: Suchen Sie Ihren Kunden, dann finden Sie auch Ihr Produkt. Ihr Kunde sollte sich außerhalb Ihres Unternehmens befinden und nicht die selbst erstellten Bedürfnisse befriedigen. Suchen Sie den Kunden am echten Markt, nicht am internen.
Wie gesagt, starten wir in einem gesamten IT-Bereich mit dem agilen Vorgehen, dann sieht die Lage oft anders aus. Wir treffen auf Kopfmonopole, komplexe Systeme mit großen Abhängigkeiten, mittelmäßigen bis schlechten Code und alles hat sich über Jahre hinweg aufgebaut.
Aus dieser verstrickten Lage kommen wir nicht mit einem Schritt alleine heraus! Wir müssen uns Schritt für Schritt einen Weg aus dem Moloch herausbahnen.

Schritt für Schritt

Zentrale Aspekte bei einer agilen Transition sind der Aufbau von Zusammenarbeit und Entscheidungen im Konfliktfall, klare Führungsaufgaben. An dieser Stelle wird auch schnell klar, warum eine Unterstützung aus dem Management notwendig ist. Kommen wir zurück zu unserem eingangs erwähnten Beispiel für hochproduktive Teams, anhand eines Feature-Teams:
In einer Organisation kann oder soll die Zusammensetzung der Teams nicht sofort komplett umgestellt werden, um cross-funktionale Teams zu erzeugen. Es werden also nicht die Menschen zusammengebracht, die schon gemeinsam, allerdings in verschiedenen Teams, die Produkte erzeugen. Wenn das nicht von Anfang an gelingt, dann darf man nicht den Kopf in den Sand stecken, sondern muss die Reise beginnen lassen. Gehen wir den ersten Schritt: Wir stärken die Zusammenarbeit und den Wissenstransfer im Team und bringen die Menschen zusammen, die einen gemeinsamen Auftrag haben, auch wenn sie ihn noch nicht gemeinsam wahrnehmen können. Wie gesagt, ein Schritt.
Ein weiterer, kleiner Schritt auf dem Weg in die für uns richtige Richtung wäre folgender: Okay, wir entwickeln eine Komponente, aber wenn schon, dann auch richtig. Unseren Teil des Features haben wir fertiggestellt und getestet bis zur Schnittstelle (mit oder ohne Versionierung, je nach Unternehmensstandard) und richtig fertig, ohne Kompromisse.

Die Demut der kleinen Schritte

Wir können nicht alles sofort umkrempeln und blitzend machen, das verbietet uns schon allein die Demut. Ein Unternehmen ist gewachsen, komplex und ist nicht reduzierbar auf Ursache-/Wirkungsprinzipien. Vielmehr arbeiten wir anhand eines empirischen Prozesses, bei dem wir unsere Erwartungen kenntlich machen und dann nach kurzer Zeit messen, ob das Erwartete eingetreten ist (inspect & adapt). So lässt sich zum einen messen, ob wir mit dem nächstmöglichen Schritt, der nächsten Schraube, an der gedreht wurde, das Gewünschte erreicht haben. Wenn nicht, dann gehen wir einen Schritt zur Seite, schräg nach vorne oder auch einen Schritt zurück.
Wenn wir begreifen, dass wir als Menschen nicht unfehlbar sind und nicht unsere Würde an unsere Entscheidungen hängen, dann haben wir die Chance, kleine Schritte zu gehen und uns selbst am eigenen Schopf aus dem Moloch herauszuziehen. Dafür müssen wir akzeptieren, dass wir nicht alles kontrollieren können, sondern wir müssen vertrauen, loslassen und genau das kontrollieren, was kritisch für das gesamte Unternehmen wird.

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

Am Anfang einer Scrum-Implementierung stellt man ein spezielles Team auf, um die Transition zu unterstützen. Dieses sogenannte Transition Team arbeitet ein priorisiertes Transition Backlog ab, beseitigt Impediments, initiiert und begleitet alle notwendigen Veränderungen, die für die Implementierung von Scrum in einem skalierten Umfeld notwendig sind.
Das Transition Backlog ist eine Kombination aus Impediments, Pilotprojekten und Maßnahmen. Es enthält für die Umsetzungsreihenfolge priorisierte Ziele, Aktivitäten und Probleme.
Beispiele für Backlog Items:

Um einen optimalen Rahmen zu schaffen, soll das Transition Team Sicherheit geben bzw. die Angst vor Veränderung reduzieren. Es muss jedem die Chance geben mitzumachen und damit den größten Erfolg zu sichern.
Hier ein paar einfache Grundprinzipien:

Die Zusammenstellung der Transition Teams selbst kann Probleme auflösen. Es ist wichtig, dass ihr euch Zeit nehmt, um euch kennenzulernen. Damit ihr in diesem neuen Gefüge feststellt, wie ihr als Team agieren wollt und könnt. Dass ihr euch wirklich einen Vertrauensrahmen aufbaut und die verschiedenen Sichtweisen und Erwartungen aufnehmt. Die erste Aufgabe ist, gemeinsam die Ziele festzulegen. Man vergisst manchmal, dass eine Veränderung einen Zweck hat und dass die Methode z.B. Scrum NUR Mittel zum Zweck ist.