9Mitarbeiter auf breiter Basis befähigen

Wenn sie es geschafft haben, Dringlichkeit und Vision so zu kommunizieren, dass dieseIhre Mitarbeiter motivieren, Ihnen zu folgen, ist es an der Zeit, alle am Wandel teilha-ben zu lassen. Anders ausgedrückt benötigen Sie Hilfe, denn Sie werden nicht alles alleineinnerhalb der Führungskoalition umsetzen können. Veränderung passiert nicht plötzlichallumfassend, sondern bei jeder einzelnen Person. Ihre Aufgabe ist es jetzt, die Betroffenenzu Beteiligten zu machen.

9.1 Betroffene zu Beteiligtenmachen

Je größer die Veränderung, desto mehrMenschen sind davon betroffen. Entsprechend vie-le Menschen müssen Sie zunächst von der Notwendigkeit der Veränderung überzeugen.Wenn diese Menschen schließlich helfen wollen, ist es Ihre Aufgabe dafür zu sorgen, dassdiese Menschen auch helfen können. Dabei treffen Sie auf verschiedene Problemfelder:

• Misstrauen,• mangelnde Fähigkeiten,• Einstellungen der Mitarbeiter sowie• äußere hemmende Faktoren wie Strukturen, Systeme und Vorgesetzte.

Gerade die Überwindung des Misstrauens ist dabei besonders schwierig. Häufig ist esfür die Mitarbeiter eine ganz neue Erfahrung, dass sie plötzlich gestaltend in Prozesse undStrukturen eingreifen sollen, statt sich strikt nach den Vorgaben des Managements zu rich-ten. Auf einmal geistert der Begriff des „Empowerment“ durch dieGänge, aber so ganz trautman dem Braten nicht: Ist das etwa nur ein Trick der Unternehmensleitung, um nochmehrLeistung aus den Mitarbeitern herauszupressen? Spätestens hier wird deutlich, warum dasTop-Management eingebunden und präsent sein muss, denn nur durch Führung aus denobersten Etagen kann sichergestellt werden, dass alle Mitarbeiter wirklich glauben, dass

53D. Maximini, Scrum - Einführung in der Unternehmenspraxis,DOI 10.1007/978-3-642-34823-5_9,© Springer-Verlag Berlin Heidelberg 2013

54 9 Mitarbeiter auf breiter Basis befähigen

es ihnen erlaubt ist, die Vision aktiv zu leben und neue Impulse mit einzubringen. Ist Ih-nen das gelungen, treffen Sie auf das Phänomen, dass einige Mitarbeiter der Meinung sind,nicht über ausreichende Fähigkeiten zu verfügen, um die Vision zu leben. Teilweise rührtdiese Einstellung von mangelndem Selbstvertrauen her, teilweise ist es aber auch wahr. Siewerden keinen Veränderungsprozess erfolgreich gestalten können, wenn Sie nicht in Schu-lungen investieren. Dabei geht es einerseits um die fachlichen Fähigkeiten der Beteiligten –also zum Beispiel Scrum-Schulungen – andererseits um Seminare, welche die Einstellun-gen der Menschen beeinflussen. Ist zum Beispiel die Kundenfokussierung ein BestandteilIhrer Vision, dann sollten Sie ernsthaft in Erwägung ziehen, Schulungen zur Schärfungder Kundenfokussierung durchzuführen. Bei allen Schulungen hat es sich bewährt, auszwei Blickwinkeln zu agieren: Einerseits kann die Selbsteinschätzung der Mitarbeiter einwertvoller Hinweis darauf sein, wo noch Schulungsmaßnahmen notwendig sind. Anderer-seits sollte auch die Fremdeinschätzung nicht vernachlässigtwerden. Es gibt viele Gründe1,warum manche Mitarbeiter versuchen, Schulungen zu vermeiden. Auf der sicheren Seitesind Sie, wenn Sie grundsätzlich alle Mitarbeiter in den Kernthemen schulen. Hier müssenSie natürlich eine Kosten-Nutzen-Abwägung durchführen.

Eng im Zusammenhang mit den Fähigkeiten stehen die Einstellungen der Mitarbeiter.Es gibt immer einige Kollegen, die zunächst abwarten oder die sich komplett der Verän-derung verweigern. Sie werden auch Kollegen begegnen, die zwar behaupten, sie würdenden Wandel unterstützen, durch ihr Handeln aber das Gegenteil beweisen. Jeder einzelnePunkt Ihrer Vision kann den persönlichen Einstellungen undWertvorstellungen IhrerMit-arbeiter zuwider laufen und entsprechendeVorbehalte auslösen.Demkönnen Sie einerseitswie oben beschrieben mit Schulungen begegnen. Allerdings sind diese nur einMosaiksteinin der Veränderung der Einstellungen. Ebenso wichtig, wenn nicht sogar noch wichtiger,sind eine offene Kommunikation und die Überzeugung der Menschen, dass die geforder-ten Veränderungen wirklich wichtig sind. Die Vorarbeiten zu Dringlichkeit, Vision undKommunikation zahlen sich jetzt aus – oder rächen sich, wenn Sie diese nicht sorgfältigdurchgeführt haben.

