Als PDF, PPTX herunterladen
![Dies ist deine letzte Chance - danach gibt es kein Zurück. [öffnet seine Hand] Schluckst du die blaue Kapsel, ist alles aus. Du wachst in deinem Bett auf und glaubst an
das was du glauben willst. [öffnet die andere Hand] Schluckst du die rote Kapsel, bleibst du im Wunderland, und ich führe Dich in die tiefsten Tiefen des Kaninchenbaus.
[Neo greift nach der roten Kapsel] Bedenke: Alles was ich dir anbiete ist die Wahrheit, nicht mehr. [Neo schluckt die rote Kapsel]
Folge mir."](https://image.slidesharecdn.com/endederkarriere-151120102006-lva1-app6892/85/Das-Ende-der-Karriere-31-320.jpg)
Hochgeladen vonJohann-Peter Hartmann
Das Ende der Karriere
Das Dokument beschreibt den Übergang von festen Rollen und Titeln zu flexiblen Teamstrukturen in einem Unternehmen, das agile Methoden implementiert hat. Es werden verschiedene Erfahrungen und Herausforderungen geteilt, die das Team und das Management während dieses Veränderungsprozesses durchlebt haben. Die Erfolge und Misserfolge zeigen, dass agile Arbeitsweisen Transparenz schaffen und die Verantwortung innerhalb der Teams dynamisch verteilt wird.
Weitere ähnliche Inhalte
Das Ende der Karriere
- 1.
- 2. „Warum wir keine (festen)Titel und Positionen mehr haben“ Wir haben vor einiger Zeit einen Blogartikel veröffentlicht, der so hiess: „Warum wir keine festen Titel und Positionen mehr haben.“. So richtig brandneu ist das nicht. Viele Firmen machen das schon so, wir haben es dann nur verbloggt. Es gab sehr viel Feedback zu diesem Artikel, und eines hat dazu geführt, dass ich hierher eingeladen wurde. Aber es gab auch viel anderes Feedback.
- 3. „Die Mitarbeiter wollen das doch gar nicht.“ Eine der Anmerkungen war, dass die Kollegen das gar nicht wollen.
- 4. „Es muss Lenkerund Entscheider geben.“ Oder „Es muss Lenker und Entscheidet geben, Führungsrollen und Backboneinfrastruktur, damit es funktioniert.“
- 5. „Die Kollegen brauchenTitel und Positionen für die Karriere.“ Und der Kollegen ist ausserdem dagegen, weil er Titel und Positionen für die Visitenkarte braucht.
- 6. Grundannahme: Spannend hinter diesenganzen Kommentaren ist, dass sie die gleiche Hypothese haben: die Unternehmensleitung, also Albrecht, Björn und ich, haben beschlossen, dass das so läuft.
- 7. Tatsächliche Historie I 2005Das Management führt Scrum ein (!) 2006 Standort Würzburg schafft Scrum wieder ab. 2007 20% aller Kollegen werden Scrum-Master. Alle Geschäftsführer & Teamleads. 2008 Agile Fluency Level 1 und Cargo Cult 2010 XP-Practices: TDD, Pair Programming, CI/CD, Sustainable Pace etc, DevOps Community of Practice 2011 Scrum-Master != Teamleads (finally), Scrum by Heart 2012 Servant Leadership & Stewardship statt Transaktionales Management Tatsächlich sah das ganz anders aus. Wir haben 2005 auf die ebenso klassische wie dümmliche Art Scrum eingeführt, wie man das damals so tat - das Management, konkret ich, ha es eingeführt. Ich habe ein langes Memo gemacht, es gab einen Workshop, ein Whitepaper, viel Dokumentation und Training. In München, wo ich die Kollegen direkt vor der Flinte hatte blieb es auch erhalten - die Kollegen vom Standort Würzburg haben es probiert und sind dann recht schnell zu dem Schluss gekommen, dass Scrum nicht zu unserer Arbeit damals - also Webentwicklung - passt. 2 Jahre später haben wir dann alle Geschäftsführer und Teamleads zu Scrum-Mastern gemacht.
- 8. Tatsächliche Historie II 2012Das Team Allstars verzichtet auf feste Positionen. 2012 Viel Diskussion im Confluence 2012 Einzelne Teams geben Teamleiter zugunsten von Teamvertreter auf 2012 Unterschriftensammlung im Wiki „Ich verzichte auf meinen Titel“ - 85% unterschreiben. 2013 In München werden die Rollen von den Teams verteilt 2014 Gehälter und Feedback über agile Werkzeuge 2015 Ich verblogge, was die Kollegen 2012 gemacht haben. Tatsächlich sah das in der Praxis ganz anders aus. Wir haben in München lange Jahre ein sehr innovatives Team gehabt, mit Sebastian Springer als Teamleiter. Die haben nicht nur Zeit zum nachdenken gehabt, sondern auch viele gute Leute. Und die haben mit dynamischen Rollen angefangen. Parallel dazu haben andere Kollegen Blogartikel etc ins Wiki gehoben, die das behandelt haben. 2012 hat ein neu entstehendes Team direkt auf den Teamleiter verzichtet, und Basti hat gemeinsam mit seinem Team seine eigene hierarchische Teamleitung deaktiviert. Kollege Albrecht hat im Wiki das Experiment gemacht, einfach mal eine Umfrage zu machen, wer auf seinen Titel verzichten würde - und sehr schnell haben viele darauf verzichtet. 2013 und 2014 ist das in München dann über den ganzen Standort dynamisch geworden, es sind Werkzeuge wie Moving Motivators, Personality Poker, etc dazugekommen - auf initiative der Leute und Teams. Das habe ich dann „für die Nachwelt“ im Wiki zusammengefasst, und erst auf Wunsch der Kollegen in den Blog gestellt, weil die meinten, das wäre eine gute Idee.
- 9. There is nomasterplan. Es gab also keinen Masterplan. Das hat sich bei uns so ergeben.
- 10. Agil ist das,was neben den Fehlern von den Experimenten übrigbleibt. Emergente Methoden sind diejenigen, mit denen man häufiger gewinnt als verliert. Man könnte auch sagen: agil ist das, was von den Experimenten übrig bleibt, wenn man die Fehler abzieht.
- 11. Cynefin In komplexen Systemenkann der Zusammenhang zwischen Ursache und Wirkung nur im Nachhinein verstanden werden. Und wenn man Cynefin trauen darf, dann wäre so ein Masterplan auch gar nicht sinnvoll gewesen. Software - und gerade innovative Entwicklung im Web- und Mobile- Bereich wie bei uns - verhält sich komplex. Und in Komplexen Systemen gibt es keine direkte Verbindung von Ursache und Wirkung - sondern beide sind über Zeit getrennt. Aber man kann es im Nachhinein verstehen und erklären.
- 12. Dann versuche ichdas doch mal. Cynefin In komplexen Systemen kann der Zusammenhang zwischen Ursache und Wirkung nur im Nachhinein verstanden werden. Und deshalb bin ich heute hier. Um mal nachträglich zu schauen, warum es genau so gekommen ist. Erwarten sie auch keine brillanten Ideen von mir, das meiste von dem was wir tun ist geklaut. Hier auf diesem Laptop befinden sich 250 Fachbücher zu diesen Themen im Kindle, und da sind auch die von den anderen Sprechern hier dabei. Ein paar von unseren Scrub-Mastern haben auch bei Boris gelernt, und it-agile berät uns schon immer. Manchmal beim Bier privat und manchmal auch beauftragt.
- 13. Johann-Peter Hartmann @johannhartmann slideshare.net/johannhartmann Ich, das istJohann-Peter Hartmann, komme aus München und bin auch über Twitter zu erreichen. Im Moment mache ich wieder sehr viele Talks - alleine in diesem Herbst habe ich 7 neue Vorträge zu allen möglichen Themen von DevOps über Leadership zu Firmenkultur halten dürfen. Eigentlich komme ich aber von einem echten IT- Background, ich bin noch eins von den Kindern mit dem Commodore 64.
- 14. Im Sinne vonScrum bin ich bei dem Thema heute ein echtes Pig und kein Chicken. Ich habe die Firma, in der ich heute arbeite, vor 18 Jahren selbst gegründet, daneben noch eine Security-Firme gegründet, und bei zwei Startups war ich als Investor dabei. Agile Leadership und die damit verbundenen Fehler sind also eine Frage des eigenen Geldes, ich habe in meinem Leben praktisch nichts ausser diese Sachen geleistet und würde es daher ungern kaputt machen.
- 15. Chief Tailwind Officer Hacker Als ich dieerste Firma gegründet habe wurde ich als Hacker vom Dienst quasi automatisch der CTO. Durch die agile Geschichte von oben hat sich das dann quasi vollständig erledigt, weil die Teams selbst über das Wie - und damit auch über die eingesetzten Methoden, Lösungen und Werkzeuge - entscheiden. Also heisse ich seit 2012 „Chief Tailwind Officer“, das ist im Sinne von Servant Leadership und, um die Seefahrtsmetapher noch eins mehr zu überdehnen, Stewardship.
- 16. Was wir lernenmussten … Dann versuche ich mal zu erklären, wie sich das ganze ergeben hat.
- 17. Net Negative Productive (Senior) Progammer Ein schöner Fehlervon uns: wir haben in einem Team einen Entwickler gehabt, der sehr erfahren und ein sehr guter Developer ist. zu den meisten Themen bringt er ein wirklich gutes Knowhow mit, und weil er auch noch freundlich ist hört jeder gerne auf ihn.
- 18. Senior-Architect: alleine oder imPair für ca 40% der Storypoints eines 7-Kopf-Teams verantwortlich. Dann hat er das Team verlassen. Was ist mit der Teamperformance passiert? Und tatsächlich hat er durch die Decke performt. In einem 7 Entwickler grossem Team hat er 40% der Storypoints im Mittel durchgesetzt. Bei jedem Problem wurde zunächst mit ihm gesprochen, und man konnte seine Handschrift auch in den Klassen sehen, die die Kollegen entwickelten. Dann hat er das Team und die Firma verlassen, aus privaten Gründen und in guter Freundschaft. Unser Kunde kam umgehend zu mir und hat seiner Panik Ausdruck verliehen. Und ich habe ihm gleich ein viel höheres Geldangebot gemacht. Alle Deadlines haben gewackelt, und Angst machte sich breit. Was meinen Sie, was dann tatsächlich passiert ist?
- 19. +20% Genau, innerhalb dernächste 5 Sprints stieg die Performance des Teams auf 120% der ursprünglichen Performance. Die verbliebenen Kollegen haben seinen Performance nicht nur absorbiert, sondern sogar wieder aufgeholt.
- 20. Senior vs Junior Die nächste Geschichte. In einem Team hatten wir einen sehr erfahrenen Senior. Sein Name ist in vielen OpenSource-Bibliotheken zu finden, er ist der Datenbankguru und regelmässig als Speaker auf Konferenzen. Im gleichen Team hatten wir einen Auszubildenden, der nicht nur ziemlich pfiffig war, sondern auch engagiert - am Wochenende hat er gerne den Source gesäubert und Prototypen gebaut. Engagement war hoch, und er kannte sich nach kurzer Zeit sehr gut aus. Er kam mit guten Vorschlägen zur Anpassung und Gestaltung der Architektur, und weil sie alle mochten, wurden sie auch umgesetzt.
- 21. Senior Developer Senior Junior Offizielle VerantwortungKompetenz Wen haben dieKollegen bei Architekturfragen um Hilfe gebeten? Wenn Sie in diesem Team wären - wen hätten Sie zu Architekturthemen um Rat gefragt? Den mit der offiziellen Rolle, oder den Kollegen mit dem Detailwissen? Genau so war es bei uns auch - die Entwickler haben sich immer an den Kollegen mit dem konkreten Sachknowhow gewandt, nicht an den erfahrenen Kollegen, der sich mit der Applikation bei weitem nicht so gut auskannte.
- 22. Der obsolete Teamlead Und eindrittes Beispiel von uns: Beim Staffing eines neuen Teams war klar, dass es durch haarige Zeiten gehen würde. Die Firma, die mit dem Projekt begonnen hatte war an ihm insolvent gegangen, und alle Beteiligten waren am Ende Ihrer Kräfte.
- 23. Unklare Anforderungen Ambitionierte Architektur TechnicalDebt Dienstleister insolvent In diesem Projekt sah wirklich alles schlecht aus. Kunde war ein Konzern, bei dem die Fachabteilungen sich nicht ganz einig waren. Dementsprechend waren die Anforderungen unklar. Deshalb hatte der erste Dienstleister auf diesem Projekt auch seinen besten Architekten an das Projekt gesetzt, der seine Fähigkeiten auch gleich in einer ambitionierten Architektur dargelegt hat. Lieferdruck und Komplexität haben dann im Zusammenspiel dafür gesorgt, dass der Technical Debt schnell ansteigt, und am Ende gab es das, was es geben musste. Missglückter Launch, zweiter Versuch schlägt auch fehl, der Dienstleister geht insolvent.
- 24. Schwieriges Projekt: erfahreneKollegen & Stimmungsteamlead Als wir das Projekt erbten haben wir dementsprechend ein Team mit erfahrenen Kollegen - und einem emphatischen Teamlead zusammengestellt, um das zu überleben. Die Aufgabe vom Teamlead war klar - die Stimmung drehen, und die Lieferfähigkeit wieder herstellen.
- 25. Es hat funktioniert. ? Undes hat funktioniert - die Kollegen haben das Projekt gut eingefangen und auf Schienen gesetzt, und mit den ersten Erfolgen kam auch die gute Stimmung zurück. Ohne den Teamlead hätte es nicht funktioniert, er hat das Projekt tatsächlich gerettet. Aber: er wurde danach nicht mehr gebraucht. Der kritische Pfad war jetzt nicht mehr die Teamstimmung, sondern die operative Arbeit. Und da wanderten die Führungsaufgaben auch automatisch hin - zum erfahrenen Senior im Team, der Architektur gut mit den Kollegen diskutieren und verhandeln konnte, und zum Senior, der Vision und Alignment für das Produkt voll im Griff hatte und ein gutes Vertrauen geniesst.
- 26. Es wird keinTeamlead mehr gebraucht. ? Und dann waren wir in einer interessanten Situation. Der alte Teamlead war da, allgemein respektiert und anerkannt. Aber man brauchte ihn nicht mehr. Weil das Team inzwischen sehr reif war, war auch kein Ersatz notwendig. Formell brauchte zu diesem Zeitpunkt bei uns jedes Team einen Teamlead, und deshalb gab es ihn - aber faktisch hatte sich die Rolle für dieses Team erledigt, es gab keine Aufgaben mehr, die übrigblieben.
- 27. Der Scrum-Master, dergar keiner war. Und noch eine Geschichte. Wir hatten zu der Zeit noch die klassische Karriere - Junior, Developer, Senior, Teamleiter, Scrum-Master und Scrum-PO. Die Weiterentwicklung wurde vor allem durch die Vorgesetzten durchgeführt. Das hat zu interessanten Effekten geführt. Ein Kollege wollte gerne Scrum-Master werden, und das Feedback seiner Kollegen war gar nicht schlecht - sie trauten ihm das zu. Daraufhin haben wir ihn zur Zertifizierung geschickt und auf agile Konferenzen, und bei nächster Chance wurde er zum Scrum-Master in dem Team, das diese Rolle für ihn auch bestätigt hat. Faktisch handelt es sich bei dem Kollegen um einen klassischen Asperger-Fall, ein Nerd reinster Güte. Jeglicher Instinkt für die Emotion anderer Leute fehlt, die Kommunikation fällt im Scrub-Kontext schwer. Das hat natürlich nicht geklappt. Die Position war aber vergeben, und der Kollege hatte den Titel schon im Lebenslauf.
- 28. Da stimmt doch wasnicht. Wir haben noch viele solche Geschichten erlebt. Mein Kollegen Albrecht hat auf der OOP einen Talk über unsere schönsten Fehler gemacht, und wir haben eine viel grössere Sammlung im Wiki.
- 29. Allergile Reaktionen Dinge, die passieren, wennAgil Dinge transparent macht. Wir haben festgestellt, dass viele Dinge, wenn man sie mit agiler Arbeit bewirft, kaputtgehen. Da verhält sich agile Arbeit wahlweise wie Pandoras Büchse oder die Borg - wenn man einmal damit anfängt kommt alles in Bewegung, und plötzlich merkt man, wie Dinge in Wahrheit gar nicht so funktionieren, wie man bisher dachte. Es ist etwas ungerecht, dass ich hier agil den schwarzen Peter unterschiebe - agil macht nur transparent was wirklich geschieht, und wir sehen die komplexe Welt, die ohnehin schon da war.
- 30. So sollte agil eigentlich eingeführt werden… Deshalb sollten die anwesenden Herrn Gloger und Wolf eigentlich bei jeder Scrub-Einführung erst einmal folgende Frage stellen:
- 31. Dies ist deineletzte Chance - danach gibt es kein Zurück. [öffnet seine Hand] Schluckst du die blaue Kapsel, ist alles aus. Du wachst in deinem Bett auf und glaubst an das was du glauben willst. [öffnet die andere Hand] Schluckst du die rote Kapsel, bleibst du im Wunderland, und ich führe Dich in die tiefsten Tiefen des Kaninchenbaus. [Neo greift nach der roten Kapsel] Bedenke: Alles was ich dir anbiete ist die Wahrheit, nicht mehr. [Neo schluckt die rote Kapsel] Folge mir."
- 32. Die Architektur entwickeltsich durch die Arbeit der Kollegen kontinuierlich. Entscheidungen werden gemeinsam Visualisiert und getroffen. Der Architekt entscheidet über die Architektur. Und genau das ist uns passiert. Bisher gingen wir davon aus, dass der Architekt entscheidet, wie die Architektur auszusehen hat. Bei agilen Methoden ergab das keinen Sinn mehr. Architektur war keine Einmalaktion mehr, sonder passierte die ganze Zeit über, und an Stelle des Architekten kam die Querschnittfunktion des Architektur-Gärtnerns, die die ganze Zeit über passiert.
- 33. Das Team entscheidetüber das Wie. Es gibt Leadership für das WAS (der PO) und Leadership zur Unterstützung des Wie (der SCrum-Master) Es gibt einen Vorgesetzten, und der ist weisungsbefugt - er trägt ja auch die Verantwortung. Vorher gingen wir davon aus, dass der Vorgesetzte Anweisen kann - schliesslich trägt er auch die Verantwortung für das, was das Team produziert, gegenüber seiner Führungsebene. In der agilen Welt ist das Team verantwortlich für das Vorgehen. Der Vorgesetzten darf nicht mehr Anweisen. Der Scrum-PO darf immerhin noch ansagen, welche Arbeit in welcher Reihenfolge geschieht, der Scrum-Master selbst ist zum besseren Flaschengeist verkommen.
- 34. DevOps: das cRossfunktionaleTeam trägt die vollständige Verantwortung für Prozessverbesserung und Produkt, über den kompletten Valuestream. Es gibt einen Vorgesetzten, und der ist weisungsbefugt - er trägt ja auch die Verantwortung. DevOps geht an der Stelle sogar noch einen Schritt weiter und dehnt die Verantwortung des Teams auf die Gesamtstrecke - von Produktentwicklung bis zur Businessanalyse im operativen Betrieb - aus.
- 35. Wir verteilen dieAufgaben in jedem Sprint im Planning so, wie es das Team für richtig hält. Die Aufgaben sind klar in der Stellenbeschreibung dokumentiert. Sonst bitte den Teamleiter fragen. Bisher war es so, dass ich mir eine Stelle aussuchte nach den Aufgaben, damit ich das machen konnte was meinen Interessen und Fähigkeiten am meisten entgegen kommt. Statt dessen schaut sich das Team mit mir im Sprint Planning 2 alle 2 Wochen an, wer welche Aufgaben machen sollte. Und wenn meine Backend-Architektur- Fähigkeiten immer Ärger im Frontend erzeugen, dann paire ich mit dem UXler so lange bei seinen Aufgaben, dass es nicht wieder passiert.
- 36. Die Rollen imTeam werden in Retrospektiven nach Fähigkeit und Bedarf zugeordnet. Der Scrum-Master wird neuer PO, ein Kollege rückt nach. Die Position ist fix und ergibt sich aus dem Karrierelevel des Mitarbeiters. Bisher hatte ich einen klaren Karrierepfad, bei dem ich mich von Stufe zu Stufe bewege, und jede Stufe ist ein Upgrade in Macht, Ansehen und Geld. Ich mache das, was meine Position enthält. In der agilen Welt gibt es nicht immer für alle Positionen die definierten Aufgaben, und das ist auch nicht planbar. Also braucht es t-shaped - oder M-shaped Personen, die mehrere Rollen in Frage kommen. Und je nach Bedarf bedienen sie die Rolle, die das Projekt braucht.
- 37. Jeder ist füralles Verantwortlich. Es zählen nur Teamergebnisse. Im vernetzten gibt es nur selten alleine Schuldige oder alleine erfolgreiche. Wir haben klare Verantwortlichkeiten. Wenn niemand den Hut aufhat, dann passiert auch nichts. Bisher gab es klare Verantwortlichkeiten. Die klare Accountability sorgt dafür, dass die Leute sich verantwortlich fühlen. Ohne diese Verantwortung würde man weder kontrollieren, noch bestrafen und belohnen können. In der agilen Welt schlägt die Verantwortung auf alle durch. Es zählt das Teamergebnis im Produkt. Wenn ich in einer vernetzten Welt nach einem Schuldigen Suche lande ich immer im Blamestorming, und es kann auch jeder konstruieren, warum er er Vater des Erfolges war. So richtig eindeutig ist es in der Praxis aber nicht.
- 38. Der Projekterfolg isteine Gemeinschaftsleistung. Das team ist so erfolgreich wie seine Kooperation. Der Teamleiter ist für den Projekterfolg verantwortlich. Er kann Teile dieser Verantwortung delegieren. Bislang gingen wir davon aus, dass Verantwortung eine Kaskade war, die von ganz oben kommt und Stufe für Stufe in der Hierarchie nach unten verteilt wird. Im komplexen und vernetzten gibt es diese eindeutige Verantwortung nicht mehr. Ich weiß ja noch nicht mal, für welche Dinge ich am Ende überall Verantwortung gebraucht haben werden. Deshalb wechselt die Verantwortung nicht nur vom Individuum zum Team, sondern auch von der Teilverantwortung zur Gesamtverantwortung.
- 39. Viele kennen vermutlichdiese Team-Performance-Kurve von Katzenbach und Smith. Wie soll ich denn individuellen Erfolg als Ziel erklären, wenn der kooperative Erfolg viel höher ist. Was ist denn die Individualleistung im High Performing Team?
- 40. Im Gegensatz zumeinem Vorgesetzten können meine unmittelbaren Kollegen in Team und CoPS gut beurteilen, welche Talente und Interessen ich mitbringe. Der Vorgesetzte ist für die Weiterentwicklung verantwortlich. Gemeinsam mit dem Kollegen arbeitet er an der Weiterentwicklung. In der bisherigen Welt hatte der Vorgesetzte - oder die Vorgesetzten - die Macht über meine Weiterentwicklung. Sie haben mich beurteilt, meine Leistungen bewertet und mich dementsprechend weiterentwickelt. In komplexen Umgebungen ist der Effekt von Individualleistung von aussen praktisch nicht mehr zu erkennen. Faktisch ist mein Selbst- und mein Fremdbild oft nicht nah beieinander. Für ein angemessenes Bild ist eine kontinuierliche Diskussion nötig.
- 41. Wenn jemand sehrerfolgreich auf einem Thema arbeitet ist er offensichtlich am richtigen Platz. Die Entwicklung folgt diesen Talenten und seinen Interessen. Wer in einem Karrierelevel sehr erfolgreich arbeitet hat es sich verdient einen Schritt auf der Karriereleiter nach oben zu gehen. Bisher waren Karrieren weitgehend lineare Bewegungen nach oben. Wenn ich mich irgendwo bewährt habe, dann habe ich es mir redlich verdient, eine Stufe nach oben zu rutschen, und mit mehr Einfluss und Macht mehr zu bewegen. In komplexen Umgebungen ist die Wirksamkeit einer hierarchisch höhenwertigen Position nicht auch höher. Ganz im Gegenteil: wenn ein Kollege mit einer bestimmten Aufgabe sehr viel Benefit für das Unternehmen erzeugt, sollte man ihn dort genau nicht entfernen. Wenn man selbst - oder jemand im Unternehmen - an anderer Stelle einen höheren Benefit erwartet, dann sollte auch gewechselt werden. Auch um einem Bore-Out vorzubeugen.
- 42. Es gibt vieleFührungsaufgaben, die immer in Bewegung sind, neu entstehen und wieder vergehen. Sie sollten jeweils von der passenden Person bedient werden. Führung ist eine hierarchische Funktion. Sei hängt an höher bezahlten Positionen, die damit beauftragt sind. Bisher gingen wir davon aus, dass Führung eine hierarchische Funktion ist, die von einer Person auf einer hierarchischen Position eingenommen wird. Manchmal, in Matrix-Organisationen, wird diese Aufgabe auch individuell von 2 Personen bedient. Komplexe Welten können nur mit Selbstorganisation effektiv bedient werden, eine Steuerung von aussen ist nicht möglich. Management ist deshalb unwirksam, und Führungsaufgaben sind nur aus dem Inneren des Systems zu erkennen - und dort kann auch erkannt werden, wer diese Aufgabe am besten übernimmt.
- 43. Es dauert monate,bis man in eine komplexe Software eingearbeitet ist, und ein Team auf Performing-Level ist. Der Aufbau von neuen Kompetenzen ist preiswerter als das Einarbeiten. Wenn eine Kompetenz im Team fehlt, muss diese für den Zeitraum des Bedarfes nachgestafft werden. Bisher ging man davon aus, dass Kollegen mit Kompetenzen wie Legosteine zu einem grossen Ganzen zusammengesteckt werden können. Dass wir spontan einen Frontend-Entwickler oder einen Scrum-Master neu dazunehmen können, wenn der gerade fehlt. Heute wissen wir, dass nicht nur die Einarbeitung in eine komplexe Domäne oder Software Monate dauern kann, auch das Herstellen eines performanten Teams dauert lange. Wenn die Performance da ist sollte man den Teufel tun und sie nicht durch Personenschach zerstören, sondern lieber mit den vorhandenen Kollegen den Knowhowaufbau lokal vornehmen.
- 44. Hmpf. Das klingt sehraufwändig, ich würde das gerne vermeiden. Nachdem wir das alles gesehen hatten war unsere erste Reaktion etwa das: Das ist zu aufwändig. Erstens bekomme ich die Kultur des Unternehmens gar nicht so schnell gedreht, dass das gehen würde, zweitens: ist das überhaupt gesichert?
- 45. Das ist dochnur modernistische Agilromantik. So NewWork-Esoterik. Eine Basisdemokratische Träumerei. Ich meine, andere Unternehmen machen das ja auch nicht, und verdienen trotzdem viel Geld. Seien wir mal ehrlich: das ist doch nur so modernistische Agilromantik. NewWork-Esoterik, mit der Coaches jetzt die nächste Kuh durch das Dorf treiben. Das ist Basisdemokratisches Gutmenschentum in Unternehmen für die Zeit nach den Asylanten.
- 46. Komplexe Systeme verhalten sichauch dann noch komplex, wenn Sie es nicht möchten. Die agile Gemeinheit. Und genau da schlägt aber wieder die agile Gemeinheit zu. Komplexe Systeme verhalten sich auch dann wie welche, wenn man es nicht möchte. Und damit haben ich alle die Muster am Hals, die in diesen zu finden sind.
- 47. Selbstorganisation Inspect & Adapt Emergenz LernendeSysteme Die agile Gemeinheit. Ich habe Erfolgsstrategien für diese Welten - nämlich Selbstorganisation, Inspect & Adapt, Emergenz in Strukturen und Methoden und Antifragilität durch lernende Eigenschaften.
- 48. Selbstorganisation Inspect & Adapt Emergenz LernendeSysteme Positionen, Strukturen, Rollen, Führung Eigentlich ist unsere Aufgabe also ganz einfach: Da diese Regeln für komplexe Systeme universell sind, gelten Sie auch für Positionen, Strukturen, Rollen und Führung selbst.
- 49. Positionen, Strukturen, Rollen, Führung Komplexe Systemeverhalten sich auch dann noch komplex, wenn Sie es nicht möchten. Ich wiederhole noch einmal: Komplexe Systeme verhalten sich auch dann komplex, wenn Sie es nicht möchten.
- 50. Auftragsbearbeitung Buchhaltung Marketing Business Development Zentrale Dienste Team Team Team Team Team Team Pfirsichorganisation Wiejede deutsche agile Firma sind wir auch bei einem Pfirsichmodell von Niels Pfläging gelandet, bei dem weitgehend autonome Teams das Unternehmenszentrum als Service nutzen. Die Teams sind meist stabil.
- 51. Auftragsbearbeitung Buchhaltung Marketing Business Development Zentrale Dienste Team Team Team Team Team Pfirsichorganisation Team Zentrum Team Extern Aufgabenwandern per Markt dorthin, wo sie mittelfristig am günstigsten sind. Was im Team selbst, was im Zentrum oder was extern gemacht wird ist eine Frage des Marktes- es wird dort gemacht, wo es am günstigsten ist.
- 52. Quervernetzung über Communities of Practices Auchähnlich zu vielen agilen Unternehmen haben wir eine Quervernetzung über Communities of Practice. Viele kennen Sie heute als Gilden und Chapter, weil das bei uns älter ist als das Spotify-Modell heissen sie noch so, wie sie damals hiessen :-) Beispiel sind die agile COP, die DevOps-Gruppe, die Open-Device-Lab-Gruppe etc.
- 53. Rollen statt Positionen M-Shaped People Team Wirsprechen bei uns - ja, liegt auch am Firmennamen - von M-Shaped-Kollegen. Meist hat ein Kollege mehr als eine Kompetenz, der Datenbankmensch ist auch gut in System Engineering, der Product Owner ist auch gut im UX des User Journeys, der Scrum-Master kann auch als Product Owner oder als Coach für ein anderes Team arbeiten.
- 54. Rollen statt Positionen Retrospektiven: - Bedarfdokumentieren - Decision Matrix zu Optionen - intern oder extern? - Konsent Team Die Rollenverteilung innerhalb des Teams geschieht über Retrospektiven. Oft haben wir zwei Retrospektivenformate pro Team - einmal die zur Iteration gehörigen normalen Retrospektiven, dazu etwa zweimonatlich Grundsatzretrospektiven, bei denen es um die Betrachtung des Gesamtsystems geht. Da kann bei uns zB ein Kunde vom Team abgewählt werden. Dort werden auch die Rollen bei Bedarf adaptiert.
- 55. Rollen statt Positionen Rollentausch Rollenanpassung Rollenerzeugung Staffinganforderung Team Die Sachen,die dann passieren können ist ein einfacher Rollentausch - wir haben Teams, bei denen der Scrum-Master zum Product Owner wurde, der System-Engineer die Datenbank geerbt hat etc. Die Rolle kann auch neu definiert werden, es können auch neue Rollen geschaffen werden, die es so noch nicht im Team gab. Es entstehen auch Staffing-Anforderungen, wenn das Team es nicht alleine kann. Meist handelt es sich dann um Kollegen, mit denen man schon gearbeitet hat, um den Performing- Level nicht zu zerstören.
- 56. Rollen statt Positionen Wenn esnicht mehr funktioniert wird es deaktiviert. Da ist der Wechsel zu Rollen recht nützlich. Wenn die Umgebung sich so ändert, dass die Position die Aufgaben nicht mehr gerecht wird, dann hat man die Gelegenheit das ganze zu korrigieren. Es kann also passieren, dass eine gefühlte Herabsetzung passiert.
- 57. Weiterentwicklung und Kompetenzausbildungist tatsächlich ein schwieriges Thema. Kennt jemand diese Grafik? Die ist schon lange debunked, die Zahlen sind purer Unsinn. Tatsächlich ist Lernen von sehr viel mehr Faktoren abhängig, von Alter, Geschlecht, Umgebung,
- 58. Lernverhalten individuell unterschiedlich in informellerUmgebung selbstgesteuert und involviert besser mit praktischer Erfahrung in Verbindung mit vorhandenem Wissen besser mit positiver Einstellung zum Lernen Quelle: Training from the Back of the Room Tatsächlich ist das Lernverhalten hochunterschiedlich nach Person, und es gibt nur wenige Dinge, die für praktisch alle gelten. Zum Beispiel lernt man in informeller Umgebung besser, man lernt selbstgesteuert und involviert in das Lernen besser, eine positive Grundeinstellung zum Lernen verbessert auch das Lernresultat. Wenn ich Dinge auch praktisch anwende setzt sich das Wissen besser fest, und auch dann, wenn ich es selbst mit vorhandenem Wissen in Bezug setzen kann. Wenn man sich diese Methoden anschaut? Funktionieren Kurse gut? Oder Konferenzen?
- 59. Slack time Communities ofPractice Barcamps (z.B. 7.6-12.6.2016 auf Mallorca) Bei uns ist der Schwerpunkt damit auf Slacktime gerutscht, oder auch Google Time genannt. Das sind Arbeitszeiten, bei denen die Kollegen ausschliesslich selbst bestimmen, was zu tun ist. Wir stellen noch nicht mal den Anspruch darauf, dass sie mit Projekten oder der Firma zu tun haben. Aber: sie müssen den Kollegen vorgestellt werden. Analog gibt es Barcamps, die einmal im Jahr offsite für die ganze Firma stattfinden und als OpenSpace organisiert sind.
- 60. In den Slackdayswerden konkrete Projekte gemacht - hier ein paar Fotos davon - aber auch Themengebiete zur Fortbildung. Heute - genau jetzt ist das bei uns der Fall - gibt es zB die Themen Alignment herstellen, Teambewertung und Public Speaking als Thema. Aktuell werden ca 13 Slackdays pro Person genutzt, mit 26 Freitagen pro Jahr, Urlaub, Krankheit etc wären 19 möglich.
- 61. Communities of Practice BiWeekly Video-Conference ca4-5 Slackdays pro Jahr Hospitieren, Rotieren Dazu kommen unsere Communities of Practice, zum Beispiel mit dem Thema Agile Coaching (war mal Scrum), Product Owner, Dev&Ops (eher System-Engineering in Wahrheit), und das M-Team, das sich um Firmenkultur kümmert. Teilnehmen kann jeder, den das Thema interessiert - vorausgesetzt, dass sein Team die Teilnahme stützt. Dort wird auch besprochen, wer wo wie wann zur Probe Aufgaben übernimmt, hospitiert oder ähnliches.
- 62. s Curiosity Honor Acceptance Mastery Power Freedom Relatedness Order Goal Status Was passiert denn, wenn ich meine Position verliere? Unsere Erfahrung zeigt: Ja, das schmerzt in der Tat, und man muss damit umgehen. Ein Degradieren der eigenen Position ist etwas, was man dem eigenen sozialen Umfeld praktisch nicht mitteilen kann. Wenn man sich die intrinsischen Motivationen anschaut - ich nutze hier die Champfrogs-Liste von Jurgen Apollo ….
- 63. Curiosity Honor Acceptance Mastery Power Freedom Relatedness Order Goal Status … dann wirdetwa die Hälfte in Mitleidenschaft gezogen. Die Akzeptanz, die Anerkennung der Leistung, die Macht, der Handlungsspielraum, die Verlässlichkeit wie auch der eigene Status werden beschädigt. Ich glaube, dass es nicht möglich ist den Kollegen das Einkommen in Deutschland zu reduzieren. Das wäre aber, angesichts der schon ohnehin vorhandenen Einbußen, auch fast geschmacklos.
- 64. Selbstgewählte TitelChief Puppeteer Secret Weapon Kommunikator DevOpsShepherd Software Guy Communication Samurai Open Source Rockstar Mrs Monneypenny Personalgranate Das erste was wir gemacht haben - nach vielen Vorbildern - wir haben die Titel durch selbstgewählte Titel ersetzt. Da kommen so Titel wie oben zu sehen heraus. Das ist aber eher die Ausnahme - das Gros der Kollegen nimmt Titel, die passen und die in ihrem sozialen Graphen funktionieren. Die sichtbare Karriere ist dann eine, die der eigenen Entscheidung entspricht.
- 65. Rollenbeschreibung a la Holocracy Rolle:Infrastrukturreparierer Purpose: Buzz über Firma & Produkte erzeugen Domains: - Social-Media Accounts, Mailingliste - Inhalte auf Website & Blog Typische Aufgaben: - Verhältnis zu potentiellen Kunden aufbauen - Produkte und Firma auf den Kanälen promoten - Speaker & Kontakte vermitteln Dazu kommen interne Rollenbeschreibungen - die nicht die Position einer Person beschreiben, sondern die aktiv eingenommene Rolle innerhalb des Teams - die auch von einer anderen Person eingenommen werden kann.
- 66. Track-Record im Wiki ImWiki wird gesammelt: - Rollen des Kollegen - Kudos von Kollegen - Kundenstatements Die Dinge, die der Kollege macht werden auch im Wiki dokumentiert - mit Rolle, Kollegenjudos und Kundenstatements. Das macht die Weiterentwicklung und die Fähigkeitsakquisition transparent. Und man kann nachschlagen, wo man welches Knowhow findet, wenn man jemand mal im Rat fragen will.
- 67. Peer Review Poker PersonalityPoker Moving Motivators Daneben haben wir eine ganze Reihe von Tools im Einsatz, um Selbstbild und Fremdbild innerhalb des Teams in Gleichklang zu haben. Konkret setzen wir Personality Poker und Moving Motivators ein - wer nutzt das noch? Und wir haben einen Peer Review erarbeitet, bei dem man mit den Kollegen um die eigene Bewertung pokert - auch das ist wieder ein aktiver Abgleich mit dem Fremdbild.
- 68. Führungs- rollen Scrum-Master Scrum-PO Teamvertreter Unternehmensleitung Mit diesen Aktivitätenbewegt sich die Mitarbeiterentwicklung weg vom disziplinarischem Verantwortlichen. Die Führungsaufgaben im agilen teilen sich bei uns der Scrum-Master, der Scrum-PO, der Teamvertreter und die Unternehmensleitung.
- 69. Scrum Master Phase FührungsstilAufgaben Forming Autoritär, Coaching Prozess, Training Storming Autoritär, Coaching Prozess, Konfliktmanagement Norming Servant, Coaching Teambuilding, Transparenz Performing Servant, Obsolet Entwicklung, Sparring Der Scrum-Master agiert als typischer Servant Leader mit einem Schwerpunkt auf Coaching und Mentoring bei uns, meist gibt die Reife es her, dass er nicht direkt anweisen muss.
- 70. Product Owner Phase FührungsstilAufgaben Forming Autoritär Konzeption, Produktmanagement Storming Autoritär, Transaktional Produktmanagement, Constraints Norming Transaktional, Kooperativ Mentale Modelle, Purpose Performing Transformational, Kooperativ Purpose, mentale Modelle Der Scrum-PO hat neben der offensichtlichen Produktmanagementtätigkeit auch die Aufgabe die Vision und das gemeinsame Mentale Modell zu pflegen, also Enabling, Inspiration und Motivation zu schaffen.
- 71. Teamvertreter Phase Führungsstil Aufgaben FormingServant, Stewardship Unternehmensressourcen Storming Servant, Kooperativ Alignment, Ressourcen Norming Servant, Kooperativ Alignment, Ressourcen, Repräsentation Performing Stewardship, Kooperativ Entwicklung, Sparring Die ersten drei Rollen werden direkt vom Team bestimmt, die letzte vom Team ausgewählt . Der Scrum-Master agiert als typischer Servant Leader mit einem Schwerpunkt auf Coaching und Mentoring bei uns, meist gibt die Reife es her, dass er nicht direkt anweisen muss. Der Scrum-PO hat neben der offensichtlichen Produktmanagementtätigkeit auch die Aufgabe die Vision und das gemeinsame Mentale Modell zu pflegen, also Enabling, Inspiration und Motivation zu schaffen. Der Teamvertreter dient sowohl Stewardship als auch Alignment. Er hat das Team im Unternehmen zu vertreten, den Zugriff auf andere Ressourcen zu stützen und Alignment von Team und Unternehmen zu stützen. Manchmal ist das der Scrum-Master in Personalunion.
- 72. Unternehmensleitung Phase Führungsstil Aufgaben Forming Stewardship, Kooperativ Unternehmensressourcen, Alignment StormingStewardship, Obsolet Ressourcen, Aligment Norming Stewardship, Hosting Alignment, Ressourcen, Repräsentation Performing Stewardship, Servant, Kooperativ Organisationsentwicklung ermöglichen, Sparring Die Unternehmensleitung - bei uns leider immer noch in Personalunion mit Gründern und Gesellschaftern - aber ich glaube, dieses Machtkonglomerat gilt für viele agile Firmen - dient vor allem als Service nach Innen. Alignment ist dabei ein Teil des Services, dazu komme ich später.
- 73. Choose Your Own Boss CYOB Under hat eine einfache Lösung - Choose Your Own Boss. Gary Hamel sieht das in Zukunft für jede Leadership-Funktion. Google arbeitet heute schon zum Teil so, dort heisst es „distributed Leadership“. Die Lifetime-Position wird also in Zukunft für unsere Branche abgelöst durch eine Rolle, die auch von den Kollegen getragen wird.
- 74. Rolle Autorisierung Scrum-Master AufZeit vom Team bestimmt Scrum-PO Auf Zeit vom Team bestimmt Teamvertreter Auf Zeit vom Team bestimmt Geschäftsleitung Anhand des Problems aus N gewählt CYOB Mit diesen Aktivitäten bewegt sich die Mitarbeiterentwicklung weg vom disziplinarischem Verantwortlichen. Die Führungsaufgaben im agilen teilen sich bei uns der Scrum-Master, der Scrum-PO, der Teamvertreter und die Unternehmensleitung.
- 75. CYOB Selbstorganisation Inspect & Adapt Emergenz LernendeSysteme Durch die Anpassungsfähigkeit und den Markt ist Choose your own boss ebenfalls adaptionsfähig. Funktionierende Systeme entstehen dadurch, nicht funktionierende verschwinden wieder. Und man muss in der Führungsrolle plausible Angebote machen, um beauftragt zu werden. Ich habe nächste Woche zB einen Workshop mit den Kollegen aus den Teams, bei denen meine persönlichen Aufgaben von Ihnen per Business Value Poker verteilt werden.
- 76. Management As A Service Aufgaben Pflichten Beistellungsleistungen Dabei istnur der individuelle Faktor neu, eine interne API für „Management as a Service“ hatten wir schon im Rahmen einer Firmenretrospektive erzeugt. Dort sind nicht nur die Pflichten, sondern auch die Voraussetzungen dabei. Mit einigen Teams sind die noch mal extra verhandelt. Kein Spass: da steht sogar die angestrebte Lead time drin. Das ist bei einem vollen Terminkalender manchmal nicht so einfach, da wäre mir Cycle Time deutlich lieber. Aber wenn es nicht klappt kann man sich ja noch einen der Kollegen schnappen.
- 77. Verantwortung Verantwortungslose Führung. „Wie HostingLeadership, nur ohne Esoterik.“ Einer der Aspekte ist etwas, was ich „verantwortungslose Führung“ nenne. Konkret bedeutet das, dass ich keinerlei Entscheidungen für das Team treffe, auch wenn es lieber zu mir delegieren möchte.
- 78. Stakes vom Unternehmen explizitmachen Gewichtung durch das Team Optionen & Decision Matrix Verantwortungslose Führung. Team-Entscheidung Etwas, was wir häufig einsetzen wenn Stakes ausserhalb des Teams berücksichtig werden müssen: die externen Stakes werden ermittelt und explizit gemacht - gerne numerisch. Das Team bildet dann die Gesamthalt aller zu berücksichtigenden Stakes, gewichtet sie und notiert die Optionen, die aktuell zur Verfügung stehen und trifft eine Entscheidung. Auf die Weise bleiben die Entscheidungen und die Umsetzungsverantwortung beim Team.
- 79. Baustellen Aber natürlich gibtes bei uns noch viele Baustellen, ich greife mal eine heraus.
- 80. Alignment Autonomy „How“ „Was“, „Warum“ Was wir nochüberhaupt nicht im Griff haben ist das hier: Diese Grafik kennen vermutlich einige Leute hier. Sie stammt ursprünglich von Moltke, und wurde im Art of Action von Stephen Bungay. Moltke sieht Alignment und Autonomie nicht im Widerspruch, sondern als Faktoren, die parallel erfüllt werden müssen.
- 81. Alignment Autonomy „How“ „Was“, „Warum“ Wirksam keit Optimal, so sagter, ist die Wirksamkeit oben rechts - hohe Autonomie bei hohem Alignment.
- 82. Alignment Autonomy „How“ „Was“, „Warum“ Wirksam keit Im Moment sindwir etwa hier - wir haben sehr viel Autonomie, aber da gehört auch viel wirklose Autonomie dazu.
- 83. Alignment Autonomy „How“ „Was“, „Warum“ Wirklose Autonomie: Lokales Optimum!= globales Optimum Opportunismus GroupThink Das sind vor allem Dinge, die zwar im Teamkontext optimal sind - aber im Unternehmenskontext schädlich sind. Spotify nannte Anfang der Woche auf der Lean Kanban Central Europe zB das völlig verteilte Ticketing-System bei ihnen als Beispiel. Ein anderes Beispiel ist eine Microservice-Basierte Architektur, bei der gemeinsames Logging fehlt, so dass ein übergreifendes Business Analytics nicht mehr möglich ist. Wir haben bei uns mit 70 Entwicklern 7 unterschiedliche Chatsysteme im Einsatz - versuchen Sie da mal, ChatOps als Teil von DevOps zu nutzen. Aber auch Opportunismus und GroupThink, beides meistens unbewusst, tritt hier auf. Da fehlen uns noch Mechanismen, um das wieder auszubalancieren.
- 84. Alignment Autonomy „How“ „Was“, „Warum“ Wirksam keit Hier brauchen wirnoch einen Mechanismus zur Reduktion wirkloser Autonomie und Erzeugung von besserem Alignment. Da haben wir uns schon ein bisschen bewegt - über Workshops mit Gerhard Wohland, der die Kopf zB hinter dem Pfirsichmodell ist, Firmenretrospektiven und Futurespectives über die ganze Firma. Im Moment stehen die Inhalte von Scaling @ Lego von Henrik Kniberg hoch im Kurs. Hoffentlich wird uns die Woche auf der Insel im Juni da weiterbringen.
- 85. Fazit Komplexe System brauchenauch adaptive Aufgabenverteilung, Rollen und Führung. Bottom-Up autorisierte Rollen statt Positionen Mechanismen für Karriere, Entwicklung und Gehalt Alignment noch eher unklar :-) Die Kollegen nennen das „Management as a Service“. Da gibt es eine auf einer Firmenretrospektive definierte API, welche Dinge ein Geschäftsführer als Service bereitstellen soll. Das ganze gibt es auch umgekehrt - als API, die man umgekehrt braucht. Bei mir sieht das zB so aus, dass ich wöchentlich ein Mittagessen mit den Teams habe, bei den grossen Retros dabei bin, einen Tag alle zwei Wochen mit bei ihnen im Team bin und Zugriff auf den internen Chat habe, um die notwendige Basiskompetenz zu haben.
- 86. Danke! Fragen: @johannhartmann hartmann@mayflower.de Slides mitTonspur: http://slideshare.net/johannhartmann Wer Fragen hat, kann sich gerne an mich wenden. Wer Beratung dazu will -die Kollegen hier fragen, die können so Dinge.
- 87. Stiefkinder Ich hätte siegerne noch reingenommen … Jetzt kommen die Slides, die zeitlich gar nicht mehr gingen.
- 88. Erfolg Erfolg Erfolg Erfolg Misserfolg Peter- Prinzip Was uns dapassiert ist ist natürlich in der Managementliteratur wohldokumentiert. Die Beförderung ging so lange gut, bis der Level erreicht wurde, bei dem es nicht mehr funktioniert.
- 89. Erfolg Erfolg Erfolg ErfolgMisserfolg Peterprinzip Komplex Bei dynamischen undkomplexen Environments wird es noch eins schlimmer. Dort ist es normal, dass die Inkompetenz nicht durch die neue Position, sondern durch den Wandel des aktuellen Verhaltens der Position erzeugt wird.
- 90. Verantwortung „Jemand muss denHut aufhaben, sonst passiert gar nichts!“ Ein weiteres Thema von Führungspositionen ist die Verteilung von Verantwortung. Wir alle kennen den Spruch „Wenn niemand den Hut aufhat, dann wird auch gar nichts passieren.“
- 91. Verantwortung Architekt Senior Entwickler Teamleiter Projektmanager Teamleiter Deshalb gibtes oft in Firmen wie in Softwareteams klare Verantwortungen - für Design, Weiterentwicklung, den Prozess, den Teamerfolg, den Projekterfolg und die Weiterentwicklung der Kollegen.
- 92. Social Loafing Mit mehrLeuten weniger leisten! Warum Personen Ihre Leistung reduzieren, wenn sie in Teams arbeiten. Bei Teamarbeit gibt es schon eine ganze Weile Forschung zur Performance. Einer der wichtigen Punkte dort ist Social Loafing, also das reduzieren der individuellen Leistung in Teams. Folgende Gründe gibt es dafür: „lost in the crowd“,
- 93. Reduktion der eigenenLeistung, wenn … … die eigene Leistung für entbehrlich gehalten wird. Social Loafing Wenn die wichtigen Bereiche der Arbeit an die die Leitungsfunktionen verteilt werden, dann sinkt die Bedeutung der individuellen Leistung im Vergleich ab - „Dispensability of Effort“ passiert, man denkt, die eigene Leistung wäre verzichtbar. Und reduziert die Leistung dementsprechend.
- 94. Reduktion der eigenenLeistung, wenn … … der Zusammenhang zwischen eigener und der Teamleistung unklar ist Social Loafing Es gibt auch den Lost in the Crowd-Effekt. Wenn jede Leistung von mir noch mal vom Senior adaptiert wird, wenn ich nur Dinge mache, die mir vom Architekten und haarklein vorgegeben wurden - dann sehe ich nicht, was mein Beitrag zur Teamleistung ist.
- 95. Reduktion der eigenenLeistung, wenn … … die eigenen Aufgaben als simpel betrachtet werden Social Loafing Bei komplexen Aufgaben wirkt die Teamarbeit positiv auf die eigene Leistung - bei simplen Aufgaben ist das anders. Wenn also die anspruchsvollen Aufgaben zu den Architekten und den Seniors fallen, dann sinkt meine Leistung.
- 96. Reduktion der eigenenLeistung, wenn … … die Teamleistung selbst nicht anerkannt wird Social Loafing Das gilt auch für das grosse Ganze. Wenn die Teamleistung selbst nicht anerkannt wird, weil nur die Führungskräfte damit hausieren gehen - auch dann geht die Motivation verloren die eigene Leistung einzubringen.
- 97. Curiosity Honor Acceptance Mastery Power Freedom Relatedness Order Goal Status Opportunistische Karriere Das ist auchdurchaus verständlich - wenn meine Kernmotivatoren Ehre, Akzeptanz, Macht, Freiheit oder Status sind - dann habe ich eine starke Motivation im Rank nach oben zu kommen. Und daneben gibt es natürlich auch noch mehr Geld, sozialen Prestige, Respekt für die neue Position.
- 98. Bitte mitzählen: Wer hatsolches Verhalten schon erlebt?
- 99. „Bestimmte Informationen habe nurich - und ich gebe sie nicht weiter. Das ist ein taktischer Vorteil.“
- 100. „Ich streue dieInformationen im Unternehmen selektiv so, dass die Kollegen machen was ich für richtig halte.“
- 101. „Ich limitiere diezur Verfügung stehenden Optionen künstlich, um eine Entscheidung in meinem Sinne zu erleichtern.“
- 102. „Ich schalte michals Zwischenschritt beim Zugriff auf wichtige Ressourcen ein, obwohl ich keinen relevanten Beitrag habe.“
- 103. „Bestimmte Kommunikationskanäle müssen über michlaufen, damit ich Kritik und Whisteblowing an meiner Person frühzeitig erkennen kann. Dann kann ich mich direkt selbst darum kümmern.“
- 104. „Wenn ich sehe,dass Konkurrenz zu mir entsteht, versuche ich mich frühzeitig einzumischen.“
- 105. Wer hat solchesVerhalten schon erlebt?
- 106. Wer davon arbeitetin einem grossen Unternehmen?
- 107. Hand aufs Herz: Werhat sich schon so verhalten?
- 108. Autorisierte Rollen verhindern (zueinem guten Teil) opportunistisches Führungsverhalten.
Hinweis der Redaktion
- #3 Wir haben vor einiger Zeit einen Blogartikel veröffentlicht, der so hiess: „Warum wir keine festen Titel und Positionen mehr haben.“. So richtig brandneu ist das nicht. Viele Firmen machen das schon so, wir haben es dann nur verbloggt. Es gab sehr viel Feedback zu diesem Artikel, und eines hat dazu geführt, dass ich hierher eingeladen wurde. Aber es gab auch viel anderes Feedback.
- #4 Eine der Anmerkungen war, dass die Kollegen das gar nicht wollen.
- #5 Oder „Es muss Lenker und Entscheidet geben, Führungsrollen und Backboneinfrastruktur, damit es funktioniert.“
- #6 Und der Kollegen ist ausserdem dagegen, weil er Titel und Positionen für die Visitenkarte braucht.
- #7 Spannend hinter diesen ganzen Kommentaren ist, dass sie die gleiche Hypothese haben: die Unternehmensleitung, also Albrecht, Björn und ich, haben beschlossen, dass das so läuft.
- #8 Tatsächlich sah das ganz anders aus. Wir haben 2005 auf die ebenso klassische wie dümmliche Art Scrum eingeführt, wie man das damals so tat - das Management, konkret ich, ha es eingeführt. Ich habe ein langes Memo gemacht, es gab einen Workshop, ein Whitepaper, viel Dokumentation und Training. In München, wo ich die Kollegen direkt vor der Flinte hatte blieb es auch erhalten - die Kollegen vom Standort Würzburg haben es probiert und sind dann recht schnell zu dem Schluss gekommen, dass Scrum nicht zu unserer Arbeit damals - also Webentwicklung - passt. 2 Jahre später haben wir dann alle Geschäftsführer und Teamleads zu Scrum-Mastern gemacht.
- #9 Tatsächlich sah das in der Praxis ganz anders aus. Wir haben in München lange Jahre ein sehr innovatives Team gehabt, mit Sebastian Springer als Teamleiter. Die haben nicht nur Zeit zum nachdenken gehabt, sondern auch viele gute Leute. Und die haben mit dynamischen Rollen angefangen. Parallel dazu haben andere Kollegen Blogartikel etc ins Wiki gehoben, die das behandelt haben. 2012 hat ein neu entstehendes Team direkt auf den Teamleiter verzichtet, und Basti hat gemeinsam mit seinem Team seine eigene hierarchische Teamleitung deaktiviert. Kollege Albrecht hat im Wiki das Experiment gemacht, einfach mal eine Umfrage zu machen, wer auf seinen Titel verzichten würde - und sehr schnell haben viele darauf verzichtet. 2013 und 2014 ist das in München dann über den ganzen Standort dynamisch geworden, es sind Werkzeuge wie Moving Motivators, Personality Poker, etc dazugekommen - auf initiative der Leute und Teams. Das habe ich dann „für die Nachwelt“ im Wiki zusammengefasst, und erst auf Wunsch der Kollegen in den Blog gestellt, weil die meinten, das wäre eine gute Idee.
- #10 Es gab also keinen Masterplan. Das hat sich bei uns so ergeben.
- #11 Emergente Methoden sind diejenigen, mit denen man häufiger gewinnt als verliert. Man könnte auch sagen: agil ist das, was von den Experimenten übrig bleibt, wenn man die Fehler abzieht.
- #12 Und wenn man Cynefin trauen darf, dann wäre so ein Masterplan auch gar nicht sinnvoll gewesen. Software - und gerade innovative Entwicklung im Web- und Mobile-Bereich wie bei uns - verhält sich komplex. Und in Komplexen Systemen gibt es keine direkte Verbindung von Ursache und Wirkung - sondern beide sind über Zeit getrennt. Aber man kann es im Nachhinein verstehen und erklären.
- #13 Und deshalb bin ich heute hier. Um mal nachträglich zu schauen, warum es genau so gekommen ist. Erwarten sie auch keine brillanten Ideen von mir, das meiste von dem was wir tun ist geklaut. Hier auf diesem Laptop befinden sich 250 Fachbücher zu diesen Themen im Kindle, und da sind auch die von den anderen Sprechern hier dabei. Ein paar von unseren Scrub-Mastern haben auch bei Boris gelernt, und it-agile berät uns schon immer. Manchmal beim Bier privat und manchmal auch beauftragt.
- #14 Ich, das ist Johann-Peter Hartmann, komme aus München und bin auch über Twitter zu erreichen. Im Moment mache ich wieder sehr viele Talks - alleine in diesem Herbst habe ich 7 neue Vorträge zu allen möglichen Themen von DevOps über Leadership zu Firmenkultur halten dürfen. Eigentlich komme ich aber von einem echten IT-Background, ich bin noch eins von den Kindern mit dem Commodore 64.
- #15 Im Sinne von Scrum bin ich bei dem Thema heute ein echtes Pig und kein Chicken. Ich habe die Firma, in der ich heute arbeite, vor 18 Jahren selbst gegründet, daneben noch eine Security-Firme gegründet, und bei zwei Startups war ich als Investor dabei. Agile Leadership und die damit verbundenen Fehler sind also eine Frage des eigenen Geldes, ich habe in meinem Leben praktisch nichts ausser diese Sachen geleistet und würde es daher ungern kaputt machen.
- #16 Als ich die erste Firma gegründet habe wurde ich als Hacker vom Dienst quasi automatisch der CTO. Durch die agile Geschichte von oben hat sich das dann quasi vollständig erledigt, weil die Teams selbst über das Wie - und damit auch über die eingesetzten Methoden, Lösungen und Werkzeuge - entscheiden. Also heisse ich seit 2012 „Chief Tailwind Officer“, das ist im Sinne von Servant Leadership und, um die Seefahrtsmetapher noch eins mehr zu überdehnen, Stewardship.
- #17 Dann versuche ich mal zu erklären, wie sich das ganze ergeben hat.
- #18 Ein schöner Fehler von uns: wir haben in einem Team einen Entwickler gehabt, der sehr erfahren und ein sehr guter Developer ist. zu den meisten Themen bringt er ein wirklich gutes Knowhow mit, und weil er auch noch freundlich ist hört jeder gerne auf ihn.
- #19 Und tatsächlich hat er durch die Decke performt. In einem 7 Entwickler grossem Team hat er 40% der Storypoints im Mittel durchgesetzt. Bei jedem Problem wurde zunächst mit ihm gesprochen, und man konnte seine Handschrift auch in den Klassen sehen, die die Kollegen entwickelten. Dann hat er das Team und die Firma verlassen, aus privaten Gründen und in guter Freundschaft. Unser Kunde kam umgehend zu mir und hat seiner Panik Ausdruck verliehen. Und ich habe ihm gleich ein viel höheres Geldangebot gemacht. Alle Deadlines haben gewackelt, und Angst machte sich breit. Was meinen Sie, was dann tatsächlich passiert ist?
- #20 Genau, innerhalb der nächste 5 Sprints stieg die Performance des Teams auf 120% der ursprünglichen Performance. Die verbliebenen Kollegen haben seinen Performance nicht nur absorbiert, sondern sogar wieder aufgeholt.
- #21 Die nächste Geschichte. In einem Team hatten wir einen sehr erfahrenen Senior. Sein Name ist in vielen OpenSource-Bibliotheken zu finden, er ist der Datenbankguru und regelmässig als Speaker auf Konferenzen. Im gleichen Team hatten wir einen Auszubildenden, der nicht nur ziemlich pfiffig war, sondern auch engagiert - am Wochenende hat er gerne den Source gesäubert und Prototypen gebaut. Engagement war hoch, und er kannte sich nach kurzer Zeit sehr gut aus. Er kam mit guten Vorschlägen zur Anpassung und Gestaltung der Architektur, und weil sie alle mochten, wurden sie auch umgesetzt.
- #22 Wenn Sie in diesem Team wären - wen hätten Sie zu Architekturthemen um Rat gefragt? Den mit der offiziellen Rolle, oder den Kollegen mit dem Detailwissen? Genau so war es bei uns auch - die Entwickler haben sich immer an den Kollegen mit dem konkreten Sachknowhow gewandt, nicht an den erfahrenen Kollegen, der sich mit der Applikation bei weitem nicht so gut auskannte.
- #23 Und ein drittes Beispiel von uns: Beim Staffing eines neuen Teams war klar, dass es durch haarige Zeiten gehen würde. Die Firma, die mit dem Projekt begonnen hatte war an ihm insolvent gegangen, und alle Beteiligten waren am Ende Ihrer Kräfte.
- #24 In diesem Projekt sah wirklich alles schlecht aus. Kunde war ein Konzern, bei dem die Fachabteilungen sich nicht ganz einig waren. Dementsprechend waren die Anforderungen unklar. Deshalb hatte der erste Dienstleister auf diesem Projekt auch seinen besten Architekten an das Projekt gesetzt, der seine Fähigkeiten auch gleich in einer ambitionierten Architektur dargelegt hat. Lieferdruck und Komplexität haben dann im Zusammenspiel dafür gesorgt, dass der Technical Debt schnell ansteigt, und am Ende gab es das, was es geben musste. Missglückter Launch, zweiter Versuch schlägt auch fehl, der Dienstleister geht insolvent.
- #25 Als wir das Projekt erbten haben wir dementsprechend ein Team mit erfahrenen Kollegen - und einem emphatischen Teamlead zusammengestellt, um das zu überleben. Die Aufgabe vom Teamlead war klar - die Stimmung drehen, und die Lieferfähigkeit wieder herstellen.
- #26 Und es hat funktioniert - die Kollegen haben das Projekt gut eingefangen und auf Schienen gesetzt, und mit den ersten Erfolgen kam auch die gute Stimmung zurück. Ohne den Teamlead hätte es nicht funktioniert, er hat das Projekt tatsächlich gerettet. Aber: er wurde danach nicht mehr gebraucht. Der kritische Pfad war jetzt nicht mehr die Teamstimmung, sondern die operative Arbeit. Und da wanderten die Führungsaufgaben auch automatisch hin - zum erfahrenen Senior im Team, der Architektur gut mit den Kollegen diskutieren und verhandeln konnte, und zum Senior, der Vision und Alignment für das Produkt voll im Griff hatte und ein gutes Vertrauen geniesst.
- #27 Und dann waren wir in einer interessanten Situation. Der alte Teamlead war da, allgemein respektiert und anerkannt. Aber man brauchte ihn nicht mehr. Weil das Team inzwischen sehr reif war, war auch kein Ersatz notwendig. Formell brauchte zu diesem Zeitpunkt bei uns jedes Team einen Teamlead, und deshalb gab es ihn - aber faktisch hatte sich die Rolle für dieses Team erledigt, es gab keine Aufgaben mehr, die übrigblieben.
- #28 Und noch eine Geschichte. Wir hatten zu der Zeit noch die klassische Karriere - Junior, Developer, Senior, Teamleiter, Scrum-Master und Scrum-PO. Die Weiterentwicklung wurde vor allem durch die Vorgesetzten durchgeführt. Das hat zu interessanten Effekten geführt. Ein Kollege wollte gerne Scrum-Master werden, und das Feedback seiner Kollegen war gar nicht schlecht - sie trauten ihm das zu. Daraufhin haben wir ihn zur Zertifizierung geschickt und auf agile Konferenzen, und bei nächster Chance wurde er zum Scrum-Master in dem Team, das diese Rolle für ihn auch bestätigt hat. Faktisch handelt es sich bei dem Kollegen um einen klassischen Asperger-Fall, ein Nerd reinster Güte. Jeglicher Instinkt für die Emotion anderer Leute fehlt, die Kommunikation fällt im Scrub-Kontext schwer. Das hat natürlich nicht geklappt. Die Position war aber vergeben, und der Kollege hatte den Titel schon im Lebenslauf.
- #29 Wir haben noch viele solche Geschichten erlebt. Mein Kollegen Albrecht hat auf der OOP einen Talk über unsere schönsten Fehler gemacht, und wir haben eine viel grössere Sammlung im Wiki.
- #30 Wir haben festgestellt, dass viele Dinge, wenn man sie mit agiler Arbeit bewirft, kaputtgehen. Da verhält sich agile Arbeit wahlweise wie Pandoras Büchse oder die Borg - wenn man einmal damit anfängt kommt alles in Bewegung, und plötzlich merkt man, wie Dinge in Wahrheit gar nicht so funktionieren, wie man bisher dachte. Es ist etwas ungerecht, dass ich hier agil den schwarzen Peter unterschiebe - agil macht nur transparent was wirklich geschieht, und wir sehen die komplexe Welt, die ohnehin schon da war.
- #31 Deshalb sollten die anwesenden Herrn Gloger und Wolf eigentlich bei jeder Scrub-Einführung erst einmal folgende Frage stellen:
- #32 Dies ist deine letzte Chance - danach gibt es kein Zurück. [öffnet seine Hand] Schluckst du die blaue Kapsel, ist alles aus. Du wachst in deinem Bett auf und glaubst an das was du glauben willst. [öffnet die andere Hand] Schluckst du die rote Kapsel, bleibst du im Wunderland, und ich führe Dich in die tiefsten Tiefen des Kaninchenbaus. [Neo greift nach der roten Kapsel] Bedenke: Alles was ich dir anbiete ist die Wahrheit, nicht mehr. [Neo schluckt die rote Kapsel] Folge mir."
- #33 Und genau das ist uns passiert. Bisher gingen wir davon aus, dass der Architekt entscheidet, wie die Architektur auszusehen hat. Bei agilen Methoden ergab das keinen Sinn mehr. Architektur war keine Einmalaktion mehr, sonder passierte die ganze Zeit über, und an Stelle des Architekten kam die Querschnittfunktion des Architektur-Gärtnerns, die die ganze Zeit über passiert.
- #34 Vorher gingen wir davon aus, dass der Vorgesetzte Anweisen kann - schliesslich trägt er auch die Verantwortung für das, was das Team produziert, gegenüber seiner Führungsebene. In der agilen Welt ist das Team verantwortlich für das Vorgehen. Der Vorgesetzten darf nicht mehr Anweisen. Der Scrum-PO darf immerhin noch ansagen, welche Arbeit in welcher Reihenfolge geschieht, der Scrum-Master selbst ist zum besseren Flaschengeist verkommen.
- #35 DevOps geht an der Stelle sogar noch einen Schritt weiter und dehnt die Verantwortung des Teams auf die Gesamtstrecke - von Produktentwicklung bis zur Businessanalyse im operativen Betrieb - aus.
- #36 Bisher war es so, dass ich mir eine Stelle aussuchte nach den Aufgaben, damit ich das machen konnte was meinen Interessen und Fähigkeiten am meisten entgegen kommt. Statt dessen schaut sich das Team mit mir im Sprint Planning 2 alle 2 Wochen an, wer welche Aufgaben machen sollte. Und wenn meine Backend-Architektur-Fähigkeiten immer Ärger im Frontend erzeugen, dann paire ich mit dem UXler so lange bei seinen Aufgaben, dass es nicht wieder passiert.
- #37 Bisher hatte ich einen klaren Karrierepfad, bei dem ich mich von Stufe zu Stufe bewege, und jede Stufe ist ein Upgrade in Macht, Ansehen und Geld. Ich mache das, was meine Position enthält. In der agilen Welt gibt es nicht immer für alle Positionen die definierten Aufgaben, und das ist auch nicht planbar. Also braucht es t-shaped - oder M-shaped Personen, die mehrere Rollen in Frage kommen. Und je nach Bedarf bedienen sie die Rolle, die das Projekt braucht.
- #38 Bisher gab es klare Verantwortlichkeiten. Die klare Accountability sorgt dafür, dass die Leute sich verantwortlich fühlen. Ohne diese Verantwortung würde man weder kontrollieren, noch bestrafen und belohnen können. In der agilen Welt schlägt die Verantwortung auf alle durch. Es zählt das Teamergebnis im Produkt. Wenn ich in einer vernetzten Welt nach einem Schuldigen Suche lande ich immer im Blamestorming, und es kann auch jeder konstruieren, warum er er Vater des Erfolges war. So richtig eindeutig ist es in der Praxis aber nicht.
- #39 Bislang gingen wir davon aus, dass Verantwortung eine Kaskade war, die von ganz oben kommt und Stufe für Stufe in der Hierarchie nach unten verteilt wird. Im komplexen und vernetzten gibt es diese eindeutige Verantwortung nicht mehr. Ich weiß ja noch nicht mal, für welche Dinge ich am Ende überall Verantwortung gebraucht haben werden. Deshalb wechselt die Verantwortung nicht nur vom Individuum zum Team, sondern auch von der Teilverantwortung zur Gesamtverantwortung.
- #40 Viele kennen vermutlich diese Team-Performance-Kurve von Katzenbach und Smith. Wie soll ich denn individuellen Erfolg als Ziel erklären, wenn der kooperative Erfolg viel höher ist. Was ist denn die Individualleistung im High Performing Team?
- #41 In der bisherigen Welt hatte der Vorgesetzte - oder die Vorgesetzten - die Macht über meine Weiterentwicklung. Sie haben mich beurteilt, meine Leistungen bewertet und mich dementsprechend weiterentwickelt. In komplexen Umgebungen ist der Effekt von Individualleistung von aussen praktisch nicht mehr zu erkennen. Faktisch ist mein Selbst- und mein Fremdbild oft nicht nah beieinander. Für ein angemessenes Bild ist eine kontinuierliche Diskussion nötig.
- #42 Bisher waren Karrieren weitgehend lineare Bewegungen nach oben. Wenn ich mich irgendwo bewährt habe, dann habe ich es mir redlich verdient, eine Stufe nach oben zu rutschen, und mit mehr Einfluss und Macht mehr zu bewegen. In komplexen Umgebungen ist die Wirksamkeit einer hierarchisch höhenwertigen Position nicht auch höher. Ganz im Gegenteil: wenn ein Kollege mit einer bestimmten Aufgabe sehr viel Benefit für das Unternehmen erzeugt, sollte man ihn dort genau nicht entfernen. Wenn man selbst - oder jemand im Unternehmen - an anderer Stelle einen höheren Benefit erwartet, dann sollte auch gewechselt werden. Auch um einem Bore-Out vorzubeugen.
- #43 Bisher gingen wir davon aus, dass Führung eine hierarchische Funktion ist, die von einer Person auf einer hierarchischen Position eingenommen wird. Manchmal, in Matrix-Organisationen, wird diese Aufgabe auch individuell von 2 Personen bedient. Komplexe Welten können nur mit Selbstorganisation effektiv bedient werden, eine Steuerung von aussen ist nicht möglich. Management ist deshalb unwirksam, und Führungsaufgaben sind nur aus dem Inneren des Systems zu erkennen - und dort kann auch erkannt werden, wer diese Aufgabe am besten übernimmt.
- #44 Bisher ging man davon aus, dass Kollegen mit Kompetenzen wie Legosteine zu einem grossen Ganzen zusammengesteckt werden können. Dass wir spontan einen Frontend-Entwickler oder einen Scrum-Master neu dazunehmen können, wenn der gerade fehlt. Heute wissen wir, dass nicht nur die Einarbeitung in eine komplexe Domäne oder Software Monate dauern kann, auch das Herstellen eines performanten Teams dauert lange. Wenn die Performance da ist sollte man den Teufel tun und sie nicht durch Personenschach zerstören, sondern lieber mit den vorhandenen Kollegen den Knowhowaufbau lokal vornehmen.
- #45 Nachdem wir das alles gesehen hatten war unsere erste Reaktion etwa das: Das ist zu aufwändig. Erstens bekomme ich die Kultur des Unternehmens gar nicht so schnell gedreht, dass das gehen würde, zweitens: ist das überhaupt gesichert?
- #46 Ich meine, andere Unternehmen machen das ja auch nicht, und verdienen trotzdem viel Geld. Seien wir mal ehrlich: das ist doch nur so modernistische Agilromantik. NewWork-Esoterik, mit der Coaches jetzt die nächste Kuh durch das Dorf treiben. Das ist Basisdemokratisches Gutmenschentum in Unternehmen für die Zeit nach den Asylanten.
- #47 Und genau da schlägt aber wieder die agile Gemeinheit zu. Komplexe Systeme verhalten sich auch dann wie welche, wenn man es nicht möchte. Und damit haben ich alle die Muster am Hals, die in diesen zu finden sind.
- #48 Ich habe Erfolgsstrategien für diese Welten - nämlich Selbstorganisation, Inspect & Adapt, Emergenz in Strukturen und Methoden und Antifragilität durch lernende Eigenschaften.
- #49 Eigentlich ist unsere Aufgabe also ganz einfach: Da diese Regeln für komplexe Systeme universell sind, gelten Sie auch für Positionen, Strukturen, Rollen und Führung selbst.
- #50 Ich wiederhole noch einmal: Komplexe Systeme verhalten sich auch dann komplex, wenn Sie es nicht möchten.
- #51 Wie jede deutsche agile Firma sind wir auch bei einem Pfirsichmodell von Niels Pfläging gelandet, bei dem weitgehend autonome Teams das Unternehmenszentrum als Service nutzen. Die Teams sind meist stabil.
- #52 Was im Team selbst, was im Zentrum oder was extern gemacht wird ist eine Frage des Marktes- es wird dort gemacht, wo es am günstigsten ist.
- #53 Auch ähnlich zu vielen agilen Unternehmen haben wir eine Quervernetzung über Communities of Practice. Viele kennen Sie heute als Gilden und Chapter, weil das bei uns älter ist als das Spotify-Modell heissen sie noch so, wie sie damals hiessen :-) Beispiel sind die agile COP, die DevOps-Gruppe, die Open-Device-Lab-Gruppe etc.
- #54 Wir sprechen bei uns - ja, liegt auch am Firmennamen - von M-Shaped-Kollegen. Meist hat ein Kollege mehr als eine Kompetenz, der Datenbankmensch ist auch gut in System Engineering, der Product Owner ist auch gut im UX des User Journeys, der Scrum-Master kann auch als Product Owner oder als Coach für ein anderes Team arbeiten.
- #55 Die Rollenverteilung innerhalb des Teams geschieht über Retrospektiven. Oft haben wir zwei Retrospektivenformate pro Team - einmal die zur Iteration gehörigen normalen Retrospektiven, dazu etwa zweimonatlich Grundsatzretrospektiven, bei denen es um die Betrachtung des Gesamtsystems geht. Da kann bei uns zB ein Kunde vom Team abgewählt werden. Dort werden auch die Rollen bei Bedarf adaptiert.
- #56 Die Sachen, die dann passieren können ist ein einfacher Rollentausch - wir haben Teams, bei denen der Scrum-Master zum Product Owner wurde, der System-Engineer die Datenbank geerbt hat etc. Die Rolle kann auch neu definiert werden, es können auch neue Rollen geschaffen werden, die es so noch nicht im Team gab. Es entstehen auch Staffing-Anforderungen, wenn das Team es nicht alleine kann. Meist handelt es sich dann um Kollegen, mit denen man schon gearbeitet hat, um den Performing-Level nicht zu zerstören.
- #57 Da ist der Wechsel zu Rollen recht nützlich. Wenn die Umgebung sich so ändert, dass die Position die Aufgaben nicht mehr gerecht wird, dann hat man die Gelegenheit das ganze zu korrigieren. Es kann also passieren, dass eine gefühlte Herabsetzung passiert.
- #58 Weiterentwicklung und Kompetenzausbildung ist tatsächlich ein schwieriges Thema. Kennt jemand diese Grafik? Die ist schon lange debunked, die Zahlen sind purer Unsinn. Tatsächlich ist Lernen von sehr viel mehr Faktoren abhängig, von Alter, Geschlecht, Umgebung,
- #59 Quelle: Training from the Back of the Room Tatsächlich ist das Lernverhalten hochunterschiedlich nach Person, und es gibt nur wenige Dinge, die für praktisch alle gelten. Zum Beispiel lernt man in informeller Umgebung besser, man lernt selbstgesteuert und involviert in das Lernen besser, eine positive Grundeinstellung zum Lernen verbessert auch das Lernresultat. Wenn ich Dinge auch praktisch anwende setzt sich das Wissen besser fest, und auch dann, wenn ich es selbst mit vorhandenem Wissen in Bezug setzen kann. Wenn man sich diese Methoden anschaut? Funktionieren Kurse gut? Oder Konferenzen?
- #60 Bei uns ist der Schwerpunkt damit auf Slacktime gerutscht, oder auch Google Time genannt. Das sind Arbeitszeiten, bei denen die Kollegen ausschliesslich selbst bestimmen, was zu tun ist. Wir stellen noch nicht mal den Anspruch darauf, dass sie mit Projekten oder der Firma zu tun haben. Aber: sie müssen den Kollegen vorgestellt werden. Analog gibt es Barcamps, die einmal im Jahr offsite für die ganze Firma stattfinden und als OpenSpace organisiert sind.
- #61 In den Slackdays werden konkrete Projekte gemacht - hier ein paar Fotos davon - aber auch Themengebiete zur Fortbildung. Heute - genau jetzt ist das bei uns der Fall - gibt es zB die Themen Alignment herstellen, Teambewertung und Public Speaking als Thema. Aktuell werden ca 13 Slackdays pro Person genutzt, mit 26 Freitagen pro Jahr, Urlaub, Krankheit etc wären 19 möglich.
- #62 Dazu kommen unsere Communities of Practice, zum Beispiel mit dem Thema Agile Coaching (war mal Scrum), Product Owner, Dev&Ops (eher System-Engineering in Wahrheit), und das M-Team, das sich um Firmenkultur kümmert. Teilnehmen kann jeder, den das Thema interessiert - vorausgesetzt, dass sein Team die Teilnahme stützt. Dort wird auch besprochen, wer wo wie wann zur Probe Aufgaben übernimmt, hospitiert oder ähnliches.
- #63 Unsere Erfahrung zeigt: Ja, das schmerzt in der Tat, und man muss damit umgehen. Ein Degradieren der eigenen Position ist etwas, was man dem eigenen sozialen Umfeld praktisch nicht mitteilen kann. Wenn man sich die intrinsischen Motivationen anschaut - ich nutze hier die Champfrogs-Liste von Jurgen Apollo ….
- #64 … dann wird etwa die Hälfte in Mitleidenschaft gezogen. Die Akzeptanz, die Anerkennung der Leistung, die Macht, der Handlungsspielraum, die Verlässlichkeit wie auch der eigene Status werden beschädigt. Ich glaube, dass es nicht möglich ist den Kollegen das Einkommen in Deutschland zu reduzieren. Das wäre aber, angesichts der schon ohnehin vorhandenen Einbußen, auch fast geschmacklos.
- #65 Das erste was wir gemacht haben - nach vielen Vorbildern - wir haben die Titel durch selbstgewählte Titel ersetzt. Da kommen so Titel wie oben zu sehen heraus. Das ist aber eher die Ausnahme - das Gros der Kollegen nimmt Titel, die passen und die in ihrem sozialen Graphen funktionieren. Die sichtbare Karriere ist dann eine, die der eigenen Entscheidung entspricht.
- #66 Dazu kommen interne Rollenbeschreibungen - die nicht die Position einer Person beschreiben, sondern die aktiv eingenommene Rolle innerhalb des Teams - die auch von einer anderen Person eingenommen werden kann.
- #67 Die Dinge, die der Kollege macht werden auch im Wiki dokumentiert - mit Rolle, Kollegenjudos und Kundenstatements. Das macht die Weiterentwicklung und die Fähigkeitsakquisition transparent. Und man kann nachschlagen, wo man welches Knowhow findet, wenn man jemand mal im Rat fragen will.
- #68 Daneben haben wir eine ganze Reihe von Tools im Einsatz, um Selbstbild und Fremdbild innerhalb des Teams in Gleichklang zu haben. Konkret setzen wir Personality Poker und Moving Motivators ein - wer nutzt das noch? Und wir haben einen Peer Review erarbeitet, bei dem man mit den Kollegen um die eigene Bewertung pokert - auch das ist wieder ein aktiver Abgleich mit dem Fremdbild.
- #69 Mit diesen Aktivitäten bewegt sich die Mitarbeiterentwicklung weg vom disziplinarischem Verantwortlichen. Die Führungsaufgaben im agilen teilen sich bei uns der Scrum-Master, der Scrum-PO, der Teamvertreter und die Unternehmensleitung.
- #70 Der Scrum-Master agiert als typischer Servant Leader mit einem Schwerpunkt auf Coaching und Mentoring bei uns, meist gibt die Reife es her, dass er nicht direkt anweisen muss.
- #71 Der Scrum-PO hat neben der offensichtlichen Produktmanagementtätigkeit auch die Aufgabe die Vision und das gemeinsame Mentale Modell zu pflegen, also Enabling, Inspiration und Motivation zu schaffen.
- #72 Die ersten drei Rollen werden direkt vom Team bestimmt, die letzte vom Team ausgewählt . Der Scrum-Master agiert als typischer Servant Leader mit einem Schwerpunkt auf Coaching und Mentoring bei uns, meist gibt die Reife es her, dass er nicht direkt anweisen muss. Der Scrum-PO hat neben der offensichtlichen Produktmanagementtätigkeit auch die Aufgabe die Vision und das gemeinsame Mentale Modell zu pflegen, also Enabling, Inspiration und Motivation zu schaffen. Der Teamvertreter dient sowohl Stewardship als auch Alignment. Er hat das Team im Unternehmen zu vertreten, den Zugriff auf andere Ressourcen zu stützen und Alignment von Team und Unternehmen zu stützen. Manchmal ist das der Scrum-Master in Personalunion.
- #73 Die Unternehmensleitung - bei uns leider immer noch in Personalunion mit Gründern und Gesellschaftern - aber ich glaube, dieses Machtkonglomerat gilt für viele agile Firmen - dient vor allem als Service nach Innen. Alignment ist dabei ein Teil des Services, dazu komme ich später.
- #74 Und er hat eine einfache Lösung - Choose Your Own Boss. Gary Hamel sieht das in Zukunft für jede Leadership-Funktion. Google arbeitet heute schon zum Teil so, dort heisst es „distributed Leadership“. Die Lifetime-Position wird also in Zukunft für unsere Branche abgelöst durch eine Rolle, die auch von den Kollegen getragen wird.
- #75 Mit diesen Aktivitäten bewegt sich die Mitarbeiterentwicklung weg vom disziplinarischem Verantwortlichen. Die Führungsaufgaben im agilen teilen sich bei uns der Scrum-Master, der Scrum-PO, der Teamvertreter und die Unternehmensleitung.
- #76 Durch die Anpassungsfähigkeit und den Markt ist Choose your own boss ebenfalls adaptionsfähig. Funktionierende Systeme entstehen dadurch, nicht funktionierende verschwinden wieder. Und man muss in der Führungsrolle plausible Angebote machen, um beauftragt zu werden. Ich habe nächste Woche zB einen Workshop mit den Kollegen aus den Teams, bei denen meine persönlichen Aufgaben von Ihnen per Business Value Poker verteilt werden.
- #77 Dabei ist nur der individuelle Faktor neu, eine interne API für „Management as a Service“ hatten wir schon im Rahmen einer Firmenretrospektive erzeugt. Dort sind nicht nur die Pflichten, sondern auch die Voraussetzungen dabei. Mit einigen Teams sind die noch mal extra verhandelt. Kein Spass: da steht sogar die angestrebte Lead time drin. Das ist bei einem vollen Terminkalender manchmal nicht so einfach, da wäre mir Cycle Time deutlich lieber. Aber wenn es nicht klappt kann man sich ja noch einen der Kollegen schnappen.
- #78 Einer der Aspekte ist etwas, was ich „verantwortungslose Führung“ nenne. Konkret bedeutet das, dass ich keinerlei Entscheidungen für das Team treffe, auch wenn es lieber zu mir delegieren möchte.
- #79 Etwas, was wir häufig einsetzen wenn Stakes ausserhalb des Teams berücksichtig werden müssen: die externen Stakes werden ermittelt und explizit gemacht - gerne numerisch. Das Team bildet dann die Gesamthalt aller zu berücksichtigenden Stakes, gewichtet sie und notiert die Optionen, die aktuell zur Verfügung stehen und trifft eine Entscheidung. Auf die Weise bleiben die Entscheidungen und die Umsetzungsverantwortung beim Team.
- #80 Aber natürlich gibt es bei uns noch viele Baustellen, ich greife mal eine heraus.
- #81 Was wir noch überhaupt nicht im Griff haben ist das hier: Diese Grafik kennen vermutlich einige Leute hier. Sie stammt ursprünglich von Moltke, und wurde im Art of Action von Stephen Bungay. Moltke sieht Alignment und Autonomie nicht im Widerspruch, sondern als Faktoren, die parallel erfüllt werden müssen.
- #82 Optimal, so sagt er, ist die Wirksamkeit oben rechts - hohe Autonomie bei hohem Alignment.
- #83 Im Moment sind wir etwa hier - wir haben sehr viel Autonomie, aber da gehört auch viel wirklose Autonomie dazu.
- #84 Das sind vor allem Dinge, die zwar im Teamkontext optimal sind - aber im Unternehmenskontext schädlich sind. Spotify nannte Anfang der Woche auf der Lean Kanban Central Europe zB das völlig verteilte Ticketing-System bei ihnen als Beispiel. Ein anderes Beispiel ist eine Microservice-Basierte Architektur, bei der gemeinsames Logging fehlt, so dass ein übergreifendes Business Analytics nicht mehr möglich ist. Wir haben bei uns mit 70 Entwicklern 7 unterschiedliche Chatsysteme im Einsatz - versuchen Sie da mal, ChatOps als Teil von DevOps zu nutzen. Aber auch Opportunismus und GroupThink, beides meistens unbewusst, tritt hier auf. Da fehlen uns noch Mechanismen, um das wieder auszubalancieren.
- #85 Hier brauchen wir noch einen Mechanismus zur Reduktion wirkloser Autonomie und Erzeugung von besserem Alignment. Da haben wir uns schon ein bisschen bewegt - über Workshops mit Gerhard Wohland, der die Kopf zB hinter dem Pfirsichmodell ist, Firmenretrospektiven und Futurespectives über die ganze Firma. Im Moment stehen die Inhalte von Scaling @ Lego von Henrik Kniberg hoch im Kurs. Hoffentlich wird uns die Woche auf der Insel im Juni da weiterbringen.
- #86 Die Kollegen nennen das „Management as a Service“. Da gibt es eine auf einer Firmenretrospektive definierte API, welche Dinge ein Geschäftsführer als Service bereitstellen soll. Das ganze gibt es auch umgekehrt - als API, die man umgekehrt braucht. Bei mir sieht das zB so aus, dass ich wöchentlich ein Mittagessen mit den Teams habe, bei den grossen Retros dabei bin, einen Tag alle zwei Wochen mit bei ihnen im Team bin und Zugriff auf den internen Chat habe, um die notwendige Basiskompetenz zu haben.
- #87 Wer Fragen hat, kann sich gerne an mich wenden. Wer Beratung dazu will -die Kollegen hier fragen, die können so Dinge.
- #88 Jetzt kommen die Slides, die zeitlich gar nicht mehr gingen.
- #89 Was uns da passiert ist ist natürlich in der Managementliteratur wohldokumentiert. Die Beförderung ging so lange gut, bis der Level erreicht wurde, bei dem es nicht mehr funktioniert.
- #90 Bei dynamischen und komplexen Environments wird es noch eins schlimmer. Dort ist es normal, dass die Inkompetenz nicht durch die neue Position, sondern durch den Wandel des aktuellen Verhaltens der Position erzeugt wird.
- #91 Ein weiteres Thema von Führungspositionen ist die Verteilung von Verantwortung. Wir alle kennen den Spruch „Wenn niemand den Hut aufhat, dann wird auch gar nichts passieren.“
- #92 Deshalb gibt es oft in Firmen wie in Softwareteams klare Verantwortungen - für Design, Weiterentwicklung, den Prozess, den Teamerfolg, den Projekterfolg und die Weiterentwicklung der Kollegen.
- #93 Bei Teamarbeit gibt es schon eine ganze Weile Forschung zur Performance. Einer der wichtigen Punkte dort ist Social Loafing, also das reduzieren der individuellen Leistung in Teams. Folgende Gründe gibt es dafür: „lost in the crowd“,
- #94 Wenn die wichtigen Bereiche der Arbeit an die die Leitungsfunktionen verteilt werden, dann sinkt die Bedeutung der individuellen Leistung im Vergleich ab - „Dispensability of Effort“ passiert, man denkt, die eigene Leistung wäre verzichtbar. Und reduziert die Leistung dementsprechend.
- #95 Es gibt auch den Lost in the Crowd-Effekt. Wenn jede Leistung von mir noch mal vom Senior adaptiert wird, wenn ich nur Dinge mache, die mir vom Architekten und haarklein vorgegeben wurden - dann sehe ich nicht, was mein Beitrag zur Teamleistung ist.
- #96 Bei komplexen Aufgaben wirkt die Teamarbeit positiv auf die eigene Leistung - bei simplen Aufgaben ist das anders. Wenn also die anspruchsvollen Aufgaben zu den Architekten und den Seniors fallen, dann sinkt meine Leistung.
- #97 Das gilt auch für das grosse Ganze. Wenn die Teamleistung selbst nicht anerkannt wird, weil nur die Führungskräfte damit hausieren gehen - auch dann geht die Motivation verloren die eigene Leistung einzubringen.
- #98 Das ist auch durchaus verständlich - wenn meine Kernmotivatoren Ehre, Akzeptanz, Macht, Freiheit oder Status sind - dann habe ich eine starke Motivation im Rank nach oben zu kommen. Und daneben gibt es natürlich auch noch mehr Geld, sozialen Prestige, Respekt für die neue Position.