Beiträge

Die Scrum Rollen – Ein Überblick

Jeder, der sich mit dem Thema Scrum und dessen Einführung auseinandergesetzt hat, hat sich schon mit einer der grundlegendsten und elementarsten Frage des agilen Framework beschäftigen müssen. Welche Rollen gibt es bei Scrum und welche Aufgaben haben diese inne? In diesem Blogartikel bekommen Sie einen kompakten Überblick über die Rollen in Scrum und deren wichtigsten Funktionen im Team.

Der Product Owner: Der Wertmaximierer

Der Product Owner – oder auch PO – sorgt dafür, dass das Team den größtmöglichen Mehrwert in jedem Sprint schafft. Er repräsentiert die Stakeholder sowie das Unternehmen hinter dem Produkt und sorgt dafür, dass dieses in jedem Sprint einen optimalen Wertgewinn erfährt.

Seine Aufgabe ist es, die Anforderungen der Stakeholder sowie Produktsponsoren zu kennen und diese sinnvoll an das Scrum Team heranzutragen. Das Ziel ist es mit diesen Informationen das Produkt möglichst optimal zu gestalten und neue Features und Fixes im Sinne der Stakeholder und der Produktoptimierung zu priorisieren.

Diese Priorisierung ist eine seiner elementarsten Aufgaben um Abhängigkeiten und Hindernisse im Produkt zu minimieren und gleichzeitig wichtige Funktionen schnell zu realisieren, um den Wert des Produktes für die Nutzer und Nutzerinnen und das Unternehmen zu maximieren.

Durch die ständige Iteration des Produktes und des Backlogs im Scrum Frameworks ist es für den Product Owner deshalb auch wichtig, auf neue Anfragen im Rahmen des Stakeholdermanagements möglichst schnell zu reagieren. Um Markt- und Strategieänderungen schnell in das Produkt und in das Scrum Team zu tragen, wird das Backlog ständig neu priorisiert.

Weiterhin ist der Product Owner auch für folgende Bereiche zuständig:

  • Verwaltung des Product Backlogs: Wie bereits beschrieben, ist der PO für die Priorisierung, Erweiterung, Reduktion und Planung des Produkt Backlogs zuständig. 
  • Release-Management: Der Product Owner ist dafür zuständig zu entscheiden, wann welches Inkrement des Produktes released werden soll. Selbst wenn das Team per Continuous Delivery & Integration arbeiten sollte, ist es am Ende der PO, der den Releaseprozess eines Inkrementes abbrechen oder genehmigen kann.
  • Stakeholder-Management: Eine weitere Aufgabe des Product Owners ist es mit den Stakeholdern wie Benutzern, Kunden, Unternehmensführung oder/und leitenden Angestellten zusammenzuarbeiten um zu gewährleisten, dass das Scrum tatsächlich einen Mehrwert schafft, der den Ansprüchen und Bedarfen der Stakeholder entspricht. Dafür ist eine intensive Kommunikation und Absprache nötig.

Der Scrum Master: Servant Leadership

Der Scrum Master sorgt in erster Linie dafür, dass das Scrum Framework und dessen Regeln im Team eingehalten und umgesetzt werden. Er ist der “Scrum-Botschafter” im Team und coacht dieses kontinuierlich, um den Prozess zu optimieren und facilitieren. Dabei nimmt er die Rolle als “Servant Leader” im Team ein und unterstützt das Team von innen heraus, mit dem Ziel mögliche Hindernisse im Sprint und im Team zu beseitigen.

Dem Product Owner hilft er dabei, als Coach das Backlog zu verwalten und eine sinnvolle und enge Kommunikation mit den Stakeholdern auf den Weg zu bringen. Währenddessen unterstützt er das Scrum Team generell dabei, sich auf die Arbeit zu konzentrieren, indem er Blockaden von innen und außen löst und dafür sorgt, dass die Scrum-Events stattfinden.

Dabei liegt der Fokus des Scrum Masters auf folgenden Bereichen:

  • Transparente Arbeitsweise: Der Scrum Master sorgt dafür, dass der Scrum Prozess und die Arbeit im Team transparent gehalten wird. Dafür nutzt er beispielsweise Confluence-Seiten oder JIRA-Dashboards.
  • Selbstorganisation: Die Selbstorganisation des Teams ist ein zentraler Punkt des Scrum Frameworks. Der Scrum Master sorgt dafür, dass das Team sich crossfunktional selbst organisiert und die damit verbundenen Risiken und Anpassungsprozesse erfolgreich bewältigt.
  • Wertevermittlung: “Mut, Fokus, Engagement, Respekt und Offenheit” das sind die 5 Grundwerte von Scrum, die es braucht, um erfolgreich agil zu arbeiten. Als Scrum Botschafter im Team sorgt der Scrum Master dafür, dass diese im Team gelebt werden.

Die Developer: Crossfunktionales Expertenteam

Die “Developer” sind diejenigen, die im Sprint die Arbeit am Produkt verrichten. Dabei meint “Developer” nicht ausschließlich den klassischen Entwickler in der IT, sondern umfasst jede Person, die an einem Produkt mitwirkt.

Die Developer sind dabei crossfunktional aufgestellt. Das heißt, dass alle Kompetenzen die im Scope der Produktentwicklung und des Testings liegen auch innerhalb der Developer vertreten sein sollten. Das können neben Entwicklern auch beispielsweise Marketingfachkräfte, Compliance-Berater, Illustratoren und UI/UX-Designer sein. Wichtig ist nur, dass alle Kompetenzen für die Entwicklung des Produktes im Team verteilt liegen.

Die Developer sollten dabei selbst organisiert arbeiten und die Entscheidungen wie sie etwas erledigen frei treffen können. Im Rahmen der Priorisierung durch den PO haben die Developer meist freie Hand, wie sie ein Problem erledigen, solange sie alle Akzeptanzkriterien zum erfolgreichen Abschluss der Story erfüllen.

Der Fokus der Developer liegt dabei auf:

  • Selbstorganisierte Fertigstellung von Aufgaben im Sprint Backlog.
  • Gewährleistung von Transparenz über Blocker und Fortschritt in den diversen Scrum Events (Daily Scrum, Retrospektive, Review,…)

Der Erfolg von Scrum

Nur wenn diese drei Rollen Hand in Hand zusammenarbeiten und ihre Aufgaben erfüllen, kann Scrum auch in Ihrem Unternehmen ein Erfolg werden. Jede einzelne Person im Scrum-Framework ist eine Säule für den gesamten Prozess und dessen Erfolg. Damit Sie dieses Ziel erreichen können, lohnt es sich einen Agile Coach schon vor der agilen Transformation ins Boot zu holen, damit dieser die Teams coachen und Ihren agilen Change erfolgreich gestalten kann.

Gerne unterstützen wir Sie bei der Etablierung und Weiterentwicklung der Scrum Rollen in Ihrem Unternehmen. Sie können dazu hier direkt Kontakt mit uns aufnehmen.

Agile Ants Product Lab – Von der Produktidee zum Minimum Viable Product

Sie haben eine Produktidee und möchten diese schnell umsetzen, wissen aber nicht genau welcher Aufwand und welche Kosten auf Sie zukommen?