Es kann nötig werden, dass Sie sich von einzelnenMitarbeitern trennen, die nicht bereitsind, an ihren Einstellungen zu arbeiten2. Gerade hoch verdiente, langjährige Mitarbeitermöchte man einerseits nicht entlassen, andererseits haben diese auch das größte Potential,unverrückbar auf Ihren Positionen zu beharren. In aller Regel helfen hier klärende Vier-Augen-Gespräche, in denen man die Gründe für das Beharren erörtert. Normalerweisefindet sich dann eine Lösung, da der Mitarbeiter entweder überzeugt werden kann, oderSchulungs- oder anderer Handlungsbedarf aufgedeckt wird. Sollten Sie es aber mit einem

1 Die Gründe können von Arbeitsüberlastung bis zu einer tief sitzenden Versagensangst reichen. Daeine entsprechendeAnalyse den Rahmen dieses Buches sprengen würde, gehe ich nicht weiter daraufein. Eine Literaturempfehlung gebe ich Ihnen aber noch mit auf den Weg: Fritz Riemann (2009).2 Die Trennung vonMitarbeitern ist hier als absolut letztesMittel zu sehen, wenn alles andere versagthat. Der professionelle Umgang mit Kritik, das Eingehen auf die Kollegen sowie deren Motivierungsind die vordringlichste Aufgabe desManagements in sich veränderndenOrganisationen. Erst wennalle Stricke reißen kann und muss die Trennung von einemMitarbeiter in Betracht gezogen werden.

9.2 Typische hemmende Faktoren in Bezug auf Scrum 55

Menschen zu tun haben, der nicht bereit ist zuzuhören oder sich zu verändern, bleibt Ihnennichts anderes übrig, als sich von dieser Person zu trennen. Wenn Sie diese im Unterneh-men belassen, wird sie den Wandel behindern und Ihre Blockadehaltung wie einen Virusauf andere Kollegen übertragen. Es ist leichter durch einen Sumpf zu waten, als eine großeVeränderung mit einem blockierenden Kollegen umzusetzen.

Haben Sie all diese Faktoren überwunden, kommen Sie zu dem Teil, der den Löwen-anteil Ihrer Arbeit ausmacht: die äußeren hemmenden Faktoren. Darunter versteht manetablierte Prozesse, Modelle, Systeme und Verhaltensweisen, die in Ihrem Unternehmenganz normal sind, aber Ihrer Vision widersprechen. Im folgenden Abschnitt gehe ich de-taillierter auf entsprechende Probleme ein, denenman häufig imZusammenhangmit einerScrumeinführung begegnet. Lösen Sie diese Widersprüche auf, um Ihr Ziel erreichen zukönnen!

9.2 Typische hemmende Faktoren in Bezug auf Scrum

Es gibt eine Reihe von hemmenden Faktoren, denen man bei Scrumeinführungen immerwieder begegnet. Je nachdem, welchen Zielzustand Sie mit Scrum erreichen wollen, möch-ten Sie möglicherweise bewusst einen für Scrum hemmenden Faktor beibehalten, da er fürIhr Unternehmen als Ganzes förderlich ist. Das ist in Ordnung. Prüfen Sie aber in jedemEinzelfall sowohl, welche Nachteile Ihnen diese Beibehaltung bringt, als auch welche Vor-teile Ihre Organisation als Ganzes dadurch genießt. Hilfreich ist auch zu hinterfragen, obdiese Vorteile nicht auch anders erreicht werden können. Im Folgenden sind einige häufiganzutreffende hemmende Faktoren aufgeführt. Welche sich dabei besonders negativ aufSie auswirken können, hängt von Ihrem spezifischen Kontext ab.

1. Es gibt keinen einzelnen Product Owner/die Verantwortung für das Produkt ist nichteindeutig geregeltViel zu oft gibt es eine Gruppe von hochrangigen Managern, die gemeinsam über dasWohl des Produktes entscheiden. Das führt dazu, dass sich niemand wirklich verant-wortlich fühlt und Entscheidungen lange brauchen. Auch sind plötzliche Richtungsän-derungen in einem solchen Umfeld häufiger, als wenn sich eine Einzelperson verant-wortlich zeigt. Scrum fordert genau aus diesemGrund einen einzelnen ProductOwner,der alleine über das Produkt entscheiden kann – der sich aber selbstverständlich durchein Gremium, seine Stakeholder und objektivierte Kriterien, leiten lassen sollte.

2. Jedes Projekt braucht einen ProjektmanagerEinige Unternehmen vertreten die Ansicht, dass jedes Projekt durch einen Projektma-nager geleitet werden muss. Dieser Projektmanager hat dann die alleinige Verantwor-tung undwill natürlich auch entsprechend steuern. Das ist ein direkterWiderspruch zuScrum, denn dort ist die Verantwortung klar geregelt: Der Product Owner ist verant-wortlich für das Produkt, der ScrumMaster ist verantwortlich für den Prozess und dasEntwicklungsteam ist verantwortlich für dieUmsetzung inklusive derUmsetzungsqua-

56 9 Mitarbeiter auf breiter Basis befähigen

