FAK – Scrum mit Fremdarbeitskräften

Was sind Fremdarbeitskräfte (FAK)?

In grossen Firmen wird Scrum für die Entwicklung von Produkten eingesetzt, bei der viele Firmen (Dienstleister) beteiligt sind. Hier stellt sich die Frage, wie die Kommunikation im Detail aussehen muss, damit nicht der Tatbestand der Arbeitnehmerüberlassung eintritt.

Worauf muss ein Scrum Team achten, wenn mehrere Firmen beteiligt sind?

Scrum und die agile Softwareentwicklung verbessern die Produktivität von Entwickler-Teams, indem sie eine hohe Dichte an gezielten Meetings schaffen, welche das Maß an Kommunikation erhöhen. Entwickler-Teams bestehen oft aus Experten von verschiedenen Dienstleistungs-Unternehmen und gelten damit oft als „Fremdarbeitskräfte“. Damit nicht der Tatbestand von ‚Arbeitnehmerüberlassung‘ eintritt, ist es notwendig, sich genau an die Spielregeln von Scrum zu halten und Zusammenkünfte so zu gestalten, dass die Selbstorganisation des Teams im Mittelpunkt steht.

Egal ob ein Werkvertrag oder Dienstvertrag zwischen beteiligten Firmen vereinbart ist, sollte der Auftragnehmer auch ein Risiko tragen solte. Dies ist ein Indiz dafür, dass er und seine Mitarbeiter nicht abhängig beschäftigt sind.

Wenn die Scrum Regeln befolgt werden, dann ist zusätzlich darauf zu achten, dass keine Weisungen von Mitarbeitern des Auftraggebers an Mitarbeiter des Auftragnehmers erteilt werden.

Siehe rechtliche Details dazu: Heise/Friedl: Flexible („agile“) Zusammenarbeit zwischen Unternehmen versus illegale Arbeitnehmerüberlassung – das Ende von Scrum?

Was ist Weisung?

Arbeitsvorgabe im abhängigen Verhältnis und lässt dem Empfänger keinen Spielraum.

Keine Weisung:

Arbeitsvorgabe ohne Hierarchieverhältnis und lässt dem Empfänger Handlungsspielraum bezüglich was, wann, wo etc.

So ist die Kommunikation an sich nicht das Problem, sondern die Art der Kommunikation zwischen dem Auftraggeber und dem Auftragnehmer.

Informationsaustausch in Scrum Teams / Arbeitsrechtliche Verhaltensregeln

Do:

  • Sorgen Sie dafür, dass in dem Review Meeting keine Aufgaben an Einzelpersonen verteilt werden, sondern diese in das Product Backlog einfließen.
  • Halten Sie sich bei Daily Scrum an die Regel, dass hier die Teammitglieder sich selbst ihre Arbeit nehmen.
  • Lassen Sie das Planungsmeeting vom Scrum Master moderieren, um alle Beteiligten auf Augenhöhe zu integrieren.
  • Stellen Sie sicher, dass der Scrum Master die Retrospektive als Meeting unter gleichwertigen Scrum Team Mitgliedern gestaltet.
  • Beantworten Sie Ad-Hoc Rückfragen von Entwicklern, auch während des Sprints.

Dont’s:

  • Beantworten Sie als Product Owner Fragen, die jemand aus dem Developer Team stellt, nie in Form einer Weisung.
  • Erteilen Sie als Product Owner nie neue Aufgaben direkt an das Team, sondern indirekt über das Product Backlog.
  • Als Product Owner erteilen Sie keine Weisungen an Entwickler-Team Mitglieder, sondern beantworten nur Fragen dieser Personen.
  • 15 Minuten Daily Scrum nicht überschreiten.
  • Sprint nicht kürzer als 2 Wochen.
  • Halten Sie keine jour-fix Refinement-Meetings mit Experten, sondern nur Ad-Hoc treffen.

Scrum mit Fremdarbeitskräften braucht Skalierung

Wenn viele Scrum Teams an einem gemeinsamen Projekt arbeiten, dann sind Techniken zur Koordination zwischen diesem Teams erforderlich, die die geleistete Arbeit zu einem lauffähigen Produkt integrieren.

Bei der Softwareentwicklung von großen Projekten und Produkten arbeiten meist Ingenieure zusammen, die nicht nur Angestellte des Projektträgers sind, sondern die bei verschiedenen Unternehmen, wie Unternehmensberatungsgesellschaften oder anderen Dienstleistern, angestellt sind.