Viele Projekte werden nach dem klassischen Wasserfallprinzip geplant. So wird das ganze Projekt am Stück definiert, in aufeinander aufbauende Phasen eingeteilt und umgesetzt, ohne die Möglichkeit der späteren Revision einer Phase. Viele gute Ideen und ein großzügiges Budget motivieren das Team mit voller Kraft in das Projekt zu starten. Jedoch kristallisiert sich oftmals nach einigen Monaten der Arbeit heraus, dass ungeklärte Fragen und überraschende Probleme aufkommen, die die geplante Markteinführung weit zurückwerfen. Zudem können sich während der Entwicklungsphase Rahmenbedingungen grundlegend ändern (z.B. technologische Weiterentwicklungen oder Marktgegebenheiten).

An dieser Stelle können viele Entscheidungen schwer rückgängig gemacht werden und das Projekt kostet deutlich mehr Zeit und Geld als ursprünglich geplant.

Solche Probleme entstehen häufig dann, wenn man schnell das fertige Produkt liefern möchte, ohne genau zu wissen, welche Komplexitäten lauern. Außerdem ist die schnelle Fertigstellung eines Produktes, das bereits im ersten Release seine volle Marktreife besitzen soll, schwierig. Deutlich effektiver ist es ein Projekt in kleineren Iterationen aufzubauen, um Fehler schnell aufzudecken oder sogar zu vermeiden. Außerdem kann dann auf Erkenntnisse, die “entlang des Weges” entstehen, einfacher reagiert werden.

Ebenso die Frage was wann budgetiert werden muss, kann eine große Hürde darstellen. Welche Größe sollte das Sparschwein haben, welche Kosten können vermieden werden und welche sind unbedingt notwendig?

Auch der zeitliche Aspekt spielt eine wichtige Rolle, denn bei der Produktentwicklung darf die Dauer des Prozesses bis zur Marktreife nicht unterschätzt werden. Je mehr Features das Produkt haben soll, desto mehr Zeit muss investiert werden.

So stellen sich Unternehmern häufig unterschiedliche Fragen, wenn es um eine neue Idee geht: Haben wir die nötige Expertise? Können wir die Kosten stemmen? Wird unsere Idee auf dem Markt funktionieren? 

Am liebsten würde man in eine Kristallkugel schauen und sich diese Fragen im Voraus beantworten lassen, um mit seiner Produktidee auf der sicheren Seite zu sein. Die gute Nachricht ist – es bedarf keiner gläsernen Kugel, sondern der richtigen Methode eine strukturierte Planung des Projekts aufzustellen und eines Teams, das Experte auf diesem Gebiet ist.

Die Lösung

Es gibt unterschiedliche Lösungsansätze für das Vorgehen in der Produktentwicklung. Bei der sogenannten iterativen Entwicklung wird das gesamte Projekt in kleinere Iterationen geteilt. Dabei ist jede Iteration ein in sich geschlossener Prozess und liefert als Ergebnis einen funktionierenden Zwischenstand des Produktes. Dieser wird anschließend vom Team anhand der Anforderungen auf Qualität geprüft und in der folgenden Iteration weiter ausgebaut. Ein Produktentwicklungs-Team spielt dabei eine entscheidende Rolle, um das Projekt strukturiert voranzutreiben.

Das Agile Ants Product Lab

In unserem Agile Ants Product Lab konkretisieren wir Ihre Idee und setzen sie schnell und kostengünstig in eine erste Version um – so entsteht das sogenannte „Minimum Viable Product“ (MVP).

Wie sieht das in der Praxis aus?

Schritt 1: Der Design Sprint

Im Verlauf eines bis zu 5-tätigen Design Thinking Workshops spezifizieren wir Ihre Produktidee gemeinsam mit Ihren Experten. Am Ende des Workshops entsteht ein erster Prototyp und wird einer potenziellen Zielgruppe vorgestellt um herauszufinden, ob das Produkt Potenzial am Markt hat. 

Schritt 2: Das Backlog Building

Im Anschluss eines erfolgreichen Design Sprint Ergebnisses definieren wir gemeinsam ein Product Backlog. Das heißt wir halten die für Sie essentiellsten Produktanforderungen und Abnahmekriterien fest. Zusätzlich definieren wir den Umfang des ersten Entwicklungsschrittes. Wir legen dabei Wert darauf, dass die Iteration klein genug ist, um sie schnell umzusetzen, aber gleichzeitig so detailliert gestaltet, um den Nutzen des Produkts vermitteln zu können.

Schritt 3: Die MVP Entwicklung

Unser Ziel ist es zusammen mit Ihnen ein MVP zu entwickeln, das einen hohen technischen Reifegrad besitzt, jedoch einen minimalen Funktionsumfang hat, der iterativ erweitert wird. So realisieren wir eine kurze „Time-to-market“ und können kontinuierlich auf dieser ersten Version aufbauen.

Im Agile Ants Product Lab schaffen wir einen für Sie berechenbaren finanziellen Rahmen, indem wir Ihnen die ersten zwei Schritte zum Festpreis anbieten. Zum anderen machen wir transparent wie viel Zeit und Ressourcen die Entwicklung Ihrer Produktidee in Anspruch nimmt. So wird das gesamte Projekt besser kalkulierbar.

Wir helfen Ihnen bei Ihrer Produktentwicklung – Ganz unkompliziert und in kleinen Iterationen. Das schafft schnelle Ergebnisse bei geringem Investitionsrisiko.

Schon morgen könnten wir mit Ihrer Produktidee starten!

Falls Sie Interesse an einem unverbindlichen Gespräch haben, schauen Sie gerne auf unserer Homepage vorbei oder kontaktieren Sie uns direkt.

Zeche Zollverein – Unser altes und neues Hauptquartier

Am 01.04.2021 war es so weit: Die AGILE ANTS zogen in ein neues Büro, damit verdoppeln wir unsere Bürofläche gegenüber den alten Räumlichkeiten. 

Wir bleiben der Zeche Zollverein und dem Triple-Z treu, darum heißt es bei unseren Posts auch weiterhin #grussvonnezeche. 

Unser neues Büro liegt in einem besonderen Gebäudeensemble auf dem Gelände von Zollverein, den „Steigerhäusern“.

Unsere postalische Adresse ändert sich nicht. Wir haben nur mehr Platz für Ihre und unsere Ideen, sowie für weitere Kolleginnen und Kollegen.

4 spannende Fakten über Zeche Zollverein

1. Das Wahrzeichen

Das markante Doppelbock-Fördergerüst gab der Zeche Zollverein die liebevolle Bezeichnung „Eiffelturm des Ruhrgebiets“ und gilt als Wahrzeichen der Region. 

2. Tourismus-Magnet

Das 100 Hektar große Industriegelände ist eine interessante Touristenattraktion und kann täglich mit einem Bus besichtigt werden. Wenn Corona es wieder zulässt planen auch wir einen kleinen Teamausflug.

3. Kultur und Design

Nicht nur Büros, wie unseres, haben hier ihren Platz gefunden, die Zeche Zollverein ist zu einem Kultur- und Designstandort geworden. So findet man hier neben zahlreichen Ausstellungen auch das Museum des „Red Dot Awards“.

