Zum Inhalt
Blog

Verstehen und aufteilen: Das ist Agile!

Wuk Petrovic • 17. Januar 2020
Share

Verständnis für die eigene Aufgaben und eine effiziente Arbeitsaufteilung: das sind die Erfolgsfaktoren durch die Agile Teams kreative, innovative und kundenorientierte Lösungen bereitstellen können.

Flink, beweglich, selbstorganisiert… so werden agile Methoden immer wieder beschrieben. Hin und wieder wird Agile auch mit „chaotisch arbeiten“ gleichgesetzt, was es auf keinen Fall sein sollte. In Wirklichkeit gibt es bei allen Agilen Frameworks ganz klare und wichtige Spielregeln die uns dabei helfen, effizient zu arbeiten.

Momentan betreue ich mehrere Teams bei den Herausforderungen, die solche Spielregeln mit sich bringen. Ich arbeite im Agile Competence Center (ACC) der twinformatics im Core-Team und unterstütze neue Scrum Master beim optimalen Einstieg in unser Unternehmen.

Neben diesen recht umfangreichen Aufgaben habe ich noch eine sehr wichtige Funktion im Unternehmen – die Ausbildung. Einerseits bringe ich NeueinsteigerInnen die agilen Methoden näher. Andererseits bilde ich auch den Scrum-Master-Nachwuchs aus. Oder, um den Nerd in mir zu bemühen: Always two there are; one master, one apprentice (Meister Yoda). Denn: Der Markt ist zwar vorhanden, aber es macht nicht viel Sinn, mehr als eine/n Junior zu betreuen. In meinem Fall ist das Eva, eine sehr engagierte Quereinsteigerin aus dem Controlling-Bereich. Sie ist seit einem Monat mit dabei und bereits voll in die agile Welt abgetaucht! Wie sie zu Scrum gefunden hat – dafür wird es einen eigenen Blogbeitrag geben. Stay tuned!

Hin und wieder wird Agile auch mit „chaotisches arbeiten“ gleichgesetzt. Das ist es nicht!
Wuk Petrovic

In meinen langen Jahren als Scrum Master habe ich eine Frage immer wieder gehört, und zwar sowohl in Managementschulungen als auch im Freundeskreis: 

„Was ist eigentlich dieses Agile?“

Diese Worte sind mir als Frage zusammen mit einem ganz bestimmten Gesichtsausdruck sehr vertraut. In diesem Blogbeitrag möchte ich euch wichtige Grundprinzipien von Agile erklären: Arbeitsaufteilung und Verständnis.

Beim agilen Arbeiten wird durch die Reduktion von Komplexität ein besseres Verständnis von Arbeitspaketen sichergestellt. Damit wissen alle im Team, was zu tun ist. Die interne Koordination funktioniert besser. Weitere Vorteile liegen in einer höheren Transparenz, schnelleren Durchlaufzeiten, schnelleren Abnahmen und höhere Motivation.

 

Wuk Petrovic und Eva Lausecker
Wuk Petrovic und Eva Lausecker

Besonders wichtig sind mir drei Grundsätze:

  • Agilität bedeutet, flexibel auf Herausforderungen reagieren und effektiv Aufgaben aufteilen.
  • Diese Interpretation von Agilität führt uns zu einem wichtigen Erfolgsfaktor: Reduktion von Komplexität = besseres Verständnis der Aufgabe!
  • Agilität bedeutet vor allem Verständnis. Dieser Erkenntnis wird auch in den verschiedenen Agilen Frameworks Rechnung getragen und sollte von uns allen bewusster gefördert werden.

Aus der Praxis: so geht Agile am Beispiel Scrum

Als Scrum Master ist für mich Agilität natürlich alles. Mein gesamter Arbeitstag dreht sich darum. Doch was macht ein Scrum Master eigentlich?

Scrum Master leiten keine Teams. Sie unterstützen Teams dabei, agile Prozesse besser und konsequenter umzusetzen. Meine KollegInnen und ich verstehen uns als AnsprechpartnerInnen rund um die agile Arbeitswese. Wir versuchen, die verschiedenen Methoden so effizient wie möglich zu implementieren, Schwierigkeiten aufzuzeigen und mit den Teams zu lösen. Außerdem räumen wir mögliche Hindernisse von außen aus dem Weg und sorgen für die reibungslose Kommunikation.

Nach außen?

Ja. Denn wenn etwas im Weg steht, ist das nicht immer das Team sich selbst. Widerstände können auch von außerhalb kommen, etwa durch festgefahrene Unternehmensstrukturen oder Abläufe, die noch im Gestern verhaftet sind. Hier noch ein paar Tipps, wie man häufige Herausforderungen zum Thema in Teams angehen kann:

Die User Story

Eine User Story (US) ist eine in Alltagssprache formulierte Anforderung an (neue) Software. In  vielen Teams gibt es dafür Vorlagen, sogenannte Templates. In diesen werden grundlegende Kriterien heruntergebrochen. Verwenden wir ein Sportbeispiel: 

  • [WER] möchte etwas (das sein Leben leichter macht)
  • [WAS] braucht er (kühlende Socken)
  • [WARUM] braucht er das (um schneller laufen zu können)