Die aktuelle Gesetzeslage zum Thema Arbeitnehmerüberlassung in Deutschland erschwert die Zusammenarbeit von Scrum Teams, bei denen Software-Entwickler bei unterschiedlichen Arbeitgebern angestellt sind. Diese Problematik betrifft viele Softwareentwicklungs-Dienstleister in West- und Ost-Europa. Ein typisches Szenario ist das Projekt eines Automobilherstellers, der dies mit Entwicklern von verschiedenen Dienstleistern umsetzt. Mitarbeiter von Dienstleistern dürfen meist nicht mehr in den Gebäuden der Auftraggeber sitzen. Die Kommunikation mit den Teams, die jetzt nicht mehr co-located sind, ist streng geregelt und eingeschränkt.

Eine Lösung die hier favorisiert wird, ist es, das Team in mehrere kleine Entwickler-Teams aufzuteilen. Jedes Team besteht dann aus Mitarbeitern von nur einem Unternehmen. Das Ziel ist es, den Verdacht einer Arbeitsvorgabe im abhängigen Verhältnis, aus dem sich eine Arbeitnehmerüberlassung ergeben würde, vorzubeugen. Weisungen, zum Beispiel von einem Teammitglied einer anderen Firma, sollen so ausgeschlossen werden. (Siehe hierzu: Scrum mit Fremdarbeitskräften) Das Resultat sind viele kleine Entwickler-Teams. Diese brauchen jetzt Techniken zur Koordination zwischen diesen Teams, um die geleistete Arbeit zu einem lauffähigen Produkt zu integrieren.

Scrum Skalieren

Jedes Softwareprodukt und das Unternehmen das dieses umsetzt hat spezielle Anforderungen an die Skalierung. Die Herausforderung kann in einem Unternehmen bei verschiedenen Projekten völlig anders sein.

Jeff Sutherland hat mit „Scrum at Scale“ hierzu auf der Agile2014 in Orlando ein Konzept vorgestellt, das als Framework dient. (siehe http://www.scruminc.com/agile2014/). Dieser Ansatz berücksichtigt Jeffs langjährige Erfahrung bei der Unterstützung einer Vielzahl an unterschiedlichsten Unternehmen.

Ken Schwaber hat mit seinem Buch „Scrum im Unternehmen“ die Grundlagen des skalierens erklärt. In dem Blog „Scaling Scrum“ widmet er sich erneut dem Thema:  http://blog.scrum.org/scaling-scrum/. Seine langjährige Erfahrung mit dem skalieren von Scrum beschreibt er folgendermaßen: „We assert that only a systematic, emergent, managed initiative to scale succeeds. Every initiative to scale is unique. Nobody knows what your organization needs to scale Scrum. And, nobody knows what your organization will look like as you scale.“

Links:

https://seminare.utakapp.de/2015/08/03/fak-scrum-mit-fremdarbeitskraeften/

http://www.scruminc.com/agile2014/

http://blog.scrum.org/scaling-scrum/

http://www.scrum-events.de/zertifizierungen/scrumscale/index.html

https://www.scrum.org/Courses/ScrumScale

English Version

Agil skalieren: Warum eigentlich?

Der Grund warum Unternehmen agiler werden wollen ist es, dauerhaft in einer sich immer schneller drehenden Welt profitabel zu sein. Agil verspricht schnelle, flexible Anpassung an das Umfeld und damit Risikominimierung.

Software als Wettbewerbsvorteil

Das Ziel für Unternehmen ist es, seine Software als strategischen Faktor für den Wettbewerbsvorteil zu nutzen. Dazu gilt es die Wertschöpfung in der Software in Linie mit den Unternehmenszielen zu bringen. Scrum ist die Methode der Wahl um einen Product-Backlog so zu sortieren, dass nur Features mit hoher Wertschöpfung umgesetzt werden. Nach einer Statistik der Standish Group wird nur ein Drittel des Codes eines Softwareproduktes genutzt. Zwei Drittel ist also „Cold Code“ der gewartet werden muss, aber keinen Mehrwert für den Nutzer/ Kunden enthält.

Messen

Firmen die gemessen haben, wieviel Prozent ihres Codes überhaupt genutzt wird kommen auf 20% bis 30%. Wenn also diese 70-80% des Codes entfernt würden, dann würden auf 70-80% der Fehler verschwinden. Nachdem laut einer Studie von Forrester über 50% der Zeit eines Softwareteams für Wartung drauf geht, würde die Identifikation und Reduktion von Cold Code enormes Potential für Innovation bringen.

Hier setzt Evidence Based Management der Scrum.org an. Das Ziel ist es, besser zu werden. Dazu gehen wir vor wie ein Arzt: Zuerst messen wir den Puls des Unternehmens. Dann verändern wir etwas. Für die Evidenz unseres Erfolgs messen wir wieder den Puls des Unternehmens.

Ein Beispiel:

A) Wir messen den Nutzungsgrad (Usage-Index) unserer Software und zum gleichen Zeitpunt

  • Kundenzufriedenheit
  • Fehlerrate
  • Wartungsaufwand
  • Mitarbeiterzufriedenheit