4. Freizeitaktivitäten

Ein besonderes Highlight erwartet die Besucher im Winter – auf einer weitläufigen Eisbahn kann man zwischen den Industriegebäuden entlang cruisen und das Gelände erkunden. Im Sommer wiederum lädt das Werksschwimmbad zu einer Abkühlung nach dem Feierabend ein.

In einer Zeit ohne Corona ziehen unterschiedliche Veranstaltungen und Konzerte die Zeche-Besucher an und sommerliche Temperaturen locken Spaziergänger, Jogger sowie Radfahrer auf die Ringpromenade rund um das Gelände.

Wir sind stolz darauf, Teil dieses besonderen Ortes zu sein und laden herzlich zu einem Besuch der Zeche Zollverein in Essen ein!

TEAMBUILDING DIGITAL – WELCHE MÖGLICHKEITEN GIBT ES, UM DEN TEAMSPIRIT ZU STÄRKEN?

Teamevents und -aktivitäten waren vor Corona nicht aus dem Arbeitsalltag wegzudenken. Sie waren ein wichtiger Grundbaustein für ein gesundes Teambuilding und eine spannende Abwechslung zum Arbeitsalltag. Doch momentan befinden sich viele Mitarbeiter:innen durch die COVID-19 Situation im Homeoffice und das persönliche Zusammenkommen in den Teams ist auf ein Minimum reduziert.

Umso wichtiger ist es, auch in der heutigen Zeit viel Wert auf Teambuilding und Aktivitäten zu legen – doch wie kann man das online und remote am besten gestalten?
Dafür haben wir hier eine Sammlung an spannenden und abwechslungsreichen Remote- und Onlineaktivitäten vorbereitet. Damit klappt das nächste digitale Offsite oder Teambuilding auch bei Ihnen.

1. Klassische Teambuilding Aktivitäten remote gedacht

Social Beer

Das Social Beer ist eher ein klassischer Ansatz zu einer Remoteaktivität für das Team. Man sucht sich einen Abend, an dem das Team Zeit hat und organisiert für diesen Abend ein sogenanntes “Social Beer”. Der Abend an sich hat kein – oder nur ein kleines – Rahmenprogramm. Hier geht es eher darum den persönlichen und privaten Austausch untereinander zu fördern. Kaltgetränke sind natürlich erwünscht, auch nichtalkoholischer Natur. 

Virtual Book Club

Der Virtual Book Club schafft eine Plattform dafür, sich über fachlich relevante, aber auch über Bücher auszutauschen, die mit der Arbeit nichts zu tun haben. Dabei gibt es zwei Möglichkeiten den Book Club durchzuführen. Entweder stellen alle Teilnehmenden ein Buch vor, das sie momentan lesen und sprechen Empfehlungen aus und diskutieren über ihre Lieblingsbücher. Die andere Möglichkeit wäre, als Book Club gemeinsam eine Lektüre zu selektieren und diese dann kapitelweise zu lesen und im Book Club immer das Kapitel der letzten Woche zu besprechen und intensiv zu diskutieren.

Online Escape Room

Der Escape-Room ist eine beliebte Teambuildingaktivität. Und das zu Recht. Umso besser, dass es jetzt auch sogenannte “Online Escape-Rooms” gibt, die den Spaß eines Escape-Rooms absolut coronakonform und remote an den eigenen Schreibtisch bringen. Man braucht keine besondere Ausstattung, alles, was man für so einen Online Escape-Room braucht, wird vom gängigen Homeoffice-Equipment mehr als abgedeckt. Es gibt diverse Anbieter für solche Online-Escape Rooms – und auch wenn es erst befremdlich wirken mag: Unsere Erfahrungen damit waren sehr spaßige Abende für das ganze Team.

Online Team Dinner

Das Online Team Dinner ist im Prinzip eine Erweiterung des Social Beers. Mit wenig Rahmenprogramm sollen hier Gespräche und der private Austausch im Team gefördert werden. Was das Online Team Dinner vom Social Beer unterscheidet, ist der Dinner-Part. Für den Abend bereiten alle Team-Mitglieder ihr Dinner vor – und essen dieses gemeinsam in einem virtuellen Raum. Wer das Ganze noch ein bisschen spannender machen will, der kann den gemeinsamen Abend schon beim Kochen starten. 

GIF-War

Eine kleine aber spannende Ergänzung an dieser Stelle ist der “GIF-War”. So nutzt man einen Channel in einem IM-Dienst wie bspw. Slack und täglich oder wöchentlich zum Feierabend haben alle Teammitglieder 10 Minuten Zeit gemeinsam das beste GIF zu einem bestimmten Thema zu posten. Wer das Ganze ein wenig ernsthafter betreiben will, kann über Reaktionen auch einen wöchentlichen Gewinner küren und ein Leaderboard einführen.

2. Spielerische Aktivitäten

Risiko

Das Spiel Risiko eignet sich wunderbar, auch langfristig angelegt für eine kleine Teamauszeit vom Arbeitsalltag. Entweder man spielt eine Partie gemeinsam am Stück – vielleicht ja im Rahmen eines Social Beers – oder man legt die Partie so an, dass man jeden Tag pro Person einen Zug ausführen kann, sodass die Partie Risiko zu einem Dauerbrenner im Team wird.

Dungeons and Dragons

Für die Rollenspiel-Fans unter uns eignet sich das Pen-and-Paper Spiel “Dungeons and Dragons” für spannende und vielseitige Teamabende. Die Regeln sind für Anfänger relativ gut verständlich und mit erfahreneren Spielern an der Seite ist eine Menge Spaß vorprogrammiert. Auch hier kann man eine langfristige Kampagne über mehrere Wochen anlegen oder sich dazu entschließen erst einmal nur zwei bis drei Sessions zu spielen. 

Among Us

Among Us hat das Netz im Sturm erobert – und das zurecht. Es ist kurzweilig und ist extrem zugänglich. Während eine Raumschiff-Crew versucht ein Raumschiff im All zu reparieren, sind unter ihnen sogenannte “Imposter”, die versuchen ihren Fortschritt zu sabotieren und die Crew nach und nach zu dezimieren. Wenn die Leiche eines Crewmitgliedes auftaucht, kann ein Notfallmeeting einberufen werden und Personen können aus dem Spiel gewählt werden. Die Crux: Niemand kann sich sicher sein, wer unter ihnen der Verräter ist. Wird die Crew überleben und die Imposter finden oder werden die Imposter sie vorher komplett ausgelöscht haben?

Scribbl.io

Bei Skribbl.io werden abwechselnd Begriffe gezeichnet (bzw. gescribbelt), das Team muss raten, welcher Begriff sich hinter dem Gekritzel verbirgt.
Klingt einfach, ist aber verdammt knifflig, zumal gegen die Uhr gespielt wird.

Bei Skribbl.io Sessions haben wir oft das Phänomen, dass die Teams kein Ende finden und immer “noch eine Runde” spielen wollen.

Virtual Boardgame Group

Für alle (virtuellen) Brettspiele, die auf einer regelmäßigen Basis oder auch einmalig als Event gespielt werden sollen, können sich Interessierte in einer Virtual Boardgame Group austauschen. Hier bespricht man miteinander virtuelle Brettspiele, tauscht Empfehlungen aus oder plant einfach mal eine gemeinsame Runde in einem Spiel der Wahl.