lität. Ein Projektmanager wird hier ständig anecken. Je nach seinen Fähigkeiten musser sich für eine dieser drei Rollen entscheiden, oder seine Erfüllung in einer anderenPosition suchen.

3. Karrieremodelle für ScrumMaster und Product Owner sind nicht vorhanden„Ich will kein Product Owner sein, heute bin ich ProduktMANAGER, das ist viel mehrwert!“ – solche und ähnliche Aussagen höre ich häufig. Hintergrund ist, dass einigeUnternehmen noch nicht einmal Fachkarrieren vorgesehen und damit die Zeichender Zeit nicht erkannt haben. In einem Scrumumfeld wird sowohl eine Führungskar-riere (für die klassischen Managementpositionen), als auch eine Fachkarriere (für dieEntwickler) sowie eine Scrumkarriere (für Product Owner und Scrum Master) benö-tigt. Beispielsweise motiviert eine Aufstiegsmöglichkeit vom Junior Scrum Master bishin zum Scrum Coach einen guten, strebsamen Mitarbeiter eher, seine Fähigkeiten indieser Position einzubringen, als wenn er nur über denWeg der Führungskarriere auf-steigen kann und daher erst einmal die Position eines Gruppenleiters ausfüllen muss.Denken Sie auch daran, die verschiedenen Karrierepfade durchlässig zu gestalten, da-mit auch ein Wechsel in einen anderen Pfad jederzeit möglich ist.

4. Anerkennung wird hauptsächlich über das Gehalt definiertDie ab 1980 geborenen Jahrgänge, so genannte Digital Natives, stellen ganz andereAnforderungen an Geschwindigkeit und Anerkennung, als dies die vorhergehendenGenerationen taten3 (vgl. Meister und Willyerd 2010). Das Gehalt muss hoch genugsein, um keine Unzufriedenheit auszulösen – darüber hinaus spielt die Höhe keinewirkliche Rolle (vgl. Pink 2010). Viel wichtiger sind kurze, zeitnahe und wertschät-zende Feedbackzyklen. Beispielsweise trägt eine SMS am Abend mit dem Text „DeinePräsentation heute war toll, gut gemacht!“ weit mehr zur Mitarbeiterzufriedenheit bei,als ein Lob am Ende des Jahres im Mitarbeitergespräch. Gerade bei Wissensarbeiternist es aber unerlässlich, dass dieMitarbeiter hochmotiviert sind. Ihr ScrumMaster wirdsein Bestes tun, um das sicherzustellen – wenn Sie ihn lassen. Einmal im Monat Pizzaoder ein Zuschuss zum Bowlingabend des Teams sollten drin sein. Sind Ihre Personal-abteilung und Ihr Controlling darauf vorbereitet?

5. Es gibt keine Räumlichkeiten für die TeamsIn der Regel führen Unternehmen Scrum ein, weil sie sich eine höhere Produktivitätdadurch versprechen. Die entsteht aber nicht durch Scrum selbst, sondern durch dieSchaffung geeigneter Rahmenbedingungen, deren Notwendigkeit durch Scrum aufge-deckt wird. Ein verstreutes Team ist wenigstens 40% weniger produktiv, als ein bei-einander sitzendes Team. Schon 30m bis zum nächsten Büro führen zu diesem Pro-duktivitätsverlust. Es ist daher nötig, die Scrum-Teams in einem Raum zu platzieren –ohne weitere störende Einflüsse. Scrum-Teams diskutieren viel und produzieren auchschon mal etwas Lärm, das würde teamfremde Mitarbeiter nur stören. Umgekehrt istdas genauso – Großraumbüros funktionieren nicht. Stellen Sie außerdem sicher, dass

3 Natürlich gibt es auch in anderen Altersgruppen solche Anforderungen. Allerdings treten diese beiden Digital Natives wesentlich häufiger auf.

9.2 Typische hemmende Faktoren in Bezug auf Scrum 57

es ausreichend Besprechungsräume und auch „stille Ecken“ gibt, in denen konzentriertohne Lärm gearbeitet werden kann.

6. Die Räumlichkeiten sind unzureichend ausgestattetScrum-Entwickler benötigen heutzutage mehr als nur Schreibtische und Stühle. Lap-tops mit schnellen Festplatten, ausreichend Arbeitsspeicher und guten Prozessoren ge-hören genauso dazu, wiemehrere große Bildschirme und eine Sicherungsinfrastruktur.Darüber hinaus braucht jedes Team mindestens ein Whiteboard und ein Flipchart.Moderationsutensilien wie Klebezettel, Stifte, Kärtchen und Klebepunkte sollten auchselbstverständlich sein. Wirklich zufrieden wird Ihr Team aber nur werden, wenn esseinen Raum selbst gestalten darf. Gewähren Sie ihm ein entsprechendes Budget undhinterfragen Sie die Entscheidungen des Teams nicht, sofern Sie vom Team als Ganzesgetroffen wurden. Egal ob das zu Postern, Pflanzen, Tischfußball oder einer Playstationführt – wichtig ist, dass das Team sich zuhause fühlt.

7. Es gibt Zentralbereiche, die steuernd in die Bereiche der Scrum-Teams eingreifen„Das Team organisiert sich selbst“ ist ein Leitsatz aus Scrum. Jede Scrum-Rolle hat da-bei ihre eigenenAufgaben undVerantwortungsbereiche. Einige dieser Aufgabenwarenvor Scrum alleiniger Herrschaftsbereich der entsprechenden Zentralbereiche. Diesewollen ihren Machtbereich nicht aufgeben, es entstehen Konflikte. Typisch sind da-bei Zentralbereiche wie Konzeptentwicklung, Qualitätssicherung und Prozessmanage-ment. Alle drei Aufgabenwerdenmit Scrumdurch die Teams erledigt, die entsprechen-den Mitarbeiter müssen aus den Zentralbereichen direkt in die Teams wandern.

8. Administrivialitäten fressen die Teams aufDeMarco (1998) hat den Begriff der Administrivialitäten geprägt. Damit sind bürokra-tische Aufwände gemeint, die mehr dem Selbstzweck dienen, als das Gesamtergebniszu verbessern. Es gibt Fälle, in denen die Vorbereitung der Dokumentation für dasMit-arbeiterbeurteilungsgespräch denMitarbeiter selbst einen vollen Arbeitstag kostet. EinTag, in dem er nichts für das Projekt tun kann. Die vielen Kleinigkeiten des Alltagssind aber viel schlimmer: Hier einen Antrag, da eine Dokumentation, dort ein paarKPIs4. Messen Sie, wie viel Zeit Ihre Mitarbeiter für solche administrativen Tätigkei-ten aufwenden. Dann entscheiden Sie, ob diese Zeit gut investiert ist, oder nicht. AllerWahrscheinlichkeit nach werden Sie nicht alles von dem, was ausgefüllt wird, auchbrauchen.

9. Budgets werden am Anfang des Jahres freigegebenMit Scrum produzieren Sie Ihre Ergebnisse in kurzen Iterationen. Alle paar Wochenstellen Sie fest, in welche Richtung das Produkt sich weiterentwickeln muss. Auch stel-len Sie alle paar Wochen fest, welche Veränderungen Sie an den Rahmenbedingungenund Prozessen vornehmen müssen, um noch produktiver zu sein. Wenn Ihre Budgetsaber gesammelt am Anfang des Jahres freigegeben werden, sind die Erkenntnisse dernächstenMonate noch nichtmit einberechnet. Das Budget zu überschreiten ist inman-chen Unternehmen schlicht nicht möglich. Sie verschenken in diesen Fällen wertvolle

4 KPI steht für Key Performance Indicator – oder einfach Kennzahlen.

58 9 Mitarbeiter auf breiter Basis befähigen

Produktivität (und damit Geld), weil Ihr Prozess es Ihnen nicht ermöglicht, mit den Er-kenntnissen der Gegenwart Schritt zu halten. Sie können das Potential von Scrum hiernicht voll ausnutzen.Meist tritt dieser hemmende Faktor gleichzeitig mit dem nächstenauf:

10. Projekte werden auf der Grundlage von Zeitschätzungen freigegebenAus demWasserfall- oder Phasenmodell ist das Vorgehen weit verbreitet, zunächst einLasten- und ein Pflichtenheft zu erstellen und auf dieser Grundlage das Projektbudgetfreizugeben. Natürlich ist im Pflichtenheft jede Tätigkeit auf die Stunde exakt geschätztund in einem Projektablaufplan festgehalten. Dieses Vorgehen funktioniert nur leiderbei komplexen Produkten wie Software nicht. Obwohl dies allgemein bekannt ist, hal-ten Organisationen in Ermangelung eines besseren Ansatzes an diesem Prozess fest.Scrum stellt klar, dass es keine absolute Planungssicherheit bei der Entwicklung vonSoftware gibt und dass wir nur schätzen können. Wenn das Entwicklungsteam sta-bil bleibt und ein Vertrauen zwischen Auftraggeber und Auftragnehmer besteht, wirdein solches Vorgehen nicht mehr benötigt. Das Streben nach absoluter Prognosefähig-keit ist Ausdruck eines tiefen Misstrauens, ausgelöst durch die Erfahrungen der letzten30 Jahre mit Softwareentwicklung. Scrum verbietet Ihnen nicht, vorab alles durchzu-planen. Scrum zeigt Ihnen aber sehr deutlich auf, dass Sie so viel Zeit verschwenden.Versuchen Sie, Projekte auf der Grundlage von Vertrauen und empirischen Daten frei-zugeben, statt aufgrund falscher Annahmen über die Zukunft. Falls Ihnen das nichtgelingt gibt es durchaus Möglichkeiten, sich auch in einem solchen Umfeld agil zu be-wegen. Eine gängige Methode ist beispielsweise, zunächst den gesamten Umfang wiefür ein Festpreisprojekt zu schätzen und anschließend zwei Regeln festzulegen: Wennsich Anforderungen ändern oder hinzukommen, müssen Anforderungen im selbenUmfang entfernt werden. Diese Änderungen bei gleich bleibendem Gesamtaufwandwerden dem Kunden nicht zusätzlich berechnet. Außerdem kann der Kunde jederzeitaus dem agilen Projekt aussteigen, wenn er das möchte, muss dann jedoch 20% desnoch nicht erfüllten Projektvolumens an den Auftragnehmer zahlen5.

11. Schulungen werden nicht genehmigtSchulungen sind teuer, insbesondereweil dieMitarbeiter in dieser Zeit nicht amProjektarbeiten. Während Schulungen für Einzelpersonen teilweise noch genehmigt werden,sind Schulungen für größere Gruppenmeistens ein No-Go. Andererseits stellt die Ein-führung von Scrum einen fundamentalen Wandel in der Denkweise, den Werten undim Vorgehen dar, der erst erlernt werden muss. Das Unternehmen steht vor der klassi-schen Frage (vgl. Covey 2012): „Die Säge schärfen, oder den Baum fällen?“Absurderweise entscheiden sich Unternehmen häufig dafür, mit einer stumpfen Sägeweiterzuarbeiten, als in ihre Mitarbeiter zu investieren. Genau das ist auch der sprin-gende Punkt: Wer Schulungen als Kosten und nicht als Investition sieht, wird sich mitjeder Veränderung sehr schwer tun. Auch mit einer Scrumeinführung.

5 Dieses Konzept heißt „Money for nothing and changes for free“ nach Sutherland (2008). Tieferbeschäftigen sich mit derThematik Opelt et al. 2012.

9.2 Typische hemmende Faktoren in Bezug auf Scrum 59

12. Entwicklungswerkzeuge sind vorgeschrieben und nicht verhandelbarWenn Sie monatlich oder sogar wöchentlich fertige Software ausliefern wollen, müssenauch die Werkzeuge entsprechend geeignet sein. Kontinuierliches Testen und Auslie-fern sind dabei nur zwei Aspekte, die es zu beachten gilt. Die dafür nötigen Werkzeugesind dem IT-Betrieb vieler Unternehmen nicht bekannt und werden nicht oder erstnach einer zeitraubenden Evaluierungsphase freigegeben. Das ist genauso, als würdenSie dem Handwerker sagen, er muss bis auf weiteres von Hand die Schrauben in dieWand drehen, da der Akkuschrauber erst in einem Jahr freigegeben wird. VersuchenSie, diese Freigabeprozesse zu beschleunigen. Jeder Tag, den Sie auf die erforderlichenWerkzeuge warten müssen, kostet Sie viel Geld und Motivation.

13. Technische Notwendigkeiten sind nicht erfüllbarEin Scrum Team stellt höhere Anforderungen an seine Umgebung, als klassische Ent-wicklungsteams. Das beginnt mit Kommunikationsinfrastruktur (verstreute Teamswerden Webcams, Headsets und eine starke Internetleitung sowie VPN-Zugänge be-nötigen) und endet noch lange nicht bei starken Entwicklungsservern mit Branching-möglichkeit6 . Wenn Ihr Unternehmen aus irgendwelchen Gründen diese technischenVoraussetzungen nicht schaffen kann oder will (bei Kameras müssen Sie zum Beispielden Betriebsrat fragen), kann Ihr Team nicht seine volle Produktivität entfalten.

14. Entwickler arbeiten in mehreren Projekten gleichzeitigJeder Wechsel zwischen zwei Aufgaben erfordert Zeit. Zeit, sich in die neue Aufgabeeinzudenken, zu rekapitulieren, was bereits erledigt ist, und natürlich Zeit, den Lö-sungsraum neu aufzuspannen. Das ist bei der Arbeit an mehreren Projekten nicht an-ders. Sie verlieren unterm Strich etwa 20% Produktivität pro zusätzlichem Projekt.Wenn Ihr Mitarbeiter also an zwei Projekten gleichzeitig zu 50% arbeitet, kommt nur40% Leistung an – der Rest wird für die Wechsel verbraucht (vgl. Weinberg 1991).Scrum fordert nicht, dass Sie nur ein Projekt gleichzeitig durchführen dürfen. Scrumzeigt Ihnen aber sehr schnell auf, dass dieses Multitasking eine Defokussierung dar-stellt, die sich sehr negativ auf die Produktivität niederschlägt.

15. Teamzusammensetzungen werden geändertUnternehmen, die Ihre Mitarbeiter als seelenlose Ressourcen auf dem Papier ansehen,verschieben gerne eben diese Ressourcen von Team zu Team, um je nach Bedarf mehrPersonentage zur Verfügung zu haben. Dieses tayloristische Denken funktioniert ineinfachen Umgebungen wie der Fließbandarbeit gut, ist in denkintensiven Umgebun-gen wie der Softwareentwicklung aber vollkommen unangemessen. Ein Team ist dannproduktiver als die Summe seinerMitglieder, wenn eine emotionale Bindung zwischenden Mitgliedern entstanden und eine gemeinsame Arbeitsweise etabliert ist7. Das er-

6 „Branching“ bezeichnet das Entwickeln eines Teams auf einem eigenen Entwicklungssystem, ei-nem so genannten Branch, um dann imHauptsystem, dem „Trunk“ fertigen, funktionsfähigen Codeintegrieren zu können („mergen“).7 Der Teambildungsprozess durchläuft verschiedene Phasen: Forming, Storming, Norming und Per-forming. Vgl. Tuckman (1965).

