Donnerstag, 18. August 2016

Warum eine hundertprozentige Auslastung schlecht ist


Eigentlich sollte man denken, dass es (zumindest aus Arbeitgebersicht) etwas Gutes ist wenn Mitarbeiter zu hundert Prozent ausgelastet sind. Keine unproduktiv verbrachte Arbeitszeit, kein untätiges Herumsitzen, kein gelangweiltes Surfen im Internet. Für viele Manager ist es eines ihrer Hauptziele, dass sie ihren Leuten soviel Arbeit zuweisen, dass die durchgehend etwas zu tun haben. Das Problem: damit begehen sie einen schweren Fehler. Und der lässt sich an einem anschaulichen Beispiel erklären.

Das oben zu sehende Display hängt im Bürgeramt der Stadt Bonn, das unter Anderem für Ausweisangelegenheiten oder die An- und Abmeldung von Autos zuständig ist. Um einen Termin zu bekommen kann man sich online anmelden und bekommt eine Vorgangsnummer und eine Uhrzeit zugemailt zu der man erwartet wird. Durch die Einblendungen auf dem Display wird man zu dieser Zeit sofort zu einem Schalter geleitet, an dem man seinen Behördengang erledigen kann. Ein zunächst unscheinbares Detail dieses Vorgangs ist, dass die Vorgangsnummer chronologisch hochgezählt wird. Die hier zu sehenden Nummern die mit Zwei-, Drei- oder Viertausend beginnen wurden mehrere Tage im voraus vergeben, die mit einer Sieben am Beginn aber erst vor wenigen Minuten, maximal vor wenigen Stunden. Es stellt sich die Frage: warum hat man diese Zeiträume so lange freigelassen? Wäre es nicht effizienter gewesen sie von Beginn an zu verplanen, so dass die Mitarbeiter auch ganz sicher ausgelastet sind?

Nun, nicht ganz. Stellen wir uns vor, dass bei vollständiger Verplanung die Bearbeitung eines Vorgangs länger dauert als gedacht, sagen wir 10 Minuten länger. Und nehmen wir an, dass der danach sich genauso in die Länge zieht. Die Folge wäre eine Verspätung von 20 Minuten, um die sich alle folgenden Vorgänge verschieben. Deswegen sind die nächsten Kunden verärgert und sie beschweren sich zunächst ausgiebig. Dadurch dauern auch ihre Fälle länger, die Verzögerung wächst und am Ende des Tages beträgt sie mehr als eine Stunde. Wer die letzten Bearbeitungszeiträume zugewiesen bekommen hat kann dann nicht mehr bedient werden und er muss am nächsten Tag wiederkommen, der dadurch gleich mit ungeplanter Arbeit und dadurch mit verspäteter Abarbeitung der geplanten Aufgaben beginnt. Und so geht es immer weiter.

Derartige Zustände sind natürlich unerwünscht, weshalb vorgegangen wird wie oben beschrieben: ein bestimmter Prozentsatz der Bearbeitungszeiträume bleibt bewusst unverplant. Wenn sich Verspätungen aufstauen können sie als Puffer genutzt werden um den Verzug aufzufangen, und wenn nicht können sie an kurzfristig aufgetauchte Kunden vergeben werden (die man bei vollständiger Verplanung wegschicken müsste). Auch der umgekehrte Fall ist mit diesem Modell möglich: wenn mehrere Bearbeitungen schneller erledigt sind als gedacht lässt sich nachträglich noch ein weiterer Kunde in die Warteschleife aufnehmen und bedienen. Man sieht - dadurch, dass die Sachbearbeiter nicht zu hundert Prozent verplant wurden sind sie in der Lage wesentlich flexibler auf das tagesaktuelle Arbeitspensum zu reagieren, ohne dass dadurch Verspätungen entstehen.

Was hier am Beispiel des bonner Bürgeramts beschrieben wird gilt natürlich auch für jede andere Art der Arbeit. Egal ob in einem Bauvorhaben, auf einem Softwareprojekt oder in einem sonstigen Unternehmen - zu ungeahnten Aufwänden kann es immer kommen. Und wenn man in solchen Momenten keinen Puffer zur Verfügung hat baut sich eine Bugwelle an unerledigter Arbeit auf die man ewig vor sich herschiebt.

Natürlich kann es bei dem Einplanen solcher Puffer dazu kommen, dass es ab und zu zu Phasen des Leerlaufs kommt. Das ist unschön, wird sich aber nie ganz vermeiden lassen. In der Gesamtbetrachtung sollte aber klar sein, dass das um ein vielfaches besser ist als das Auftürmen von immer neuen Verspätungen, die irgendwann nur noch mit Überstunden und Wochenendarbeit zu bewältigen sind. Übermüdete und frustrierte Mitarbeiter führen nämlich zu weiteren nachteiligen Effekten (aber das wäre dann ein Thema für sich).

Montag, 15. August 2016

Ein Bild sagt mehr als 1000 Worte (XII)


Donnerstag, 11. August 2016

Agilität durch Job Hopper

Bild: Wikimedia Commons/Brussels Airport - CC BY-SA 2.0
Ich habe mal wieder einen Artikel für das IT-Freelancer Magazin verfasst: Warum meine Kunden davon profitieren, dass ich nicht nur für sie arbeite. Verkürzt gesagt geht es dort darum, dass jemand der für mehr als ein Unternehmen arbeitet in ganz anderer Weise zur gemeinsamen Wertschöpfung beitragen kann als jemand der Vollzeit vor Ort ist. Neue Methoden, andere Programmiersprachen, alternative Tools und vieles mehr würden für viele interne Mitarbeiter nur schwer zugänglich sein, jemand der bei einem zweiten Kunden unterwegs ist erlebt sie dort ständig live in Aktion. Auch "alternativlose" Entscheidungen lassen sich ganz anders hinterfragen wenn man belegen kann dass die angeblich nicht vorhandenen Alternativen an einem anderen Ort existieren und erfolgreich umgesetzt werden. Das Einbinden von Freelancern, Consultants und sonstigen "Job-Hoppern" kann also für frische Ideen, neue Blickwinkel und neue Lösungsansätze sogen. Und: für mehr Agilität.

Im Grunde ist auch das relativ einfach: das in agilen Methoden vorgesehene Inspect & Adapt bedeutet nichts anderes, als dass permanent nach neuen Wegen gesucht wird effizienter, einfacher, billiger oder schneller ans Ziel zu kommen. Neues soll ausprobiert werden, Experimente gewagt, Hypothesen validiert. Das setzt allerdings voraus, dass man überhaupt von diesen neuen Möglichkeiten weiss. Ein simples Beispiel: ein Team aus introvertierten Eigenbrötlern kann möglicherweise in ungeahnter Weise zu besserer Zusammenarbeit gebracht werden indem man es zu Mob Programming oder auch nur zu Mob Code Reviews überredet. Und nicht nur die Zusammenarbeit kann sich so verbessern - in diesem Fall kann auch die berühmte Schwarmintelligenz zum Tragen kommen, wordurch das Produkt schneller und in besserer Qualität fertig wird. In den meisten Firmen in denen ich war ist dieses Konzept allerdings völlig unbekannt gewesen. Ohne externen Input (in diesem Fall durch mich) wäre es das auch geblieben.

Natürlich bedeutet das nicht, dass externe Teilzeitkräfte ein Allheilmittel sind. Einiges kann auch dagegen sprechen, etwa die dadurch verursachte Instabilität der Teams, die Abstimmungsprobleme in den Abwesenheitsphasen oder die Errichtung bürokratischer Hürden durch Konzern-Trolle. Auch kann es je nach Rolle Unterschiede geben, z.B. mag es bei einem agile Coach besser funktionieren als bei einem Tester. Das alles wird sich je nach Einzelfall anders lösen lassen, die Gesamtaussage bleibt aber: wer sich Job Hopper in Haus holt kann dadurch die eigene Agilität befördern.

Montag, 8. August 2016

Konzern-Trolle

Bild: Flick/Jared - CC BY 2.0
Eine kleine Geschichte aus einer großen Firma: Ein Entwicklungteam kommt eines Morgens zur Arbeit und erkennt das eigene Büro nicht wieder: Sprint Board, Product Backlog, Burndown Chart, Velocity Chart und Impediment Backlog sind verschwunden, abgehängt von der Betriebsfeuerwehr wegen Verstoß gegen die Brandschutzvorschriften. Alle Proteste helfen nichts, Papierwände sind nicht erlaubt.

Eine zweite Geschichte aus einer großen Firma: Mitten im Sprint taucht ein Compliance Manager im Teamraum auf und fordert, dass ab sofort keine Daily Standups mehr durchgeführt werden. Zu berichten, was man gestern gemacht hat, würde der Betriebsvereinbarung widersprechen, die eine Erfassung der Arbeitsleistung auf Personenebene verbietet. Als darauf hingewiesen wird, dass Scrum dann nicht mehr funktioniert, sorgt der Manager dafür, dass diese Methode ganz verboten wird.

Eine dritte Geschichte aus einer großen Firma: Nach dem Inkrafttreten einer neuen Sicherheitsrichtlinie darf ein Scrum Team nicht mehr in einem Raum zusammensitzen. Ein Teil der Entwickler ist extern, der andere intern, wodurch sie zu verschiedenen Sicherheitsstufen gehören. Die Externen müssen sogar in ein anderes Gebäude umziehen und sich jedes einzelne Meeting im Hauptgebäude gesondert genehmigen lassen.

Diese drei Geschichten (und noch viele weitere mehr) haben sich genau so zugetragen. Sie gehen jeweils zurück auf einen Menschenschlag, für den sich der schöne Begriff des "Konzern-Trolls" eingebürgert hat. Konzern-Trolle sind Personen ausserhalb der eigentlichen Produkt-Entwicklung, die die Verantwortung für irgendeinen Prozess oder die Einhaltung irgendeiner Vorschrift haben. Über diese wird eifrig und eifersüchtig gewacht, und zwar auch dann, wenn anderen Mitarbeitern die Arbeit dadurch erschwert oder unmöglich gemacht wird. "Da kann man nicht machen" heisst es dann immer, "ich habe die Vorschrift nicht gemacht, ich sorge nur für ihre Einhaltung."

Von den normalen Prozessmanagern unterscheiden sich Konzerntrolle übrigens deutlich, und zwar durch ihre explizit destruktive Grundeinstellung. Fast alle Vorschriften auf die sie sich berufen ließen sich nämlich auch deutlich weniger rigoros auslegen, in einer Weise in der sie nicht mehr ein absolutes Hindernis für agiles und/oder produktives Arbeiten wären. Warum diese Menschen so destruktiv geworden sind wäre nochmal ein Thema für sich, aber selbst wenn man es wissen sollte wäre das nur bedingt hilfreich. Sie sind wie sie sind, was macht man jetzt mit ihnen?

Was ich in diesem Zusammenhang häufig als Lösungsansatz erlebt habe, ist die Holzhammer-Methode: das Problem wird zum Vorgesetzten des Trolls eskaliert, der diesen zu sich ins Büro zitiert, um ihm dort einen ordentlichen Anschiss zu verpassen. Kurzfristig ist das eine sehr effektive Lösung, da der Widerstand des Trolls auf diese Art sofort gebrochen werden kann. Nachhaltig ist es allerdings nicht, da er sich bei der nächsten Gelegenheit sofort wieder querstellen wird.

Zielführender finde ich den Ansatz, die Schmerzen dorthin zu verlagern, wo sie entstehen: sobald ein Konzern-Troll mit seiner Paragraphenreiterei beginnt, kann man ihm selbst einen Arbeitsauftrag geben. Er muss dann einen Weg erarbeiten und vorschlagen, der einerseits die Einhaltung seiner Vorschrift ermöglicht, auf der anderen Seite die Arbeitsprozesse der anderen nicht verlangsamen oder ineffektiv machen darf. Und so lange der nicht von allen Beteiligten akzeptiert ist, muss er wieder und wieder überarbeitet und neu vorgelegt werden. Mein Erfahrungswert: jeder Troll, der das einmal mitgemacht hat, wird sich in Zukunft deutlich zurückhalten.

Freitag, 5. August 2016

Agile Testkonzepte

Bild: Public Domain Images/Amanda Mills - CC0 1.0
Zu den wohl unagilsten Dingen die mir auf verschiedenen Projekten begegnet sind gehörten die Testkonzepte mitsamt der damit verbundenen Testmanager. Die gesamten Dokumente waren durchzogen von Wasserfall, V-Modell, Command & Control, Dokumentationszwängen und ähnlichen Management-Relikten des zwanzigsten Jahrhunderts. Bedingt dadurch, dass nicht nur ich derartige Erfahrungen gemacht habe, ist die Idee des Testkonzepts im agilen Umfeld stark beschädigt und wird häufig kategorisch abgelehnt. Das muss allerdings nicht so sein. Ich habe bereits mehrfach als agiler Testmanager gearbeitet und in diesem Rahmen agile Testkonzepte schreiben dürfen - ohne dass das als Widerspruch zum agilen Vorgehen empfunden wurde. Es kommt eben darauf an wie man es macht.

Aber was gehört in ein agiles Testkonzept?

Im Grunde das Gleiche, das man auch in einem "klassischen" Testkonzept erwarten würde. Es sollte dort geklärt werden wer was wann wie und wo testet. Folgende Punkte sollten sich meiner Meinung nach dort finden:
  • Was bedeutet Testen im agilen Umfeld? (so früh und umfassend wie möglich)
  • Wer trägt QA-Verantwortung? (alle)
  • Was wird getestet? (sowohl die neuen Features als auch regressiv alle alten)
  • Wie wird getestet? (möglichst automatisiert)
  • Auf welchen Ebenen wird getestet? (auf allen, in Form einer Testpyramide)
  • Wann beginnt die Testphase?  (ganz am Anfang, bzw. es gibt sie nicht gesondert)
  • Welche Tools werden eingesetzt? (z.B. Jenkins, Fitnesse)
  • Auf welchen Umgebungen wird getestet? (möglichst produktionsnah)
  • Wie lang sind die Testzyklen (idealerweise maximal ein Tag, siehe Punkt 4)
  • Gibt es spezielle Test-Arten? (z.B. Lasttests, Penetrationstests, A/B-Tests)
  • Wie werden die Ergebnisse dokumentiert? (im Idealfall durch das Test-Tool selbst)
Darüber hinaus kann es je nach Einzelfall Sinn machen weitere Bereiche aufzunehmen, zum Beispiel diese:
  • Wie ist die Rolle des Testers definiert? (Teil des Entwicklungsteams)
  • Wie ist die Rolle des Test-/QA-Managers? (Servant Leader)
  • Gibt es Testvorgaben in den Anforderungen? (Ja, Definition of Done und Akzeptanzkriterien)
  • Wer verfasst diese Vorgaben? (der Product Owner zusammen mit dem Team)
  • Werden interne und externe Regulierungsvorgaben erfüllt? (z.B. durch Mapping-Tabelle)
  • Sonstiges (z.B. Test Driven Development)
Derartig aufgebaute Testkonzepte umfassen meiner Erfahrung nach je nach Prosa-Anteil bis zu 20 Seiten, sind also deutlich schlanker als die noch weit verbreiteten "Telefonbücher". Von mir (mit)verfasste derartige Konzepte waren auch bereits Untersuchungsgegenstand von Revisionsabteilungen und haben somit ihre Praxistauglichkeit unter Beweis gestellt. Voraussetzung dafür ist allerdings die Bereitschaft des Managements sich auf agile Vorgehensmodelle einzulassen und nicht auf dem "haben wir immer schon so gemacht" zu bestehen. Das ist zwar nicht immer gegeben, aber in diesen Fällen gibt es ganz andere Probleme als das Testkonzept.

Dienstag, 2. August 2016

Scrum-Checkliste

Bild: Wikimedia Commons/Ceeseven - CC BY-SA 4.0
Egal ob ein Team neu mit Scrum anfängt oder schon lange damit unterwegs ist, es macht Sinn von Zeit zu Zeit zu überprüfen ob man nicht in ganz andere Richtungen abrutscht. Die folgende Checkliste basiert auf einer die ich bei einem meiner Kunden eingesetzt habe. Sie geht an einigen Stellen über den Scrum Guide hinaus um auch die Best Practices zu umfassen, andere Dinge werden nicht erwähnt, da sie dort selbstverständlich waren (z.B. dass technische Lösungswege oder Architektur von den Teams selbst festgelegt werden). Eine gute Einsatzmöglichkeit für so eine Liste ist, sie ausgedruckt ans Team-Board zu hängen. Sobald ein Punkt aus Sicht eines Teammitglieds nicht mehr erfüllt ist kann er ihn rot markieren, wodurch ein Thema für die nächste Retrospektive entsteht. Alternativ kann sie auch in Workshops, Audits oder zu sonstigen Anlässen genutzt werden. Was ich nicht machen würde wäre ein komplettes Besprechen aller Punkte in einiger einzigen Retrospektive, dafür dürfte die Zeit nicht reichen.
  • Das Team besteht aus 3 - 7 Mitgliedern, einem PO und einem Scrum Master 
  • Das Team ist crossfunktional besetzt (FE, BE, QA, UX, etc) 
  • Der PO und der Scrum Master sitzen beim Team 
  • PO und der Scrum Master sind Vollzeit-Jobs 
  • Der PO hält ständigen Kontakt zu seinen Stakeholdern 
  • Der Scrum Master tauscht sich regelmässig mit dem Management aus 
  • Die Regel-Meetings finden statt (Daily Standup, Planning, Retrospektive, Review) 
  • In jedem Sprint finden Backlog Refinements statt 
  • Es existiert ein physisches Sprint-Board 
  • Es existieren ein Burndown-Chart und ein Velocity Chart 
  • Es existieren eine Definition of Ready und eine Definition of Done 
  • Die Sprints haben jeweils ein fachliches Sprint-Ziel
  • Alle Stories im Sprint sind fachlich geschnitten 
  • Alle Stories im Sprint haben fachliche Akzeptanzkriterien 
  • Alle Stories im Sprint sind geschätzt 
  • Alle Stories im Sprint sind Epics zugeordnet 
  • Alle Stories im Sprint sind in Tasks unterteilt 
  • Die Stories im Sprint werden sequenziell abgearbeitet 
  • Die Tasks sind so geschnitten, dass sie in einem Tag erledigt werden können 
  • Es gibt WIP-Limits für die Team-Mitglieder 
  • Im Sprint finden Pairing und gegenseitige Reviews statt, es gibt shared Codeownership 
  • Die Tests ergeben eine Test-Pyramide 
  • Alle Aufwände (auch SoS, Spikes, Bugs, etc.) sind auf dem Board abgebildet 
  • Nach dem Sprint ist jede fertige Story potentially shippable 
  • Nach dem Sprint erzeugt jede fertige Story eine nutzbare Funktionalität 
  • Im Sprint Review sind Stakeholder anwesend 
  • Impediments werden erkannt und bearbeitet 
  • Es wird an technischen Schulden und Bugs gearbeitet 
  • Der PO weiss woran die Entwickler arbeiten 
  • Das Team kennt die Produktvision und den ungefähren Inhalt der nächsten Sprints 
  • Das Team kennt seine Velocity 
  • Es existiert eine Story Map und/oder Road Map 
  • Es gibt ein Scrum of Scrums zur fachlichen Abstimmung zwischen den Teams 
  • Es gibt eine Community of Practice zum Erfahrungsaustausch mit anderen Personen

Samstag, 30. Juli 2016

Kommentierte Links (XV)

Grafik: Pixabay / Geralt - Lizenz

  • Vladimir Oane: Medieval Lessons to Help Your Company Become More Lean & Agile

    • Und ich dachte, ich hätte mit Graf Clausewitz die Messlatte schon hochgelegt. Vladimir Oane überbietet das locker, indem er bei den mongolischen Eroberern Dschingis Khan und Subutai agile Managementmethoden findet. Zumindest was die Aspekte des (bewussten) Kontrollverlustes und der Teamautonomie betrifft scheint er da durchaus recht zu haben, mir fehlt allerdings ein bisschen der datengetriebene Ansatz. Den von den beiden bekennenden Analphabeten zu verlangen wäre allerdings auch etwas vermessen. Insgesamt ein interessanter Blickwinkel.

  • Erik Duindam: How I built an app with 500,000 users in 5 days on a $100 server

    • Über Lean Startup und Minimum viable Products reden können viele, das Ganze in die Tat umsetzen nur wenige. Erik Duindam scheint dazuzugehören, und er reichert den Begriff sogar noch um eine zusätzliche Dimension an: die Skalierbarkeit. Im klassischen Sinn mag die nicht immer Teil der Methode gewesen sein, aber in der extrem volatilen digitalen Ökonomie hat Duindam einen Punkt - ein Produkt das nicht in der Lage ist eine extrem schnell steigende Nachfrage zu befriedigen läuft in die Gefahr am eigenen Erfolg zu ersticken.

  • Petra Wille: Böse Deadline! Wie man zu einer realistischen & flexiblen Planung kommt

    Ich habe Ende letzten Jahres mal etwas über Scrum und feste Deadlines geschrieben, und darüber, wie ein Team damit umgehen kann. Petra Wille geht zu diesem Thema wesentlich tiefer ins Detail und nähert sich ihm von verschiedenen Seiten um die Frage nach Planungsmöglichkeiten im agilen Umfeld zu beantworten. Ich bin mir nicht sicher ob ich ihren Rat gut finde, ab einem gewissen Punkt die Planungen vor Change Requests zu schützen, im Großen und Ganzen sagt sie aber viele richtige und kluge Dinge.

  • Daniel Hüfner: In dieser deutschen IT-Firma hat der Chef nichts mehr zu sagen

    • In mehreren Firmen konnte ich bereits Schnappatmung beim Management auslösen, wenn ich als Antwort auf die Frage nach "agilem HR" Modelle wie das hier von Sipgate vorgestellt habe. Selbstverantwortliche Teams, ja bitte - aber doch nicht in Personalfragen! Und transparent zu Stande kommende Gehälter, wo kämen wir denn da hin? Auf einmal war Agilität im Personalbereich doch nicht mehr so wichtig. Sicher lässt sich das Sipgate-Vorgehen nicht in jede Firma übertragen, allerdings würde es nicht schaden, wenn einige mehr es zumindest versuchen würden.

  • Resalin Rago: 5 Non-Agile TED Talks About Agile

    • Ich könnte ja stundenlang TED-Videos ansehen, wenn ich nur die Zeit dafür hätte. Glücklicherweise hat mir hier jemand das Kuratieren und Kommentieren abgenommen. In Summe trotzdem mehr als eine Stunde Material, also etwas für einen verregneten Abend (wann auch immer so etwas wieder vorkommen wird).

Dienstag, 26. Juli 2016

Wie man Kreativität ins Arbeitsleben (zurück)bringen kann

Irgendwo in den kommentierten Links habe ich schonmal etwas daüber geschrieben, dass in den meisten modernen Firmen Kreativität systematisch unterdrückt wird. In diesem Vortrag von Catherine Courage geht es darum wie man sie zurückbringen kann. Verkürzt gesagt: indem man sich daran erinnert, mit welchen Mitteln man als Kind kreativ sein konnte.