Virtual Game Group

Eine weitere Idee, um Aktivitäten im Unternehmen – auch bereichsübergreifend – im virtuellen Raum zu fördern, ist eine Virtual Game Group. Diese dreht sich rund um den Austausch zum Thema Videospiele und die Planung gemeinsamer Spieleabende. 

Nach unserer praktischen Erfahrung können die oben beschriebenen Teamaktivitäten, gerade in der aktuellen kontaktarmen Zeit, dazu beitragen den Teamspirit aufrecht zu halten bzw. weiter zu verbessern.

Wenn Sie weitere Fragen zur Umsetzung von Online-Teamaktivitäten oder zur erfolgreichen Umsetzung von agilen Projekten haben, kontaktieren Sie uns gerne unter contact@agile-ants.com

TESTEN IN AGILEN PROJEKTEN

Agile Softwareprojekte folgen besonderen Methoden, um Software anwenderzentrisch und iterativ zu entwickeln (ein paar Ansichten zu Sinn und Unsinn agiler Methoden: https://agile-ants.de/2019/11/27/alles-agil-oder-was/). Agiles Arbeiten führt zu schnelle Feedbackzyklen zwischen Entwicklungsteam und Product Owner und damit auch zu häufigen Lieferungen neuer Software Artefakte.

Potentiell produktionsreife Software mit jedem Sprint

In Scrum ist das Ziel jedes Sprints die Umsetzung der User Stories, auf die sich das Team zu Beginn des Sprints committed hat. Somit wird zum Ende jedes Sprints ein Stück Software geliefert, das diese neu umgesetzten Funktionalitäten beinhaltet.

Das bedeutet auch, dass dieses Sprint Artefakt einen Qualitätsanspruch haben sollte, der einem produktionsreifen Zustand entspricht (“potentially shippable”). Um dies zu erreichen, muss das Testen der Software fest in der Entwicklung verankert werden und in der Verantwortlichkeit der Entwicklungsteams liegen.

“Shift left” pattern

Je später im Entwicklungsprozess ein Bug gefunden wird, umso mehr Schaden (Kosten, Projektrisiko, Zeitverzögerungen, Verlust an Reputation) entsteht für das Unternehmen. Organisationen sollten also bestrebt sein, Fehler möglichst früh im Entwicklungsprozess zu finden und beheben. Das klingt zunächst logisch. 

Dennoch organisieren viele, auch agile, Projekte ausgerechnet ihre Testphasen nach dem Wasserfallprinzip: Erst wenn alle zu testenden Lösungsbausteine verfügbar sind finden zwei- bis dreimal jährlich groß angelegte Testvorhaben und komplexe Staging-Orgien statt.

Leider macht man auf diese Weise beim Thema Testen einen Teil der gewonnenen Agilität des Entwicklungsprozesses wieder zunichte. Funktionale Anforderungen werden im jeweiligen Sprint entwickelt und im Sprint Review abgenommen. Das umfangreiche Testen von funktionalen und – insbesondere auch – nichtfunktionalen Anforderungen wird jedoch oft asynchron zum Sprint oder einfach “irgendwann später” gemacht.

Man verschenkt zudem die Möglichkeit, die man durch das häufige Testen kleiner Inkremente hat: Frühzeitiges Erkennen und Beheben von Bugs und Verhinderung von Fehlerkaskaden, also unerkannte Fehler, die Folgefehler mit sich bringen (und deren Analyse meistens aufwendig und zeitraubend ist).
Daher streben agile Teams das “Shift left” Pattern an, also das Heranrücken der Testaktivitäten an den Entwicklungsprozess, der ganz links, also am Anfang einer Iteration steht, daher “Shift left”.

Regressives Testen

Regressives Testen ist ein fester Bestandteil in agilen Projekten. Es bedeutet, dass man bei der Neuimplentierung einer Funktionalität stets überprüft, ob diese Änderung/Erweiterung am Quellcode nicht zu einem anderen Problem führt. Dies gilt auch für Bugfixes, bei denen manchmal ein Fehler behoben wird und gleichzeitig zwei neue Fehler unbeabsichtigt eingebaut werden. 

Die Häufigkeit der Durchführung macht eine Automatisierung dieser Tests zwingend notwendig, um die Schlagzahl der Testdurchläufe realisieren zu können.

Hoher Automatisierungsgrad

Die Anforderungen an eine entwicklungsbegleitende Qualitätssicherung lassen sich am besten mit einem hohen Grad an automatisierten Test- und Deploymentverfahren bedienen. 

Dabei gilt keinesfalls “Viel hilft viel”, man sollte sich stattdessen vorher Gedanken machen, für welche Softwarekomponenten und Akzeptanzkriterien bestimmte Testarten am sinnvollsten sind. Ausserdem sollte die Wiederholbarkeit im Vordergrund stehen, also Tests die voraussichtlich bei jedem neuen Artefakt neu ablaufen werden.

Für die verschiedenen Testarten, z.B.

  • Unit Tests
  • statische und dynamische Codeanalyse
  • Oberflächentests
  • Schnittstellentests
  • Last- & Performancetests
  • Kapazitätstests

gibt es eine Vielzahl von Tools am Markt, sowohl im kommerziellen Bereich, aber auch als Open Source oder Community Projekt. Wir helfen Ihnen gerne bei der herstellerneutralen Auswahl des geeigneten Tools für Ihr Testvorhaben.

Continuous Integration

Meistens werden diese Tools mit Continuous Integration (CI) Werkzeugen wie Jenkins, Octopus oder Bamboo zu sogenannten Pipelines zusammengestöpselt, um automatisiert und regelmässig die Qualität der Software zu überprüfen. In den Pipelines werden der Ablauf der einzelnen Tools und ihre Parametrisierung festgelegt.

Das Starten der Pipeline kann entweder zeitlich gesteuert (z.B. nächtlich) oder ereignisgesteuert (z.B. bei Einchecken von Quellcode im Repository) erfolgen.

In einer erweiterten Variante einer CI-Pipeline kann auch die Auswertung der Testergebnisse anhand von vorher festgelegten Key Performance Indikatoren (KPIs) automatisch erfolgen, sodass ein manueller Eingriff nur bei Abweichung der Ergebnisse von den KPIs erforderlich ist.

Fazit:

Der Vorteil agiler Softwareentwicklung lässt sich nur dann vollständig heben, wenn man auch das Testen der Software agilisiert.

Testautomatisierung ist einer der Schlüssel zum Erfolg, jedoch für sich genommen keine Garantie für eine erfolgreiche agile Qualitätssicherung. Die konzeptionelle Vorarbeit ist nicht zu unterschätzen, zudem muss das Mindset aller am Projekt beteiligten stimmen.

Sollten Sie Rückfragen oder konkrete Anforderungen in den Bereichen “Agiles Testen” oder “Continuous Integration” haben, helfen wir Ihnen gerne mit unserer umfangreichen Projektpraxis in diesem Umfeld. Nehmen Sie gerne einfach Kontakt mit uns auf.

VERTEILTE TEAMS EFFEKTIV FÜHREN MIT OBJECTIVES & KEY RESULTS

Die Methodik von Objectives and Key Results (OKRs) ist an sich nicht neu: John Doerr brachte sie bereits 1999 bei seinem Jobwechsel von Intel mit zu Google. Der heutige Suchmaschinenriese war damals mit rund 40 Mitarbeitern noch recht überschaubar, hat OKRs aber bis heute im Unternehmen mit immerhin >100.000 Mitarbeitern beibehalten. 
Heute arbeiten viele Startups, aber auch zunehmend Grown-ups (z.B. LinkedIn, Zalando, Spotify) und Corporates mit OKRs, um transparentes Performance Management zu betreiben. 

Man kann also feststellen, dass OKRs durch ihren schlanken Ansatz für kleine Unternehmen gut funktionieren, dennoch gut skalieren und damit auch für grosse Konzerne einsetzbar und nützlich sind. Man kann einfach und schnell innerhalb eines kleinen Teams damit beginnen, ohne gleich das “ganz große Rad” drehen zu müssen.

Das organisatorische Setup ist ebenfalls sehr schlank. Neben den ohnehin beteiligten Akteuren in einem Zielabstimmungsprozess (Unternehmensführung, Führungskräfte, Teams) gibt es noch einen OKR Master, der sich um die Organisation und Einhaltung der OKR Events kümmert und alle Themen und Ergebnisse rund um die OKR Ein- und Durchführung dokumentiert.
Der OKR Master ist keine Führungsrolle, sondern eher als Facilitator zu verstehen, weswegen wir auch den Begriff “OKR Facilitator” für diese Rolle bevorzugen

WAS SIND DIE VORTEILE VON OKRs?

Man könnte auch fragen: “Was ist der Vorteil gegenüber klassischen Zielvorgaben, die es ja schon lange gibt?”. Ganz einfach: Offenheit, Transparenz und Ownership. Zudem fällt es Unternehmen damit oft schwer, klare und nachvollziehbare Ziele abseits kaufmännischer Teams (Vertrieb, Einkauf etc.) zu formulieren.

Offenheit & Transparenz

OKRs setzen sehr stark darauf, dass alle Teilnehmer (Unternehmensführung, Teams) sich ständig über die Richtung des Unternehmens austauschen, diese herunterbrechen (Objectives) und dann anhand messbarer Kriterien (Key Results) überprüfen. Dabei ist die offene und kontinuierliche Kommunikation zwischen den Beteiligten wichtig, ausserdem können alle Beteiligten sehen, welche OKRs andere Akteure haben. 

Wenn man die Ziele von Kollegen/Teams kennt, versteht man eher, warum sie tun, was sie tun. Ausserdem erfahren die Mitarbeiter eine vollkommen andere Wertschätzung, weil sie in den Prozess der Zielgestaltung mit eingebunden sind – in Zeiten eines Arbeitnehmermarktes sicherlich nicht verkehrt.

Ownership & Verantwortlichkeit

Bei klassischen Zielformulierungen werden den Teams oft Ziele vorgesetzt. Bei OKRs verstehen die Teams die übergeordneten Ziele (Leitbild und MOALS, siehe nächster Abschnitt) und nehmen sich daraus eigene Teilziele. Daraus ergibt sich eine Summe von Teilzielen, anhand derer wiederum überprüft werden kann, wo sich Lücken zum Gesamtziel ergeben. So kann man steuern, bevor diese Lücken in den Zielen zu Problemen führen.

Durch das eigenverantwortliche Nehmen von Zielen und Ableitung von Teilzielen durch die Teams ergibt sich eine vollkommen andere Verantwortlichkeit, als wenn die Teams das Gefühl haben Ziele “von oben” aufgedrückt bekommen zu haben. Wer kennt sie nicht, die Diskussionen in Zielgesprächen durch diktierte Ziele (“Konnte ja nicht funktionieren, aber ihr habt mir das ja so aufgedrückt” oder “Wenn ihr mir so unrealistische Ziele gebt…”).

WAS SIND DIE KERNELEMENTE VON OKRs?

Vision/Leitbild

Die formulierte Unternehmensstrategie für die nächsten 3-5 Jahre. Die meisten Unternehmen haben dieses Leitbild bereits formuliert. Gerade bei mittelständischen Unternehmen stellen wir aber oft fest, dass es ein gelebtes Leitbild gibt, was aber nirgendwo schriftlich festgehalten ist. Damit sollte man beginnen. Das Leitbild wird von der Unternehmensführung formuliert und den Mitarbeitern vorgestellt (“top down”).

MOALS (Mid-Term Goals)

Die formulierten Unternehmensziele für die nächsten 12 Monate. Die MOALS ermöglichen es den Teams und einzelnen Mitarbeitern entsprechende Objectives abzuleiten. Die MOALS werden von den Führungskräften des Unternehmens formuliert, sollten aber dann gemeinsam mit dem Team diskutiert und ggf. angepasst (z.B. weil unverständlich) werden.

Objectives

Die Objectives werden von den Teams, gemeinsam mit OKR Master und Führungskräften formuliert. Sie können gerne qualitativer Natur sein und ambitioniert formuliert sein (Beispiel: „Mit unserem neuen Produkt XYZ wollen wir bis Ende 2021 Marktführer in Deutschland sein“).

Key Results

Die Key Results werden ebenfalls von den Teams formuliert und mit den Führungskräften im Verlauf eines OKR Plannings vereinbart, Sie müssen klar messbar sein und eine interpretationsfreie Definition zur Erreichung haben („In Quartal 3/2020 wollen wir mindestens 5.000 Subscriber für das Produkt XYZ haben“).

WAS SIND DIE OKR EVENTS?

Wir führen die Events grundsätzlich “time-boxed” durch, das heisst es steht ein fester Zeitrahmen für einzelne Schritte innerhalb des Events zur Verfügung. Damit wird verhindert, dass endlose Detaildiskussionen geführt werden und das Ziel des Meetings aus den Augen verloren wird. Trotzdem kann sich das Team jeweils für eine weitere Timebox entscheiden, falls allen das diskutierte Thema wichtig genug ist. Die Timebox wird vom OKR Master mittels eines Timers visualisiert, damit das Team jederzeit sehen kann, wieviel Zeit noch zur Verfügung steht.
Folgende Events sind elementar für die Umsetzung von OKRs im Team:

OKR Planning

Das Planning dient den Teams dazu, aus den vorgegebenen MOALS ihre Objectives and Key Results abzuleiten. Dies geschieht in Zusammenarbeit mit dem OKR Master und der Führungsebene. Die OKRs werden vom OKR Master in einem Tool (mögliche Tools siehe weiter unten)  festgehalten.

Weekly Check-in

Wöchentliche kurze (ca. 30 Minuten pro Team) Betrachtung, was in der vergangenen Woche geleistet wurde, was für die kommende Woche geplant ist und ob es Hindernisse gibt. Der weekly check-in dient nicht der Detaildiskussion, sondern nur der Klärung dieser drei Punkte. Sollte sich im Weekly herausstellen, dass weitere Details diskutiert werden müssen, organisiert der OKR Master entsprechende Termine im Nachgang.

OKR Review

Im Review zum Ende eines OKR-Zyklus (z.B. Quartal) schauen Team und Führungsebene gemeinsame welche Ziele erreicht wurden wie sich die Erfahrungen im aktuellen Zyklus auf die Zieldefinition im nächsten Zyklus auswirken. Dabei stellt das Team die zuvor vereinbarten OKRs und deren Erreichung vor. Sollten Ziele nicht erreicht worden sein, dienen die Erkenntnisse, die die Zielerreichung verhindert haben, zur Verbesserung der Zieldefinition im nächsten Planning.

OKR Retrospektive

Die Retrospektive dient ausschließlich der Verbesserung des OKR Prozesses und der Zusammenarbeit, sowohl im Team, als auch teamübergreifend. In der Retrospektive werden hingegen keine inhaltlichen Diskussionen zu definierten OKRs geführt.

WIE STARTEN SIE MIT OKRs?

  1. Starten Sie mit einem kleinen Pilotteam!
    Wenn OKRs bei Ihnen funktionieren, wird es schnell genug in die Breite gehen.
  2. Finden Sie mindestens einen erfahrenen „OKR Master“.
    Er dient als Facilitator für die Startphase und mindestens die ersten 1-2 Zyklen. Ausserdem enabled der OKR Master weitere Teams („Train the trainer“). Da der reibungslose Ablauf Frust bei der Einführung von OKRs verhindert, kommt dem OKR Master insbesondere zu Beginn eine wichtige Bedeutung zu. Ein für die Transformation nützlicher OKR Master hat zuvor bereits praktische Erfahrung bei der Einführung von OKRs gesammelt. 
  3. Formulieren Sie eine Vision bzw. ein Leitbild für das Unternehmen.
    Insbesondere bei mittelständischen Kunden existiert dieses in den Köpfen, ist aber oft nicht ausformuliert. Stellen Sie dieses Leitbild dem Pilotteam vor.
  4. Formulieren Sie Moals.
    Oft hilft es dabei sich an den Geschäftsjahreszielen zu orientieren. Hier würden wir empfehlen, das Team bereits aktiv zu involvieren.
  5. Schulen Sie das Pilotteam.
    Ein OKR Kickoff-Workshop macht das Pilotteam mit der Methodik vertraut, ein guter Workshop enthält viele praktische Übungen. Nach unserer Erfahrung verführen schlanke/agile Methoden dazu, die Aufgabe zu unterschätzen und dann zu scheitern, einen Artikel oder ein Buch als Start zu lesen ist nicht genug.
  6. Starten Sie den ersten OKR-Zyklus.
    Er wird sicher nicht perfekt, aber agile Methoden sehen eine ständige Verbesserung vor. Denken Sie daran: „Done is better than perfect“.

VERBREITETE OKR ANTIPATTERNS

Natürlich laufen Dinge schief, wenn man mit OKRs startet. Das ist nicht schlimm, sollte jedoch vom Team und OKR Master verstanden und im Laufe der Zeit ständig verbessert werden. Das sind die “Klassiker”, die uns immer wieder begegnen:

Zu viele Objectives/Key Results:

Es gibt natürlich keine harte Regel für die richtige Anzahl. Unsere Faustformel lautet aber: Nicht mehr als jeweils fünf pro Zyklus.

Zu wenig Abstimmung:

Zum Beispiel keine verbindlichen weekly check-ins, dadurch Verlust von iterativer Verbesserung. Oft lässt die Motivation von einzelnen Teammitgliedern für eine kontinuierliche Teilnahme an den weekly check-ins auf Dauer nach oder wird wiederholt abgesagt (“wichtiger Kundentermin” etc). Hier gilt es nachzusteuern, da der kontinuierliche Abstimmungsprozess sehr wichtig für de nachhaltige Durchführung von OKRs ist.

Falscher Scope 1:

Tasks werden fälschlicherweise als Objectives definiert. Beispiel: „10 Kunden anrufen“; „Modul XYZ entwickeln“. OKRs sollen ja eigentlich aus einer “Command & Control” Organisation herausführen, bei der jeder Handlungsschritt vorgegeben ist und überprüft wird..

Falscher Scope 2:

MOALS oder Mission/Vision werden fälschlicherweise als Objective definiert. 
Beispiel: „Wir wollen Marktführer im Bereich ERP-Systeme werden“
. Daraus lassen sich keine granularen Ziele ableiten, die innerhalb eines Quartals erreichbar sind.

Key Results sind nicht messbar:


Beispiel: „Wir haben das Produkt XYZ am Markt etabliert“. Besser: „Wir haben für Produkt XYZ bis Ende Q4 mindestens 100 Kunden gewonnen“.
 Nur durch messbare Key Results kann im Review ein klarer Abschluss gefunden werden, daher müssen Key Results interpretationsfrei sein.

Verantwortlichkeiten sind unklar:

Das Team oder der Mitarbeiter haben den Eindruck, dass ihnen zur Erreichung eines Ziels notwendige Entscheidungen fehlen oder es bestehen Unsicherheiten, wer zielrelevante Entscheidungen treffen darf/kann/muss. Dadurch wird die Performance von Teams teils erheblich blockiert oder verlangsamt.

Wir setzen gerne Decision Maps und Delegation Poker ein, um klare Absprachen zur Entscheidungsfindung zu treffen, sowie Team Performance und Zufriedenheit massgeblich zu steigern. Mit unserem AGILE ANTS Starter Kit “Decision Map & Delegation Poker” können sie schnell und einfach dieses Thema. Weitere Infos zum Starter Kit finden Sie hier:

TOOLÜBERSICHT

Die nachfolgenden Tools nutzen wir bei AGILE ANTS selber regelmässig im Projektkontext. Die erwähnten Werkzeuge bieten die Möglichkeit zur kostenfreien Evaluierung (nur zur Information, keine Werbung, keine Affiliate-Links!):

Mural

Browser-basiert, damit optimal für verteilte Teams.
Großer Umfang an verschiedenen Templates. Ebenfalls geeignet als digitales Whiteboard, z.B. für Scrum-Sessions oder Ideation bzw. Design Sprints.
Weitere Informationen unter https://mural.co

Workpath

Umfangreiches Tool zum für unternehmensweites Performance Management mit umfangreichen Tracking- und Auswertungsfunktionen.
Unterstützung & Dokumentation von regelmässigen Abstimmungsgesprächen („Checkins“).
Transparente Darstellung der team- und unternehmensweiten Fortschritte.
Weitere Informationen unter https://workpath.com

Confluence

Ein bekanntes und universelles Wiki zur Dokumentation von Informationen.
Confluence lässt sich durch entsprechende Plugins und Templates flexibel erweitern und auch wunderbar für die Einführung von OKRs nutzen. Zudem bietet Confluence weitere nützliche Features Elemente, um Fragen und Ergebnisse zu dokumentieren, z.B. Decision Logs und Meeting Notes.
Weitere Informationen unter https://www.atlassian.com/de/software/confluence

Timeboxing 

Mit “Time timer” als physischer Anzeige der noch verbleibenden Dauer einer Timebox (https://www.amazon.de/Time-Timer-Countdownuhr-Zoll-JAC5008/dp/B000J5OFW0)
Oder als App für iPad (https://apps.apple.com/de/app/time-timer/id332520417).

AGILES ARBEITEN IN VERTEILTEN TEAMS – BEST PRACTICES

Es gibt viele Gründe und Situationen, bei dem sich das Arbeiten mit verteilten Teams lohnt und für Ihren Betrieb eignet. Ob es wirtschaftliche Gründe sind, wie das Einsparen von Zeit im Berufsverkehr oder eine optimalere Auslastung Ihrer Büroflächen oder es sogar – wie im Falle von COVID-19, dem Corona-Virus, der Sicherheit der Angestellten gilt.

Doch die Arbeit in verteilten Teams bringt einige Herausforderungen mit sich, besonders, wenn diese verteilten Teams agil arbeiten. Wichtig an dieser Stelle ist es, dass das Mindset starke Kommunikation, Koordination und Transparenz reflektiert und auch remote so gelebt wird, wie bei den agilen Teams vor Ort.

Weiterhin ist es wichtig zu wissen, dass ein agiles verteiltes Team mit den richtigen Tools und Kommunikationstechniken dieselbe Produktivität an den Tag legen kann wie sein lokales Komplementär. Was Sie dazu benötigen, erklären wir in diesem Artikel.

WIE KÖNNEN SIE VERTEILTE TEAMS OPTIMAL KOORDINIEREN?

  • Nutzen Sie Videokonferenzen.
    Videokonferenzen ermöglichen es Ihnen, die Emotionen und Gesten Ihres Gegenübers zu erkennen und lassen dem Team die Möglichkeit von non-verbaler Kommunikation offen. Weiterhin wird durch ein Bild des Gegenübers im Gespräch ein besseres Verhältnis im Team geschaffen.Es heißt ja nicht umsonst: “Ein Bild sagt mehr als tausend Worte”.
    Es gibt heute viele günstige oder kostenlose Tools, die es ermöglichen effizient Videokonferenzen abzuhalten und zu moderieren. Wir bei AGILE ANTS nutzen beispielsweise die Lösung „Zoom“ (https://zoom.us) für die tägliche Videokommunikation. Wir haben im Laufe der Zeit verschiedene Lösungen ausprobiert, haben Zoom aber insbesondere für sehr stabile Videoverbindungen, auch bei schmalbandigen Verbindungen und einer grossen Anzahl von Teilnehmern schätzen gelernt.
  • Stellen Sie einheitliche Tools zur Verfügung.
    Nichts ist frustrierender als ein „Tool-Zoo“, der Teams vor die Frage stellt, welches sie nun am besten nutzen können. Stellen Sie ausserdem sicher, dass alle Teammitglieder Zugang zu den benötigten Tools und zu allen Projektdaten haben. Dabei sollten Sie Wert auf möglichst unkomplizierte Zugangsstrukturen und Berechtigungssysteme legen um das einfaches onboarding von neuen Teammitgliedern zu ermöglichen.
  • Erschaffen Sie einen transparenten, klar definierten und leicht zugänglichen Backlog.
    Der Backlog ist das Herzstück ihres Projektes und sollte entsprechend leicht für das gesamte Team zugänglich sein. Es ist von großer Relevanz, dass das Team versteht, was der Product Owner wie umgesetzt sehen möchte. Um dieses Kriterium zu erfüllen, ist es wiederum sehr wichtig, den Backlog ganz klar zu definieren und anhand von Akzeptanzkriterien und einer passenden “Definition of Done” die Items im Backlog möglichst im Vorhinein rückstandslos zu definieren. 
  • Ermöglichen Sie kollaboratives Arbeiten im Team.
    Häufig entstehen die besten Resultate, wenn man Aufgaben in einem aktiven Austausch mit seinem Team bearbeitet. So auch bei agilen, verteilten Teams. Durch Echtzeit-Kollaborationen wie sie bei Google Docs oder Google Sheets möglich sind, können kann das Team live miteinander arbeiten und Ideen austauschen und gegenseitig optimieren. Es gibt viele Tools auf dem Markt, die Ihrem Team kollaboratives Arbeiten in Echtzeit ermöglichen.

WIE UNTERSTÜTZEN SIE AGILE METHODEN DABEI?

Das Scrum Framework bringt einige Events und Strukturen mit sich, die man als Team in einem Sprintzyklus durchläuft. Wie zeigen Ihnen, wie Sie diese Events in verteilten Teams optimal durchführen und anpassen können. 

  • Sprint Planning:
    Im Sprint Planning werden die Ziele des nächsten Sprints definiert. Es wird ein klares Ziel gesetzt und der Sprint Backlog wird erstellt. Bei einem verteilten Team hat ein Alignment hier die oberste Priorität. Am Ende des Sprint Plannings muss anhand des Sprint Backlogs ganz klar für jedes Team ersichtlich sein, welche Aufgaben innerhalb des nächsten Sprints zu erledigen sind. Durch eine gemeinsame Zielsetzung im Team soll außerdem verhindert werden, dass das Team in unterschiedliche Richtungen entwickelt.
  • Daily Scrum: 
    Das Daily im Scrum ist ein elementarer Bestandteil des Frameworks und ein wichtiges Event für die Teammitglieder die hier täglich in den Austausch treten können. Beim Daily Scrum geben die Teammitglieder ein kurzes Statusupdate und klären das Team über aktuelle Hindernisse in Ihrer Arbeit auf. In einem verteilten Team ist dieses Event genauso wichtig wie bei einem lokalen Team – wenn nicht noch wichtiger. Hier können Strategien für den Tag besprochen und definiert werden und es kann, durch schnelle und persönliche Kommunikation, oft ein ausschweifender Mailverkehr verhindert werden.
  • Der Sprint:
    Während des Sprints sind für ein verteiltes, agiles Team eine klare Tool Suite und ein einfacher Zugang zu den Projektdaten elementar. Die Arbeit im Sprint an sich kann – je nach Mindset und Präferenz des Teams – bei verteilten Teams dann jedoch weitestgehend autark oder mit Hilfe von Echtzeit-Kollaborationstools vonstatten gehen.
  • Sprint Review:
    In diesem Event werden die Ergebnisse des letzten Sprints gegengeprüft. Während bei allen anderen Events prinzipiell eine Videokonferenz ausreicht, ist es an dieser Stelle elementar auch Bildschirmübertragungen live zu ermöglichen. Dieses Event sorgt bei verteilten Teams für ein zentrales Feedback und gibt dem Team ein Gefühl dafür, welchen realen Wert sie geschaffen haben.
  • Retrospektive:
    An dieser Stelle iterieren wir den Scrum Prozess als solchen und daher ist dieses Element besonders für verteilte Teams von großer Bedeutung. Da jedes Team anders funktioniert und besonders die verteilte agile Arbeit eine große Herausforderung darstellt, gibt dieses Event die Möglichkeit das gesamte Framework an mein Remote-Team anzupassen und ein verteiltes Arbeiten so weit zu optimieren, dass es der Arbeit vor Ort nicht mehr nachsteht.

Natürlich sollten Sie genug Zeit für Iterationen einplanen und jedes Team wird eine andere agile Arbeitsweise für sich finden. Es ist wichtig, dass Sie jedem Team die Zeit und Freiräume lassen, damit es sich selber stetig optimieren kann. Wenn Sie aber eine gute Grundlage durch das Bereitstellen einer passenden Infrastruktur schaffen und dem Team die Zeit geben sich auf das verteilte, agile Arbeiten einzustellen, dann steht der reibungslosen Umsetzung nichts mehr im Wege.

TOOLÜBERSICHT

Übersicht einiger Tools, die wir bei AGILE ANTS selber regelmässig nutzen (keine Werbung, keine Affiliate-Links!):

VIDEOKONFERENZEN/WEBINARE

  • Zoom
    Cloudbasierte Audio-, Video- und Screensharinglösung, sehr stabil auch bei schmalbandigeren Verbindungen und hohen Teilnehmerzahlen; diverse Erweiterungsmodule, z.B. zur Durchführung von Webinaren oder zur Anbindung von Videokonferenz-Hardware (https://zoom.us)
  • Jitsi
    Fokus auf Videokonferenz, Community-getriebenes Projekt, lizenzkostenfreie Version, on-Premise Lösung; keine Möglichkeit von weltweiten Einwahlnummern (https://jitsi.org)

DIGITALE WHITEBOARDS

  • Miro
    Whiteboard-Tool mit Unterstützung zahlreicher Plattformen und grosser Auswahl an fertigen Templates (https://miro.com/)
  • Figma
    Spezieller Fokus auf kollaboratives Arbeiten an UI-Design, z.B. im Rahmen von Design Sprints (https://www.figma.com/)
  • Zoom Rooms
  • Cloudbasierte Lösung (Zusatzmodul zu Zoom, zur Nutzung von virtuellen Whiteboards in Verbindung mit Touch-Hardware (https://zoom.us/de-de/zoomrooms.html)

SYNCHRONE TEAMKOMMUNIKATION

PLANNING (POKER)

RETROSPEKTIVE

  • FunRetro
    Cloudbasiertes Tool zum Durchführen von Retrospektiven, mit zahlreichen Templates, wie z.B. Starfish, SWOT, Six thinking hats etc. (https://funretro.io/)

AUDIO HARDWARE

VIDEO HARDWARE

ALLES AGIL ODER WAS?

Wann machen agile Methoden Sinn und wann lässt man besser die Finger davon?

Auch als begeisterte “Agilisten” sind wir manchmal erstaunt, welche Projekte an uns herangetragen werden, die agil umgesetzt werde sollen.

Momentan scheinen agile Methoden das Allheilmittel für viele Vorhaben zu sein. Bei allem Hype sollte man aber genau betrachten wann und für wen agile Methoden nützlich sind, um das gewünschte Projektziel zu erreichen.

Dabei können agile Methoden der Treibstoff für die erfolgreiche Digitalisierung in Unternehmen sein. Entscheidend ist der sinnvolle Einsatz.

Ein sich ständig wandelndes Marktumfeld stellt hohe Anforderungen an Unternehmen:

Neue Ideen müssen frühzeitig auf ihre Machbarkeit geprüft werden, ohne aufs falsche Pferd zu setzen und große Budgets in weniger vielversprechende Produkte zu verschwenden.

Während der Produktentwicklung müssen Unternehmen dann stets in der Lage sein, auf sich ändernde Anforderungen und ein sich änderndes Marktsegment (Kunden, Wettbewerber) reagieren zu können. Ein sehr dynamischer Markt muss ständig beobachtet werden, Marktveränderungen müssen in die Produktentwicklung direkt einfliessen.

Und schließlich muss am Ende auch noch ein qualitativ hochwertiges Produkt entstehen, das ein gutes Kundenerlebnis bietet und sich gegen den Wettbewerb durchsetzen kann.

Wann machen agile Projektmethoden Sinn?

Bei vielen Projekten stehen die Anforderungen zu Projektstart noch nicht fest oder sind nicht zumindest nicht gänzlich formuliert. Ausserdem sind die Prioritäten, nach denen die Anforderungen umgesetzt werden sollen unklar.

Zudem entschliessen sich viele Unternehmen dazu, bereits in einem frühen Entwicklungsstadium Kundenfeedback zu erhalten und dieses direkt in die Verbesserung und Weiterentwicklung des Produkts einfliessen zu lassen. Damit erreichen sie eine bessere „time to market“ und durch die Kundeneinbeziehung auch eine höhere Kundenakzeptanz.

In diesen Fällen machen agile Methoden Sinn und können durch das iterative Vorgehen helfen, schneller mit einer 80%-Lösung (oder bereits mit einem MVP, “Minimum Viable Product”) auf den Markt zu kommen, den Markt rechtzeitig zu besetzen und das Produkt dann kontinuierlich weiterzuentwickeln. Auch bei einem reduzierten Funktionsumfang ist jedoch stets derselbe Qualitätsanspruch anzusetzen, den man auch für das vollständige Produkt vorsieht.

Wann machen agile Projektmethoden eher keinen Sinn?

Bei Projekten, in denen zu Beginn des Projekts bereits alle entscheidenden Parameter (Scope, Delivery, Lieferzeitpunkt) von vornherein feststehen, können agile Projektmethoden ihre Stärken nicht ausspielen und keinen signifikanten Mehrwert liefern.

Ausserdem kann es Projekte geben, bei denen das Projektziel sehr detailliert und vollständig spezifiziert ist (oder sein muss) und “vom Ende her gedacht” ist. Dies trifft beispielsweise oft in Engineering-Projekten zu. Der Grund können aufwendige technische Zertifizierungen für bestimmte Systemteile sein. Jede Änderung an den Anforderungen hätte eine ebenso aufwendige und kostspielige Re-Zertifizierung zur Folge und sollte vermieden werden.

In diesen Fällen steht der bewusst durchgeplante Projektcharakter im völligen Gegensatz zu einer iterativen und agilen Vorgehensweise, die Veränderungen und Verbesserungen während der Produktentwicklung ausdrücklich fördert. Wir versuchen hier gar nicht erst eine agile Herangehensweise zu forcieren, sondern

Als erste Entscheidungshilfe für den sinnvollen Einsatz agiler Methoden kann die nachstehende Stacey Matrix helfen, die wir Kunden für die erste grobe Orientierung empfehlen.

Fazit:

Agile Projektmethoden sind kein Allheilmittel. Wenn Verantwortlichkeiten und/oder Anforderungen vollkommen unklar sind oder niemand da ist, der eine Produktvision formulieren kann, dann wird keine Methodik dies per se lösen.

Agilität sollte ausserdem keine Entschuldigung für schlecht formulierte Anforderungen (und vor allem Akzeptanzkriterien) oder für allgemeines Anforderungs- und Priorisierungschaos sein (beliebte Phrase: “Wir sind ja agil…”). Damit verbrennt man wertvolle Teammotivation und eine an sich sinnvolle Methodik.

Wir helfen unseren Kunden in einem solchen Fall durch ein ehrliches Projekt-Assessment, bei dem die Vor- und Nachteile der unterschiedlichen Herangehensweisen, bezogen auf das konkrete Projekt, beleuchtet werden und eine Vorgehensweise empfohlen wird. Und das kann dann durchaus auch eine nicht-agile sein.