60 9 Mitarbeiter auf breiter Basis befähigen

fordert Zeit und kann kaum gesteuert werden. Jedes Mal wenn die Zusammensetzungverändert wird, muss der Prozess neu durchlaufen werden. Außerdem entsteht ein tie-fes Misstrauen des Teams gegen diese Willkür, die Motivation sinkt.

16. Entscheidungen fallen über die Köpfe des Teams hinwegEntscheidungen über Arbeitsorte, -mittel, Teamzusammensetzungen usw. fallen ingroßen Organisationen oft über die Köpfe der Betroffenen hinweg. Eine Akzeptanzdurch die Mitarbeiter ist hierdurch nur schwer möglich und wird durch Macht er-reicht. Das wiederum reduziert die Motivation des Teams und mindert die Fähigkeitzur Selbstorganisation.Wieso sollten dieMitarbeiter auch selbst denken, wenn sowiesoalle Weisheit „von oben“ herab fällt? Fehlt aber die Selbstorganisation, so können Siekeinen großen Nutzen aus Scrum ziehen, da das Team sich nicht an der kontinuierli-chen Verbesserung der Prozesse beteiligen wird.

17. Manager beharren auf einem direkten Zugriff auf die EntwicklerEs ist sehr bequem für Manager, ihre Wünsche und Ideen direkt bei den Entwick-lern „einzukippen“. Das erspart lange bürokratische Wege und verhindert, dass manes vergisst. Gerade wenn alle es so machen, ist das oft der einzige Weg, seine An-forderungen überhaupt umgesetzt zu bekommen. Wenn dann noch persönliche Zie-le und damit der Bonus am Jahresende ins Spiel kommen, ist es mit der Akzeptanzvon Scrum vorbei. Schließlich fordert Scrum, dass alle Anforderungen über den Pro-duct Owner in den Prozess gegeben und nur von ihm priorisiert werden. Ohne Pro-duct Owner gibt es allerdings auch kein Scrum, damit keine Fokussierung auf dengrößtmöglichen Geschäftswert und keine Lieferung in kurzen Iterationen, was wie-derum zu einem gesteigerten Bedürfnis führt, Anforderungen am Prozess vorbei ein-zuschleusen. Durchbrechen Sie diesen Teufelskreis, indem Sie auf den Scrum Regelnbeharren.

18. Persönliche Ziele stehen über gemeinsamen ZielenHaben Sie einen größeren Anteil persönlicher Ziele in Ihrer Zielvereinbarung stehen,oder herrscht der Gesamterfolg des Unternehmens vor? In aller Regel werden bei Ihnendie persönlichen Ziele vorherrschen. Damit hängt Ihr persönliches Gehalt aber nichtmehr davon ab, ob Sie das Beste für das Unternehmen tun, sondern dass Sie das tun,was vereinbart wurde. Auch wenn sich die Welt um Sie herum weiter dreht. Das wirdinsbesondere dann problematisch, wenn die Ziele der einzelnen Personen sich wider-sprechen. Besonders deutlich wird das im Produktmanagement, wenn Manager A dasFeature 1 umsetzen soll, Manager B aber Feature 2 benötigt und beide dazu dasselbeTeam einsetzen wollen. Sie können sich viele endlose Diskussionen ersparen, wenn Sieauf persönliche Ziele verzichten.

19. Es gibt keine ProduktvisionLeider wird viel zu oft aufgrund des aktuellen Tagesgeschäftes priorisiert und nichtaufgrund einer ausgefeilten Produktvision. Ob ein Feature wirklich wertvoll für dasGesamtprodukt oder nur für einen besonders „lauten“ Kunden ist, wird häufig nichtunterschieden. Damit fällt aber die Fokussierung auf die „Total Cost of Ownership(TCO)“ weg, also die Betrachtung der Gesamtkosten, die das Produkt auch über die

9.2 Typische hemmende Faktoren in Bezug auf Scrum 61

Entwicklung hinaus verursacht. Mit Scrum sind Sie dann besonders erfolgreich, wennIhr Product Owner sich auf eine abgestimmte Produktvision stützt.

20. Kurzfristige Ergebnisse stehen weit höher im Kurs als langfristiger ErfolgWie lange im Voraus denkt Ihr Unternehmen? Denken Sie in Monaten? Quartalen?Jahren? Nur ganz wenige denken strategisch in 5- oder 10-Jahresschritten. Ihr Produktwird aber nicht nur ein Quartal oder ein Jahr überdauern, sondern aller Wahrschein-lichkeit noch wenigstens fünf Jahre. Vielen Unternehmen passiert es daher, dass sieden Nutzen eines Jahres gegen die Kosten der Entwicklung rechnen, statt den Nutzenüber die restliche Lebensdauer des Produktes gegen die gesamten Kosten, die bis dahinanfallen werden. So manche Entscheidung wäre sonst vermutlich anders ausgefallen.Denken Sie in Produkten, nicht in Quartalen.

21. Kommandostrukturen werden Vertrauen vorgezogenÜberall da, wo kein Vertrauen zu denMitarbeitern besteht, wird versucht ein undurch-dringliches Kontrollsystem aufzubauen. Verantwortlichkeiten werden definiert, Tätig-keitsbeschreibungen verfasst, Gremien installiert und so fort. AmEnde steht dann eineklare Hierarchie, die Macht und Verantwortung nach oben delegiert. Operative Ent-scheidungen müssen aber dort getroffen werden, wo sie nötig sind: in den Teams. Mili-tärische Strukturen helfen hier nicht weiter, stattdessen muss der Fachkompetenz auchdie entsprechende Entscheidungskompetenz zugeordnet werden. Das ist formal rechtsimpel, wird Sie aber auf der Metaebene noch lange verfolgen: Sie müssen es schaf-fen, Vertrauen in beide Richtungen aufzubauen. DasManagement muss nicht nur demTeam vertrauen, sondern das Team auch dem Management.

22. Die Herrschaft der KPIsWas gibt es schöneres als aussagekräftigeKennzahlen (Key Performance Indicator, kurzKPI) mit deren Hilfe sich klar die Leistungsfähigkeit einer Abteilung, eines Teams odereinzelner Personen beurteilen lässt? Leider ist dieseVorstellung der Steuerbarkeit durchKennzahlen einMythos. Sobald die durch Kennzahlen gelieferten Informationen nichtmehr wertneutral betrachtet, sondern zur Steuerung verwendet werden, kehrt sich ih-re Wirkung ins Gegenteil um (vgl. Campbell 1976)8. Kurz gesagt: Man findet immereinen Weg, die Kennzahl zu verbessern ohne die reale Leistung der gemessenen Grö-ße zu erhöhen. Ein Beispiel: Hin und wieder wird in Unternehmen immer noch dieAnzahl der geschriebenen Codezeilen als Messgröße für die Produktivität eines Mitar-beiters verwendet. Jeder Entwickler ist aber in der Lage, Ihnen so viele Zeilen Code zuproduzieren, wie sie wollen – ohne dadurch mehr Features auszuliefern. Das Produzie-ren der dafür benötigten Codezeilen nimmt Zeit in Anspruch. Im Ergebnis verbessertsich die Kennzahl, aber der Output sinkt – die KPI-Perversion hat zugeschlagen. Umnicht in diese Falle zu laufen, sollten Sie so wenige Kennzahlen wie möglich erfassenund diese ausschließlich imGesamtkontext und wertfrei behandeln. Es dürfen niemalsBelohnungen oder Strafen aus diesen Kennzahlen entstehen, sonst werden sie nutzlos.Mehr zur Messung von Erfolg finden Sie auch in Abschn. 10.3.5.

8 Vgl. das sog. “Campbell’s law”.

62 9 Mitarbeiter auf breiter Basis befähigen

23. Ein sehr hoher Spezialisierungsgrad der Entwickler verhindert gemeinsame Verant-wortungIn manchen Teams sind die einzelnen Mitarbeiter in einem enorm hohen Maße spe-zialisiert. Dies kann sowohl einzelne Fachlichkeiten betreffen (z. B. Features), als auchBereiche im Code oder allgemeine Fähigkeiten (z. B. Architekten, Tester, Toolexperten,Datenbankspezialisten, usw.). Ein zu hoher Spezialisierungsgrad kann dazu führen,dass Abhängigkeiten entstehen, die den Arbeitsfluss beinträchtigen. Auch fühlen sichdie einzelnen Personen eher nicht für Bereiche des Produktes verantwortlich, die sienicht verändern können oder dürfen. Das wiederum schwächt den Teamzusammen-halt und kann die Qualität des Gesamtproduktes mindern. In manchen Fällen führtdas Fehlen von Generalisten auch dazu, dass die ideale Teamgröße von 3–9 Personenerheblich überschritten werden muss, damit alle Aufgaben abgedeckt werden können.Führen Sie in solchen Fällen Ihrem Entwicklungsteam die Problematik vor Augen undbitten Sie es, Lösungen zu erarbeiten. Insbesondere Abhängigkeiten führen normaler-weise zu einer intrinsischen Motivation des Teams, die mit hoher Wahrscheinlichkeitzum Vorschlag sinnvoller Maßnahmen führt. Diese könnten beispielsweise die Ar-beit in Paaren (Pair Programming) oder Schulungen innerhalb des Teams umfassen.Meiden Sie Vorschläge, welche die Aufteilung des Teams nach technischen Schichtenvorsehen.

24. Abteilungen und Teams stehen in Konkurrenz zueinander, es existiert kein gemeinsa-mes unternehmensweites LeitbildVielleicht haben Sie das auch schon erlebt: Statt Ihnen die benötigten Informationen zuliefern, hält Sie dieNachbarabteilung hin.Das geht so lange, bis Sie IhrenAbgabeterminverpassen, oder der Vorfall eskaliert. Solche Machtkämpfe spielen sich leider immerwieder ab. Je größer das Unternehmen, desto häufiger und härter sind diese Macht-kämpfe im Allgemeinen. Was Sie hier brauchen, ist ein gemeinsames übergeordnetesZiel, eine Vision, ein Leitbild. Dieses sollte sich dann auch in den Zielvereinbarungender Mitarbeiter wieder finden. Allen Mitarbeitern muss bewusst sein, dass sie für das-selbe Ziel kämpfen – also miteinander für eine bessere Zukunft, statt gegeneinander.

