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.