Warum Lachen im professionellen Umfeld so wichtig ist

In einem Gesuch für einen Agile Coach las ich neulich etwas sehr Bemerkenswertes unter der Überschrift „Das bringst du mit“:

Du solltest mindestens zwei Mal am Tag lachen!

Lächerlich? Ganz und gar nicht. Denn…

Lachen hilft, trockene Themen locker anzugehen – werden sie mit einer Prise Humor in kleine Geschichten eingebettet, wird der Zuhörer sogar darin unterstützt, sich die Inhalte besser zu merken (nicht umsonst heißen die User Stories User Stories).
Weitere Gründe:

  • Widerstände gegenüber Veränderungen und bedrohlich wirkende Dinge werden mit der richtigen Portion Humor wohlwollender aufgenommen.
  • Lachen stiftet eine angenehmere Arbeitsatmosphäre und wirkt ansteckend!
  • Lachen, Forschen und Erfinden gehen auf denselben Mechanismus zurück: Das „Haha!“ steckt im Lachen, das „Aha!“ im Begreifen und das „Ahh!“ im Entdecken (aus: „Heel of Achilles“,Koestler 1976) .Eine Aufgabe von Scrum Mastern und Agile Coaches ist es, die Rahmenbedingungen der Teams so zu gestalten, dass ihr kreativer Geist und dadurch ihre Produktivität gefördert werden.
    Kein Wunder also, dass sie selbst lachen und vor allem andere zum Lachen bringen können sollten :-).

Sven Röpstorff im Interview

In der Interview-Kolumne befrage ich in unregelmäßigen Abständen bekannte Gesichter der Agile-Szene zu aktuellen Themen.
Heute freue ich mich, meinen Lesern das erste Interview vorstellen zu können. Mein Interview-Parntner: Sven Röpstorff, „Agile By Nature“!

Georg:
Hallo Sven,
toll, dass du dir die Zeit für dieses Interview genommen hast!

Du bist als Agile Coach in ganz Deutschland unterwegs und hast deine Erfahrungen, die du als Scrum-Master und Agile Coach in den zurückliegenden Jahren gemacht hast, zusammen mit Robert Wiechmann in dem Buch “Scrum in der Praxis” vereint.
“Agile” und “Scrum” sind in aller Munde und werden in vielen Unternehmen bereits praktiziert. Dennoch heißt es nicht zu Unrecht: “Scrum zu verstehen ist einfach, Scrum richtig umzusetzen jedoch nicht so sehr”.
Welches sind aus deiner Sicht die größten Herausforderungen, vor denen Unternehmen heute stehen, wenn sie Scrum bereits einsetzen?

Sven:
Hallo Georg, vielen Dank, dass ich heute dein Interviewpartner sein darf.

Ich beobachte immer wieder, dass Unternehmen lediglich die Prozesskomponente von Scrum betrachten. Das heißt, sie hatten einen Softwareentwicklungsprozess X, der gegen einen anderen Prozess Y ausgetauscht wurde, zum Beispiel Scrum. Das mag auch bis zu einem gewissen Grad erfolgreich sein, aber letztendlich wird man hinter den selbstgesteckten Erwartungen zurückbleiben und nur einen Bruchteil des Potenzials nutzen.

In meinen Trainings lege ich großen Wert darauf, dass die Teilnehmer verstehen, dass Agilität kein Prozess ist, sondern auf einem Wertesystem basiert, das im Kopf anfängt. “Don’t do agile, be agile”. Wenn man wirklich agil arbeiten möchte, muss man sich darauf einstellen, dass sich auch die Organisation und die Rollen insbesondere von Führungskräften verändern.

Agilität ist kein Prozess, sondern basiert auf einem Wertesystem basiert, das im Kopf anfängt:
“Don’t do agile, be agile”

Wo wir gerade bei Führungskräften sind: Viele “gestandene” Führungskräfte haben Angst, dass sie zum einen die Kontrolle über das verlieren, was passiert, und zum anderen überflüssig werden.
Das ist sehr schade, denn gerade diese Menschen werden gebraucht, um mit ihrer Erfahrung und Seniorität den Wandel zu unterstützen. Ja, die Rolle der Führungskraft verändert sich, weg von Command & Control hin zu Mentoring & Coaching, und diese Veränderung kann für die Führungskraft unglaublich bereichernd sein.

 

Georg:
Als Agile Coach wirst du angefragt, wenn sich ein Unternehmen dazu entscheidet, agile Methoden wie Scrum einzuführen. Welche Aufgaben hat ein Agile Coach neben der Schulung der Mitarbeiter in den Scrum-Rollen (Scrum-Master, PO, Scrum-Team), und wie kann man den von dir oben beschriebenen Herausforderungen als Agile Coach entgegenwirken?

Sven:
Du hast Recht, die Schulung der Mitarbeiter ist elementar. Damit meine ich zunächst die von dir genannten Rollen, weil diese Kollegen sofort einen aktiven Part übernehmen. Bereits hier verankere ich die Agilen Werte, um später darauf zurückzukommen.
Sehr zeitnah muss aber auch eine Schulung des Umfelds erfolgen, also der Führungskräfte, der anderen Teams, der Stakeholder und auch des höheren Managements. Diese zweite Schulung muss nicht so sehr ins Detail gehen, im Wesentlichen muss das Umfeld verstehen, dass in dem Scrum Team etwas Neues passiert, dem man offen und wohlwollend gegenüberstehen und dem man eine Chance geben sollte. Auch hier muss die Saat der Agilen Werte gesetzt werden. Meine Erfahrung zeigt, dass ein Scrum Team, dem man einen Sprint lang alle notwendigen Freiheiten gewährt, die Organisation im Review so richtig begeistern kann.

Meine Erfahrung zeigt, dass ein Scrum Team, dem man einen Sprint lang alle notwendigen Freiheiten gewährt, die Organisation im Review so richtig begeistern kann.

Die Arbeit des Agile Coaches besteht also zunächst darin, dem Scrum Team nach außen diesen Freiraum zu verschaffen und es nach innen eng zu begleiten und zu unterstützen. In dieser Phase bin ich noch sehr direktiv und sage sehr klar, was ich vom Team erwarte und wie ich es haben möchte.
Wenn diese erste Phase erfolgreich ist, hat man eine gute Vertrauensbasis geschaffen und kann von hier aus weiterarbeiten. Spätestens jetzt muss der Coach individuell auf die Führungskräfte zugehen, um ihnen die oben beschriebenen Ängste zu nehmen und ihnen aufzeigen, wie sie zum Erfolg beitragen können.
Ganz wichtig finde ich, dass ein neues Scrum Team zu Beginn nicht allein gelassen wird, sondern von einem erfahrenen Coach begleitet wird. Andernfalls besteht die Gefahr, dass das Team bei der Umsetzung Fehler macht und dass die Organisation in gewohnter Weise “hineinregiert”.

Georg:
Scrum funktioniert vor allem in kleineren Teams mit bis zu 8 Personen. In größeren Organisationen stellt sich dann die Frage, wie man die Teams teilen kann, um Scrum skalierbar zu machen. Ich kannte bislang nur das “Scrum of Scrum”-Prinzip, zuletzt haben sich hier offenbar neue Ansätze wie LeSS, SAFe uvm. am Markt gebildet. Wie stehst du zu skalierbaren Scrum-Frameworks?

Sven:
Ich habe mich mal ein bisschen mit diesen Frameworks beschäftigt, es gibt da noch ein paar mehr. Generell halte ich es da mit Craig Larman, derLeSS zusammen mit Bas Vodde  entwickelt hat: “Don’t do it!” *lacht*.
Zumindest in der Theorie ist es meist besser, die Organisation und die Architektur des Systems zu verändern, als Scrum zu skalieren. Das macht nur leider in der Praxis fast niemand, so dass diese Frameworks zum Einsatz kommen.

Mein persönlicher Favorit ist hier tatsächlich LeSS, weil es versucht, so nah wie möglich an den Wurzeln von Scrum zu bleiben und sehr viel Verantwortung bis in die Teams gibt.

Mein persönlicher Favorit ist hier tatsächlich LeSS, weil es versucht, so nah wie möglich an den Wurzeln von Scrum zu bleiben und sehr viel Verantwortung bis in die Teams gibt. Besonders mag ich hier die Feature Teams, die in der Lage sind, allein und ohne Abhängigkeiten einen Wert zu liefern. SAFe adressiert eher Umgebungen ab 50 Personen aufwärts. Mich erinnert es zu sehr an den Methodenbaukasten des PMI; für jede mögliche Eventualität gibt es eine Vorgehensweise. Ich empfinde das als Einschränkung, aber das ist meine persönliche Meinung, ich habe tolle Kollegen, die auf SAFe schwören und es erfolgreich einsetzen.

 

Georg:
Scrum gibt es ja nun schon so einige Jahre. Kannst du uns einen Eindruck davon vermitteln, inwieweit sich Scrum weiterentwickelt hat und uns einen Ausblick geben, wohin die Reise hingehen könnte?

Sven:
Wenn ich an meine Anfänge mit Scrum vor acht Jahren zurückdenke, ist seitdem eine Menge passiert. Damals lag der Fokus voll auf den Scrum Teams, das Umfeld wurde nicht betrachtet. Mit der Zeit hat man dann festgestellt, dass man u.a. das mittlere und auch das höhere Management vergessen hat, was zu den eingangs erwähnten Ängsten und damit Widerständen führte. Und auch wenn sie immer schon da waren:
Die Agilen Werte sind auch erst in den letzten Jahren mehr in den Fokus gerückt. Besonders interessant fand ich, dass das Agile Manifest im Jahr 2011, also zehn Jahre nach seiner Verfassung, noch genauso aktuell war wie am ersten Tag.

Besonders interessant fand ich, dass das Agile Manifest im Jahr 2011, also zehn Jahre nach seiner Verfassung, noch genauso aktuell war wie am ersten Tag.

Ich sehe auch, dass sich die Aufgabe des Scrum Masters verändert hat:
War er früher noch der Hüter des Prozesses und der Beschützer des Teams, so ist er heute eher eine Art Facilitator und nimmt oft die Rolle eines Agile Coaches wahr, der viel mehr in die Organisation wirkt als früher.
“Agile Coach” ist dabei so ein Buzzword… Wenn man mal ehrlich ist, ist ein Agile Coach kein Coach, sondern ein Consultant. Ich werde als Agile Coach beauftragt, weil Firmen von mir wissen wollen, wie sie bestimmte Dinge machen sollen. Sie wollen Vorschläge, die auf Erfahrung beruhen. Das ist aber kein Coaching. Wenn man sich aber nicht “Agile Coach” nennt, wird man z.B. auf Xing nicht gefunden.

Um dieser Bezeichnung dennoch gerecht zu werden, habe ich eine zusätzliche Ausbildung zum Co-Active Coach durchlaufen. Damit kann ich nun Menschen richtig coachen, was im Idealfall sogar gar nichts mit Agilität zu tun hat, so laufe ich nicht in die Consulting-Falle *lacht*

Georg:
*lacht* Und ich habe mich schon als Consultant bezeichnet, obwohl mich die Kunden weniger gefragt denn mir aufgetragen haben, wie ich die Dinge tun soll… Dann nehme ich demnächst gern die Agile Coach-Rolle ein und lege den Consultant dafür ab :-).
Sven, vielen Dank für die interessanten Einblicke!

Sven:
Gern geschehen. Ich freue mich darauf, das Interview in deinem Blog zu lesen.

Design Thinking und Employee Branding

„Design Thinking“ und „Employee Branding“ – zwei Themen, die derzeit viel Wirbel („Hype“) machen.
Ein Vortrag, den ich besuchte, sollte etwas Licht ins Dunkel bringen, denn ich fand im Netz nur diffuse Informationen.

Klären wir zuerst die Frage, worum es sich bei Employee Branding handelt:
Es geht um Methoden, Mitarbeiter langfristig für ein Unternehmen zu gewinnen, und zwar optimalerweise so, dass sie sich als Bestandteil des Unternehmens fühlen.

Das war der einfache Teil. Kommen wir zur Frage…

Was ist Design Thinking?

Hinter Design Thinking verbirgt sich zunächst eine Sammlung von Methoden, die zum Ziel haben, Produkte zu schaffen bzw. so zu verbessern, dass der Mensch als Benutzer des Produktes im Mittelpunkt steht.
Der Prozess zum Schaffen solcher Produkte weist ein paar Parallelen zu den agilen Werten sowie Scrum auf:

  • Die Entwicklung findet inkrementell statt
  • Das Team, welches das Produkt entwirft, denkt aus Sicht des Benutzers. Die Bedürfnisse des Benutzers stehen im Mittelpunkt.
  • Die Zusammenarbeit mit dem Kunden kommt besondere Bedeutung zu
  • die Inkremente werden dem Kunden möglichst oft vorgestellt, um von Feedback-Schleifen zu profitieren
  • Kultur ist wichtiger als Prozesse
  • Man lernt aus Fehlern („Fehlerkultur“)
  • empirische Beobachtungen bilden die Grundlage bei der Verständnisentwicklung

Zur Ideenfindung und Modellierung des Produktes werden im Team kreative Ansätze wie z.B. Knete oder auch Lego verwendet.
Der eigentliche Auftrag des Kunden wird in der Verstehens-Phase hinterfragt, um den eigentlichen Mehrwert eines Produktes zu verstehen (es geht z.B. nicht darum, ein neues Auto zu bauen, sondern ein schnelleres Fortbewegungsmittel).
Ansätze, die sich als nicht ideal herausstellen, werden schnell verworfen.

Schritte beim Design Thinking
Schritte beim Design Thinking

 

Es werden die Schritte wie auf der obigen Abbildung zu sehen durchlaufen. Der eigentliche Knackpunkt stellt dabei die Synthese-Phase statt, in der es darum geht, das ermittelte Verständnis auf Grundlage der Beobachtungen („oberserve“) in Ideen für geeignete Prototypen zu überführen.

Fazit

Design Thinking ist als Methodensammlung sehr allgemein gehalten. Das erklärt, weswegen es für unterschiedlichste Anwendungsfälle geeignet zu sein scheint (wie z.B. Employee Branding) – aber auch, weswegen es keine allgemein-gültige Definition gibt.
Aus meiner Sicht geht es um Methoden, die sich bewährt haben, um im Team durch kreative Ansätze zu Ideen für benutzer-zentrierte Produkte zu gelangen. Nicht mehr und nicht weniger.

Wer sich weitergehend informieren möchte findet, mag vielleicht folgende Seiten nützlich finden:

  1. http://vividbreeze.com/design-thinking-workshop/
  2. https://spielraum.xing.com/2016/02/design-thinking-besser-vernetzt-denken/ (Thema: New Work)

Prime Directive

In der Retrospektive und anderen Aktivitäten im Scrum-Geschehen kann es schnell zu Situationen kommen, in denen auf Einzelne gezeigt wird. Dann stehen Schuldzuweisungen im Raum, die erst ausgeräumt werden müssen. Das ist der Moment, in dem der Scrum-Master auf die Prime Directive hinweisen (und am besten vor der nächsten Retro in Erinnerung rufen) wird:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.“

(aus: Norm Kerth)

Auf deutsch, kurz gefasst:
Jedes Team-Mitglied hat nach seinem besten Wissen und Gewissen gehandelt.

Oder, näher am Original:
Unabhängig davon, was wir entdecken werden, verstehen und glauben wir aufrichtig, dass jeder sein Bestes in der gegebenen Situation mit dem verfügbaren Wissen,  den Ressourcen und unseren individuellen Fähigkeiten getan hat.

Komfort-Zone

Anschnallen und zurücklehnen? Nur in der Komfort-Zone! So wird der Bereich gemeint, in dem man sich als Mitarbeiter in seiner „täglichen Routine“ befindet und in dem gemächlichen Tempo arbeitet, von dem man weiß, dass man am Ende des Tages den Großteil der Aufgaben geschafft hat – aber nicht alle, denn morgen ist ja auch noch ein Tag.

Scrum setzt auf die stetige Verbesserungen des Teams. Dafür ist es notwendig, die Komfortzone zu verlassen, über den Tellerrand hinauszublicken, von alten Gewohnheiten das Bewährte beizubehalten und aufgeschlossen Neues aufzugreifen („Inspect and Adapt“).
Das Verlassen der Komfortzone ist in gewisser Weise mit dem Überwinden des inneren Schweinehundes vergleichbar: Man schafft nur Neues, kann sich nur verbessern, indem man sich ständig überwindet!

Karriereanker: Glückliche Mitarbeiter machen den Team-Erfolg

Unbetritten ist der „Glücksfaktor“ bei der Arbeit einer der stärksten Treiber; er ist Voraussetzung für Motivation und Engagement. Nur durch Motivation kann ein Mitarbeiter zu seiner Höchstform auflaufen. Und dies ist wiederum ist eine grundlegende Voraussetzung dafür, dass sich starke und erfolgreiche Teams bilden (der geneigte Leser wird bemerkt haben, wie ich versuche den Bogen in Richtung Scrum-Team zu bringen).
Nachdem ich mich mit drei von vielen Möglichkeiten beschäftigt habe, wie man Scrum-Teams ziemlich sicher auszubremsen kann soll nun ein „konstruktiver“ Beitrag folgen.

Agile Methoden wie Scrum werden natürlich nicht um ihrer Selbst Willen betrieben, sondern vor dem Hintergrund, besser getestete und akzeptierte (Software-)Produkte in weniger Zeit entwickeln zu können. Es ist ein angenehmer Nebeneffekt, dass Scrum nicht nur vom Management, sondern auch von Mitarbeitern eingefordert wird, weil es eine natürliche Art der Arbeitsweise und Zusammenarbeit fördert: Mehr Beteiligung am Produkt bedeutet auch mehr Selbstverwirklichung.

Kurz gefasst (TLDR):

Motivierte Mitarbeiter -> produktiver Teams -> qualitativeres Produkt in kürzerer Zeit

Motivation als Schlüssel erfolgreicher Teams

Erfolgreiche Teams gibt es nur, wenn jedes einzelne Team-Mitglied glücklich und dadurch motiviert ist.
Was aber wollen Mitarbeiter, wodurch motivieren wir uns? Philosophischer gefragt, was ist der Grund, dass wir uns jeden Morgen aus dem Bett bewegen?

Dass Geld allein nicht glücklich macht, ist ein offenes Geheimnis. Motivatoren der Arbeit sind beispielsweise darin zu sehen:

  • Anerkennung zu erhalten
  • Selbstverwirklichung erleben
  • Etwas Sinnstiftendes tun, etwas verändern und bewegen (die Welt retten, zum Beispiel ;-)) – an etwas großem Ganzen beteiligt sein
  • etwas Neues zum ersten Mal tun
  • etwas tun, wovon ich denke dass es für die Karriereleiter förderlich sein kann (in Verbindung mit monetären Zielen und auch Anerkennung)Eine Studie von Bain&Company hat herausgefunden, dass die Bedürfnisse einander bedingen und pyramiden-artig aufgebaut sind:
  • Pyramide der Mitarbeiter-Bedürfnisse
    Pyramide der Mitarbeiter-Bedürfnisse nach Bain&Company

8 Karriereanker

Als Karriereanker werden solche Aspekte bezeichnet, die Mitarbeiter an ihrer Arbeit als so bedeutend betrachten, dass sie ihnen grundlegende Entscheidungen im Hinblick auf ihre berufliche Entwicklung abhängig machen (unter der Annahme, dass sie ein „hinreichend hohes“ Gehalt beziehen, dessen Höhe nicht diese Entscheidungen wesentlich beeinflusst). Jeder Mensch hat natürlich individuelle Präferenzen und Wahrnehmungen, so dass die nachfolgend erläuterten Karriereanker in unterschiedlichen „Dosen“ bei jedem Menschen ausgeprägt sind.
Lanzenberger, Looss und Stadelmann haben diese 8 Karriereanker identifiziert:

  1. Technisch-funktionale Kompetenz
  2. Befähigung zum General Management
  3. Selbständigkeit
  4. Sicherheit und Beständigkeit
  5. Unternehmerische Kreativität
  6. Hingabe für eine Sache
  7. Totale Herausforderung
  8. Lebensstil-Integration

Die wichtigsten Anker sollen nachfolgend vorgestellt werden:

Technisch-funktionale Kompetenz

Wer sich auf eine besondere fachliche (vor allem technische) Kompetenz spezialisiert, wird sich im technisch-funktionalen Karriereanker wiederfinden. Charaktere dieser Kategorie finden Anerkennung eher im Lob durch Kollegen, deren Kompetenz sie schätzen, als im Lob eines Vorgesetzten, von dem sie wissen, dass er/sie die Leistung mangels technischer Expertise kaum zu würdigen weiß.

Selbständigkeit

Diese Kategorie hätte vermutlich auch „Freidenker“ benannt werden können, denn hierunter werden Mitarbeiter verstanden, die gerne gegen den Strom schwimmen, sich Normen widersetzen und ihrer persönlichen Freiheit den größten Wert beimessen. Sie stehen im direkten Gegensatz zum Karriereanker „Sicherheit und Beständigkeit“: Der sog. goldene Käfig, also die enge Integration und langfristige Bindung von Mitarbeitern ans Unternehmen, ist für die Selbständigen ein äußerst abschreckender Aspekt. Anerkennung empfinden die „Selbständigen“ am ehesten in der Bewerkstelligung der ihnen übertragenen Aufgaben.

Lebensstil-Integration

Flexibilität seitens des Arbeitgebers im Hinblick auf die Lebenssituation ist das „A und O“ bei diesem Karriereanker. Laut den Autoren ist es einer, der immer mehr Zulauf findet, da das Thema der Vereinbarkeit von Job und Familie immer mehr Stellenwert einnimmt.
Themen wie HomeOffice, flexible Arbeitszeiten, Möglichkeiten um Sabbaticals zu nehmen und eine grundsätzlich familienfreundliche Firmenpolitik spielen für Mitarbeiter dieser Kategorie eine große Rolle.

Glücklichsein

John Lennon hat über die Bedeutung von Glücklichsein (hapiness) einmal gesagt:

When I was 5 years old, my mom always told me that happiness was the key to life. When I went to school, they asked me what I wanted to be when I grew up. I wrote down ‚happy‘. They told me I didn’t understand the assignment and I told them that they didn’t understand life.

„Glücklich sein“, das ist Lennons Verständnis darüber, was er später sein möchte. Man mag ihm natürlich vorhalten, dass er als Kind ein naives Weltbild gehabt hatte. Und doch kann man einen grundlegenden Wahrheitsgehalt in seiner Aussage nicht abstreiten. Denn ist nicht die Arbeit, unser Beruf, eine der zentralen Lebensinhalte?

Ich fand dieses Zitat von John Lennon so treffend, dass ich sie in mein Xing-Profil übernommen habe :-).

Fazit

Jedes Team ist nur so erfolgreich wie die Summe der Team-Mitglieder. Der Erfolg jeden Unternehmens hängt von seinen Mitarbeitern wiederum ab. Je glücklicher und motivierter Mitarbeiter sind, umso produktiver sind sie. Dadurch, dass Scrum die Möglichkeiten zur Mitgestaltung genauso wie Verantwortung an jeden Mitarbeiter überträgt, bietet es eine wunderbare Grundlage um gute Voraussetzungen für erfolgreiche Teams zu schaffen.
Dafür ist es notwendig, auf die Bedürfnisse der Mitarbeiter einzugehen, zu erkennen, was sie ganz persönlich motiviert, und wie sie ihre Karriereanker gesetzt haben bzw. wie sie sich einschätzen.

Scrum wurde erfunden, um bessere Produkte in kürzerer Zeit herstellen zu können. Dies wird einerseits durch eine forcierte Kommunikation zwischen Kunden, Product Owner und Entwicklungsteam erreicht; andererseits durch eine Umkehrung der Verantwortung:
Weg vom Command&Control-Ansatz aus dem Management ins Team, hin zur gemeinsamen Verantwortung des selbstorganisierten Teams.

Ausblick

Seit ein paar Monaten hat Xing mit der Kolumne „Spielraum“ einen eigenen Kanal eingerichtet, der sich dem Thema New Work widmet. Hier werden Ideen über die Arbeit der Zukunft (kontrovers) diskutiert und Unternehmen vorgestellt, welche bereits die Weichen in diese Richtung gestellt haben. Diese Unternehmen haben erkannt, dass sich der Arbeitsmarkts grundlegend ändert, dass Mitarbeiter mehr sind als nur Ressourcen.
Diese Einsicht ist notwendig, um langfristig erfolgreiche Teams zu bilden.

Agile Methoden entwickeln sich immer weiter. Wen es interessiert, wohin die Reise mit Scrum gehen könnte, dem sei ein Artikel zur Einschätzung von Boris Gloger in Sachen Scrum 3.0 und Organization 4.0 empfohlen.

3 Produktivitäts-Killer für jedes agile Team

Agile Methoden wie Scrum oder Kanban zu verstehen ist einfach, sie aber gut umzusetzen hingegen weniger.
Mit diesen drei Killern, die ich im Alltag oft zu spüren bekommen habe, wird die Produktivität von jedem Team nachhaltig gebremst:

3. Das Team arbeitet dezentral

Es lässt sich oftmals nicht vermeiden, dass Teams an verschiedenen Orten zusammenarbeiten müssen. Welche Konsequenzen dies jedoch auf die Produktivität und Kosten hat, wird dabei oft übersehen.
Schauen wir uns einmal an, womit verteilt arbeitende Teams zu kämpfen haben:

  • Menschen nehmen Dinge besser auf, wenn sie sich sehen können. Die Mimik und Gestik, die z.B. von den Teilnehmern im Daily Standup vermittelt wird, sagt viel darüber aus, wie wohl sich die Team-Mitglieder mit dem Sprint fühlen. Dies ist ein Indikator für den Stand des Projekts. Fehlt diese wichtige Information, können Risiken nicht gesehen oder falsch eingeschätzt werden.
  • Wie lassen sich Gespräche, die „zufällig“ in der Kaffeeküche stattfinden, ersetzen? Mehr Teams erfordern mehr Kommunikation, damit sie nicht den Draht zueinander verlieren.
  • Video- und Telefonie-Technik muss für jedes Meeting absolut verlässlich arbeiten und daher gut vorbereitet werden. Das kostet Zeit. Gleichzeitig miteinander zu sprechen ist über Skype & Co nicht so einfach wie wenn man zusammensteht.
  • Team-Mitglieder, die am gleichen Standort arbeiten, entwickeln durch das tägliche Miteinander einen eigenen Spirit und kennen ihre Stärken und Schwächen. So können sie sich besser fachlich ausgleichen. Durch einen vereinfachten Wissenstransfer entstehen damit weniger Wissensinseln. Dadurch ist das z.B. bei Krankheitsfälle besser aufgestellt.
  • Auch wenn es im Team mal nicht ganz rund läuft, kann der Scrum-Master die Besetzung des Teams einfacher ändern, wenn das Team an einem Ort arbeitet. Spannungen und Disharmonien lassen sich erst wahrzunehmen, wenn man persönlich mit Leuten arbeitet.
  • Product Backlog, Impediment Log, Release Map, Story Maps… alle Dokumente sind nicht physisch greifbar, sondern zwischen elektronischen Tools (wie JIRA, Confluence) verteilt.
  • Arbeiten Teams in unterschiedlichen Zeitzonen, ist es mit bis zu doppelt so viel Zeit für die Synchronisation der Teams einzukalkulieren, jenachdem wie groß der Zeit-Versatz zwischen den Zeitzonen ist.
  • Der ProductOwner soll „mal eben“ etwas am Whiteboard skizzieren. Hoppla, dazu muss man ihn erst einmal telefonisch erreichen oder sogar einen Termin vereinbaren, statt am Nachbarbüro anzuklopfen. Und dann muss er seine Skizze auch digital anfertigen anstelle mit Stift und Papier, wenn er nicht parallel seinen Entwurf filmen möchte. Schade!
    Effektiv ist der ProductOwner in dem Moment für das Team nicht wirklich ansprechbar, denn allein die Hürde, um ihn anzurufen, ist zu hoch.

2 .Es wird an Hardware oder Lizenzen gespart

Wenn ich auf Baustellen bin, haben die Handwerker dort meistens Maschinen von Makita. Sogar das wetterfeste Radio. Die Dinger sehen oftmals abgenudelt aus, aber es ist schließlich DAS Werkzeug, mit dem der Handwerker jeden Tag seine Werk verrichtet.