BeispielBei einem Kunden hassten die Programmierer die Qualitätssicherer regelrecht. Ständigkamen neue Anforderungen, die als Gängelei empfunden wurden. In der Wahrneh-mung der Programmierer sahen sich die Qualitätssicherer als „etwas Besseres“ undentschieden über die Köpfe der Kollegen hinweg. Umgekehrt fühlten sich die Qualitäts-sicherer durch die Programmierer bedroht, weil diese ihre Anordnungen und Richtli-nien einfach ignorierten. Erst als ich anfing, alle Beteiligten regelmäßig an einen Tischzu setzen und die Frage zu stellen, wie wir denn gemeinsam Software entwickeln könn-ten, die auch den Qualitätsanforderungen des Unternehmens entsprach, begann dasgegenseitige Misstrauen zu bröckeln. Drei Monate später arbeiteten die Abteilungenproduktiv zusammen.

9.3 Das sollten Sie sichmerken 63

Die obige Liste ist natürlich nicht abschließend. Es gibt eine Vielzahl weiterer Proble-me, die auftreten können. Ich habe mich hier auf diejenigen beschränkt, denen ich sehrhäufig begegne. Bitte beachten Sie, dass das Auftreten eines der genannten Probleme nichtzwingend bedeutet, dass Sie „gegen Scrum“ handeln. Das ist auch vollkommen irrelevant.Worum es geht ist, Ihr Unternehmen produktiver zumachen und IhrenMitarbeitern mehrFreude an der täglichen Arbeit zu geben. Im Übrigen bestehen diese Probleme auch ohneScrum und können ebenso ohne Scrum gelöst werden. Falls Sie aber Scrum implementie-ren, haben Sie den großen Vorteil festzustellen, dass die obigen Punkte sich wie Sand imGetriebe auswirken. Sie werden immer und immer wieder von den Scrum Teams als Pro-blem transparent gemacht werden und die Produktivität sichtbar mindern. Dadurch habenSie die Chance, die Punkte anzugehen und zu lösen – eine Chance, die Ihnen bei anderenVorgehensmodellen nicht unbedingt gegeben ist.

9.3 Das sollten Sie sich merken

Nachdem Sie Dringlichkeit, Vision und Ziele erfolgreich kommuniziert haben, kommt dieeigentliche Arbeit auf Sie zu.

1. Um Mitarbeiter auf breiter Basis zu befähigen, müssen Sie vier Kernprobleme lösen:• Misstrauen,• mangelnde Fähigkeiten,• Einstellungen der Mitarbeiter sowie• äußere hemmende Faktoren wie Strukturen, Systeme und Vorgesetzte.

2. Dazu ist es notwendig, dass die vorhergehenden Phasen, insbesondere die Ausarbeitungder Dringlichkeit und Vision sowie die Kommunikation dieser Elemente, stattgefundenhaben und erfolgreich waren.

3. Schaffen Sie Vertrauen, indem Ihr gesamtes Management die Veränderungen vorlebtund anführt. Außerdem müssen die Mitarbeiter ständig ermutigt werden, sich aktiv zubeteiligen.

4. Begegnen Sie mangelnden Fähigkeiten mit Schulungen. Nutzen Sie zur Beurteilung derFähigkeiten sowohl das Selbst- als auch das Fremdbild.

5. Die Einstellungen derMitarbeiter lassen sich überGespräche,Verständnis und Schulun-gen beeinflussen. In Einzelfällen kann sich dies aber als unmöglich erweisen. In solchenFällen kann es sein, dass Sie sich von einem Ihrer Mitarbeiter trennen müssen.

6. Äußere hemmendeFaktorenwie Strukturen, SystemeundVorgesetztemüssen analysiertund angepasst werden.

7. Manche hemmende Faktoren müssen unbedingt schon vor einer Scrumeinführung ge-löst werden, andere werden währenddessen, zu einem späteren Zeitpunkt oder niemalsadressiert. Treffen Sie diese Entscheidungen bewusst und machen Sie die Gründe sowiedie Folgen transparent.

8. Führen Sie durch Ihr Vorbild!

64 9 Mitarbeiter auf breiter Basis befähigen

Literatur

Riemann F (2009) Grundformen der Angst, 39. Aufl. Reinhardt Verlag, MünchenCampbell DT (1976) Assessing the Impact of Planned Social ChangeThe Public Affairs Center. Dart-mouth College, HanoverPink DH (2010) Drive, 2. Aufl. Ecowin Verlag, SalzburgMeister J, Willyerd K (2010) Mentoring für Millenials. Harvard Business Manager 32:38–43de Marco T (1998) Der Termin. Carl Hanser Verlag, MünchenOpelt A et al (2012) Der agile Festpreis. Hanser Verlag, MünchenCovey S (2012) Die 7 Wege zur Effektivität: Prinzipien für persönlichen und beruflichen Erfolg,25. Aufl. Gabal Verlag, OffenbachWeinberg G (1991) Quality Software Management: SystemsThinking. Dorset House, New YorkTuckman BW (1965) Developmental sequences in small groups. Psychological Bulletin 63:384–399