Montag, 11. Dezember 2017

Kick the ball out of the tent

FS
Ein Parforce-Ritt durch eine ganze Reihe von Aspekten: Wasserfall, Komplexität, Lean, Agile, Flow, Prinzipien, Prognosen und vieles mehr. Erkennbar für ein Publikum ohne vertiefte Vorkenntnisse gedacht und gerade deshalb geeinet für jeden der Inspirationen für seine eigenen Einführungsworkshops braucht.



Ähnlich wie ich experimentiert Kniberg anscheinend mit seinen Vorträgen und verändert sie immer wieder, im wesentlichen sind die Folien aber mit diesen hier identisch.

Donnerstag, 7. Dezember 2017

User Stories

FS
Bild: Pxhere - CC0 1.0
Wenn immer es möglich ist sollten Scrum Teams versuchen ihre Anforderungen in Form von User Stories zu verfassen. Das ist zwar nicht im Scrum Guide vorgeschrieben und es muss auch nicht immer in der klassischen Form Als [Benutzer mit Rolle ...] möchte ich [Aktion ... durchführen können] um [Mehrwert ... zu haben] sein (es gibt auch andere), es empfiehlt sich aber trotzdem so vorzugehen. Die Vorteile sind unverkennbar.

Um im Sinn des agilen Prinzips Maximizing the amount of work not done vozugehen lohnt es sich darüber nachzudenken wie man die Menge neu implementierten Codes so gering wie möglich halten kann. Ein weithin beliebter Ansatz ist dabei die Fokussierung auf den (End)Anwender. Nur was der tatsächlich benutzen kann ist von Wert, alles andere kann im Zweifel weggelassen werden. Folgerichtig sollten Anforderungen idealerweise auf Use Cases (Anwendungsfällen) beruhen.

User Stories greifen diese Idee auf und reichern sie um weitere Elemente an: in verständlicher Sprache erklären sie wer der Anwender ist, welche neue Funktion er braucht/bekommt und welcher Mehrwert damit verbunden ist. Neben dem oben genannten häufigsten Muster gibt es auch andere Variationen, etwa Um [Ziel ... zu erreichen] ermöglichen wir [Benutzer mit Rolle ...] die Aktion [...] durchzuführen oder ganz schlicht Nutzer: [...], Aktion: [...], Mehrwert: [...].

Natürlich werden trotzdem immer wieder Anforderungen auftauchen die nicht in dieses Muster passen: Arbeit an technischen Komponenten, Anpassungen an Architekturvorgaben, Bugfixes, Absicherung durch Tests, Code Cleaning, Abbau technischer Schulden, etc. Da viele von ihnen ein Zeichen von fehlender Anwender-Zentrierung oder (Spät)Folgen nachlässiger Arbeit sind kann es hilfreich sein das Verhältnis zu tracken: wieviel Prozent der umgesetzten Anforderungen sind User Stories und wie viele nicht? Bei einem zu niedrigem User Story-Anteil kann sich ggf. eine Retrospektive lohnen.


PS: es gibt leider auch Teams in denen der Begriff User Story ein generisches Synonym für Anforderungen aller Art ist. Mitglieder dieser Teams mögen sich bitte zur Behandlung in der nächsten Coach-Klinik melden.

Montag, 4. Dezember 2017

Scaled Agile: Chief Product Owner

FS
Bild: Flickr / Rod Waddington - CC BY-SA
Wenn Teams nach Scrum arbeiten gilt in Bezug auf die Rolle des Product Owners das Highlander-Prinzip: Es kann nur einen geben. Der Scrum Guide formuliert das an gleich zwei Stellen sehr eindeutig: "The Product Owner is the sole person responsible for managing the Product Backlog." und "The Product Owner is one person, not a committee." Für ein einzelnes Team ist das auch nachvollziehbar, aber was passiert wenn mehrere Teams an einem gemeinsamen Produkt arbeiten?

Passend zum teamübergreifenden Konstrukt des Tribes findet man in vielen Organisationen die Rolle des Chief Product Owners oder CPO (auch Head PO, Lead PO, o.ä.) der die übergreifende Produktvision verantworten soll. Er gibt damit das Fernziel vor, das erreicht werden soll und aus der die Product Owner nach dem Pull-Prinzip die Arbeit der Teams ableiten können. Diese Konstellation ist im Rahmen des Frameworks zulässig, da die Vision zwar erwähnt wird, aber nicht festgelegt ist, wer ihr Owner ist. Es kann also auch jemand anderes als der PO sein. Wie aus ihr allerdings konkrete Arbeit (an einem Increment) abgeleitet wird liegt sehr wohl bei ihm.

Was explizit nicht zum Aufgabenbereich des CPO gehören kann ist die Arbeit an den Backlogs, er soll also weder Arbeitsaufträge an die Teams vergeben noch deren Reihenfolge oder Priorität festlegen. Das bleibt dem PO vorbehalten, der dafür auch Teil mehrerer Scrumteams sein kann. Dass lässt sich indirekt aus dem Scrum Guide ableiten, der zum einen festlegt, dass nur der PO das Backlog verantwortet, zum anderen aber auch, dass mehrere Teams aus einem Backlog arbeiten können.

Diese Aufteilung in CPO (Produktvision) und PO (Product Backlog) kann in der Anwendung schnell künstlich wirken und im schlimmsten Fall zu Konflikten führen, durch die Ressourcen gebunden und die Organisation gelähmt werden. Im Rahmen des Scrum-Frameworks ist es aber die einzige mögliche Aufteilung. Das heisst zwar nicht, dass man nicht alles anders organisieren könnte - aber dann ist es kein Scrum mehr.

Donnerstag, 30. November 2017

Kommentierte Links (XXXI)

FS
  • Mary Poppendiek: The cost center trap

    Ich sage ja: ein Scrum Master sollte über den Tellerrand blicken und wirtschaftliche Zusammenhänge kennen. Mary Poppendiek beschreibt einen weiteren guten Grund dafür - das Center-Konzept, das in vielen Unternehmen verbreitet ist. Wenn die Softwareentwicklung eines Unternehmens als Cost Center (oder Service Center) gilt und nicht als Profit Center, dann besteht das dauerhafte Risiko im wahrsten Sinn des Wortes kaputtgespart zu werden. In einer solchen Situation kann man mit agilen Ansätzen bestenfalls Symptome abschwächen. Bevor es zu strukturellen Verbesserungen kommt muss das zentrale Impediment beseitigt werden: die Center-Zuordnung in ihrer bisherigen Form.

  • Jason Little: We don't need agile leadership

  • Hinter diesem Artikel stehen zwei Aussagen. Zum einen die, dass es sich bei den meisten Begriffen die "agile" als Präfix haben um Unsinn handelt. Speziell das aktuell gehypte agile Leadership hat erkennbar den primären Zweck Lehrgänge und Zertifikate zu verkaufen. Wirklich Bemerkenswertes findet man hier selten. Interessanter finde ich die zweite: Jason Little geht davon aus, dass der typische agile Coach ständig auf der Suche nach Neuem ist (oder wie er es sagt - schnell gelangweilt). Bedingt dadurch werden auch die obskursten Ideen durchdiskutiert und ausprobiert. Da ist leider etwas dran. Andererseits - wie sonst soll man diese Ansätze bewerten können?

  • John Cutler: The trouble with Scrum

    Ein Thema das immer wieder aufkommt. Man kann sich komplett an alle Scrum-Regeln halten und trotzdem kann das Ergebnis unbrauchbar sein. Zweifellos richtig. Was John Cutler als "mechanistisches Scrum" bezeichnet kann auf derartige Effekte herauslaufen. Viele agile Practicioner (darunter auch ich) würden das allerdings nicht als echte Umsetzung betrachten sondern als Cargo Cult. Das zu erklären und zu begründen ist mittlerweile eine der Hauptaufgaben von agile Coaches und Scrum Mastern geworden, und dazu eine die dauerhafte Beschäftigung verspricht. Denn dass die mechanistischen Lösungen eine magische Anziehungskraft auf klassische Manager ausüben kann man in fast jeder größeren Firma erleben.

  • FAZ: So einfach geht Elektroauto

    Was Anna Steiner hier zur Firma Streetscooter zusammengetragen hat klingt sehr nach agiler Produktentwicklung. Die hier hergestellten Elektroautos sind MVPs (sie sind in der ersten Generation nur auf kurzen Strecken und in gemäßigten Klimazonen nutzbar), sie werden modular und iterativ weiterentwickelt (mit neuen Funktionalitäten in jedem Produktzyklus) und nach jeder dieser Iterationen können die Nutzer Feedback und Weiterentwicklungswünsche abgeben, die zügig in die Planung aufgenommen und umgesetzt werden. Verabschiedet hat man sich dafür von dem an Overengeneering grenzenden Perfektionismus, der im deutschen Ingenieurwesen noch immer vorherrscht. Man kann gespannt sein wie dieser Geist nach der Übernahme durch den Großkonzern Deutsche Post weitergetragen wird.

  • Techcrunch: How bad decision making could undermine good innovation

    Wie man auf englisch sagt - der Niedergang von Kodak ist eine Geschichte "that keeps on giving". Nachdem ich schon vor drei Monaten eine Analyse des damaligen Management-Verhaltens verlinkt hatte führt Ron Miller in weitere Aspekte ein: die Firma Kodak hat nicht nur die Technologie von der sie vom Markt gefegt werden sollte (Digitalfotografie) selbst entwickelt, sie hat sie sogar selbst an den Markt gebracht. Das allerdings so sehr im Rahmen der bisherigen Produktstrategie, dass für die Nutzer kaum relevanter Mehrwert entstand. Erst als andere Firmen die neue Technologie auch in neuen Kontexten einsetzten wurden sie zu einer Disruption. Man kann erahnen welcher gewaltige Mindset-Change hier für agiles Reagieren notwendig gewesen wäre.

Montag, 27. November 2017

Ein Kanban-Flickenteppich

FS
Agile und Lean im Konzern - geht das überhaupt? Und wenn ja wie? Diese Fragen stellen sich immer wieder. Dieses Video zeigt, dass es grundsätzlich geht und führt Möglichkeiten und Potentiale vor, aber auch Begrenzungen und Kompromisse. Denn selbst wenn das Gesamtbild beeindruckend ist - ab Minute 29 erkennt man noch das klassische Gantt-Chart- und Langfristplanungs-Projektmanagement.



Offenlegung: Daniel und ich kennen und schätzen uns.

Donnerstag, 23. November 2017

Rollen und Tätigkeiten

FS
Bild: Wikimedia Commons / Andriy Makukha - CC BY-SA 3.0
Zu den Gründen aus denen viele Unternehmen Verschlimmbesserungen an Scrum vornehmen (was häufig zum Harikiri führt) gehört die Sorge, dass komplexe Vorhaben ohne leitende und koordinierende Rollen nicht funktionieren. Die Argumentationen sind immer wieder die gleichen: Es gibt viele übergreifende Tests? Dann braucht man einen Testkoordinator. Es gibt eine komplexe Architektur? Dann braucht man einen Architekten. Es müssen verschiedene Features gleichzeitig Live gehen? Dann braucht man einen Releasemanager. Und so weiter. Die Folge: Mit den Rollen kommen Arbeitsteilung und Bürokratie zurück, alles wird langsamer, die Agilität verschwindet.

Dass diese Entwicklung immer wieder auftritt lässt sich auf einen zentralen Denkfehler zurückführen: Es wird davon ausgegangen, dass Tätigkeiten nicht mehr durchgeführt werden wenn sie keiner Person zugeordnet sind. Würde das zutreffen wäre es tatsächlich ein Problem, allerdings trifft es in richtig implementiertem Scrum nicht zu. Hier werden diese Tätigkeiten auch weiterhin erledigt, nur eben von keinem Koordinator oder Mittelmanager mehr sondern vom Entwicklungsteam selbst, und zwar immer dann wenn es notwendig ist.

"Aber das geht nicht, das können die gar nicht!" wird an dieser Stelle häufig eingewandt. Und hier kommen wir wieder zum korrekt implementierten Scrum zurück: Wenn zu den Aufgaben die erledigt werden müssen z.B. Testmanagement gehört, dann müssen dem Entwicklungsteam Personen zugeordnet sein die das können. Der Scrum Guide ist da eindeutig - Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment. Auch hier gilt die alte Wahrheit, dass dieses Framework nur funktioniert wenn man es einsetzt wie gedacht.

Und das lässt sich sogar noch weitertreiben: um dem Regelwerk formal Genüge zu tun könnte man einfach den Test- oder Releasemanager in das Team versetzen, wo er zwar seinen Titel verlieren würde, seine Rolle aber weiter ausüben könnte. Zu empfehlen wäre das aber nicht, da er zum einen in nur einem Team kaum ausgelastet wäre und zum anderen der Bus-Faktor bedenklich nach unten gehen würde. Zielführender wäre auch hier die Anwendung des Pull-Prinzips: Die Tätigkeit kommt als Task auf das Board und sobald sie erledigt werden muss kann sie vom jeweils nächsten Teammitglied übernommen werden das eine Aufgabe abgeschlossen hat.

Natürlich muss umgedacht werden wenn so gearbeitet wird. Manager müssen Verantwortung dorthin geben wo sie bisher noch nicht war, Mitarbeiter müssen weitergebildet werden und Entwickler müssen Aufgaben übernehmen die sie vorher noch nicht hatten. Die Vorteile wiegen das aber mehr als auf - Wissensverteilung, Abbau von Flaschenhälsen, ganzheitliche Sicht und Übernahme von Verantwortung sind nämlich genau die Faktoren die ein Team schon nach kurzer Zeit effektiver und effizienter machen.

Montag, 20. November 2017

Agilität, dort wo man sie nicht vermutet (II)

FS
Bild: Pixabay / Skeeze - CC0 1.0
Einer der wirksamsten Impulse gegen festgefahrenes Denken besteht in der Bemerkung, dass einige der besten Umsetzungen agiler Arbeitsweisen aus dem öffentlichen Dienst kommen. In der Regel führt das sofort zu Widerspruch. Das wäre ja gar nicht möglich. Der Staat sei doch für starre Strukturen und ineffizientes Handeln bekannt, für langsame Prozesse, lange Dienstwege und ähnliches. Wor wären denn da Einheiten die flexibel und reaktionsschnell arbeiten würden? Die gäbe es doch gar nicht.

Allerdings - es gibt sie doch, und sie sind sogar so bekannt, dass jeder sofort etwas mit ihnen anfangen kann. Zu ihnen gehören Feuerwehrwachen, Notaufnahmen und Operationsteams in Krankenhäusern, Flugleitzentralen, militärische Einheiten im Fronteinsatz und viele mehr. In jedem dieser Fälle sind die jeweiligen Teams mit sich schnell ändernden und instabilen Umgebungen konfroniert, in denen es überlebenswichtig sein kann innerhalb kürzester Zeit Entscheidungen zu treffen und sie umzusetzen. Und genau deshalb findet das dort statt.

Das Ziel dieses Gedankenspiels (Agilität im öffentlichen Dienst) sind verschiedene Erkenntnisse. Zum einen: jede organisatorische Einheit kann es schaffen sich agil zu organisieren. Wenn sogar Behörden es schaffen können, dann kann jede andere Organisation das auch. Denn soviel Wahrheit steckt doch im Klischee - die deutschen Amtsstuben sind im Normalfall eben doch ein Umfeld das eher Gemächlichkeit und Geruhsamkeit befördert. Aber das kann überwunden werden, wenn man nur will.

Hieraus ergibt sich dann auch die zweite Erkenntnis: es sind oft die Umgebungsfaktoren, die die Fähigkeit eines Teams zur agilen Organisation erst möglich oder unmöglich machen. Wenn die Umgebung einen Sinn in schnellen Reaktionen sieht (z.B. in Notaufnahmen oder Brandwachen), dann wird sie alles dafür tun diese auch herzustellen - sogar beim Staat. Wenn dieser Sinn aber nicht erkannt wird, dann werden die organisatorischen und bürokratischen Hürden im Zweifel nicht beseitigt werden, dann geht alles weiter seinen gemächlichen Gang.

Donnerstag, 16. November 2017

Exkurs in die empirische Sozialforschung

FS
Dieser Talk von Linda Rising erinnert mich sehr stark an die Seminare zur empirischen Sozialforschung die ich vor langer Zeit an der Universität gemacht habe. Und genau wie bei einigen meiner damaligen Dozenten bin ich mir nicht sicher - finde ich ihren Vortragsstil beruhigend, spannend, einschläfernd oder nervtötend? Unabhängig davon hat sie einen Punkt: wenn man im Lean Startup-Modus Experimente durchführen will sollte man darüber nachgedacht haben was das ist.

Powered by Blogger.