Durch diese einfachen Abklärungen werden Verlinkungen hergestellt – sowohl zu guten Dingen (Enabler) als auch Hindernissen (Blockern). So wird eine schnelle Bearbeitung der jeweiligen US unterstützt, da es dank klarer Informationslage bei der Umsetzung in der Regel weniger Rückfragen bzw. Missverständnisse gibt.

Kleine UserStory

StoryPoints – eine Bewertung von einzelnen Aufgaben oder Items - spiegeln unter anderem Abhängigkeiten, Komplexität, Risiko und den Aufwand wider. Daher hat es sich in der Praxis bewährt, eine Maximalgröße für US zu definieren. Hierbei haben sich folgende Zahlen in den letzten Jahren bewährt: 2 Wochen Sprints / US max. 8 Storypoints (SP). Dauert der Sprint 3 Wochen, sollten es maximal 13 SPs sein. Sollte die US größer sein, ist meine Empfehlung, sie auf mehrere Sprints zu splitten. Das ist meiner Erfahrung nach immer möglich. Zu diesem Thema kann man leicht eine Dissertation schreiben. Hier ist eine von vielen Quellen, in denen dieser Vorgang beschrieben wird: https://agileforall.com/resources/how-to-split-a-user-story/

Beispiel agiles Arbeiten bei der twinformatics GmbH
Beispiel agiles Arbeiten bei der twinformatics GmbH

So teilt man große Aufgaben richtig

Denkt jetzt auf keinen Fall an einen saftigen Cheeseburger.

NICHT an Cheeseburger denken.

Ist der Cheeseburger unauslöschbar in eurem Hirn eingebrannt und ihr müsst heute noch ganz dringend zum Schachtelwirt? Gut.

Jetzt stellt euch vor, wir zerlegen den Burger in seine Bestandteile. Weckerl, Patty, Käse, Tomate, Zwiebel, Ketchup. Ist das Geschmackserlebnis noch immer genauso attraktiv? Eher nicht, oder. Schneidet man aber aus demselben Burger eine Ecke heraus, wird zwar der Hunger zwar weniger befriedigt, aber zumindest gibt’s schon einen realistischen Eindruck, wie das Gesamtprodukt schmeckt.

Beispiel agiles Arbeiten bei der twinformatics GmbH
Beispiel agiles Arbeiten bei der twinformatics GmbH

Komplex? Sinnvoll!

Die Reduktion von Komplexität führt in der Regel zu einem besseren Verständnis sowohl der kleineren, als auch der größeren Arbeitspakete. Somit weiß jede/r im Team was zu tun ist und die interne Koordination funktioniert besser. Weitere Vorteile liegen in einer höheren Transparenz, schnelleren Durchlaufzeiten, schnelleren Abnahmen, höheren Motivation und besseren Abbildung im Burndown-Chart.

Story-Champ Prozesse

In der Regel besteht eine US aus einer technischen und einer fachlichen Seite. Die fachlichen Fragen werden in der Regel durch Product Owner, Business Analysten und/oder Solution Managern mit dem Kunden geklärt. Die technischen Aspekte werden vorab meistens von Lead Developern und Architekten geklärt. Ich empfehle, die Details innerhalb des Teams zu klären. Das bringt einige Vorteile:

  • Jemand aus den Team kann mögliche Blocker frühzeitig aufzeigen
  • Die Auseinandersetzung mit der Aufgabe baut Wissen auf
  • Durch eine Aufbereitung aus einem technischen Blickwinkel werden viele Fragen die während eines Refinements auftauchen könnten schon frühzeitig geklärt
  • Eine direkte Zusammenarbeit zwischen Product Owner und Team
  • Refinements werden deutlich effektiver

Die Geschichte der Arbeitsaufteilung 

Agiles Arbeiten ist innovativ, aber die Idee dahinter ist keine ganz neue oder gar singuläre. Der Prozess hat je nach Betrachtungsweise entweder 1968 oder in den 30er-Jahren begonnen. Für mich persönlich war es der Ökonom Adam Smith (1723-1790). In seinem Werk Pin Factory/The Wealth of Nations legt er den ersten agilen Arbeitsentwurf vor: Um die Effizienz zu steigern, werden große Arbeitspakete auf viele kleinere heruntergebrochen.

Das machst du eh sowieso immer? Gratuliere, du arbeitest bereits agil!

Über mich

Agile Coach im Agile Competence Center der twinformatics. Offen gesagt bin ich zwar ein Kind der 80er (für die Jüngeren unter uns, die Zeit von C-64, x386er CPUs, Knight Rider…) und habe immer schon IT im Blut gehabt - aber leider kein Talent zum Entwickler. Was wahrscheinlich auch ein Grund war, weshalb ich meine Berufung im Projektmanagement gefunden habe. In Summe kann ich auf über 20 Jahre, davon 9 Jahre im Projektumfeld (Rollouts, klassische Projekte und Agile Projekte) Berufserfahrung zurückschauen. Ich bin begeistert von Star Trek, Star Wars, HiFi, natürlich auch Agilität. Aber im Privatleben versuche ich einfach mit Freunden, Familie oder auch mal nur bei guter Musik abzuschalten.

Zur Hauptnavigation
Diese Website verwendet Cookies, um Ihnen den bestmöglichen Service zu gewährleisten. Durch die Nutzung dieser Website erklären Sie sich mit der Verwendung von Cookies einverstanden. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung .