Agiles Anforderungsmanagement: die wesentlichen Kernelemente für erfolgreiche IT-Projekte

Immer häufiger werden IT-Lösungen nach dem Lean-Start-Up Prinzip realisiert. Beginnend mit der initialen Entwicklung eines, auf die Kernfunktionen fokussierten Produktes zum Markteinstieg („Minimal Viable Product – MVP“), wird das Produkt nach dem Go-Live durch direktes Marktfeedback, weiterentwickelt und optimiert.

Das erfordert ein entsprechendes Umdenken, auch im Anforderungsmanagement. Was sind die wesentlichen Kernelemente, die beim agilen Anforderungsmanagement über Erfolg und Misserfolg eines Softwareprojektes entscheiden?

Eine Frage auf die es vermutlich viele verschiedene Antworten gibt. In folgendem Blogbeitrag wollen wir uns dem Thema auf den drei Ebenen „Prozess“, „Tooling“ und „Mindset“ annähern und praxisnah darauf eingehen, wie agiles Anforderungsmanagement in diesen Bereichen jeweils Beachtung finden kann. Die Inhalte stammen größtenteils aus unserem Vortrag, den wir auf der ModernRE 2019 in Berlin gehalten haben.

Der Prozess: Von der Idee zur spezifizierten Anforderung

In einem Projekt liegt die thematische Verantwortung beim Fachbereich. Daher erstellt und aktualisiert dieser regelmäßig die Vision des Produkts – das Zielbild. Anhand dieser Vision werden viele Ideen abgeleitet um dieses Zielbild zu erreichen.

Die technische Verantwortung liegt wiederum beim IT Team. Das IT Team hat eine etwas andere Perspektive auf das Produkt und daher auch andere Ideen, als der Fachbereich, Im besten Falle ergänzen sich die Sichtweisen der IT mit der des Fachbereiches.

Von der Idee zur spezifizierten Anforderung
Abbildung: Von der Idee zur spezifizierten Anforderung

Eine Besonderheit ist es, dass alle Teammitglieder dazu aufgerufen sind ihre Ideen an einen eigens hierfür eingerichteten Bereich, dem sogenannten Ideen-Backlog, einzutragen und zu detaillieren. Ideen kommen dabei von einzelnen Teammitgliedern, die Verbesserungs- und Optimierungspotenziale erkannt haben, von externen Studien, in Form von direktem Feedback von Kunden, oder Dritten aus dem Markt.

In regelmäßigen Abständen findet durch den Fachbereich eine Begutachtung aller neuer Ideen aus dem Ideen-Backlog statt. Bei der inhaltlichen Prüfung der Ideen wird der bereits priorisierte Backlog betrachtet, sodass neue Ideen, die weiterverfolgt werden sollen, direkt priorisiert werden können. Auf diese Weise ist sichergestellt, dass immer die Idee als nächstes im Detail spezifiziert wird, die den größten Nutzen für Dritte und Kunden stiftet oder die größte Relevanz für das Produkt hat.

In der Spezifikation werden die Themen detailliert und im Sinne des Anforderungsmanagements spezifiziert. Es müssen beispielsweise Stakeholder ermittelt werden, die in einem Kick-off-Termin in das Vorhaben eingeweiht werden. Erste Erkenntnisse und Anforderungen werden notiert und grafisch in Form von Wireframes, Mockups oder mittels eines passenden Diagrammtyps aufbereitet. Ein Spezifikationstemplate hilft, wiederkehrende Fragen und Sachverhalte standardisiert zu betrachten und so keine wichtigen Aspekte zu vergessen. Klassische Ansätze kommen an dieser Stelle ebenfalls zum Tragen. Anforderungen müssen erhoben, analysiert, spezifiziert und validiert werden.

Nach jeder Spezifiaktionsphase steht das Review der fertigen Spezifikation an. Für das Review wird ein Teilnehmerkreis, bestehend aus dem Fachbereich und einem dedizierten IT-Ansprechpartner, dazu eingeladen, Feedback zur Spezifikation abzugeben. Um technische Risiken und die Umsetzbarkeit zu prüfen, sollte eng mit dem IT Team zusammen gearbeitet werden. Zusätzlich nehmen Kollegen aus der IT einen anderen Betrachtungswinkel ein und decken so zum Beispiel häufig noch nicht betrachtete Randfälle auf. Am Ende eines definierten Zeitraums ist es die Aufgabe des Autors, das Feedback zu konsolidieren, zu sichten und in die Spezifikation einzuarbeiten.

Am Ende steht eine finale Version der Spezifikation (v1.0), die sowohl vom Fachbereich, als auch vom IT Team gleichermaßen mitgetragen wird. Prozessual wird die fertige Fachspezifikation im IT-Refinement vom Fachbereich an das IT Team übergeben, Letzte Zusammenhänge werden betrachtet und ein einheitliches Verständnis hergestellt. Anschließend werden aus der Spezifikation User Stories für das Product Backlog der Software Entwicklung abgeleitet, definiert, priorisiert und detailliert.

Tooling in einer kollaborativen & verteilten Arbeitswelt

Ein toller Prozess allein reicht nicht aus! Es sind Tools notwendig, die diesen kollaborativen Ansatz ermöglichen und unterstützen. Zumeist werden zwei Tools in Kombination, beispielthaft JIRA und Confluence aus der Atlassian Suite, eingesetzt, um diesen Prozess abbilden zu können.

In einem Ticketingtool (Abbildung: Requirements Board im Ticketingtool) wird ein Kanban Board erstellt. Dort werden sämtliche Prozessschritte abgebildet, um den Überblick über alle Themen im Prozess zu behalten. Die Tickets im Status „Ready for Specification“ stellen den bereits priorisierten Backlog dar, der aus dem Ideen-Backlog gespeist wird. Ideen, die keine Relevanz für das Produkt liefern, werden hier schon gar nicht mehr berücksichtigt. Themen, die sich momentan in der Bearbeitung befinden – sei es in der Erstellung der Spezifikation („In Specification„) oder im Review („In Review„) – werden per Drag-and-Drop in den entsprechenden Status gezogen. Durch die Verlinkung des Tickets zur Spezifikation besteht die Möglichkeit, in einem Klick vom Ticketingtool zum Kollaborationstool (Erklärung im nachfolgenden Absatz) zu springen. In die entgegengesetzte Richtung ist dies ebenso möglich. Auf diese Weise werden unnötige Tool- und Systembrüche vermieden und Arbeitsabläufe effizienter gestaltet. Aus Fachbereichssicht ist eine Spezifikation, nach dem das Review beendet wurde, mit der Übergabe an das IT Team („Handover to IT„) fertiggestellt. Um eine vollständige Dokumentation zu gewährleisten, ist es notwendig, dass diese um die umgesetzten Funktionserweiterungen ergänzt wird („Documentation done„). Erst jetzt ist der Zeitpunkt erreicht, an dem man guten Gewissens von einer umgesetzten Anforderung sprechen kann.

Requirements Board im Ticketingtool
Abbildung: Requirements Board im Ticketingtool

In einem Kollaborationstool findet die Dokumentation der Spezifikation und das Review statt. Zwischen den beiden Tools sind Verlinkungen der entsprechen Tickets und Spezifikationen möglich, um so direkt vom einen in den anderen Bereich springen zu können. Zusätzlich lassen sich Workshops ebenfalls im Kollaborationstool dokumentieren und als Entscheidungsprotokolle direkt in die Spezifikation verlinken. Durch zahlreiche Add-ons kann der Funktionsumfang eines Kollaborationstools sehr individuell auf die Bedürfnisse im Projekt und Prozess angepasst werden. So können beispielsweise Wireframes direkt im Kollaborationstool selbst erstellt und bearbeitet werden.

Der wohl größte Vorteil durch den Einsatz eines Kollaborationstools ergibt sich bei der Durchführung des Reviews einer Spezifikation. Vor dem Umzug in der Spezifikation in das Kollaborationstool wurde das Review anhand eines Word-Dokuments durchgeführt, wodurch je Review-Teilnehmer eine Version des Dokuments auf dem Fileserver abgelegt wurde. Die Aufgabe des Requirements Engineers bestand daraus, das Feedback zu konsolidieren und in die Spezifikation einzuarbeiten. Bei doppelten oder gar widersprüchlichen Kommentaren in den unterschiedlichen Review-Dokumenten führte das zu erhöhtem Abstimmungs- und Klärungsaufwand mit den entsprechenden Review-Teilnehmern. Durch den Umzug in das Kollaborationstool kann nun auf die vollen Funktionsumfänge zur Unterstützung und Verbesserung der Kollaboration unter den Review-Teilnehmern und des Requirements Engineers zurückgegriffen werden. Die Inline-Kommentarfunktion (Abbildung: Spezifikation und Review im Kollaborationstool) bietet die Möglichkeit, dass jeder Review-Teilnehmer durch Markieren einer Textstelle einen Kommentar platzieren kann, welcher für alle anderen Review-Teilnehmer sichtbar ist. Auf diese Weise werden Dopplungen vermieden, es entstehen Diskussionen, die neue Themen aufwerfen oder etwaige Rückfragen direkt klären. Für den Requirements Engineer verringert sich der Konsolidierungsaufwand des Review-Feedbacks signifikant, da nun mehr alle Kommentare in einem Dokument zu finden sind, Dopplungen und Widersprüche leichter zu identifizieren und aufzulösen sind.

Spezifikation und Review im Kollaborationstool

Abbildung: Spezifikation und Review im Kollaborationstool

Am Ende eines jeden Reviews sind alle Teilnehmer dazu aufgefordert, zu bestätigen, dass das Review beendet wurde und anzugeben, ob eine weitere Abstimmung mit dem Autor der Spezifikation gewünscht wird.

Review Log am Ende jeder Spezifikation

Abbildung: Review Log am Ende jeder Spezifikation

Mindset

Damit ein Projekt erfolgreich abgeschlossen werden kann, benötigt es mehr als funktionierende Prozesse und moderne Tools. Häufig wird ein wichtiges Kernelement übersehen: Das Mindset. Nur wenn die Menschen im Projekt kooperativ und auf das Projektziel ausgerichtet arbeiten, greifen die Prozesse und Tools effektiv ineinander. Heutzutage stoßen wir in Projekten jedoch häufig auf sogenannte Silos (z.B. bei verschiedenen Abteilungen innerhalb eines Konzerns), die das Zusammenarbeiten erschweren können. Silos verfolgen im schlechtesten Falle eigene Ziele, welche auf den ersten Blick nicht immer mit den Zielen des aktuellen Projekts übereinstimmen.

Georg Jocham, Coach für Projektmanager und Führungskräfte, greift in einem seiner Podcasts zum Thema „Silos“, auf eine im Jahre 2005 durchgeführte Studie zurück. Hier zeigte der Sozialpsychologe Mark Levin, welchen negativen Einfluss Silodenken auf das Kooperationsverhalten über die eigene Gruppe hinaus haben kann. Dazu werden Fußballfans von Manchester United zu Beginn des Versuchs Fragen im Themenumfeld rund um ihren Verein gestellt. Anschließend kann beobachtet werden, dass die Hilfsbereitschaft unter den Teilnehmern gegenüber anderen Manchester Fans um ein Vielfaches höher ist, als gegenüber Fans eines rivalisierenden Vereins. Beim zweiten Teil der Studie werden weitere Manchester United Fans eingeladen. Nun wird mit Hilfe einer anfänglichen Umfrage jedoch der Fokus nicht auf den Verein gelegt, sondern auf die gesamte englische Liga. Interessanterweise ist die im Anschluss beobachtete Hilfsbereitschaft gegenüber Menschen, die dem rivalisierenden Verein angehören massiv gestiegen ist. Sie erreicht dabei fast dasselbe Niveau wie die Kooperation den eigenen Vereinskollegen gegenüber.

Die Studie zeigt wie eklatant sich das Kooperationsverhalten unterscheidet: Je nachdem welcher Gruppe sich Menschen zum aktuellen Zeitpunkt zugehörig fühlen und ob deren Gegenüber ebenfalls Teil dieser Gruppe ist oder nicht. Die Studie zeigt neben den Gefahren die Silos bergen können, bereits eine mögliche Lösung, um aus dem Dilemma zu entkommen. Menschen, die in einem Projekt über verschiedene Abteilungen oder Firmen zusammenarbeiten, benötigen eine gemeinsame Projektidentität. Diese muss möglichst früh im Projekt etabliert werden, z. B. durch Vermittelung des gemeinsamen Projektziels im gemeinsamen Kick-off zu Beginn des Projekts.
Ist eine Projektidentität geschaffen muss sichergestellt werden, dass diese Bestand hat. Innerhalb dieses Projektteams haben sich zwei grundlegende Werte herausgeprägt die für den Zusammenhalt und eine funktionierende Zusammenarbeit innerhalb der Gruppe von großer Bedeutung sind: Wertschätzung und Vertrauen.

Ein wertschätzender Umgang im Projekt kann sich auf vielseitige Art und Weise äußern. So ist es zum Beispiel wertschätzend, andere nach Ihrer Meinung zu fragen oder sich für geleistete Arbeit zu bedanken. Eine hohe Wertschätzung im Projekt kann dazu führen, dass das Team eine höhere Loyalität dem Projekterfolg gegenüber zeigt.
Auch ein hohes Maß an Vertrauen spielt eine nicht unwesentliche Rolle, ob ein Team die gemeinsam etablierten Prozesse und Tools optimal nutzen kann. Dazu muss sichergestellt werden, dass jeder Beteiligte sich darauf verlassen kann, dass das gesamte Team auf den Projekterfolg ausgerichtet ist und somit auch das Ansprechen von Risiken, Fehlern und auch das Einbringen der eigenen Meinung als einen Beitrag zu diesem angesehen werden. In Projekten in denen ein hohes Maß an Vertrauen herrscht, steigt die Transparenz und die Berührungsängste in fachlichen Diskussionen und im schriftlichen Austausch nehmen stark ab. Es geht wieder mehr um die Sache. Insbesondere Transparenz ist in agilen Frameworks, wie zum Beispiel Scrum, eine wesentliche Grundvoraussetzung.

Wertschätzung und Vertrauen im Projekt

Abbildung: Wertschätzung und Vertrauen im Projekt

Fazit

Jedes der drei obigen Themen würde mehr als einen eigenen Vortrag füllen. Das hat sich unter anderem auch in der Agenda der diesjährigen ModernRE 2019 gezeigt. So wurden auf der Konferenz eigene Vorträge zum Einsatz einzelner Tools im Anforderungsprozess und zum Zusammenspiel von Ticketing- und Kollaborationstools gehalten. Auch auf das Thema Mindset wurde in einem spannenden Vortrag mit dem Titel „Wie Teams wirklich Stark werden“ eingegangen.
Auch wenn die Rahmenbedingungen in IT-Projekten sehr unterschiedlich sind, so lohnt es sich doch von Zeit zu Zeit den eigenen agilen Anforderungsprozess unter die Lupe zu nehmen und bei Bedarf zu Überarbeiten. Besonders leicht fällt das, wenn man mit Tools arbeitet, die hier die notwendige Flexibilität mitbringen.

Wovon mit Sicherheit alle Projekte profitieren, unabhängig der Rahmenbedingung, ist ein wertschätzender und vertrauensvoller Umgang innerhalb eines gemeinsamen Projektziels.

Co-Autor Findan Eisenhut

 


Weiterführende Links

10 Erfolgsfaktoren für das Anforderungsmanagement in agilen Software-Großprojekten

Kundenzufriedenheit durch Erfüllung von Anforderungen – das Kano-Modell

 

Mehr zur Anforderungsanalyse für Softwareprojekte gibt’s hier

 

Agile Mixperience – die prickelnde Alternative zu Scrum Cooking

Mit Cocktails vermitteln, wie Scrum funktioniert

Nach jahrelanger Erfahrung mit dem Erfolgskonzept „Scrum Cooking“ inklusive optimierter Rezepte, zahlreichen neuen Koch-Skills und Kunden, die leckere Menüs genießen durften, wird es Zeit für ein wenig Abwechslung. Also warum die Methodik Scrum nicht bei einer Agile Mixperience erlernen? Statt 3-Gänge-Menüs werden hier Cocktails gemixt.

Es gibt zahlreiche Zertifizierungen, die sich mit den theoretischen Grundlagen der Projektmanagement-Methode Scrum beschäftigen. Wirklich nachhaltig lernt man am besten mit Praxisbezug und Spaß. Mit dem Workshop „Agile Mixperience“ vermitteln unsere Agile Coaches wie auch bei „Scrum Cooking“ die spezifischen Rollen, Prozesse und Artefakte der Methodik. Der eintägige Workshop wird entweder beim Kunden vor Ort oder in einer Location aus unserem Netzwerk durchgeführt. Die Teilnehmer lernen spielerisch die Grundprinzipien kennen, werden selbst aktiv und erleben unmittelbar die Effekte agiler Arbeitsmethoden. Sie schildern aus eigener Erfahrung:

„Es geht nur mit Kooperation.“
Für die Bearbeitung unserer strategischen und organisatorischen Aufgaben haben wir im Management Team agile Methoden schätzen gelernt. Die „Agile Mixperience“ hat uns ganz schnell wieder vor Augen geführt, dass eine reibungslose Kooperation im Team das A und O für den Erfolg des agilen Ansatzes ist.

 

„Raus aus der Falle „definition of (almost) done“
Seit Monaten arbeiten wir Product Owner mit unserem Entwicklungsteam agil zusammen und freuen uns über jede erfolgreiche Zwischenlieferung. Mit der Agile Mixperience wollten wir das Team nach einem Wechsel in verschiedenen Rollen neu zusammenschweißen. Wir haben aber noch mehr gelernt. Denn richtig lecker ist ein Cocktail erst, wenn er auch wirklich fertig ist und alle ihn genießen können.

 

„Agiles Arbeiten kann auch abseits der Software-Entwicklung sinnvoll sein.“
Wir standen vor der Frage, ob eine agile Arbeitsweise auch in unserem Vertriebsteam anwendbar ist. Nach dem Workshop steht fest: Wir werden nur gewisse Elemente aus dem Scrum Framework umsetzen können, diese jedoch konsequent bei uns etablieren. Nach der praktischen Anwendung zwischen Stößel, Shaker und Cocktails werden unsere Mitarbeiter jedenfalls nie wieder vergessen, was ein Scrum Master und ein Product Owner machen.

So funktioniert die Agile Mixperience:

  • Theoretische Einführung in das Scrum Framework, um bei den Teilnehmern ein gemeinsames Verständnis zu schaffen.
  • Team-Building und Verteilung der Rollen des Scrum Masters, Product Owners und der Teammitglieder.
  • Vorbereitung der Produktvision und des Product Backlog. Ziel ist es, dem „Kunden“ ansprechend dekorierte leckere Cocktails anbieten zu können – je nach Wunsch vom Virgin Cocktail bis zum Classic Cocktail.
  • Praktische Durchführung von drei Iterationen inklusive Sprint Planning, Sprint Review und Sprint Retrospektive, um das Erlernte zu festigen.
  • Gemeinsame Reflexion und Übertragung des Erlebten in die eigene Arbeitswelt.

 

Zusätzliche Herausforderungen entstehen durch Aktionskarten und veranschaulichen immer wieder, dass eine gute Planung, Transparenz und klare Kommunikation das A und O bei einer agilen Vorgehensweise sind. Auch die Zeit wird anfangs häufig unterschätzt. „Eine halbe Stunde für einen Cocktail? Das ist doch keine Herausforderung!“ Und doch geraten die Teams zu Beginn in Hektik. Mit jedem Sprint wird die zuvor besprochene Theorie verständlicher und besser angewendet – das Team schwingt sich ein, es lernt dazu und arbeitet in der nächsten Iteration produktiver.

doubleSlash Agile Mixperience Cocktails
Abbildung 1: Hanami-Cocktail bei einer Agile Mixperience mit doubleSlash im September 2019 in München

Während des gesamten Tages werden die Teilnehmer durch erfahrene Agile Coaches begleitet, die alle selbst in unterschiedlichen Rollen in agilen Projekten arbeiten.

Fazit: Agile Mixperience – für jedes agile Level und individuell nutzbar

Agile Mixperience schafft ein gemeinsames Verständnis im Projektteam und ist ideal für:

  • den Kick-off von anlaufenden agilen Projekten.
  • neue Projektmitglieder, die in laufende agile Projekte integriert werden.
  • erfahrene Projektmitglieder, die einen frischen Blick auf Ihre Scrum-Praxis werfen möchten.
  • Unternehmen, die sich eine Einführung von agilen Arbeits- und Entwicklungsmethoden überlegen.

 

Gemeinsam mit verschiedenen Kunden haben wir den Workshop „Agile Mixperience“ bereits erfolgreich verprobt. In lockerer Atmosphäre holen wir die Teilnehmer mit unterschiedlichsten Wissensständen ab – von Scrum Anfängern bis zum erfahrenen Scrum Master. Unser Ziel ist es, die Methodik verständlich zu vermitteln, den Teilnehmern die Scheu vor der praktischen Anwendung zu nehmen und die Essenz für die eigene Arbeitswelt mitzugeben.

Mehr Agile Workshops gibt es hier

 

Mal über den Tellerrand geschaut: Was können Softwareprojekte von sozialen Projekten lernen?

Am kommenden Samstag startet in Friedrichshafen wieder das Entenrennen auf dem Seehasenfest. Ein soziales Projekt, das auch von doubleSlash wieder als Hauptsponsor unterstützt wird und über das seit über zwölf Jahren jährlich 20.000 Euro Spendengelder für bedürftige Familien in der Region eingesammelt werden. Eine Erfolgsgeschichte, von der auch Softwareprojekte lernen können? Schauen wir uns die Erfolgsfaktoren einmal genauer an.

Die Projektvision

Das Projekt begann mit der irrwitzigen Idee, 5000 gelbe Gummienten auf einem See, also ohne Strömung, in ein Ziel schwimmen zu lassen. Durch den Verkauf von „Entenlosen“ wollte der Lions Club Friedrichshafen bedürftigen Familien in der Region helfen, die sonst durch die Raster des Sozialstaates fallen. Ein Ziel, dass den Seehasenfestausschuss, die freiwillige Feuerwehr, den THW, die Firmen und Einzelhändler der Region und die Bürger so sehr begeistert hat, dass bereits im ersten Jahr alle Lose verkauft und die volle Summe von 20.000 Euro ausgeschüttet werden konnte. Damit wären wir bei dem ersten Erfolgsfaktor, für ein soziales Projekt: Eine starke Projektvision.

Das erste Rennen – Noch klein, aber es funktioniert

Das Projekt fing natürlich nicht gleich perfekt an, sondern mit einem ersten MVP (Minimum Viable Product). Übersetzt heißt das: eine kleine Version des Rennens, die funktions- und überlebensfähig ist. Die technischen Hürden um Strömung zu erzeugen, die Reihenfolge der einschwimmenden Enten zu registrieren, die Informationen zum Rennen an die Zuschauer zu vermitteln. All das wollte noch mit hohem manuellem Aufwand gemeistert werden. Die Enten waren von einem anderen Club entliehen und wurden am Renntag per Hand aus ihren Säcken gewassert und nach dem Zieleinlauf mit Körben aus dem Wasser gefischt. Das Rennen fand pünktlich statt. Die Enten wurden korrekt registriert. Die Inhaber der Gewinnerlose konnten sich über ihre Preise freuen. Der zweite Erfolgsfaktor für das soziale Projekt ist gefunden: Eine erste Version (ein MVP), die den erhofften Nutzen bereits bringt.

Sukzessive Weiterentwicklung mit vielen engagierten Beteiligten

Nach dem Rennen ist vor dem Rennen. In einer Retrospektive wurde aus Fehlern gelernt und Verbesserungspotenzial zur Skalierung identifiziert. Bei aller Liebe zur Automatisierung bestimmter Abläufe war immer klar: Das darf die Ausschüttung an die Familien nicht schmälern. D.h. alles was Rennen für Rennen investiert werden musste,  brauchte einen Sponsor. Die Preise, eigene Enten für Friedrichshafen, Chips für die Enten zum automatischen Auslesen am Ziel, ein Zieleinlauffloß mit Registrierungssensoren und dieses Jahr erstmals ein Startfloß aus Pontons. All das wäre ohne die Sponsoren und freiwilligen Helfer nicht möglich gewesen, die es zu finden und zu motivieren galt. Der dritte Erfolgsfaktor heißt also: Intensives Stakeholdermanagement.

Alle machen mit

Ein soziales Projekt dieser Größenordnung lässt sich nur umsetzen, wenn alle an einem Strang ziehen. Dazu gehört der „Product Owner“, der die Idee ins Leben gerufen hat und seit zwölf Jahren weiterentwickelt. Ebenso wichtig ist das Kernprojektteam, das sich um Planung,  Akquise der Preise, Vorbereitung der Lose, Umsetzung organisatorischer und technischer Anpassungen, Verkauf der Lose, sowie die technisch organisatorische Umsetzung des Rennens und der Preisverteilung kümmert. Dazu kommen Seehasenfestausschuss, freiwillige Feuerwehr und THW, ohne die die Organisation unmöglich wäre. Die Sponsoren von Preisen und notwendigen Investitionen. Die ehrenamtlichen Helfer und Einzelhändler, die die Lose verkaufen. Und nicht zuletzt die vielen engagierten Bürger, die jedes Jahr ihre Lose kaufen. All diese Menschen zusammen machen den Erfolg des Sozialprojektes aus. Damit wären wir bei dem vierten und vielleicht wichtigsten Erfolgsfaktor für Projekte: ein starkes Commitment aller Beteiligten.

Erfolgsfaktoren für Softwareprojekte

In Softwareprojekten sind zunehmend agile Vorgehensweisen die Arbeitsmodelle der Wahl. Man verspricht sich durch ein iteratives Vorgehen eine Verringerung der Projektrisiken. Häufig wird Scrum mit seinem einfachen und gut durchstrukturierten Rahmenwerk aus Rollen, Meetings und Artefakten als Basis verwendet. Inzwischen gibt es viele Projektmanagement Tools auf dem Markt, die ein solches agiles Vorgehen unterstützen. Trotzdem – oder vielleicht gerade deswegen – beobachten wir immer wieder, dass gerade in großen Projekten ein paar wichtige Bausteine für erfolgreiche Softwareprojekte wieder mehr in den Hintergrund geraten:

  • Das Einschwören des Teams auf eine gemeinsame Produktvision.
  • Der unbedingte Wille aller Beteiligten, den Nutzen jeder Iteration zu erreichen.
  • Transparenz und intensives Einbeziehen der Stakeholder außerhalb des Kernteams.
  • Die Zentrierung auf die Interaktion der Menschen im Projekt.

Mein Fazit:

Es lohnt sich als Kunde, Projektmanager oder Sponsor eines Softwareprojektes mal über den Tellerrand zu schauen und sich wieder auf vernachlässigte Werte zu besinnen. Und wenn im Projekt alles so läuft wie es soll, muss man das nicht als selbstverständlich nehmen und darf den Erfolg auch mal feiern.

Mob Testing: Kollaboratives Testen und Wissenstransfer

Als Test Manager, der vor allem fachliche, manuelle Tests betreut, habe ich insbesondere ein Thema des diesjährigen German Testing Days in Frankfurt mitgenommen: Mob Testing aus einem Vortrag von Katharina Warak und Benedikt Wörner (beide Maiborn Wolff).

Beim Mob Testing handelt es sich um eine kollaborative explorative Testmethode. Kollaboratives Testen hat per se schon den Vorteil, dass mehrere Tester einfach mehr sehen. Dies ist jedoch nicht der einzige Vorteil, den Mob Testing zu bieten hat.


Doch zunächst einmal zur Vorgehensweise:

Beim Mob Testing gibt es folgende vier Rollen, die möglichst cross-funktional besetzt sein sollten (Projekt Manager, Fachbereich, Entwickler, Anwender, Tester, …):

  • Facilitator: beobachtet die Testsession, notiert die gefundenen Abweichungen (Findings) und achtet darauf, dass Regeln und Zeit eingehalten werden. Diese Rolle wird innerhalb einer Session als einzige nicht ausgewechselt.
  • Navigator: bestimmt die Vorgehensweise und gibt dem Driver Anweisungen.
  • Driver: führt die Anweisungen des Navigators aus, ohne sie infrage zu stellen oder mitzureden. Und das ist nicht so einfach, wie es klingt.
  • Mob: zwei bis fünf Personen im Mob beraten (auf Anfrage) den Navigator.

 

Mob Testing doubleSlash Christian Spohr
Bild: doubleSlash Christian Spohr

Nach einer fest definierten Zeit (meist zwischen 4 und 7 Minuten) werden die Rollen durchgewechselt, immer in der gleichen Reihenfolge. Je nach Größe des Teams wird also jeder mehrere Runden im Mob sein, aber immer nur einmal in Folge Navigator oder Driver.


Mob Testing bietet zahlreiche Vorteile:

  • Vier(oder mehr)-Augen-Prinzip: Mehr Tester entdecken mehr Fehler und kommen im explorativen Test auf mehr Ideen, auch abseits der Standardprozesse zu testen.
  • Vielfältige Perspektiven: Wenn die Besetzung des Test-Teams möglichst breit gefächert ist, führen die unterschiedlichen Blickwinkel nicht nur zu einer breiter gestreuten Durchführung des Tests, sondern helfen auch, andere Herangehensweisen bzw. Perspektiven als die eigenen kennenzulernen.
  • Wissenstransfer: Durch die unterschiedlichen Blickwinkel und Vorgehensweisen wird auch Wissen gestreut. Beispielsweise sieht ein Entwickler, wie der Fachbereich mit der Applikation umgeht und entwickelt ein Verständnis dafür und umgekehrt.
  • Interdisziplinär: Die Kommunikation zwischen den Teilnehmern und damit ihren Arbeitsbereichen wird gefördert.
  • Group Thinking: Aus dem gemeinsamen Erlebnis von Problemstellungen und daraus resultierenden Anforderungen zieht das Team an einem Strang und findet sich leichter in einer gemeinsamen Lösung wieder.
  • Rotation: Eher zurückhaltende Kollegen finden sich ohne großen Stress in einer Rolle wieder, in der sie Entscheidungen treffen (als Navigator). Andere, die sonst eher im Vordergrund stehen, müssen damit leben, nur auf Nachfrage zu beraten (in der Mob-Rolle) oder Dinge wider (vermeintlich) besseren Wissens durchzuführen (als Driver).
  • Nicht zuletzt: eine Mob Testing Session macht Spaß! Für viele Beteiligte ist das ein Raus-aus-der-Routine, etwas Neues kennenlernen – und der Zusammenhalt wird gestärkt.

 