In der IT scheint Geiz aber geil zu sein:
Auch in der IT werden Werkzeuge benötigt, die täglich und teils ohne Pausen zum Einsatz kommen. Diese Werkzeuge sind dann aber schlecht ausgestattet oder aber Marke Baumarkt für Hobby-Handwerker.
Beispiele:

  • Ich bin letztes Jahr, also 2015, in ein Büro eines Teams gekommen: Interne Mitarbeiter hatten schicke MacBooks, externe Mitarbeiter klapprige Windows-Rechner, per VGA an einen Monitor angeschlossen. Was für eine gewollte Zwei-Klassen-Gesellschaft!
  • Weil die Windows-Lizenzen ja schon teuer genug sind, werden einige Entwickler dazu gedrängt Eclipse zu verwenden, obwohl sie IntelliJ-Profis sind (das Beispiel ist nur exemplarisch zu sehen). Mitarbeiter sollten sich das Werkzeug, mit dem sie am besten arbeiten können, aussuchen dürfen – ohne Wenn und Aber.
  • Die Rechner sind lahm,  weil SSDs zu teuer sind. Und heute, da SSDs günstiger sind, werden winzige SSDs verbaut, weil größere ja zu teuer sind. Plötzlich geht gar nichts mehr: „No space left on device„! Ich glaube ich habe die Meldung zuletzt vor 20 Jahren gesehen. Aber nein, das war vorgestern, wir schreiben das Jahr 2016… Nicht zu fassen.
    Rechner müssen so ausgestattet sein, dass effiziente Arbeit damit möglich ist.
  • Ein Mitarbeiter möchte einen Zweit-Monitor oder sogar ein Retina-Display? Das geht wirklich nicht. Wenn er es wirklich will, muss er ein Beschaffungsformular gemäß den IT-Beschaffungsrichtlinien einreichen. Und Geduld haben. Viel Geduld für Bürokratie!
    Ich habe es erlebt, die Bestellung einer externen Festplatte hat 4 Monate gedauert, weil die Beschaffungsrichtlinie genau einen Händler vorsieht, der das Teil erst nicht vorrätig und dann falsch geliefert hatte. Geliefert hat am Ende übrigens Amazon.
    Für Bürokratie ist an einem wissens-intensiven Arbeitsplatz kein Platz.
  • Der Build-Server ist stets an seinen Grenzen, das Bauen von Artefakten dauert 30 Minuten? Das kann vorkommen, wenn man ihn sich mit anderen Teams teilt. Den Server mit RAM oder Speicher aufzurüsten würde das Problem schnell lösen. Aber verdammt, RAM ist so verdammt teuer geworden…
    Wenn Teams durch Wartezeit bedingt durch Hardware ausgebremst werden, kostet das Zeit und bremst damit den Fortschritt.

(Wenn ich so etwas erlebe, mache ich im Kopf eine Überschlagsrechnung:
Nehmen wir an, eine vernünftige SSD koste 400€ netto und ein Mitarbeiter werde intern mit 80€/Std. verrechnet. Nehmen wir ferner  großzügig an, der Einbau der SSD koste nochmal 2h intern, also 160€. Effektiv hat sie 400€+160€=560€ gekostet.
Das bedeutet, schon nach 7h Zeit-Ersparnis ist dieser Mitarbeiter produktiver und glücklicher.)

Geiz ist nicht geil. Zum Glück hat sich das schon etwas herumgesprochen. Dass ein Mitarbeiter aber glücklicher ist, weil er nach seinem Verständnis von Effizienz arbeiten kann, dadurch motivierter ist und produktivere Beiträge leistet… das lässt sich doch kaum in Geld aufwiegen!

1. Der Product Owner sind zwei Personen

Schizophrenie? Mehrere Personen als Product Owner zu haben ist ein Anti-Pattern, was es aber nicht besser macht ;-).
Warum ist dies ein Anti-Pattern und warum ist es überhaupt ein Muster?
Ein Erklärungsansatz: Es gibt mehrere Produkte oder Produkt-Sorten im Unternehmen, für die es jeweils einen Ansprechpartner gibt. Nun wird ein Scrum-Team gebildet, aber da es um alle Produkte oder -Sorten geht, sollen auch alle Produkt-Verantwortlichen gleichermaßen einbezogen werden.
Klingt nach Gleichberechtigung, birgt aber zahlreiche Probleme:

  • Ein Product Owner ist verantwortlich für den Produkt-Erfolg. Die Verantwortung wird bei mehreren Personen aber verteilt. Verantwortung ist jedoch nicht teilbar. Die Konsequenz von Verantwortung, die versucht wird auf mehrere Schultern zu verteilen: Niemand hat den Hut auf. Stattdessen wird Verantwortung verschoben.
  • Die Entscheidungsfindung wird verlangsamt und erschwert. Denn es dauert, bis sich mehrere Personen einigen. Wenn sie sich denn einigen können. Auch Rückfragen vom Team können nicht spontan geklärt werden, was die Entwicklungsgeschwindigkeit dramatisch reduziert.
  • Die Entscheidungen, die von mehreren Product Ownern getroffen werden, stellen lediglich Kompromisse dar. Denn wenn sich mehrere Personen in einer Sache nicht ganz einig sind und keinen gemeinsamen Nenner finden, hilft nur noch noch, ein gemeinsames Vielfaches als Lösung vorzustellen. Was nicht die beste Lösung ist.
  • Wen fragt das Team bei Rückfragen? Genau einen zentralen Ansprechpartner gibt es nicht. Soll es nur einen fragen oder beide? Wessen Meinung ist die bessere, wenn die beiden Product Owner gegensätzliche Antworten liefern. Nein, das funktioniert nicht.

 

Dies sind bloß drei Punkte, aber drei richtige Killer.
Welche Erfahrungen habt ihr im Projekt-Alltag gemacht? Ich bin auf eure Kommentare gespannt!

Retrospektive

Ist ein Sprint durchlaufen, schließt sich daran die Retrospektive an – der Rückblick des Teams auf den Sprint.
In der Retrospektive benennt jedes Team-Mitglied Punkte, die es als besonders gut und die es als verbesserungswürdig einstuft.

Eine der grundlegenden und wichtigen Gedanken von Scrum manifestiert sich in der stetigen Verbesserung.
Das Inspect and Adapt-Prinzip besagt, aus Fehlern zu lernen und positive Erkentnisse beizubehalten.
Mit der Retrospektive wird diesem Prinzip Rechnung getragen, denn erst mit der Erkenntnis, welche Probleme („verbesserungswürdigen Punkte“) es gibt, kann der Weg für Verbesserungen geebnet werden.
Gleichzeitig sollen funktionierende Prozesse in Fleisch und Blut des Teams übergehen, damit sie nicht verlernt werden.

Die Retrospektive ist somit ein mächtiges Werkzeug des Change- und Wissensmanagements.

Technische Schulden (technical debts)

Als technische Schulden werden Qualitätsmängel in der Produktentwicklung bezeichnet, die während eines Projekts in Kauf genommen werden. Technische Schulden entstehen z.B., wenn auf Tests verzichtet oder deren Umfang vernachlässigt wird oder Teile der Definition of Done nicht eingehalten werden.
Der Begriff „Schulden“ kennzeichnet dabei denselben Umstand, den man aus dem Finanzwesen kennt:
Wer sich Geld leiht, muss dieses zuzüglich Zinsen zurückzahlen. Es gibt allerdings einen gravierenden Unterschied zur aktuellen Zins-Situation auf dem Finanzmarkt:

Tilgen von technischen Schulden

Bei technische Schulden in der Software-Entwicklung sagt man, dass zum Tilgen von 1€ Schulden 4€ aufgewendet werden müssen.
Man sollte sich also tunlichst überlegen, ob man bereit ist, technische Schulden zu machen, es sei denn es geht um einen Wegwerf-Prototypen.

Warum werden trotzdem technische Schulden gemacht?

Ursachen technischer Schulden

Ursächlich ist zumeist weniger mangelndes Qualitätsbewusstsein im Team als folgende häufige Gründe:

  • Unrealistische zeitliche Zielsetzungen bzw. das Vorziehen von „Deadlines“, ohne dass der Funktionsumfang verringert wird. Das Team versucht dann, denselben Funktionsumfang in weniger Zeit zu realisieren. Dies geht nur auf Kosten der Qualität
  • Im Team herrscht Stress, der wiederum durch unterschiedliche Ursachen hervorgerufen werden kann:
    • Überstunden,
    • Zeitmangel,
    • Umstellung infolge von Umstrukturierungen des Teams,
    • Einflüsse aus dem Management,
    • Kompensation ausgefallener Mitarbeiter,
    • anhaltende technische Probleme,
  • Unverhältnismäßige Vergrößerungen des Product Backlogs oder unverhältnismäßig häufige Anpassungen von User Stories: Das Team muss viel Zeit aufwenden, um die geänderten User Stories neu zu bewerten. Diese Zeit fehlt in der Folge an anderer Stelle
  • Fehlerhafte Architektur-Entscheidungen, die nicht oder zu spät angegangen werden
  • Scrum-Master

    In Scrum gibt es neben der Rolle des Product Owners und des Scrum-Teams natürlich noch den Scrum-Master.

    Kommunikator, Moderator, Organisator

    Er fungiert als Kommunikator, Moderator, Organisator, vermittelt allen Beteiligten wie Scrum funktioniert und gilt als Ansprechpartner, wenn etwas in der Organisation nicht funktioniert. Ein guter Scrum-Master ist ein „Enabler“. Das heißt, er gibt den Beteiligten alle Mittel und alles Wissen, damit diese selbständig (und selbstorganisiert) agieren können.

    Der Scrum-Master achtet darauf, dass alle Beteiligten nach den „Scrum-Spielregeln“ arbeiten, insbesondere die agilen Werte kennen und anwenden.

    Man mag meinen, dass ein Scrum-Master nur in der Anfangsphase benötigt wird. Dies ist jedoch ein allgemeiner Irrtum: Niemand anders als der Scrum-Master kann durch seine neutrale Haltung in Konfliktfällen vermitteln, Impediments („Bedrohungen“) objektiv beurteilen, zu deren  Behebung beitragen und Scrum als Prozess im Sinne der stetigen Verbesserung überschauen.
    Jedes agile Projekt hat eine natürliche Dynamik, ist internen und externen Einflüssen ausgesetzt und lebt entwickelt sich mit den Menschen. Oder bildlich gesprochen: Wenn das Projekt ein Boot ist, dann ist der Scrum-Master der Kapitän und damit derjenige, der dafür sorgt, dass das Boot auf Kurs bleibt.