Auf dem Agile Day der JAX 2016

Agiles, Allzuagiles: Wege aus dem agilen Pandämonium

Hartmut Schlosser, Melanie Feldmann, Dominik Mohilo, Kypriani Sinaris

Agile im Jahre 2016 – eine Bestandsaufnahme der agilen Softwareentwicklung nahm sich der Agile Day der JAX 2016 vor. Wir werfen einige Schlaglichter auf die sechs Vorträge des Tages.

Wenn man ein wiederkehrendes Motiv des Tages herausgreifen wollte, dann wohl dieses, dass im agilen Manifest nicht nur von einer verbesserten Methodik zur Entwicklung von Software die Rede ist. Es geht vor allem auch darum, „wertvolle“ Software zu entwickeln, die dem Kunden/User auch tatsächlich hilft, seine Wünsche zu erfüllen: Agile und UX sind zwei Seiten derselben Medaille. Doch wie misst man den Wert einer Software?

Das agile Pandämonium

Auf dem Weg zum agil arbeitenden Team sind so einige Hürden zu nehmen. Eine davon: die Menschen. Denn nicht immer sind die verschiedenen Charaktere eines Teams dafür gemacht, agil im Team zu arbeiten. Das eine oder andere Persönchen braucht Moderation und auch ein wenig Erziehung. „Dem Team muss der Rücken gestärkt werden, damit es sich traut, gegen einen Platzhirschen zu argumentieren“, gaben Alessandro Grimaldi und Daniel Haslinger (Objectbay) in ihrem Talk den Zuhörern an die Hand. Ein Mauerblümchen muss man aus der Komfortzone locken und dem Grenzzieher klar machen, dass Zusammenarbeit mit anderen Teams und Abteilungen besser transparent und offen funktioniert. Dann klappt das auch mit dem Scrum.

CgVR7j6WcAAxvHH.jpg_large

Panel auf der Agile Day: (v.l.n.r.) Konstantin Diener, Lutz Malburg, Fahd Al-Fatish, Glenn Lamming, Nicole Rauch, Mirko Schrempp.

„Wenn man kein Ziel hat, ist jeder Schuss ein Treffer“

Ein weiterer agiler Klassiker kam in Konstantin Dieners (CoSee GmbH) Session „Scrum und mittelfristige Planungen – ein Widerspruch?“ zur Sprache: die Projektplanung. Sie kennen das: Man plant im Detail, wie jeder Sprint aussehen soll, am Ende verlaufen diese aber doch anders oder der Budgetrahmen wird schon nach der Hälfte des Projekts gesprengt. Was also tun? Die Lösung besteht aus einem schlanken Planungsverfahren, in dem wichtige Stationen festgehalten, bewusst aber auch Lücken gelassen werden. Viele Details klären sich eben erst auf dem Weg. „Planänderung als bewusste Entscheidung“ empfiehlt Konstantin Diener.

Dasselbe gilt für das Product Backlog. In einem Product Backlog wird das grobe Ziel definiert. Dieser Schritt ist wichtig, denn „wenn man kein Ziel hat, ist jeder Schuss ein Treffer“. Doch sollte das Backlog keinesfalls von oben nach unten fertig ausdefiniert sein. Die einzelnen Backlog Items haben eine unterschiedliche Granularität, insgesamt handelt es sich um eine Art “Reiseplanung”. Hier werden Größenordnungen, Aufwände, Story Points vermittelt, grobe Schätzung also. Und diese müssen nicht zwingend in Zahlen ausgedrückt werden. Hier können zum Beispiel T-Shirt-Größen aushelfen: XS, S, M, L, XL. Was diese Größen dann tatsächlich in Arbeitsstunden bedeuten, kann den Erfahrungen der ersten Iterationen angepasst werden – ganz agil eben.

User Stories und Effektivität

Vom Product Backlog zur User Story – dieses beliebte Mittel zur agilen Planung nahmen sich Lutz Malburg und Glenn Lamming (beide Novatec) in ihrer Session „Effektive User Stories – Wie Sie Ihre Produktivität in Projekten deutlich steigern können“ vor. Ihre zentrale Aussage: Bei agiler Softwareentwicklung geht es nicht darum, einen konkreten Wunsch eines Kunden möglichst genau umzusetzen. Vielmehr sollte der Wert im Zentrum stehen, den ein Kunde mit seinem Wunsch verbindet.

IMG_20160418_115001

Glenn Lamming, Lutz Malburg: Effektive User Stories – Wie Sie Ihre Produktivität in Projekten deutlich steigern können

 

Ein Beispiel: Die 70jährige Henriette wünscht sich eine übersichtlichere Nutzerführung eines Online-Shops, um ohne Irritationen eine Bestellung absenden zu können. Anstatt sich als Entwickler nun allein um den geforderten schnelleren Bestellprozess zu kümmern, geht es erst einmal darum zu verstehen, welche Verbesserungen für Henriette tatsächlich wertvoll wären. Und das können Dinge sein, die auf den ersten Blick nicht auffallen: Große, gut lesbare Schriftart, keine verwirrende Popups, wenig Scrollen auf einer Seite, User-Führung in Anlehnung an eine Katalog-Bestellung.

Die Sprecher empfehlen an dieser Stelle, mit Personas zu arbeiten, sich also User-Profile mit typischen Eigenschaften anzulegen, um die „Rolle“ auf einer User Story nicht abstrakt zu halten.

Der Wert wird typischerweise auch bei der Überprüfung des Erfolges eines Sprints nicht ausreichend berücksichtigt. Während es einfach ist, gelieferte Features aufzuzählen, so tut man sich doch viel schwerer damit, den Wert zu quantifizieren, den diese neuen Features tatsächlich für die anvisierte Zielpersona erzielt hat. Wie war das noch im agilen Manifest?

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung
wertvoller Software zufrieden zu stellen.

Es gibt kein Förderband für Skalierung – Sie werden selbst laufen müssen

„Agile“ funktioniert in Ihrem kleinen Pilotteam – doch wie geht man nun den nächsten Schritt? Wie skaliert man Agilität in der ganzen Abteilung? Geht das überhaupt?

In seiner Session „Nexus – Scaled Professional Scrum“ sprach Fahd al-Fatish (andrena objects ag) zunächst von den drei Skalierungsfallen:

  1.     Zu frühes Skalieren
  2.     Zu schnelles Skalieren
  3.     Zu unbedachtes Skalieren

Ein Klassiker ist die Fehlannahme, dass mehr Teams auch eine höhere Geschwindigkeit bei der Entwicklung bedeuten. Fahd al-Fatish empfiehlt, sich zunächst gut zu überlegen, wie groß die Anzahl der Teams tatsächlich sein muss:

Wer mehr als 80 Entwickler beschäftigt für ein Projekt, sollte sich überlegen, ob nicht schon initial bei der Planung große Fehler begangen wurden.

Ein weiterer wichtiger Faktor ist, die Abhängigkeiten der einzelnen Teams im Auge zu behalten, seien es nun Abhängigkeiten in Bezug auf Skills, Software, Domänen oder technologische und infrastrukturelle Abhängigkeiten. Erkennt man sich wiederholende Muster in den Abhängigkeiten untereinander, kann man einen großen Schritt in Richtung Optimierung gehen. Fahd al-Fatish empfiehlt auch die Nutzung eines Skalierungsframeworks wie Nexus, in dem die Abhängigkeiten zwischen den Teams von einem eigenen „Nexus Integration Team“ transparent gemacht wird.

IMG_20160418_111504

Fahd Al-Fatish auf dem Agile Day

 

Kommt man zu der unangenehmen Erkenntnis, dass die Skalierung einfach nicht klappen will, gibt es drei Möglichkeiten. Als erstes kann man die systematische Professionalisierung versuchen. Diese funktioniert allerdings nur, wenn alle Beteiligten wirklich wollen. Ein Change-Team muss gebildet werden, das fehlerhafte Prozesse ausfindig macht und entsprechende Maßnahmen zur Verbesserung vorgibt.

Kommt man mit diesem Ansatz nicht weiter, ist es Zeit für eine De-Skalierung. Das bedeutet nichts anderes, als die Reduktion an Teams und Entwickler. Scheitert auch die De-Skalierung hilft nur ein sogenannter Scrumble – ein absoluter Stopp aller Entwicklungsarbeiten und ein Neubeginn mit frischen Ressourcen.

Conway’s Law Revisited

Das Gesetz von Conway besagt, dass die Kommunikationstrukturen von Organisationen sich in ihren Produkten widerspiegelt. Lose gekoppelte Organisationen bringen Produkte mit modularen Architekturen, präferiert unter Nutzung von Open Source-Technologien, hervor; „tightly-coupled“ Unternehmen tendieren zu Monolithen und kommerziellen Lösungen. Diese Hypothese, man nennt sie auch “Spiegelhypothese”, nahm sich Jens Himmelreich (neuland – Büro für Informatik) anhand von Beispielen aus dem E-Commerce-Bereich vor.

Wer agil an lose gekoppelten Systemen arbeiten will, ist gut beraten, verschiedene Seiten und Domänen eines Webshops in einzelne Scrumteams zu unterteilen, die für ihren jeweiligen Bereich und NUR für diesen zuständig sind. Für die nötige Einheitlichkeit im User Interface sorgt ein Style-Guide.

Fazit: “Mehr miteinander reden”

Es gibt zahlreiche Ansätze, um die Softwareentwicklung zu verbessern: Von Extreme Programming, über Specification by Example bis hin zur agilen Softwareentwicklung. Je nachdem, welche Voraussetzungen in einem Projekt gegeben sind, ist auch das Modell zu wählen. Möchte ich selbstorganisierende Teams und schnelles und flexibles Reagieren auf Veränderungen? Liegt mein Fokus auf lebhafter Dokumentation? Im Kern mag es kleine Unterschiede zwischen den Modellen geben, aber was alle verbindet, fasst ein Kommentar während der JAX-Session von Nicole Rauch (freiberufliche Softwareentwicklerin) zusammen: Kommunikation ist der Schlüssel zum Erfolg.

IMG_20160418_143727

Nicole Rauch: Eine „Grand Unified Theory“ der Softwareentwicklung

 

 

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Melanie Feldmann
Melanie Feldmann
Melanie Feldmann ist seit 2015 Redakteurin beim Java Magazin und JAXenter. Sie hat Technikjournalismus an der Hochschule Bonn-Rhein-Sieg studiert. Ihre Themenschwerpunkte sind IoT und Industrie 4.0.
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kypriani Sinaris
Kypriani Sinaris
Kypriani Sinaris studierte Kognitive Linguistik an der Goethe Universität Frankfurt am Main. Seit 2015 ist sie Redakteurin bei JAXenter und dem Java Magazin.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: