Montag, 21. August 2017
Team-Urlaub für einen Sprint
 |
| Bild: Pixabay / Walkerssk - Lizenz |
Diese Frage dürfte bei so gut wie jedem Scrum Team regelmässig auftreten, und das nicht nur im August sondern in allen üblichen Ferienzeiten, z.B. Ende Dezember. Jedesmal wenn sich ein Teil der Teammitglieder für einige Tage oder Wochen verabschiedet fehlen Erfahrungswerte, unerwartete Mehraufwände fallen schwerer ins Gewicht und Arbeitstechniken wie Pair Programming oder Code Reviews können ggf. gar nicht mehr angewandt werden, weil wie im gerade genannten Beispiel nur ein Entwickler übrig ist.
Ein Lösungsansatz den ich bei einem anderen Kunden gesehen habe war, dass ein Team sich entschieden hat geschlossen in den Urlaub zu gehen, und zwar für genau einen Sprint. Nach der Retrospektive des Sprints davor gingen alle in ihre Ferien. Nach der Rückkehr gab es ein kurzes Backlog Refinement um sicherzustellen, dass sich in der Zwischenzeit nichts Neues ergeben hatte, danach ging der normale Rhythmus mit einem Planning wieder los.
Der Vorteil dieses Vorgehens war, dass die oben genannten negativen Effekte auf diese Art vermieden werden konnten. Statt mehrere Sprints mit ausgedünnter Personaldecke zu haben war das Team mit Ausnahme dieser zwei Wochen durchgehend voll besetzt, der "Urlaubssprint" wurde in der Sprintplanung ignoriert und auch in der Berechnung der Velocity nicht berücksichtigt. Dass das Review ausfallen würde wurde den Stakeholdern rechtzeitig vorher mitgeteilt.
Was dieses Vorgehen in diesem Fall begünstigt hat war eine besondere Rahmenbedingung: das Team war Teil eines Tribes, so dass andere Teams einspringen konnten wenn Bugfixing- oder Support-Aufgaben zu erledigen waren. In Konstellationen in denen das nicht der Fall ist müsste man über Ausgleichsmaßnahmen nachdenken. Eine die ich an anderer Stelle miterlebt habe war z.B. die, dass ein Team-Mitglied sich bereiterklärt hat seinen Urlaub später zu nehmen. Während des Urlaubssprints arbeitete er aber in einem anderen Team mit, wodurch die Auswirkungen der Ferienzeit auch dort abgeschwächt wurden.
Donnerstag, 17. August 2017
Scaled Agile: Chapter (Querschnitts-Organisationen)
 |
| Bild: Flickr / iMorpheus - CC BY 2.0 |
Genau wie der Begriff des Tribes ist der des Chapters durch den Skalierungsansatz der Firma Spotify bekanntgeworden, wo diese beiden Konzepte auch in Verbindung miteinander stehen. Ein Tribe ist dort eine Gruppe von Teams die an einem gemeinsamen (Teil)Produkt arbeiten, weshalb sie durch gegenseitige technische und fachliche Abhängigkeiten verbunden sind. Um sich nicht gegenseitig zu behindern ist eine Koordination zwischen diesen Teams nötig. Da der klassische Lösungsweg (die Einsetzung eines koordinierenden Managers) zu Hierarchien und Flaschenhälsen führen würde, wurde ein anderer Ansatz entwickelt, die Chapter.
In einem Chapter sind aus allen beteiligten Teams die Verantwortlichen für jeweils ein Spezialgebiet zusammengefasst. Häufig sind das Frontend, Backend und QA, es sind aber auch andere Konstellationen möglich, z.B. UX oder SEO. Zusammen haben sie die Aufgabe an übergreifenden Architekturen und gemeinsamen Standards und Tools zu arbeiten. Im Grunde eine ausdifferenzierte Version eines Scrum of Scrums, gewissermassen mit jeweils einem davon für jedes Spezialgebiet. Über Frequenz und Intensität der gegenseitigen Abstimmung entscheidet jedes Chapter dabei selbst.
Was ein Chapter ausserdem noch von einem Scrum of Scrums unterscheidet ist die Rolle des "Chapter Lead". Sie wird von einem der beteiligten Entwickler in Teilzeit ausgeübt und übernimmt das was von den klassischen Management-Tätigkeiten übrigbleibt: Personalentwicklung/Coaching, Gehaltsverhandlungen, Koordination des Recruitings, etc. Explizit nicht zu ihren Aufgaben gehört dagegen das Entscheiden fachlicher und technischer Konflikte oder das Vorgeben von Architekturen und Standards.
Wenn andere Organisationen versuchen Spotify zu kopieren ist die Rolle des Chapter Lead eine häufige Bruchstelle an der Probleme auftreten. Oft wird sie mit Personen besetzt die vorher Manager, Teamleiter, Architekt oder Lead Developer waren und sich aus ihrer alten, weisungsbefugten Rolle nur schwer lösen können. In solchen Fällen kann die helfende oder hemmende Begleitung durch einen Scrum Master oder Agile Coach Sinn machen.
Montag, 14. August 2017
Organizations that are fit for the Future
Das Internet hält offensichtlich einen nie versiegenden Nachschub mitreißender Redner bereit. Die neueste Entdeckung ist Gary Hamel, der sich das Thema der zukunftsfähigen Organisationen zu eigen gemacht hat:Wie viele professionelle Konferenzredner ist er nicht nur rhetorisch brilliant sondern verfügt auch über das Wissen wie man gute, den Vortrag unterstützende und trotzdem nicht ablenkende Powerpoint-Präsentationen erstellt. Und sein ab Minute 07.40 vorgestelltes Beispiel von "Reverse Accountability" in einer indischen Firma ist wirklich inspirierend.
[Edit: das ursprüngliche Video wurde gelöscht, stattdessen ist jetzt ein inhaltlich ähnliches eingebunden]
Donnerstag, 10. August 2017
Why agile: Feature-Wettrennen
 |
| Bild: Pixabay / Macayran - Lizenz |
Die beiden Firmen die diese Vorgehensweise am weitesten perfektioniert haben dürften vermutlich Facebook und Google sein, die sich bereits mehrere solche Wettläufe geliefert haben. Facebook hat einen solchen im Jahr 2009 sowohl gegen Twitter als auch gegen StudiVZ gewonnen und führt im Augenblick einen gegen Snapchat. Google hat alle anderen Suchmaschinen (Altavista, Yahoo, Lycos, Ask, Bing, etc.) weit hinter sich gelassen und 2009 seinen Landkartendienst gegen Apple um die Wette entwickelt. Der aktuelle Wettstreit findet gegen ein Unternehmen namens Pinterest statt, das im Nischenmarkt der Bildersuche und -kuratierung ein Konkurrent ist. Beide Firmen arbeiten zeitgleich an Bilderkennung und Schnittstellen, wodurch z.B. Kuchenbilder sowohl mit ähnlichen Aufnahmen als auch mit Rezepten verknüpft werden können.
 |
| Pinterest vs. Google |
Auf lange Sicht bedenklich ist, dass die beiden Großunternehmen durch ihre Fähigkeit Feature-Wettrennen zu gewinnen praktisch jede neue Konkurrenz marginalisieren können. Selbst disruptive Technologien und Ideen bringen wenig wenn ein bereits etablierter Wettbewerber sie in kürzester Zeit kopieren und in sein Produkt einbauen kann. Auf der anderen Seite kann man gespannt sein ob der ständige Nachbau von Konkurrenzprodukten nicht irgendwann zu überladenen Funktionsumfängen und Codebases führen wird. Die wiederum wären für Agilität hinderlich.
Montag, 7. August 2017
Diversität
 |
| Bild: pxhere - CC0 1.0 |
Zunächst deshalb, weil diverse Teams in der Regel eine größere Vielfalt an möglichen Innovations- oder Lösungsoptionen erarbeiten können. Entgegen einer häufigen Annahme allerdings nicht weil Diversität das befördert sondern weil Gleichartigkeit das behindert. Je homogener eine Gruppe ist, desto einmütiger denkt sie und verhält sie sich. Dieses Phänomen, das so genannte Group Think, wird durch diverse Teams aufgebrochen.
Als Zweites kommt ein wirtschaftlicher Aspekt dazu. In Zeiten des Fachkräftemangels ist es nahezu fahrlässig wenn weite Teile der Bevölkerung einem Segment des Arbeitsmarktes nicht zur Verfügung stehen. Man muss dazu nicht nach Kalifornien blicken, es reicht ein Blick in eine Maschinenbau-, IT- oder Buchhaltungsabteilung eines beliebigen deutschen Unternehmens. Frauen und Gastarbeiter-Kinder sind hier sehr, sehr, selten. Angesichts zahlloser unbesetzter Stellen ist das ein Zustand den zu ändern sich lohnen würde.
Zuletzt kann Diversität zu einer besseren (weil ausgeglicheneren) Firmenkultur führen. Es ist ein tiefer Griff in die Klischee-Kiste, aber rein männliche Teams neigen häufig zu einer gewissen Ruppigkeit im Umgang, Teams aus älteren Mitarbeitern hinterfragen Routinen seltener und rein deutsche Teams sind tendenziell weniger sensibel gegenüber kulturellen und religiösen Befindlichkeiten ausländischer Mitarbeiter (und Kunden). In diversen Teams ist all das meistens besser.
Natürlich ist Diversität nicht die Wunderlösung für alles, die gibt es nicht. Gerade in agil arbeitenden Unternehmen, solchen also in denen Offenheit und Anpassungsfähigkeit eminent wichtig sind, ist sie ein wichtiger Baustein für Erfolg und Wettbewerbsfähigkeit. Dass man damit auch Kontroversen auslösen kann zeigt das oben genannte Beispiel Google [Edit: Siehe dazu auch diesen Beitrag in der Zeit, diesen aus der FAZ oder diesen aus der New York Times]. Allerdings ist davon auszugehen, dass sich auch hier mittels Inspect & Adapt eine Lösung finden lassen wird.
Samstag, 5. August 2017
lean-agility.de
 |
| Bild: Flickr / Chris Dlugoz - CC BY 2.0 |
Die bisherige Blogspot-URL besteht immer noch, leitet aber auf die neue Web-Adresse weiter. Es ist also nicht nötig gesetzte Links anzupassen, sie sollten weiterhin funktionieren.
Zusammen mit der URL wurde auch der Seitenname angepasst, er hat jetzt mehr Bezug zu den hier behandelten Themen. Auch das ist ja von Zeit zu Zeit kritisiert worden.
Soviel dazu, Maschinenraum Ende.
Donnerstag, 3. August 2017
Make Rules Explicit
Manchmal ergeben sich die spannendsten Diskussionen dort wo man sie am wenigsten erwarten würde. Im Rahmen eines Kanban-Workshop bei einem Kunden gab es den größten Gesprächsbedarf zu dem Grundsatz, dass alle Regeln unzweideutig formuliert werden müssen. Eigentlich eine Selbstverständlichkeit - bevor eine Organisation ihre Prozesse optimieren kann müssen alle ihre Mitglieder das selbe Verständnis haben wie diese Prozesse überhaupt aussehen, sonst versuchen verschiedene Personen "in verschiedene Richtungen zu optimieren", was selten gut geht.
In diesem Fall ergab sich allerdings an dieser Stelle starker Widerspruch. Es wäre Best Practice und seit je her üblich, dass Regeln "hinreichend unscharf"formuliert sein müssten. Nur dadurch könne man sicher sein, im Zweifel nicht unnötig in der eigenen Entscheidungsfreiheit eingeengt zu werden. In der Vergangenheit habe es zwar immer wieder Versuche gegeben die Regeln zu verschärfen, das sei aber immer wieder an der Realität gescheitert. Damit jetzt wieder anzufangen wäre unnötig und kontraproduktiv.
Ein Blick in die firmeninternen Regelwerke zeigte deutlich was mit "hinreichend unscharf" gemeint war. Immer wieder tauchten Einschränkungen oder Verallgemeinerungen auf, wie etwa "so weit wie möglich", "falls machbar", den üblichen Standards entsprechend", "erfahrungsbasiert" oder "je nach Erfordernis". Letztendlich hätte man sich die kompletten Dokumente sparen können, unterschwellig zog sich durch alle die Aussage "jeder macht was er will und keiner fragt genau nach".
Nach längerer Diskussion schälte sich langsam die wirkliche Begründung dieses Zustands heraus. Ohne diese Relativierungen und Verallgemeinerungen wären die Vorgaben einfach nicht erfüllbar gewesen. An einer Stelle liefen sie beispielsweise darauf hinaus, dass die Übergabe neu programmierter Features an die nächste Abteilung erst erfolgen durfte wenn die Auswirkungen ihrer Integration in das Altsystem klar waren. Das Problem - Integrationstests fanden erst noch später in der Prozesskette statt, die Auswirkungen konnte also noch niemand wissen.
Das unzweideutig machen der Regeln (das dann doch beschlossen wurde) führte in diesem Fall zu der für viele schockierenden Erkenntnis, dass ein Großteil der eigenen Prozesse aufgrund ihrer eigenen Widersprüchlichkeit gar nicht funktionieren konnte. Als logischer nächster Schritt wurde ein Großteil davon gestichen, das übrigens gegen den erbitterten Widerstand des eigenen Qualitätsmanagements. Wie sich herausstellte hatte das seine Aufgabe vor allem darin gesehen den Teams immer härtere Auflagen aufzudrücken ohne sich um deren Umsetzbarkeit zu kümmern.
Dieses wildgewordene Qualitätsmanagement einzufangen ist jetzt die nächste große Herausforderung in diesem Unternehmen. Und dass man sie angeht (und damit einiges verbessert) wäre bei den alten, "hinreichend unscharfen" Formulierungen vermutlich nicht passiert. Das unzweideutig machen der Regeln hat sich bereits ausgezahlt.
Montag, 31. Juli 2017
Kommentierte Links (XXVII)
 |
| Grafik: Pixabay / Geralt - Lizenz |
Paul Rosenzweig: Bad Code Is Already a Problem. Soon, Companies Will Be Liable.
Ein noch zu wenig bedachter Aspekt der aktuellen technischen Entwicklungen. Das "Internet der Dinge" und künstliche Intelligenz machen fehlerhafte Software zu einem immer größer werdenden Risiko, z.B. in selbstfahrenden Autos, automatisierten Kraftwerken oder Flugzeug-Leitsystemen. Paul Rosenzweig geht in diesem Artikel davon aus, dass es nur noch eine Frage der Zeit ist bis IT-Firmen gesetzlich verpflichtet werden ihre Anwendungen einfach und verständlich zu strukturieren, sie updatefähig zu halten, regelmässig zu testen, über Schnittstellen zugänglich zu machen und Fehlfunktionen unverzüglich zu beheben. Sollte das so kommen wäre es de facto ein juristischer Zwang agil zu arbeiten.
Melissa Perri: Product Manager vs. Product Owner
Eigentlich behandelt Melissa Perri in diesem Text zwei Themen. Zum einen das Scaled Agile Framework (SAFe) und seine Dysfunktionalität in Bezug auf kunden- und benutzerorientiertes Produktmanagement, zum anderen die grundsätzliche Differenzierung zwischen Product Manager und Product Owner. Zum ersten Thema muss man nicht viel sagen, ausser, dass sie Recht hat. Das zweite lautet in einem Satz zusammengefasst: Product Owner ist eine Rolle in Scrum, Product Manager ist ein Beruf den man behält, auch wenn die Methode sich ändert. Und: ein Product Manager kann auch andere Rollen ausfüllen, die nichts mit Scrum zu tun haben. Das ist ein wichtiger Punkt - viele POs sind "One Trick Ponies" und ohne das umgebende Framework relativ hilflos. Daran zu arbeiten sollte Teil der Personalentwicklung jedes agilen Unternehmens sein.
Stephen Frein: Donning the agile camouflage - 5 ways to tell if you're agile in name only
Ich habe es in mehr als einem Unternehmen selbst erleben dürfen - nicht überall wo Agil (bzw. Scrum) draufsteht ist auch Agil drin. Viel zu häufig handelt es sich doch nur um Cargo Cult. Damit Unternehmen selbst feststellen können ob sie in einer solchen Situation sind hat Stephen Frein fünf Anzeichen dafür gesammelt und aufgeschrieben:- Es gibt innerhalb der Entwicklungsteams Sub-Teams (z.B. Design, Entwicklung, Test) die sich in Form von Mini-Wasserfällen organisieren.
- Es gibt eine weit in die Zukunft reichende Detailplanung der Sprints, die wenig Raum für Anpassungen lässt.
- Am Ende der Sprints gibt es zwar einen Fertigstellungs-Fortschritt, der aber keine benutzbare Funktionalität erzeugt hat.
- User Stories sind zu groß für einen Sprint und werden entweder gar nicht oder nach Phasen (z.B. Design, Entwicklung, Test) geteilt.
- Retrospektiven sind formalisierte Zeremonien die ohne Überzeugung abgehalten werden und zu keinen Veränderungen führen.
Klaus Leopold: Zwischen den Zeilen – Swimlanes am Portfolioboard [Edit: Link ist mittlerweile tot]
Ein kurzer aber wichtiger Text. Wenn Unternehmen ihre Change-Vorhaben visualisieren (was Bestandteil jeder agilen Transition sein sollte), dann können diese nach verschiedenen Kriterien angeordnet sein: entsprechend den Abteilungs- oder Bereichsgrenzen, nach Wichtigkeit oder Dringlichkeit oder nach Impact auf die Positionierung am Markt. Während Variante 1 zu einer Abart von Conway's Law führen kann und Variante 2 schnell in abstrakte Diskussionen abgleitet führt Variante 3 den Focus zurück auf den Grund warum eigentlich etwas geändert werden soll. Nach meiner Erfahrung ist diese Variante leider auch die seltenste. Im Grunde nachvollziehbar, schließlich fordert sie den Beteiligten die größte Änderung im Denken ab.
Jeff Sutherland: How to Optimize Your Kanban
Als Beitrag zu einer Diskussion um optimale und dysfunktionale Kanban-Systeme gibt Jeff Sutherland einige Ideen zum Besten. Wie man es vom Begründer von Scrum erwarten kann bestehen die aus der Einführung von Scrum-Elementen. Letztendlich geht das in die selbe Richtung wie die Bemühungen von David Anderson seinen Essential Kanban Condensed Guide zu etablieren. Es scheint einen Bedarf dafür zu geben Kanban zu formalisieren.
