Dienstag, 28. Februar 2017

Kommentierte Links (XXII)

FS
  • Thorbjørn Sigberg: Agile doesn’t scale

    Ironie der Geschichte. Eigentlich als Kritik und Beschimpfung gedacht beschreibt der Satz "Agile Methoden skalieren nicht" ziemlich genau eines ihrer Erfolgsgeheimnisse. Probleme werden hier eben nicht gelöst indem man immer weitere Ressourcen daraufkippt (dazu ein aktuelles Beispiel) sondern indem man fokussiert arbeitet, große Aufgaben in kleine herunterbricht und früh Prototypen und MVPs ausliefert. Ich würde Sigbergs Text noch ergänzen um einen weiteren Erfahrungswert: Wenn Du im kleinen Maßstab nicht lieferfähig bist, dann bist Du es im großen erst recht nicht.

  • Chris Edwards: How to Fail Your TDD Rollout and Piss Everyone Off. A Train Wreck Story

  • Diese Geschichte passt nicht nur zu TDD sondern auch zu jeder anderen agilen (oder nichtagilen) Methodeneinführung. Wenn den Leuten der Sinn der Einführung nicht klar wird werden sie alles was ihnen komisch vorkommt (und das ist sehr viel) in Frage stellen und nur zögerlich umsetzen, vielleicht auch gar nicht. Wenn das dann dazu führt, dass die neuen Ideen mit Druck oder Zwang eingeführt werden entsteht Widerstand und alles reibt sich in einem fruchtlosen Kleinkrieg auf. Aus meiner Erfahrung: erstaunlich viele Scrum Master und Coaches tun sich mit der Beantwortung dieser Sinnfragen schwer. Eine Geschichte für sich.

  • Katrina Clokie: Test Manager vs. Test Coach

    Meine Zeit als agiler Testmanager ist mittlerweile ein paar Jahre her, aber das hier kann ich unterschreiben und es entspricht dem was ich versucht habe umzusetzen. Vermutlich wäre es seinerzeit besser gewesen meine Rolle in Test Coach umzubenennen, ich bin permanent mit der Erwartungshaltung aus der umgebenden Organisation kollidiert, dass ich mich doch wie ein klassischer Testmanager benehmen sollte. Andererseits habe ich vor gar nicht zu langer Zeit mit einem "QA Coach" zusammenarbeiten müssen der in seinem Selbstverständnis alles zusammenfasste was im klassischen Testmanagement dysfunktional ist. Letztendlich ist das Verständnis wichtiger als die Bezeichnung.

  • Mark Poppenborg: Wie lautet die Spielanleitung Deines Unternehmens?

    Das hier geht mehr in Richtung Change Management, greift aber ein Grundproblem hinter den letzten beiden verlinkten Beiträgen auf: viele Menschen verhalten sich einfach nicht so wie es eigentlich sinnvoll wäre sondern sind bockig und scheinbar irrational. Was zu oft vergessen wird - dieses Verhalten hat Gründe, die sich oft in der Unternehmenskultur, bzw. in der "Spielanleitung" des Unternehmens wiederfinden. Die dann umzugestalten ist die Herausforderung, z.B. mit Culture Codes.

  • Jurgen Appelo: Stop Your “Agile” Transformation! Right. Now.

    Etwas populistisch aber im Kern richtig. Wer eine agile Transformation nach dem Copy & Paste-Muster durchführen will, der wird mit großer Wahrscheinlichkeit einen Fehlschlag hinlegen. Mein Reden. Was Appelo macht ist darüber hinaus didaktisch interessant: er bettet seine Erklärungen in popkulturelle Kontexte ein die man als 35 - 45 Jahre alter Mensch aus seiner Jugend kennt. Ein geschickter Schachzug - das ist in etwa die Altersgruppe derjenigen die heute die agilen Transformationen verantworten.

Donnerstag, 23. Februar 2017

Kanban-Boards (box hide answer)

FS
Bild: Flickr/Joakim Olander - CC BY-SA 2.0
Manchmal kommen die kleinen Highlights ja unvermutet. Vor wenigen Tagen erreichte mich die Mail eines alten Studienfreundes, in der er sich unter anderem über ein Ärgernis aus seiner Arbeit aufregte. Zur Zeit ist eine Unternehmensberatung bei ihm in der Firma, die dort geradezu Ungeheuerliches macht:
Ich werde am 23.02. von einigen Consultants durchoptimiert. Die haben eine "tolle neue" Erfindung. Projektplanung und -übersicht mit Hilfe einer Tafel und Klebestickern, statt Excel-Tabellen oder MS Project. Man fasst es nicht, wofür wir Geld ausgeben...
Ich habe ihm mitgeteilt, dass diese "tollen neuen Methoden" auch zu meinem Berufsalltag gehören - bei unserer nächsten Begegnung sehe ich schon ein längeres Gespräch auf mich zukommen. In gewisser Weise in Vorbereitung darauf: warum machen wir das eigentlich, warum benutzen wir nach Möglichkeit Kanban-Boards statt Computerprogrammen?

Die Antwort darauf ist im Grunde nichts anderes als das "big Picture". Die Darstellung großer Wertströme durch verschiedene Phasen könnte man zwar auch digital umsetzen, es wäre dann aber kein Bildschirm groß genug um das alles so wiederzugeben, dass es auf einen Blick sichtbar ist. Jeder der schon einmal Excel, Jira, Redmine, Trello oder ein ähnliches Tool auf seinem Rechner gesehen hat kennt das Phänomen: immer ist irgendetwas ausserhalb des sichtbaren Bereichs. Erst durch ständiges Scrollen wird es sichtbar, wodurch sich aber andere Elemente aus dem Schirm herausbewegen. Es gibt sogar Abschnitte an denen man nur selten bis gar nicht vorbeikommt, und was dort hängt wirde gerne vergessen. Was noch dazu kommt: wenn der Rechner aus ist oder ein anderes Fenster geöffnet ist sieht man gar nichts mehr. Aus den Augen, aus dem Sinn, oder mit den Worten eines Toyota-Managers: "When you put problem in computer, box hide answer. Problem must be visible!"

Beispiele für große Boards habe ich auf meinen Projekten schon einige gehabt, und sie sind bis zu sechs Meter breit und bis zu zwei Meter hoch gewesen. Wie hätte man darauf navigieren wollen, wenn sich das irgendwo in digitaler Form befunden hätte? Wie oft hätten Aufgaben oder Probleme (zeitweise) in Vergessenheit geraten können wenn wir sie nicht permanent vor Augen gehabt hätten? Und wie wäre es uns gelungen Managern und Stakeholdern eine "schnelle Übersicht" zu geben, wenn wir dafür ewig hätten hin- und herscrollen müssen? Boards und Post Its sind zwar weder neu noch innovativ, für den Blick auf das Große Ganze aber unverzichtbar.

Montag, 20. Februar 2017

It's the business, Scrum Master

FS
Bild: Unsplash/Olu Eletu - CC0 1.0
Beim Bonner Scrumtisch letzte Woche war meine Session diejenige mit dem wenigsten Zuspruch. Vielleicht waren die anderen interessanter, vielleicht bin ich unbeliebt, vielleicht lag es aber auch am Thema: es war "Business Value". Bei derartigen Meetups machen Scrum Master und Agile Coaches den Großteil der Teilnehmer aus, und mein Erfahrungswert ist der, dass die meisten sich bei diesem Thema nicht zuständig fühlen. Für den Business Value wird im besten Fall auf den Product Owner verwiesen (der dann oft auch untätig ist), im schlechtesten Fall heisst es "der kann für unsere Anwendung nicht berechnet werden".

Die Folgen dieser Haltung sind offensichtlich: ich habe in den letzten Jahren eine mittlere zweistellige Zahl an Scrum Teams begleiten dürfen, mir fallen aber keine fünf ein in denen Anforderungen anhand ihres Geschäftswertes priorisiert wurden1. Genau das was mit Scrum erreicht werden sollte trat dann oft nicht ein: die frühe Lieferung benutzbarer und Mehrwert schaffender Software. In den betroffenen Unternehmen wurde der Ruf der Methode dadurch beschädigt - man hatte zwar "shippable Code", der tatsächliche Mehrwert entstand aber so spät, dass behauptet werden konnte, dieser Zeitpunkt wäre mit einem Wasserfall-Vorgehen genauso schnell erreicht worden.

Ja aber, haben mir Scrum Master an dieser Stelle regelmäßig entgegnet, der Business Value liegt nun mal im Aufgabenbereich des Product Owners. Ich kann dem ja schlecht sagen wie er sein Backlog priorisieren soll, und wenn ich es doch tun würde, dann würde ich gegen die Aufgabenverteilung in Scrum verstossen. Allerdings lagen sie an dieser Stelle so falsch wie es falscher kaum sein könnte. Der Scrum Guide ist mehr als eindeutig: The Scrum Master serves the Product Owner in several ways, including [...] Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.

Machen wir uns nichts vor, diese Aufgabe ist nicht einfach. Die meisten Scrum Master die ich kenne waren ursprünglich Software-Entwickler, Teamleiter oder Projektmanager, die wenigsten haben einen betriebs- oder sonstwie -wirtschaftlichen Hintergrund. Und oft genug kommt man an eine Stelle an der man nicht weiter weiss: wie ist z.B. der Wert einer User Story mit der eine Seite von adaptive auf responsive Design umgestellt wird? Aber [Populismus on] wenn es einfach wäre könnte es jeder [/Populismus off]. Wie das im Detail aussieht ist dann nochmal ein eigenes Thema.

Wichtig ist die Erkenntnis, dass man als Scrum Master für den Business Value zuständig ist und sich daher intensiv damit beschäftigen sollte.


1Weitere haben sich von mir überreden lassen es zu versuchen, haben aber nach kurzer Zeit aufgegeben

Donnerstag, 16. Februar 2017

Ein Bild sagt mehr als 1000 Worte (XVI)

FS
Heute wieder aus der Unterkategorie "Ein Bewegtbild sagt mehr als 1000 Worte".


Montag, 13. Februar 2017

The Soft Power of Scrum

FS

Vor langer Zeit habe ich in meinem geisteswissenschaftlichen Studium etwas über die verschiedenen Dimensionen der Machtausübung gelernt. Vereinfacht gesagt gibt es in sozialen Systemen zwei wesentliche Möglichkeiten auf das Verhalten von Personen und Gruppen einzuwirken: man kann sie zwingen, der Begriff dafür ist Hard Power. Wesentlich effektiver ist es aber wenn die eigenen Ziele, Lösungswege und Verhaltensmuster für die Betroffenen so attraktiv sind, dass sie von sich aus gewollt werden. Diese Attraktivität wird als Soft Power bezeichnet. Das klassische Beispiel für diese beiden Dimensionen war der kalte Krieg: während die kommunistischen Staaten ihre Bevölkerung mit Polizei- und Militärgewalt in Kommunismus und Planwirtschaft zwingen mussten (Hard Power) beteiligte sich die Bevölkerung der westlichen Staaten freiwillig an Demokratie, Marktwirtschaft und Konsumkultur (Soft Power). Tatsächlich waren diese Dinge sogar so verlockend, dass auch die Menschen im Osten Wahlen, Popmusik, Hollywood-Filme und Fast Food haben wollten und sich dafür gegen die Unterdrückung auflehnten.

In Unternehmen sind die beiden Arten der Machtausübung ebenfalls anzutreffen. Hard Power entspricht hier den Wasserfall-, Top-Down- oder Command & Control-Ansätzen. Oben wird entschieden, unten wird nur ausgeführt - und wer sich dagegen auflehnt wird sanktioniert, vom Gespräch mit dem Vorgesetzten über die Abmahnung bis zur Entlassung. Die agilen Ansätze gehen dagegen von flachen Hierarchien und vom Führungsstil der Servant Leadership aus, in deren idealer Ausprägung es keine Befehlsgewalt mehr gibt. Infolgedessen ist Soft Power nötig, ohne die würden die Prozesse nicht mehr befolgt werden. Mit anderen Worten: obwohl Agilität wirtschaftliche Ziele hat (u.a. kurze Time to Market, geringe Cost of Delay) stehen in der Vermittlung häufig Mitarbeiterzufriedenheit und Mitarbeiterbindung im Vordergrund. Wenn die dazu führen, dass die agilen Vorgehensweisen befolgt werden, folgen die wirtschaftlichen Effekte von alleine.

In der Praxis sieht das so aus, dass Scrum & Co in einer Weise umgesetzt werden, die den Mitarbeitern Mitbestimmung, humane Arbeitsbelastungen und einen gewissen Coolness-Faktor bietet1. Die Teams dürfen selbst entscheiden wie viel Arbeit sie realistisch leisten können, unklare Anforderungen dürfen abgelehnt werden, Kunden und Stakeholder sind direkt erreichbar und werden nicht durch eine Management-Schicht ferngehalten. Zusätzlich dazu gibt es eine kreativitätsfördernde, Startup-ähnliche Atmosphäre mit Standup-Meetings, bunten Post Its an großen Boards und vielen spielerischen Elementen (bestes Beispiel ist das Estimation Poker). Das fördert nicht nur das Engagement und Commitment in den Teams sondern strahlt auch nach aussen ab. Genau wie die Menschen im Kommunismus sich nach dem westlichen Way of Life sehnten würden viele der "klassisch" arbeitenden Kollegen am liebsten ebenfall sofort "agil werden" wenn sie die damit verbundenen Arbeitsbedingungen sehen.

Die Herausforderung dieser Situation besteht darin, auch das Management mitzunehmen. Ohne Befehlsgewalt und Kontrollmacht haben viele Manager das Gefühl, dass die Situation unkontrollierbar und stressig wird - die Soft Power wirkt hier nicht mehr so wie auf den unteren Ebenen. An dieser Stelle muss die Vermittlung rationaler und zahlengetriebener werden und die wirtschaftlichen Effekte müssen in den Vordergrund treten. Zum Glück liefern aber auch die ausreichend gute Argumente für mehr Agilität.


1Wobei die beiden ersten ausserdem noch zu Effizienz und Produktivität beitragen

Donnerstag, 9. Februar 2017

Off Topic: die Tools hinter dieser Website

FS
Bild: Wikimedia Commons/Donald Lachland - CC BY 2.0
Seit erstaunlichen zwei Jahren schreibe ich mittlerweile in dieses Internet, jede Woche etwas Neues über Agile, Scrum, Kanban, Change Management und den ganzen Rest. Eine Frage die mir seitdem immer wieder gestellt wird ist die nach der dahinterstehenden Technik. Pünktlich zum zweijährigen Jubiläum gibt es die Antworten darauf, nächste Woche geht es dann mit den gewohnten Themen weiter. Die von mir genutzten Tools sind:
  1. Blogger/Blogspot

    Die Blogging-Plattform von Google. Bietet nicht nur das CMS sondern auch das Hosting auf blogspot.com. Zur Auswahl standen auch andere Dienste wie Wordpress oder Medium, da ich aber bereits vorher verschiedene Dienste von Google benutzt habe bin ich dabei geblieben.
  2. Templateism

    Blogger hat zwar seine Vorzüge, ansprechendes Design gehört aber nur eingeschränkt dazu. Das lässt sich allerdings ausgleichen: auf Seiten wie Templateism kann man bessere Layouts herunterladen und in seine Seite integrieren. In meinem Fall ist es das Publisher Template.
  3. Feedly

    Einen Teil meiner Themen und Inspirationen beziehe ich aus meiner täglichen Arbeit, einen anderen aus den Texten anderer Leute (entspricht etwa dieser Liste). Feedly sammelt sie über RSS ein, filtert unnötige Formatierungen heraus und liefert sie synchronisiert auf das Handy oder in die Browser-App.
  4. Twitter

    Nutze ich ähnlich wie Feedly, wenn auch deutlich seltener. Auch hier folge ich verschiedenen Accounts, bzw. den Menschen dahinter.
  5. Evernote

    Ersetzt bei mir das Notizbuch. Egal ob Zeitungs- oder Blogartikel, Notizen, Bilder oder was sonst noch anliegt - alles wird abgespeichert und steht dann in der Handy-App, im Browser oder auf dem Computer zur Verfügung.
  6. Excel/Powerpoint

    Ein einfacher Weg Grafiken zu erstellen sind die Microsoft Office-Programme. Alles was dort zusammengebaut wurde kann als Grafik gespeichert werden und sieht dann z.B. so aus, oder so.
  7. Wikimedia Commons, Flickr, Pixabay, uvm.

    Irgendwann habe ich angefangen, Schmuck- oder Symbolbilder in meine Texte einzubauen. Die sind machmal von mir selbst, meistens aber von Bilderdatenbanken im Internet, vor allem von diesen dreien.
  8. Creative Commons

    Gehört zum letzten Punkt dazu. Einfach irgendwelche Bilder zu übernehmen kann in teuren Abmahnungen enden, es sollten solche sein die zur allgemeinen Nutzung freigegeben sind. Die Creative Commons legen die Nutzungsart fest und werden von mir immer angegeben (die kryptischen Abkürzungen unter den Bildern).
Das alles ist natürlich nur der Ist-Stand, bei Bedarf werde ich mit neuen Diensten experimentieren (z.B. Google Docs) oder bestehende weglassen. Mal sehen.

Montag, 6. Februar 2017

Neusprech

FS
Bild: Flickr/Gage Skimore - CC BY-SA 2.0
Zu den vielen verstörenden Aspekten der neuen amerikanischen Regierung gehört deren Umgang mit der Wahrheit. Bereits während der ersten Tage im Amt haben Präsident Trump und seine Leute nicht nur offen die Unwahrheit gesagt, es gab auch den Versuch das ganze Konzept von Wahrheit und Unwahrheit so umzudeuten, dass es nicht mehr brauchbar ist. Konkret handelt es sich um die Umbenennung von erkennbaren Falschaussagen in "alternative Fakten" durch Trumps Beraterin Kellyanne Conway. Ein derartiger Missbrauch der Sprache macht eine ernsthafte Beschäftigung mit diesem Thema unmöglich. Die irgendwann auf Trump folgende nächste Regierung muss nicht nur Vertrauen und Glaubwürdigkeit wiederherstellen, sie wird auch bestimmte Begriffe (z.B. das Wort "Fakten") zu ihrer ursprünglichen Bedeutung zurückführen müssen, damit das überhaupt möglich ist.

Genug von der Politik. Was mich an der Thematik des Umdeutens eigentlich klarer Begriffe sofort gefesselt hat war, dass sie auch in meinem beruflichen Umfeld regelmässig auftritt. Auch hier sind zentrale Aspekte mitunter nicht mehr diskutierbar, solange man nicht aufhört die sie beschreibenden Worte falsch zu verwenden. Ein Beispiel das mir in mehreren Unternehmen begegnet ist war die "Transparenz". Eigentlich verbirgt sich dahinter die freie Zugänglichkeit von Informationen über den aktuellen Sachstand (sei es der Stand der Umsetzungen oder der Stand der Planungen). Dort wurde jedoch etwas anderes darunter verstanden: Transparenz bedeutete, dass man im Detail sagen konnte in welchem Zustand sich ein Projekt zu einem bestimmten Zeitpunkt in der Zukunft befinden würde (z.B. in einem Jahr).

Auch andere Umdeutungen durfte ich erleben: ein Klassiker sind die mitunter recht wilden Beschreibungen von Agilität: Agilität bedeutet, dass nicht geplant wird, Agilität bedeutet, dass nicht dokumentiert wird, Agilität bedeutet, dass nicht getestet wird, Agilität bedeutet, dass Change Requests kein Geld mehr kosten. Weitere Klassiker wären Qualität (umgedeutet zu Dokumentation), Planung (umgedeutet zum Zukunft vorhersagen) oder Produktivität (umgedeutet zum Produzieren möglichst vieler Lines of Code). Natürlich ist das alles Unsinn, aber gefährlicher Unsinn. Wenn das Management (oder auch nur Teile davon) ihn glauben sind Verbesserungsmassnahmen kaum noch möglich, denn Unterhaltungen laufen dann so: "Transparenz? Funktioniert mit Agil nicht.", "Agilität? Ist Mist, aufs Testen verzichten wir nicht.", "Qualität? Mehr als jetzt geht nicht, wir dokumentieren schon alles."

Wenn solche Unternehmen wirklich besser werden wollen führt kein Weg daran vorbei, in einem der ersten Schritte die Sprache zu bereinigen. Egal wie viel Tradition bestimmte Begriffsverwendungen haben - wenn man sie nicht loswird werden sie hartnäckige Hindernisse für jeden Fortschritt sein.

Freitag, 3. Februar 2017

"Was war gut" als Thema für Retrospektiven

FS
Bild: Flickr/Aldo Rodrigo Sanchez Gonzalez - CC BY-SA 2.0
Das vermutlich häufigste Format für Sprint-Retrospektiven ist die Diskussion der beiden Fragen "Was war gut?" und "Was können wir besser machen?"1 Auch ich habe dieses Format diese Woche benutzt, woraus sich eine weitergehende Diskussion mit dem Team entwickelt hat. Nachdem wir zu beiden Fragen Themen gesammelt hatten wollten wir sie für die Diskussion priorisieren, woraufhin zwei Entwickler meinten, dass nur die aus dem Bereich "Was können wir besser machen?"diskutiert werden sollten. Nur hier könnte man schließlich besser werden, im anderen Bereich wäre ja offensichtlich alles in bester Ordnung.

Dieses Argument habe ich bereits bei mehreren Teams hören dürfen, ich versuche aber jedesmal zu vermitteln, dass ich es nicht für valide halte. Selbst da wo alles gut gelaufen ist gibt es einiges zu besprechen. Das kann zum Beispiel dort der Fall sein wo man ein Ziel nur mit Glück erreicht hat. Von dem abhängig zu sein ist nie gut, und von ihm unabhängig zu werden ein Ziel auf das man hinarbeiten kann. Ein anderer Fall liegt vor wenn ein Erfolg auf Überstunden, Wochenendarbeit oder Ähnlichem beruht, auch das ist keine nachhaltige Lösung. Und um einen positiveren Aspekt in den Mittelpunkt zu stellen: wenn ein Erfolg auf guter Arbeit, großer Sorgfalt oder kreativen Ideen beruht kann die Retrospektive genutzt werden um sich bei den Beteiligten zu bedanken.

Den größten Nutzen sehe ich aber darin, dass man darauf hinarbeiten kann Erfolge wiederholbar zu machen. Sei es dadurch, dass man sie zur Messlatte erhebt die man auch in Zukunft erreichen will (mit anderen Worten: man betreibt Benchmarking) oder ganz einfach dadurch, dass man sich noch einmal vor Augen ruft aufgrund welcher Maßnahmen man überhaupt erfolgreich gewesen ist. Nur wenn man das benennen kann ist es nämlich möglich bewusst auf eine Wiederholung hinzuarbeiten. Ohne das ist man darauf angewiesen intuitiv die richtigen Dinge zu wiederholen, was letztendlich auch wieder nichts anderes ist als Glück zu haben.

Mein Team hat sich dann doch entschieden die Themen aus dem Bereich "Was war gut?" zu diskutieren. Das Ergebnis war, dass die in letzter Zeit besonders enge Zusammenarbeit mit Endanwendern und Stakeholdern ein großer Erfolgsfaktor gewesen ist. Um das beizubehalten und auszubauen konnten wir gleich mehrere Maßnahmen ableiten und in den nächsten Sprint einplanen. Ich bin zuversichtlich, dass wir an seinem Ende wieder einige Erfolge in der Retrospektive diskutieren können.

1Ich habe ja eine Theorie warum das so ist
Powered by Blogger.