Mob Testing bietet sich an:

 

  • als ganzheitlicher Prüfstand für ein Produkt.
  • als regelmäßiger Event, um allen im Projekt Beteiligten das Produkt, an dem sie arbeiten, greifbar zu machen und up to date zu bleiben. Das betrifft auch Bereiche, an denen sie in ihrer täglichen Arbeit selbst nicht tätig sind.
  • als Einführung für Kollegen, die neu in ein Projekt / Team kommen. So lernen sie das Produkt auf einfache Art und Weise praktisch kennen.

 

Ich bin sehr gespannt, wie sich Mob Testing in unterschiedlichen Projekten bewährt. Im Gespräch mit Entwickler-Kollegen hat sich übrigens herausgestellt, dass sie dieses Vorgehen in ihren Coding Dojo Sessions ebenfalls anwenden, um so Wissen im Bereich Softwareentwicklung zu verteilen.
Ich denke, diese vielversprechende Methode ist so vielseitig einsetzbar, dass es sich lohnt, sie als Option zu betrachten, wenn es um Tests oder Wissenstransfer in unterschiedlichen Bereichen geht.

Mehr zu Testmanagement erfahren

 

Agile Starthilfe für Konzern IT´s – Warum die agile Transformation im Unternehmen gar nicht so leicht ist

Agile Starthilfe für ProjekteStudien zur Verbreitung agiler Methoden[1] haben ergeben, dass sich agiles Projektmanagement in den Unternehmen immer mehr durchsetzt. Aus IT Abteilungen von Konzernen wird uns in letzter Zeit sogar berichtet, dass sie inzwischen alle IT-Projekte agil abwickeln müssen. Gleichzeitig tut sich die Konzern IT schwer, ihre Softwareprojekte flächendeckend auf agil umzustellen. Wir beobachten das mitunter daran, dass wir gerade jetzt vermehrt Anfragen nach „agilen Starterpaketen“ für Softwareprojekte erhalten. Warum ist das so?

 

Mehr

DevOps Kultur: Wenn Teams die Prinzipien der agilen Softwareentwicklung ernst nehmen

Wie können Entwicklung und Betrieb im Rahmen von moderner Softwareentwicklung erfolgreich miteinander verbunden werden? Das war Thema auf einer Veranstaltung des Agile Table in Kooperation mit der deutschen Gesellschaft für Projektmanagement (GPM) bei doubleSlash. Die beiden Referenten Alexander Birk und Christoph Lukas, beide seit 18 Jahren als Freiberufler unter dem Namen pingworks tätig, brachten ihre langjährige Erfahrung in der Softwareentwicklung mit ein und stellten die Prinzipien und Herausforderungen einer DevOps Kultur vor.

Mehr

Scrum: Ein Reality Check

Es lässt sich mittlerweile statistisch gut belegen, dass Projekte die agile Methoden einsetzen signifikant erfolgreicher sind als Projekte, die ein klassisches Projektmanagement nutzen [1]. Daher verwenden auch wir in vielen Kundenprojekten agile Vorgehensweisen, von denen Scrum eine der populärsten und am weitesten verbreiteten Methoden ist.
Die Realität zeigt jedoch, dass die überwiegende Mehrheit der Projekte von einem durchgängig agilen Vorgehen abweichen.Mehr

Agiles Arbeiten mal anders: Scrum Cooking mit dem ZF Innovationsmanagement

Lehrreich, lecker, lustig – ein kulinarisches Vergnügen mit Mehrwert war der Scrum Cooking Workshop zusammen mit dem ZF Innovationsmanagement im exquisiten Fränkel Kochstudio in Friedrichshafen. Neben einem gemeinsamen Teamevent sollte der Workshop vor allem die Frage nach bewährten Methoden aus der Softwareentwicklung beantworten – und wie sich diese auf Hardware-Entwicklungsbereiche übertragen lassen.Mehr