B) Wir verändern den Code indem wir ungenutzte Anteile entfernen.

C) Wir messen wieder den Nutzungsgrad (Usage-Index) unserer Software und zum gleichen Zeitpunt

  • Kundenzufriedenheit
  • Fehlerrate
  • Wartungsaufwand
  • Mitarbeiterzufriedenheit

Agil Scalieren mit Methode

Damit ist die Methode dies zu erreichen zweitrangig. Alle haben ihre Gültigkeit, wenn sie zur Verbesserung des Unternehmespuls beitragen. Es gibt viele Methoden für Enterprise Scaling. Alle haben, abhängig vom Stand des Unternehmens, ihre Einsatzgebiete.

Coaching

Klassischerweise nutzen wir coaching auf Unternehmensebene, um dem Management Hilfestellung zu geben, wie es agiler wird. Wenn das obere Management den Softwareteams Raum läßt zur Selbstorganisation und diesen Raum schützt, dann organisiert sich das Unternehmen von Unten nach Oben agil neu.

Die Hilfestellung hierzu ist vielfältig. Ich favorisiere hier einen klassischen professionellen Coaching Ansatz. Hilfe zur Selbsthilfe.

Frameworks

Frameworks haben das Ziel den Rahmen zu stecken, aber keine Methode zu sein. Scrum ist das bekannteste agile Framework. Da der Scrum-Guide nicht viel dazu aussagt, wie agil mit vielen Teams funktioniert, wird es neuerdings in die Ecke gestellt nur für einzelne Teams da zu sein und nicht für viele Teams oder gar ganze Unternehmen.

Jeff Sutherland’s Antwort hier ist das Scrum-At-Scale Framework.

Ken Schwaber beschreibt seine Erfahrung in Scrum@Scale

Best Practices

Unternehmen brauchen Beratung zum Skalieren von Agil und Scrum. Dazu erwarten sie Kochrezepte und Erfahrungen von anderen Unternehmen, die das schon einmal gemacht haben. Diese Practices können hilfreich sein. Sie sind jedoch gewissermaßen ein Paradox. Wenn ich andere Unternehmen kopiere, dann kann ich nicht führend in meiner Domäne sein. Vorgefertigte Methoden können also nur den Einstig erleichtern.

Beispiele:

LESS – Craig Larmans Scaling Scrum

SaFe – Dean Leffingwells Scaled Agile Framework

Spotify – So scaliert Spotify und teilt seine Erfahrungen

Fazit

Wenn wir über Skalierung von Agilität sprechen, dann müssen wir einen ganzheitlichen Ansatz für ein Unternehmen finden. Letztendlich ist Software Mittel zum Zweck, um Unternehmen zukunftsfähig aufzustellen. Wenn das gelingt, dann wird Software zu einem strategischen Faktor für das Unternehmen.

Laterale Führung braucht Spielregeln

„Was wir aus der agilen Softwareentwicklung lernen können“

Laterale Führung ist das Führen ohne Weisungsbefugnis. Unternehmen haben heute komplexe Aufgaben zu erledigen. Der Projektverlauf ist nicht planbar, weil mehr unbekannt ist als bekannt. In einer globalisierten Welt ist das Wissen das ein Unternehmen hat, das größte Potenzial. Ursache ist in eine sich ständig wandelnde Welt. Die Geschwindigkeit der Veränderung wird schneller und schneller. Unternehmen sind im Wissenszeitalter weitgehend netzwerkartig strukturiert. Bereichsgrenzen und Hierarchiestufen spielen eine immer kleinere Rolle. Unternehmensübergreifende Teams strukturieren sich, um Projekte gemeinsam durchzuführen.
John Kotter, der amerikanische Experte für Change, hat in den letzten Jahren die Erkenntnis gewonnen, dass Hierarchien kontraproduktiv sind, wenn es gilt dem beständigen Wandel zu begegnen.
Videos von Kotter:
Organizational Hierarchy – http://www.youtube.com/watch?v=CxLC3BXZ1Ek
The Evolution of the 21st Century Organization – http://www.youtube.com/watch?v=Pc7EVXnF2aI

