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

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

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?

Related posts:

1. Der ScrumMaster: Status, Position, Rolle
2. Einzelkämpfer ScrumMaster? Herausforderungen als ScrumMaster-Team gemeinsam meistern / Teil 1 / Dieter Rösner
3. “How long does it take to become excellent?” — “A minute!”

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.

Related posts:

1. Kaiserlautern hat 32 neu Certified ScrumMaster
2. Führung in Scrum | der Manager | Verhalten | Teil 2
3. “How long does it take to become excellent?” — “A minute!”

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”.

Related posts:

1. The Toyota Production System and Scrum (1)
2. Agile People – Right Brain
3. Lean, Lean, Lean — Lean is dead — I cannot bear it any longer!

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.

Related posts:

1. Bug Fixing
2. Christbaumschmücken Advanced
3. Wir leiden an Selbstüberschätzung – und das ist auch gut so!

Geht es bei Scrum wirklich um Software-Entwicklung? Kann es das richtige Ziel sein, ein einzelnes Entwicklungs-Team produktiv zu machen? Dreht sich die Einführung eines agilen Mindsets in einem Unternehmen tatsächlich um technische Praktiken und Management-Frameworks?

Nein! Das alles greift viel zu kurz.

Immer wieder höre ich von Managern den Wunsch: „Wir müssen effizienter werden.“ Dahinter steckt oft der klassische Ansatz der lokalen Optimierung. Wenn nur jeder Bereich, jede Abteilung, jedes Team und jeder Mitarbeiter maximal ausgelastet sei, dann würden unsere Projekte auch schneller fertig.

Immer wieder höre ich von Managern die Aussage: „Die Entwicklung muss eine bessere Qualität liefern. Das Anforderungsmanagement muss bei uns vorgelagert sein. Der Betrieb ist sowieso voll ausgelastet, da die Software nie richtig funktioniert.“ Auch hier wird die Software-Entwicklung als zentraler Schuldiger gesehen, durch den die Probleme in der restlichen Organisation verursacht würden.

Was geschieht nun im Regelfall nach einer erfolgreichen Einführung von Scrum und agilen Entwicklungsmethoden? Die beteiligten Manager erkennen nach kürzester Zeit, dass die Probleme in der restlichen Organisation nicht verschwinden, obwohl die Entwicklung funktionierende Software schneller und in besserer Qualität liefert.

Scrum hat die Macht, die wahren Probleme einer Organisation sehr schnell offenzulegen! Und diese Offenlegung geschieht eben auch an den Schnittstellen der Entwicklungsteams in andere Bereiche. Damit erkennen wir die Kommunikationsschwierigkeiten zwischen allen Beteiligten am Produktentstehungsprozess. Produktmanager haben vielleicht noch nie mit Administratoren gesprochen, Verkäufer noch nie mit Testern, Entwickler noch nie wirklich mit dem Support. Aber all diese Mitarbeiter mit ihren unterschiedlichen Verantwortungen müssen gemeinsam daran arbeiten, den „Wow!“-Effekt für Kunden und Anwender zu erzeugen!

Durch die reine Optimierung unserer Entwicklungsmannschaft werden wir es nicht schaffen, den Anwender signifikant zu begeistern. Nur durch das Zusammenspiel aller Beteiligten können wir ein Produkt, eine Dienstleistung erzeugen, die der Anwender wirklich haben möchte.

Was müssen wir also tun, um ein erfolgreiches Scrum-Unternehmen zu transformieren?

Eigentlich ganz einfach: die Scrum-Teams müssen cross-funktional mit Beteiligten aus allen Unternehmensbereichen besetzt werden, die zur Erschaffung des Produktes benötigt werden!

So einfach dies klingt, so schwierig ist die Umsetzung der dafür notwendigen Grundlage: Veränderung der Unternehmensstruktur und vor allem der Unternehmenskultur. Das bedeutet, das agile Mindset, also die agilen Werte und Prinzipien, im Unternehmen auf allen Ebenen zu etablieren. Dies ist die eigentliche Herausforderung, mit der wir es zu tun haben. Und ich freue mich jeden Tag darüber, wenn ich sehe, wie Mitarbeiter und Manager sich von ihren traditionellen Vorstellungen Stück für Stück trennen, weil sie erkannt und erfahren haben, dass es andere, vielleicht erfolgreichere Wege gibt, mit Menschen gemeinsam ein funktionierendes Produkt zu bauen.

Wenn ich meinen alten Kollegen das nächste Mal treffe, werde ich ihm also antworten: „I have fun changing product development organizations. And sometimes that even may have something to do with making software teams productive.“

Related posts:

1. Scrum History | Ken´s Talk über Qualität
2. Scrum mit verteilten Teams | Jeff Sutherlands Paper and Talk
3. Effektiver mit Scrum | Hamburg |18.06. 20:00 | Lehmanns Fachbuchhandlung |

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:

• Vision und Ziele der Implementierung festlegen und kommunizieren
• Infrastruktur und Arbeitsmittel
• Kommunikation nach innen und nach außen
• Information und Kooperationsbereitschaft anderer Abteilungen
• Pilotimplementierung
• Klärung aktueller Anforderungen und Bedingungen
• Analyse der Organisationsstruktur und -kultur
• Teamzusammenstellung, Personenauswahl
• Scrum-Trainings, Identifikation des Bedarfs
• Einstellung von Scrum-Mastern / Teammitgliedern
• Scrum Räumlichkeiten
• Architektur und Qualitätssicherung

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:

• Sicherheit schaffen: KOMMUNIZIEREN! Auf dem Weg zu Veränderung sind nicht alle gleich weit und nicht alle gehen gleich schnell. Jeder soll sich wohl fühlen, Zeit und Rahmen bekommen, um seine Fragen, Emotionen und Ängste mitzuteilen. Jede Meinung muss ernstgenommen, wertgeschätzt, wahrgenommen und respektiert werden. In solchen Zeiten es ist auch wichtig, klar zu kommunizieren, dass vor dem Anfang nicht alle Lösungen bekannt sind oder zuzugeben, dass man Kommunikationsfehler gemacht hat. Gegebenenfalls  kann es sehr hilfreich sein, einen Moderator beizuziehen.
• Teams vor Störungen schützen: Lasst eure Mitarbeiter nicht alleine vor der Veränderung stehen, noch dazu mit den alten Problemen und Interventionen der Außenwelt. Schafft Rückhalt, damit nicht auf einzelne Mitarbeiter Druck ausgeübt wird.
• Fokus und Priorisierung: Um Chaos und Verwirrung zu verhindern, hilft es den Mitarbeitern, sich auch eine reduzierte Vielfalt von Aufgaben und Ziele zu konzentrieren.
• Managing bei Example: Die Einführung einer Methode muss mit der Methode erfolgen, die eingeführt werden soll. Das Transition Team sollte denselben Prinzipien und Methoden wie alle Scrum Teams folgen. Es bedeutet vor allem: Transparenz über was ihr tut und was ihr liefert und natürlich über die Impediments, die ihr aufräumen müssen.

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.

Related posts:

1. Langfristig verändern
2. Scaling Scrum is simple but very hard | 10 Tipps
3. Der ScrumMaster – Wirklich ein Weichei?

The Retrospective is one of those personal meetings where I feel that my duty as a ScrumMaster is to enable each one of my Team members to freely voice his or her opinion. Another one of my tasks is – as always – to facilitate the smooth running of the meeting‘s moderation. Particularly when faced with a geographically dispersed Team, this can be somewhat of a challenge.

Thanks to Hofstede‘s cultural dimensions and personal experience, I have become particularly aware of the elements of individualism and power distance amongst different locations. Since my current Team covers six time zones and a couple of fascinating cultures, I am continuously trying to find the right approach to minimise the aspects of strong collectivism or large hierarchy without pushing any of my Team members into a situation where they might lose face.

One such way to hold a successful Retrospective is to divide up the Team into smaller groups and make sure that cultures, power and character traits are well mixed. This allows each Team member the possibility to voice his or her opinion and concerns on the last Sprint without the presence of the supervisor. Furthermore, I have found the medium of the chat rather fulfilling, as it enables my Team members to write more freely and speak more directly. In a chat session, nobody can be interrupted and language issues can be worked out more easily.

Building upon past Retrospectives, I would like to share some of my experience with you and guide you through a successful Retrospective with a geographically dispersed Team.

Start off by asking your Team members to prepare for the upcoming Retrospective by collecting their thoughts in a separate document prior to the Retrospective, from which they can then simply copy and paste into the chat. This ensures that the time spent chatting is used in the most efficient way.

The actual Retrospective is divided into two parts (depending on the size of your Team, you might even have three parts).

1) Split your Team into two hierarchically mixed-up, cross-cultural groups. Nominate one session moderator per group. Each group will have exactly 40 minutes to discuss and work through the following five topics by using chat.

Discussion #1

What specific events happened during the Sprint? (Split them up into when they happened: at the beginning, middle and end of the Sprint)

Explanation: Have your Team members write down three events that spring to their mind. Anything and everything, both personal and work-related things. The three events could be:

• at beginning: my child was ill and cried 5 nights in a row so I got little sleep
• in the middle: that day Team member X repaired the build
• at the end: Team night on Wednesday.

Anything that comes to your Team members‘ minds when someone tells them to reflect on everything that has happened over the past 2 weeks should be noted down. At least three events would be good, since something always happens in one‘s life over the course of one Sprint!

Discussion #2

What went well? For example: we fixed lots of bugs, we started considering the Definition of Done prior to actually moving a Story to Done on the Taskboard, communication improved thanks to the new telephone system etc.

While Discussion #1 lists specific events (personal and/or business-related) from the perspective of an individual Team member, Discussion #2 names things that worked well for the Team within this Sprint, which would be good to see repeated in the next Sprint.

Discussion #3

What could be improved? Explanation: The Team members should list issues or things that happened in the last Sprint that need improving for the next Sprint.

Discussion #4

The Team members need to prioritise the list of items that came out of discussing #3 and select the top three things which need improving the most.

Discussion #5

Brainstorm on measures that can be derived from these top three future improvements and think about how to present them in the next session.

2) The next and final session of the Retrospective will take 40 minutes and include all Team members via telephone conference. Here, the prioritised results from Discussion #3 and the proposed measures from each group chat should be presented to the other Team members. Together, discuss these prioritised improvements and measures and make sure that you come out of the Retrospective with three overall top priority measures that can and will be acted upon by everyone in the next Sprint in order to improve the Team‘s productivity. The ScrumMaster may facilitate this final session.

Tips & Tricks

• For some reason, I always get the same question: Why don‘t we combine Discussion #1 into Discussions #2 and #3?!

I believe that if Discussion #1 were to be left unaddressed, a major element of the Retrospective (the personal element) would be left out. Discussion #1 sometimes gives you a special insight into personal issues that may have “infiltrated” the Sprint without anyone‘s notice. Furthermore, it often unveils underlying Team issues that may not be addressed by Discussions #2 and #3. Consider the following situation: one of your Team members writes down the event „Tuesday I worked all throughout the night because I had to fix bug X. As a result, I was tired and irritated the next day.“ By reading this, the other Team members immediately realises that s/he is not the cranky person they had thought her/him to be, but rather that they have let down their Team member. Nobody should have to work throughout the night, particularly not on their own.

This could be turned into future measures, such as: Everyone has to offer help to at least one other Team member per day. Every Team member has to ask at least once during the Daily Scrum whether s/he can help another team member. The often empty phrase of „How are you?“ should be taken more seriously.

If we had, however, combined Discussion #1 into Discussions #2 and #3, this event might have never come up. Sometimes these problems, such as staying up all night, are not named during Discussion #3, since Team members do not believe that their situation could be improved. When, in fact, their fellow Team members can help.

• During these three sessions, the session moderators and ScrumMaster should make sure to…

… keep the Timebox.

… ensure that the group members discuss the correct topics during the 40 minute chats. Often, Team members jump from Discussion #1 to Discussion #3 and back to Discussion #2. However, each topic should get its own time slot.

… summarise and list the results of the Discussions not only in order to bring them forward in the Team session, but to have them as documentation.

… note down the proposed future improvements in a list and help out with the voting process for prioritisation.

Depending on your Team members‘ personalities, cultures and language know-how, the chat sessions could be exchanged with telephone conferences.

Have fun and good luck trying this method! I am looking forward to hearing your feedback.

This article is the result of teamwork between Stephanie Gasche & Kristina Klessmann.

Related posts:

1. Pre-SP2 Design Sessions or How to use your Time during a Sprint Change
2. The Retrospective in Scrum. Thank you, EditGrid.
3. Weekly updates – Brazilian Scrum Community

From four to nine – that’s fine

Team size has been discussed at length in many books and blogs and I cannot add much insight here. Remember that the teams must be able to communicate well and therefore the size must not be too large. Any number with two digits is too large in my opinion. And to be able to compensate for absences and have sufficient diversity, I believe four is the minimum number. So there you have my suggested range: four to nine. In a Scrum context, for example, I really like a scrum team of seven, with one PO, one ScrumMaster and five development team members.  I have seen this work well many times.

But who is on the team? Conventional wisdom calls for cross- (or multi-) functional teams. In other words have a bunch of people with diverse specialties on a team. Depending on the organization and its projects these could be developers with various areas of expertise, QA specialists, documentation experts, UI designers, but even business people such as marketing and sales could make sense if the results to be produced include, for example, sales kits or other business materials.

For the most part, I agree with this conventional wisdom – cross-functional teams offer much greater flexibility and tend to be more efficient. Why more efficient? As I have pointed out in previous posts, I believe direct communication is key to high productivity. Efficiency reduces dramatically when communication takes long (not taking the direct route between the parties that need to talk) or even worse if the messages are compromised through too many indirections (I call this the ‘Chinese Whispers’ syndrome, after the children’s game of that name – no offense to Chinese people or language). So it seems natural to put the people into one team who need to communicate much in order to implement some functionality. Depending on the functionality that the team typically needs to produce, this probably means that the team needs to have people with skills in various disciplines, in other words: cross-functional.

But what about a skill that is only required occasionally and does not keep a person busy for a complete development iteration? It seems wasteful to include for example a technical writer in a team that only has a few paragraphs of help text for each implemented functionality. Ideally a person with writing skills will also be able to code or test or do other relevant tasks to complete the implementation. Unfortunately, there are very few gifted people that are specialists in many, diverse subjects.

This is why I also find functional teams a useful construct in an agile organization. For example, a UIX team with experts on user interface design could make sense, or a team of technical writers.

And how do these teams work together with their cross-functional counterparts?

One option is to hire team members out temporarily to cross-functional teams. This way the specialist will be very involved in the actual implementation and the communication is easy, especially if the hired out person really physically moves to the hiring team for the duration. On the other hand it might well be very disturbing for the hiring team to incorporate a new and temporary team member, especially if the hiring period is short.

I much prefer the concept of functional teams as service teams. They offer services to the cross-functional teams that those teams cannot provide themselves. In this way, the service teams can grow together as a team because they offer the services as a team not a single person. And they are able to have their own projects within an iteration. The UIX team could develop general UI components, stylesheets etc.

But such service teams must be able to deliver services on very short notice. A build and CI team, for example, may have to make branches available quickly due to an emergency patch to be delivered to a customer. Often the cross-functional development teams notice the need for a UIX service (e.g. some graphical component) only in the middle of a development iteration. So, the service teams will have to work in a highly event driven way, where the events coming in must be properly prioritized so that the team can focus on the most important services. Often, a Kanban organization works well for service teams.

I use the term service deliberately. Service teams must make it their primary goal to serve the organization as quickly and efficiently as possible while maintaining the highest quality. All too often have we seen service teams deteriorate into isolated groups stymied by complicated service request processes. The rest of the organization must beg them for help or does not even dare to ask. Service teams must regard the rest of the organization as their valued customer and continue to ask them: How can we serve you even better.

Are there even more types of teams around? What about Management? What kind of a team are they? How do they organize their work? I have some proposals which I intend to discuss here soon.

See also previous posts from this series by Christof Braun:
Manager in a networked organization
Communities are communication bridges
Agile and organizational structures

Related Training:
Management 3.0

Related posts:

1. US Marines & Scrum
2. Pitfalls in Scrum