Teamwork statt Einzelkampf
Die Softwareentwicklung hat in den letzten Jahren ein Maß an Komplexität angenommen, dass Unternehmen die erfolgreich in ihrem Markt bestehen, wollen das gesamte Potenzial ihrer Mitarbeiter nutzen müssen. Das funktioniert nur dann, wenn die Summe aller Teile mehr ist, als der Einzelne. Teamwork ist Trumpf. So hat sich die agile Softwareentwicklung durchgesetzt. Statt starrer Prozesse gibt es hier einen Rahmen, der die Spielregeln bestimmt. Dieser wird von dem Team ausgefüllt. Bei der agilen Methode Scrum gibt es den Scrum Master. Dieser hilft dem Team die Spielregeln mit Leben zu füllen und Konflikte zu lösen.
Das muss man sich so ähnlich wie beim Fußball vorstellen. Der Trainer sitzt während dem Spiel auf der Tribüne und kann nur auf freiwillige Gefolgschaft setzen.

Spielregeln statt Chaos
Teamwork braucht Spielregeln, genau wie bei einem Fußballspiel. Diese funktionieren nur dann, wenn Konsens darüber besteht, welches Spiel wir spielen: Fußball oder Rugby?
Scrum stellt einen Satz Spielregeln dar, der einem Team als Basis Rahmenpaket dient. Dies ist eine gemeinsame Grundentscheidung und jeder muss sein Committment dazu geben und seine Bedenken äußern dürfen. Zusätzlich dazu gibt es Vereinbarungen im Team und mit dem Management. Diese müssen immer wieder neu ausgehandelt werden.
Führung via Feedback
Weiterentwicklung durch institutionalisierte Reflexion und Wertschätzung wird groß geschrieben. Das schwäbische Motto „Nix gesagt ist genug gelobt“ reicht nicht aus, um immer neu zu lernen. Das bedarf einer gewissen Kritikfähigkeit. Dazu ist es sinnvoll, wenn alle Beteiligten empathische Kommunikationstechniken üben, wie die Methode der „Gewaltfreien-Kommunikation“ von Marschall Rosenberg. In agilen Projekten evaluieren wir das Ergebnis zusammen mit den Kunden im Review Meeting. Hier wollen wir wertschätzendes konstruktives Feedback und kein Lob, Tadel oder Beifall. Es ist Kommunikation auf Augenhöhe. Diese müssen wir lernen.

Führen mit Zeitboxen
Ein Sprint ist eine Etappe mit fester Zeiteinheit. Am Anfang steht die Planung und am Ende das Feedback. Es ist ein Irrtum zu glauben, dass agile Führung ohne Planung auskommt. Die geplanten Einheiten sind überschaubar und damit eine Risikoeinheit. Es geht vor allem darum, den aktuellen Plan immer wieder zu korrigieren und sich Feedback von Kunden und Stakeholdern einzuholen. Es geht natürlich auch um das Committment den ursprünglichen Plan einzuhalten. Wenn sich der jedoch als falsch herausstellt, dann ist es notwendig so schnell wie möglich Korrektur einzuleiten. Diese Korrekturen sind mit kleinen Zeitspannen einfacher durchzusetzen. Die Zeiteinheit sollte also so kurz sein, dass das Risiko welches das Management eingeht, wenn das Team in die falsche Richtung marschiert, kalkulierbar ist.

Führen mit Zielen
In einem Projekt kann es unterschiedliche Ziele und Motivationen geben. Die Produktvision sollte bei einer Produktentwicklung immer im Vordergrund stehen. „Was“ bauen wir hier eigentlich.
Eine zweite Frage, die wir uns stellen müssen ist das „warum“. Diese Frage wird jeder anders beantworten. Ein Dienstleister der ein Produkt umsetzt, hat ein anderes „warum“, als der eigentliche Product Owner. Für ein Entwicklerteam ist das „warum“ die stärkste Motivationsquelle und deshalb sollte diese Frage für alle Mitglieder die gleiche Antwort haben.

Fazit
Laterale Führung ohne Weisungsbefugnis muss motivieren und kann nicht auf alt bewährtes wie Belohnung durch Bonus, Strafe, Verführung durch Statussymbole oder Geheimwissen zurückgreifen.

Agility Path

Die Scrum.org hat mit seinem Agility Path eine Lösung für die kontinuierliche Verbesserung der Agilität im Unternehmen entwickelt. Dieses Framework hat eine 2 Stufen Feedback-Schleife:

1. Analyse des Ist-Stand

2. Metriken zum Messen der Verbesserung

Als Unternehmen sollten Sie sich folgende Fragen stellen:

Wie war der ROI (Return on Investment) in der Vergangenheit?
Wie viel mehr ist das Unternehmen agil als im letzten Jahr?
Wie effektiv wird der Wert der Produkte des Unternehmens gemanaged?
Welcher nächste Schritt wird dem Unternehmen den größten ROI bringen?
Welche Praktiken sollten wir umsetzen?
Welche Praktiken erhöhen die Qualität am meisten?
Wie kann ich Agility Path (TM) in meinem Unternehmen nutzen?
Informationen finden Sie auf der Seite der Scrum.org unter P2A. oder den Client Guide PDF.

Agile Führungskompetenzen

Für die Softwareentwicklung setzen immer mehr Firmen auf agile Methoden. Dies bedeutet, dass Teams sich selbst organisieren um gemeinsam ein Produkt zu entwickeln. Dies ist ein radikal anderer Ansatz als klassisches Projektmanagement, bei dem Aufgaben an Einzelpersonen delegiert und von der Projektleitung kontrolliert werden. Selbstorganisation ist der Kern dieser Methoden, wie Scrum, Kanban oder Extrem-Programming (XP). Dies erfordert Führungskompetenzen, die auf Vertrauen Selbstverantwortung setzen.
Kürzlich, auf meiner Reise durch Indien, stellte ich mir die Frage, was der Unterschied zwischen Selbstorganisation und Chaos ist.

Die Straßen Indiens teilen sich Rikschas mit schnellen Autos und heiligen Kühen. Sie scheinen gleichzeitig eine Fußgängerzone zu sein. Hier gilt das Gesetz: „Der Schwächere hat Recht“. Gleich einem Schwarm organisieren sich die Verkehrsteilnehmer, achten auf einander und arrangieren sich. Der Tatsache, dass auch ich als Fußgänger als Teil dieses Schwarms unbeschadet an mein Ziel kam, überzeugte mich, dass es sich hier um Selbstorganisation handelt.Chaos

Ahimsa
Das Stichwort Ahimsa wurde nicht erst von Mahatma Ghandi erfunden, aber populär. Es bedeutet Gewaltfreiheit und schließt nicht nur Menschen ein, sondern auch Affen, Kühe und andere heilige Tiere. Marshall Rosenberg, ein Amerikaner, hat die Methodik der „Gewaltfreien Kommunikation“ (http://de.wikipedia.org/wiki/Gewaltfreie_Kommunikation) geprägt und uns damit im Westen Ahimsa ein Stückchen näher gebracht. Softwareentwicklung bedeutet an erster Stelle Verhandlung und Kommunikation. Im Unterschied zur Verhandlung im Gerichtssaal, wollen wir mit unseren Kunden und Entwicklern die Anforderungen, Termine und Ressourcen immer wieder neu verhandeln. Es darf also keine Gewinner und Verlierer geben, sonst ist eine Produktentwicklung schnell zum Scheitern verurteilt und Motivation und Vertrauen sind dahin. Ahimsa kann uns hier der Leitgedanke sein, wenn wir auch morgen vertrauensvoll zusammenarbeiten wollen.
Vertrauen
Vertrauen ist ein großes Wort, das sich wie Liebe oder Mut nicht erzwingen lässt. Es ist schneller zerstört als aufgebaut. Ehrlichkeit, Respekt, Loyalität und Verantwortung sind Kriterien, die Vertrauen flankieren.
Für Manager ist das eine große Herausforderung, wenn Teams agil arbeiten möchten und sollen. Früher oder später tauchen Konflikte auf, die agil gelöst werden müssen, wenn die Beziehung zwischen Team und Manager nicht wieder alte Muster annehmen soll. Um einem Team durch seine Konflikte hindurch zu helfen, muss sich eine Führungskraft als Coach verdient machen statt dem Wunsch einzelner nachzugeben und als Steuerkünstler Mitarbeiter zu bestrafen oder gar zu entlassen. Stattdessen muss er darauf vertrauen, dass das Team in der Lage ist seine Konflikte selbst zu lösen und dies auch gegenüber Vorgesetzten vertreten. Er sollte dem Team also einen Vertrauensvorschuss einräumen, auch wenn dieser enttäuscht werden kann.
Führungsstärke
Auch bei agiler Produktentwicklung gibt es Normen und Regeln. Ein Framework, wie Scrum, stellt diese Spielregeln bereit. Diese Regeln schreiben eine regelmäßige Inspektion des Erreichten vor und entsprechende Anpassungen, wenn Ziele nicht erreicht werden. Dazu müssen Ziele vorab klar definiert und allen verständlich und bekannt sein.
Der agile Werkzeugkasten hält auch für das Management alle Werkzeuge bereit, die Notwendig sind um die nötige Transparenz zu erhalten. Am Ende jeder Iteration gibt es ein Review des Produktes. Dies ist der Zeitpunkt für die Inspektion und nötige Intervention. Die Zeitlänge einer Iteration stellt hier das Maß für Risiko dar, dass eine Führungskraft eingeht.
In einem klassischen Management Szenario heißt Führungsschwäche, wenn man nicht sagt, wo es lang geht und Aufgaben nicht sauber delegiert und kontrolliert werden. Mitarbeiter fühlen sich nicht ermächtigt selbst die Initiative zu ergreifen.
Bei einem agilen Management erwarten wir von den Teams, dass die selbstverantwortlich die Dinge vorantreiben und die Ziele im Blick behalten. Das ist vielleicht nicht unbedingt jedermanns Sache. So erlebe ich immer wieder in Teams, dass Einzelne in Krisensituationen vom Management eine Lösung erwarten statt selbst aktiv zu werden. Das sind alte Muster, die nicht von alleine verschwinden. Gerade bei sehr jungen Mitarbeitern kommt diese neue Art der Führung jedoch besonders gut an. Die Generation Facebook hat früh gelernt kollaborativ zusammen zu arbeiten.
Wir verlangen von der Führungskraft also Gewaltfreiheit, um das Vertrauen nicht zu zerstören. Dies erfordert mehr Fragen als Antworten. Der Manager wird hier zum Coach, der das Team zu Bewusstsein für den Kern des Problems führt.

Effektivität und Effizienz

Eine Führungskraft sorgt dafür, dass ein Team effektiv arbeitet. Dazu braucht das Entwicklerteam die nötigen Tools und Techniken. Dies erfordert eventuell Schulung und Investitionen. Wir waschen unsere Wäsche schließlich auch mit der Waschmaschine und nicht mit Waschbrett am Fluss. Dies ist die wichtigste neue Aufgabe einer agilen Führungskraft: dem Team dienen und ihm Schwierigkeiten aus dem Weg räumen.
Seminar zum Thema: Agile Führungskomptenzen
Uta Kapp

Scrum – was ist das?

Vom Sport können wir viel für die Entwicklung von Software lernen. So können wir vom Segelsport etwas über den sinnvollen Einsatz vom Bordcomputer für die Steuerung einer Yacht in einer Segelregatta abschauen. So wie der wohl bekannteste Segelwettbewerb, der Americas Cup, in einzelnen Rennetappen (Match Races) stattfindet, so werden bei der agilen Softwareentwicklung fest definierte Zeitetappen von etwa 30 Tagen gesetzt. Bei Scrum heißen diese Etappen Sprints.

Eine der wichtigsten Rollen an Bord der Segelyachten ist der Navigator. Dieser hat zwei simple und doch schwierige Aufgaben: Sicherzustellen, dass das Boot anhand der Gegebenheiten wie Wind, Strömung etc. schnell fährt und dass es in die richtige Richtung fährt. Er überprüft mithilfe seines Bordcomputers, ob das Geschwindigkeitspotential den Wetterbedingungen entsprechend ausgenutzt wird. Bei Scrum hat der ScrumMaster die Funktion eines Navigators. Er überwacht, dass alle Prinzipien eingehalten werden und dass das Scrum-Team somit möglichst effektiv ans Ziel kommt.

Der Steuermann auf den Yachten führt das Ruder und gibt damit die Richtung an, in die das Schiff steuert. In Scrum entspricht dies der Rolle des ProductOwner, der die Sicht des Kunden vertritt und bestimmt, was mit höchster Priorität umgesetzt wird.

So wie der Bordcomputer Informationen zur Position der Yacht in der Regatta liefert, so schaffen Scrum-Tools Transparenz bezüglich des Projektstandes. Sie sind nützlich für die Verwaltung der zu erledigenden Aufgaben und der Planung. Das einfachste und sehr oft verwendete Tool ist hierbei eine Pinnwand mit Kärtchen und ggf. ein Excel-Sheet. Damit sollte jedes Team das anfängt sich mit Scrum zu organisieren, beginnen. So ist es möglich, im zuerst kleinen Kreis, den Umgang mit den für Scrum typischen Arbeitsabläufen zu erproben. Gemeinsam wird ein Taskboard gepflegt und bereits erledigte Aufgaben werden z.B. am Ende des Arbeitstages markiert.

Teams und Projekte wachsen mit der Zeit und ein unübersichtlicher Aufgabendschungel entsteht. Die Teams werden an verschiedene Standorte verteilt. Manche Teams arbeiten sogar über mehrere Zeitzonen. Der Einsatz von Hilfsmitteln für die Verwaltung wird dann unerlässlich.

Ein Kernkonzept in Scrum ist die Selbstorganisation des Teams. Dies ist ein radikal anderes Konzept als im klassischen Projektmanagement. Hier gibt es niemanden der vergleicht ob und wie schnell einzelne Teammitglieder Arbeitsschritte durchgeführt haben. Wie auf einer Segelyacht bringt jeder die Leistungen, die erforderlich sind, um die Etappe zu gewinnen. Da in einem cross-funktionalen Team prinzipiell jeder an allen Aufgaben mitarbeiten kann, interessiert hier nur das gemeinsam geleistete Ergebnis und dass, was noch gemeinsam zu erledigen ist. In einem sich selbst organisierenden Team ist jedes Mitglied selbst-verantwortlich und proaktiv. Das ist ein sehr hoher Anspruch an alle Beteiligten. Kooperation, Kommunikation und Offenheit sind erforderlich. Jedes Teammitglied sollte zu jedem Zeitpunkt auf alle Informationen eines Projektes zugreifen können.

Scrum bezieht seine Effektivität aus der Fähigkeit der Beteiligten ihr Potential zusammen zu schließen, sodass das Ganze mehr wird als die Summe aller Teile. Sobald ein Konkurrenzverhalten der Teammitglieder untereinander gefördert wird, ist das Miteinander geschwächt. Metriken für die Verwaltung von Aufgaben sollten also immer nur das Gesamtsystem darstellen und nicht die geleistete Arbeit von Einzelpersonen. Der wirkliche Beitrag einer Einzelperson zum System ist nur in einer Fließbandproduktion in Arbeitseinheiten quantifizierbar, nicht aber in einem Entwicklungs- und Lernprozess.

Die Komponenten von Scrum

Auf den ersten Blick bietet Scrum einen Rahmen aus Zeitabläufen und verschiedenen Meetings, die zu bestimmten, festen Zeitpunkten abgehalten werden. Es gibt Iterationen von 30 Tagen, Sprints genannt, die fest eingehalten werden. Zu jedem Sprint werden Meetings fest eingeplant. Dies sind der tägliche Scrum, die Sprint Planungsmeetings am Anfang, sowie Produkt-Review und Pozess-Retrospektive am Ende. Des weiteren gibt es ein Product-Backlog, in dem alle zu erledigenden Anforderungen geführt werden. Für jeden Sprint werden Backlog-Einträge ausgewählt und abgearbeitet.

Auf den zweiten Blick wird dieser Rahmen gefüllt mit menschlichen Beziehungen und Bewusstsein, Kooperation und Selbstorganisation, sowie Kreativität, Mut und Vertrauen. Dieses sind alles formlose Faktoren, die nur subjektiv erfassbar sind. Verständigung zwischen den Menschen in einer Organisation kann nicht erzwungen werden. Machtspiele und verdeckter Boykott lassen sich nicht verbieten. Vertrauen kann nicht gefordert werden. Die einzige Möglichkeit die wir haben, um auf die formlosen Faktoren in der menschlichen Zusammenarbeit einzuwirken, ist indirekt. Dazu sind die richtigen Rahmenbedingungen erforderlich. Es ist vergleichbar mit den Spielregeln die für ein gutes Gesellschaftsspiel, wie Skat, gelten. Trotz gleicher Regeln ist jede Skatrunde eine eigene Welt.

Scrum bietet viele Hilfsinstrumente, um die Spielregeln einzuhalten.

Time-Boxing

Iterationen, die auf einen festen Zeitrahmen von z.B. 30 Tagen fixiert sind, profitieren von Vorteilen die daraus folgen:
Ein Projekt, bei dem in der laufenden Iteration, mit festem Zeitfenster, nur die Features mit der augenblicklich höchsten Priorität implementiert werden, haben kein Zeitproblem mehr. Damit fällt der größte menschliche Stressfaktor weg.
Wenn der Zeitrahmen bis zur nächsten Produktauslieferung fixiert ist, dann gibt es nur noch Schwierigkeiten bei dem setzen von Prioritäten und der Bereitstellung von Programmierkapazität.

Wenn nur die Features mit der höchsten Priorität umgesetzt werden, dann ist das Resultat automatisch der größte mögliche Wertzuwachs.Wenn jede Iteration das bestmögliche Produkt für den Kunden liefert und das Produkt „fertig“, also auslieferbar, ist, dann liegt das Projekt immer in der Zeit. Es wären dann andere Faktoren als Zeit zu diskutieren. Dies sind dann Qualifikation der Entwickler um mehr Features in einer Iteration zu verwirklichen. Die Optimierung der Kommunikation wäre ein Diskussionspunkt. Höhere Investitionen früher in der Zeit könnten Thema sein. Eventuell das Thema Motivation. Zeitplanung, als solches, ist aber kein Thema mehr.

Backlog Priorisieren

Prioritäten festlegen ist die Aufgabe des Kunden. Ein gut priorisierter Product-Backlog ist die Basis für die Planung.

Relative Schätzung

Da Software ein Entwicklungsprozess ist und keine Reproduktion am Fließband, ist es bei einem durchschnittlichen Projekt nicht möglich abzuschätzen, wie viele Stunden die Implementierung eines Features dauert. Es ist sehr wohl möglich zu schätzen, wie groß der Brocken ist, den ein Feature relativ zu einem anderen darstellt. Dazu wird ein Feature als Referenz festgelegt. Es ist so möglich abzuschätzen, ob ein anderes Feature größer, kleiner, doppelt so groß oder zehn mal so groß erscheint. Zu große Einheiten sollten in überschaubare aufgeteilt werden.

Planungspoker

Die relative Größe von Features lässt sich gut gemeinsam im Team schätzen. Diese Gruppenaufgabe hat verbindenden Charakter. Wenn jeder dabei ist, dann ist das gleichzeitig ein Committment für das Projekt. Wenn der Schätzvorgang als Planungspoker durchgeführt wird, dann wird es zu einem spielerischen Vergnügen. Diese Form von Poker funktioniert folgendermaßen:
jeder Teilnehmer bekommt einen Satz Pokerkarten mit den Ziffern 1, 2, 3, 5,10, 13, 20
Die Ziffern stehen für die relative Größe von Features zueinander. Eine mittelgroßer Brocken hat die Einheit 5.
Zuerst wird eine Referenzaufgabe festgelegt, relativ zu der weitere geschätzt werden.
Jedes Feature aus der Anforderungsliste (Product-Backlog) wird der Reihe nach bearbeitet, indem jeder, wie beim Pokerspiel, gleichzeitig seine Karte mit der Schätzzahl auf den Tisch legt.
Die geschätzte Größe ergibt sich aus dem Durchschnittswert.

Es zeigt sich hierbei, bei welchen Anforderungen Verständigung darüber notwendig ist, was hier gemeint ist.
Die relative Größe sagt nichts über die Zeit aus, die notwendig ist um das Feature zu Implementieren. Damit ist dieser Schätzvorgang unpolitisch.

Von der relativen Grösse zur Sprintplanung

Bei der Planung für den nächsten Sprint muss das Team abschätzen, wie viele Aufgaben aus dem Product-Backlog in der nächsten Iteration von 30 Tagen umsetzbar sind. Dazu ist es notwendig zu wissen, wie viel Zeit eine mittlere oder kleine Aufgabe in Anspruch nimmt. Daraus lassen sich dann Zeiten für größere Aufgaben errechnen. Ein neu gebildetes Team braucht mindestens drei Sprints, bis ihm genaue statistische Werte zur Verfügung stehen. Vorher kann es nur grobe Schätzungen abgeben.

Review und Retrospektive

In Scrum gibt es 2 verschiedene Ebenen des Beobachtens und Lernens:
a) Das aktuelle Produktergebnis wird zusammen mit dem Kunden inspiziert. Ist das Ergebnis so, wie der Kunde sich das vorstellt? Was lernen wir aus dem Prototyp für den nächsten Sprint?
b) In der Retrospektive wird der Teamprozess untersucht. Was lief gut, was lief schlecht? Wie können wir unseren Prozess verbessern? Die kontinuierliche Gestaltung der Prozesse wird so zu einem Führungsinstrument, mit dem jeder am Projekt Beteiligte einbezogen wird. Dies ergibt eine Rückkopplung mit der der Effizienzgrad im Team ständig erhöht wird. Damit hat jedes Team seine eigenen Spielregeln und somit sein eigenes Scrum.

Fazit

Scrum ist mehr als nur ein neuer Hype oder ein neues Produkt. Ähnlich wie in einem Match Race fordert es das gesamte Potential eines Softwareentwicklungsteams. Ein Team ist mehr als die Ansammlung von Personen. Wenn die Intelligenz, Kreativität und das menschliche Potential von Entwicklern zusammengeschlossen wird, dann ist das Ergebnis etwas völlig anderes, als die Summe aller Teile. Scrum bietet uns ein Konzept, mit dem wir es schaffen diese Ressourcen zu nutzen. Es hilft uns nicht nur die logisch-rationalen Fähigkeiten zu nutzen, sondern auch unsere zutiefst menschlichen wie Intuition, Bauchgefühl, Empathie und Vertrauen.