Wie wird man agil? — Eine Hilfestellung für Agenturen
So schaffst du Rahmenbedingungen, die agiles Arbeiten ermöglichen
Dieser Artikel ist auch auf Englisch verfügbar.
Agiles Arbeiten ist zu einem Buzzword mutiert, das in den letzten Jahren auch in der Agenturszene immer häufiger zu hören ist. Kaum eine Firma, die nicht auf ihrer Webseite behauptet, agil zu arbeiten. Aber was bedeutet das eigentlich genau? Woher weiß man, wie agil eine Firma wirklich ist? Wenn man in Sprints arbeitet, ist man dann schon agil? (Antwort: Nein.)
Bei Aperto Move haben wir in den letzten zweieinhalb Jahren unsere Arbeitsweise stetig hinterfragt und weiterentwickelt und unsere Vision von agiler Arbeitsweise vorangetrieben. Eine der größten Erkenntnisse dabei war, dass die Transformation zu agilem Arbeiten Zeit und Erfahrung braucht. Es ist nicht möglich, mal eben auf agiles Arbeiten „umzustellen“. Auch wir sind noch nicht hundertprozentig dort angekommen, wo wir hin wollen, aber die Verbesserungen sind bereits deutlich spürbar.
Gerade in einer Agentur ist es im Allgemeinen schwieriger, agil zu arbeiten als z.B. in der Produktentwicklung, da man verschiedene Produkte für verschiedene Kunden entwickelt und sich die Rahmenbedingungen von Projekt zu Projekt manchmal stark unterscheiden. Schwer zu glauben, dass also plötzlich jede Agentur agil sein will. Doch zum Glück gibt es Faktoren, an denen man relativ einfach feststellen kann, wie weit eine Firma auf dem Weg zu agilem Arbeiten bereits gekommen ist.
Die in diesem Artikel präsentierten Maßnahmen zur Schaffung der Rahmenbedingungen für agiles Arbeiten basieren auf Situationen, die in vielen Agenturen üblich sind. Uns selbst sind solche Situationen als Stolpersteine im Arbeitsalltag begegnet, die wir — einmal als Problem erkannt — aus dem Weg räumen konnten. Sie stellen demnach keine Patentlösung dar, sondern geben wieder, was in unserem Fall am besten funktioniert hat.
1. (Er)Kläre die Begrifflichkeiten
Wenn man agiles Arbeiten einführt, ist es wichtig, dass jeder in der Firma dasselbe Verständnis davon hat, was der Begriff „agil“ bedeutet. Ist das nicht der Fall, können sich daraus gefährliche Folgen ergeben: ich habe Personen erlebt, die unter agilem Arbeiten verstanden, auf jegliche Konzeption, Planung und Regeltermine in einem Projekt zu verzichten und stattdessen einfach drauf los zu arbeiten und zu sehen, was passiert. Dass so ein Projekt nicht gerade entspannt ablief, kann man sich vorstellen.
Andere wiederum haben vor allem von Scrum gehört und nicht selten Vorbehalte dagegen: So habe ich schon öfters die Aussage mitbekommen, Scrum sei „nur etwas für Entwickler“ und behindere daher den kreativen Prozess. Solche Aussagen kamen in der Regel von Personen, die sich selbst noch nicht tiefergehend mit Scrum oder agilem Arbeiten auseinandergesetzt oder es ausprobiert haben.
Hieraus ergibt sich eine weitere Gefahr: Nicht jeder, der es noch nicht selbst genutzt hat, kennt notwendigerweise den Unterschied zwischen agilem Arbeiten und Scrum und setzt beides daher unter Umständen gleich.
Scrum und Agiles Arbeiten sind nicht dasselbe
Scrum ist ein Vorgehensmodell, das bestimmte Regeln, Rollen und Arbeitsabläufe definiert, um Software zu entwickeln, u.a. das Arbeiten in zeitlich fest definierten Sprints. Die Anwendung von Scrum trägt zur agilen Softwareentwicklung bei, deswegen werden agiles Arbeiten und Scrum gerne synonym gesehen, sie sind es aber nicht.
„Agil“ ist hingegen eine eigene Denkweise oder Kultur, die einiges mehr umfasst als das, was Scrum abdeckt. Die Prinzipien, die agiles Arbeiten ausmachen, sind im Agilen Manifest definiert. In diesem Video wird das anschaulich dargestellt:
Scrum ist nur ein mögliches Framework für agiles Arbeiten. Man kann auch agil arbeiten, ohne Scrum einzusetzen. Umkehrt bedeutet allein die Tatsache, dass man das Regelwerk von Scrum befolgt, noch lange nicht, dass man wirklich agil arbeitet.
2. Verabschiede dich von der Rolle des Projektmanagers (etabliere stattdessen agile Rollen)
In Scrum sind folgende Rollen definiert:
- Product Owner
- Scrum Master
- Entwicklungsteam
Dazu kommen weitere Stakeholder wie z.B. die Endnutzer oder Beteiligte auf Kundenseite. Mehr Rollen gibt es nicht und mehr braucht man auch nicht. Es gibt also keinen klassischen Projektmanager mehr. Er wäre in diesem Setup auch eher hinderlich, denn alle bisherigen Aufgaben zur Projektsteuerung werden von den oben genannten Rollen erfüllt. Auch die Verantwortung für den Projekterfolg liegt nicht mehr bei einer Person, sondern beim gesamten Team.
Jede weitere Rolle, die im laufenden Projekt neben diesen existiert und zwischen dem Scrum-Team und dem Kunden steht, behindert eine direkte und effektive Kommunikation zwischen dem Team und den Kunden.
Nimm die Rollen und Verantwortlichkeiten ernst
Wenn man keine Projektmanager mehr braucht, würde es sich dann nicht anbieten, bisherige Projektmanager dann einfach als Scrum Master und Product Owner in Personalunion einzusetzen?
Nein. Einerseits sind sowohl Scrum Master als auch Product Owner Rollen, die für sich allein bereits genug Aufgaben mit sich bringen, sodass eine Person, die beide Rollen erfüllen müsste, zwangsläufig Aspekte einer der Rollen vernachlässigen müsste. Vor allem haben beide Rollen zuweilen gegensätzliche Interessen: Während der Product Owner daran interessiert ist, dass das richtige Produkt bestmöglich abgeliefert wird und im stetigen Austausch mit allen Stakeholdern steht, muss der Scrum Master unter anderem sicherstellen, dass das Team nicht überlastet oder bei der Arbeit behindert wird. Der Scrum Master hat demnach inhaltlich nichts mit dem Produkt zu tun.
Noch kritischer ist es, wenn niemand die Rolle des Scrum Masters besetzt. Dann ist nicht definiert, wer sicherstellt, dass das Team produktiv arbeiten kann, dass Termine eingehalten werden oder das Team mit Hilfe von Retrospektiven dazulernt und effektiver wird; kurz gesagt: Der dazu beiträgt, dass das Projekt agil durchgeführt werden kann. Nach unserer Erfahrung ist das insbesondere im Agenturumfeld mit wechselnden Kunden, Stakeholdern und Rahmenbedingungen wichtig, denn hier übernimmt der Scrum Master auch eine Coaching-Rolle in Richtung der Kunden.
Dieser Artikel erklärt die unterschiedlichen Funktionen von Scrum Master und klassischem Projektmanager anhand einer einfach verständlichen Analogie zum Straßenverkehr:
3. Verabschiede dich von Ressourcenplanung (etabliere stattdessen das Pull-Prinzip)
In einer Agentur werden häufig mehrere Projekte für mehrere Kunden gleichzeitig bearbeitet. Dabei entsteht die Herausforderung, die anfallende Arbeit möglichst effektiv auf alle Mitarbeiter zu verteilen.
Der klassische Agentur-Ansatz ist dabei die Ressourcenplanung: Projektmanager erstellen Pläne für mehrere Tage oder Wochen in der Zukunft und teilen Mitarbeiter Projekten bzw. Aufgaben zu. Dabei muss einige Zeit in die Planung und Abstimmung investiert werden und das Ergebnis ist sehr unflexibel, denn es setzt voraus, dass alle Schätzungen und Annahmen, die man für diese Zeit getroffen hat, auch eintreten.
Die Erfahrung zeigt jedoch, dass solche Pläne in der Realität nie aufgehen: Eine wichtige Zulieferung kommt nicht rechtzeitig, Kollegen werden krank oder andere unvorhergesehene Ereignisse treten auf, was dazu führt, dass einzelne Aufgaben länger dauern als angenommen. Die Konsequenzen sind eine ungleiche Arbeitsbelastung zwischen Kollegen, Stress und Überstunden.
Dieses sogenannte „Push“-Prinzip (weil Mitarbeitern einzelne Aufgaben extern „aufgedrückt“ werden) ist also nicht optimal. Auch gibt es im agilen Setup ja keine Projektmanager mehr, wie funktioniert dann die Verteilung der Arbeit? Auch hier ist ein Umdenken erforderlich:
Das Pull-Prinzip
Agiles Arbeiten setzt eine Pull-Mentalität voraus. Das bedeutet, dass die Mitarbeiter eigenverantwortlich bestimmen, welche Aufgaben sie wann bearbeiten. Damit das funktionieren kann, müssen anstehende Aufgaben und deren Fortschritt transparent kommuniziert werden.
Im Optimalfall passiert dies nicht nur auf Projekt-Ebene, sondern für alle anfallenden Aufgaben in der Firma. Dazu zählen z.B. auch Aufwandsschätzungen, das Erstellen von Präsentationen, die Vorbereitung von Workshops, die Teilnahme an Bewerbungsgesprächen oder auch das Verfassen dieses Artikels. Das kann z.B. durch ein Kanban-Board realisiert werden:
Das Pull-Prinzip hilft dabei, eine gleichmäßige Auslastung aller Kollegen sicherzustellen und die Kollegen haben die Freiheit, selbstständig zu entscheiden, wann sie die Kapazität haben, um Aufgaben zu bearbeiten. Dementsprechend wird eine Überlastung einzelner Mitarbeiter ausgeschlossen.
Damit das Pull-Prinzip funktioniert, müssen folgende Anforderungen erfüllt sein:
- Ein häufiger Austausch ist wichtig. Bei uns wird der Status dreimal wöchentlich mit allen Kollegen am Board besprochen.
- Es erfordert Mitarbeiter, die eigenverantwortlich handeln können und nicht darauf warten, dass ihnen jemand sagt, was sie tun sollen.
- Es begünstigt die Realisierung flacher Hierarchien. Dementsprechend muss der Wille gegeben sein, diese einzuführen.
- Seitens der Führungsebene des Unternehmens muss Vertrauen in die Mitarbeiter vorhanden sein und es diesen ermöglicht werden, Verantwortung zu übernehmen.
- Es muss zwischen einzelnen Aufgaben und Projekten unterschieden werden: Projekte werden nicht von Einzelpersonen, sondern von Teams gezogen. Das wird im nun folgenden Abschnitt genauer thematisiert.
4. Etabliere stabile Teams
Da in Agenturen üblicherweise für mehrere Kunden gleichzeitig gearbeitet wird und häufig kurzfristige Aufgaben anfallen, die schnell bearbeitet werden müssen, wie z.B. Aufwandsschätzungen, Pitches oder Bugfixes, werden Projektteams häufig aus gerade verfügbaren Mitarbeitern zusammengestellt. Diese Art von „Ressourcenplanung“ verhindert effektiv erfolgreiche agile Projekte.
Agile Teams sollten vor allem stabile Teams sein, die sich im besten Fall selbst gefunden haben. Nur feste Teams können sich optimal entwickeln und ihre Geschwindigkeit halten oder sogar steigern, indem sie voneinander lernen, ihre Prozesse und Kommunikation aufeinander abstimmen, durch Retrospektiven Probleme identifizieren und sie lösen.
Um diese effektiven Teams von Kollegen, die gut miteinander arbeiten können, nicht wieder zu zerreißen und damit jegliche Lern- und Routineeffekte zu eliminieren, sollten demnach für anstehende Projekte nicht einzelne Personen, sondern stabile Teams eingeplant werden.
Es ist allerdings illusorisch, eine komplette Agentur kurzfristig über alle Disziplinen in stabile Teams aufzuteilen, die gleich gut ausgelastet sind. Möglicherweise möchte auch nicht jeder dauerhaft mit denselben Kollegen in einem Team zusammenarbeiten. Hier gilt es eine Balance zu finden, die für alle Beteiligten funktioniert.
5. Erstelle agile Angebote
Eine klassische Angebotsphase zwischen einem Kunden und einer Agentur sieht vereinfacht dargestellt in der Regel so aus: Ein Kunde möchte ein Produkt (z.B. eine Software) haben und hat eine mehr oder weniger genaue Vorstellung, wie dieses aussehen soll und bis wann es fertig sein muss.
Er brieft die Agentur über seine Anforderungen (vielleicht veranstaltet er sogar einen Pitch) und bittet darum, dass diese ein Angebot abgibt, also den Preis festlegt, um dieses Produkt zu entwickeln. Um sich gegenseitig abzusichern, investieren beide Parteien einen nicht unwesentlichen Arbeitsaufwand, das Angebot so detailliert wie möglich auszuarbeiten, damit es nicht zu Missverständnissen kommt.
Aus Kundensicht klingt das in der Regel erst einmal sehr gut: Man weiß, was man wann für welchen Preis bekommt.
Anforderungen ändern sich
Was Kunden bei solchen Angeboten in der Regel nicht bedenken ist, dass sie zu Projektende nicht selten etwas ganz anderes wollen als zu Projektbeginn, weil sich die Welt um sie herum weiter gedreht hat.
Da jedoch alles fest im Angebot definiert wurde, ist es schwer bis unmöglich, am Projekt nachträglich noch etwas zu ändern, ohne nachzuverhandeln:
- In der Zwischenzeit sind andere Features wichtiger geworden?
- Das gewünschte Produkt ist technisch nicht realisierbar?
- Nutzertests haben ergeben, dass das Produkt nicht verstanden wird oder keinen Sinn ergibt?
- Ein Wettbewerber hat ein ähnliches Produkt herausgebracht, wodurch eine strategische Neuausrichtung nötig wird?
Eine Neupriorisierung ist in diesem Fall nicht so einfach möglich, wenn die alten, überholten Liefergegenstände im Angebot festgeschrieben sind. Auch weitere wesentliche Aspekte des agilen Arbeitens werden durch diese Art von Angeboten ausgehebelt: Ein kontinuierliches, kollaboratives Verbessern des Produkts wird erschwert, da das Produkt schon zu Beginn relativ klar feststehen muss, um ein genaues Angebot abgeben zu können. Dies führt zu einem typischen Wasserfall-Workflow. Ein Sprint Planning Meeting mitsamt Planning Poker wird ebenfalls obsolet, weil ohnehin schon vorgegeben ist, was bis wann fertig sein muss.
Wenn solche Rahmenbedingungen gegeben sind und der Lieferumfang, die Deadline und der Preis bereits zu Beginn feststehen, ist es unter Umständen nicht mehr sinnvoll, überhaupt ein agiles Framework wie Scrum anzuwenden. In diesem Fall kann man die Hauptvorteile des agilen Arbeitens nicht mehr nutzen, hat aber einen Extraaufwand für Scrum-Meetings, aus denen man jedoch keinen echten Mehrwert mehr ziehen kann. Dieses Vorgehen wird auch als „Pseudo-Scrum“ bezeichnet.
Eine andere Art Angebot wird nötig
Sinnvoller ist es daher, im Angebot keine genauen Liefergegenstände festzulegen, sondern geleistete Arbeitsaufwände abzurechnen (sog. Time and Material-Verträge). Erst dadurch wird ermöglicht, ein Projekt wirklich agil durchzuführen. Wie viel und was der Kunde für sein Geld bekommt, bestimmt er im Projektverlauf maßgeblich selbst mit, indem er die Liste seiner Anforderungen zusammen mit dem Team aktuell hält und regelmäßig neu priorisiert.
Damit der Kunde nicht die Katze im Sack kauft, kann man vorher eine ungefähre Schätzung abgeben, wie viel in einer bestimmten Zeit geschafft werden kann bzw. wie lange es dauern würde, einen bestimmten Umfang umzusetzen. Je länger ein Team schon zusammenarbeitet, umso präziser wird diese Schätzung ausfallen, da es einfach und verlässlich seine eigene Geschwindigkeit (die sog. Velocity) messen kann. Dies ist ein weiterer Grund, warum es sinnvoll ist, feste Teams zu etablieren.
Dennoch ist die Angebotsstellung eine der schwersten Aufgaben beim Übergang zu agilem Arbeiten. Kaum ein Kunde, der noch keine Erfahrung mit agilem Arbeiten gesammelt hat, wird gerne ein Angebot unterschreiben, bei dem er vorher nicht sicher ist, was er am Ende für sein Geld bekommen wird. Hier gilt es, Geschick zu beweisen und Vertrauen beim Kunden zu schaffen.
Nach unserer Erfahrung entfällt diese Hürde schnell, sobald man einmal ein solches Projekt mit dem Kunden durchgeführt hat, da dieser selbst im Projektverlauf sieht, dass er viel schneller ein greifbares Ergebnis bekommt und sich dieses durch das iterative Arbeiten, die enge Zusammenarbeit und die kürzeren Feedback-Zyklen viel stärker mit seiner Vorstellung deckt als bei typischen Wasserfallprojekten.
Für die agile Angebotsstellung existiert darüber hinaus hilfreiche Literatur wie z.B. dieses Buch:
6. Binde das Projektteam so früh wie möglich in der Akquisephase ein
Nicht selten sind in Agenturen die Akquise- und Angebotsphase und die Projektumsetzung voneinander isoliert. Ein New Business-Team kümmert sich dort um neue Projekte und das Projektteam wird das erste Mal mit den Details konfrontiert, wenn die Umsetzung beginnen soll. Dadurch werden Konflikte in der Umsetzung sehr wahrscheinlich.
Die Angebotsphase kann schon maßgeblich darüber entscheiden, ob ein Projekt erfolgreich wird oder nicht. Dabei ist es unerlässlich, dass das agile Team so früh wie möglich in die Kommunikation involviert wird.
So lässt sich möglichst früh beurteilen, ob eine agile Umsetzung des Projekts überhaupt sinnvoll ist und mit welchem zeitlichen Aufwand ungefähr zu rechnen ist. Den zeitlichen Aufwand, z.B. die Anzahl der benötigten Sprints in einem Scrum-Projekt, kann nur das Team selbst einschätzen, wenn es schon möglichst viel über das Projekt weiß.
Es kann vorkommen, dass es mehr Projektanfragen gibt, als von den Teams bearbeitet werden können. Um das Pull-Prinzip umsetzen und das geeignetste Projekt wählen zu können, muss das Team möglichst viel über alle anstehenden Projekte wissen. Nur so kann es eine fundierte Entscheidung treffen und neue Projekte sinnvoll in Sprints von aktuellen Projekten eintakten.
Wenn das neue Projekt startet, muss das Team möglichst früh alle Stakeholder und deren Anforderungen kennen, um das richtige Produkt in der bestmöglichen Qualität liefern zu können. Eine effektive Maßnahme, dies zu erreichen, ist ein Workshop mit dem Team und den Stakeholdern auf Kundenseite.
Darüber hinaus gilt es, beim Kunden die agilen Werte zu vermitteln, den Hauptansprechpartner zu identifizieren und das gemeinsame Vorgehen im Projekt im Detail zu kommunizieren.
7. Verlasse die Dienstleister-Rolle (und arbeite mit dem Kunden im Team)
Ein Kunde / Dienstleister Verhältnis ist kontraproduktiv, denn es impliziert, dass der Kunde letztendlich nur einen Auftrag vergibt und ein Ergebnis erwartet. Ein erfolgreiches Projektergebnis, das alle Beteiligten zufrieden stellt, bedeutet in der Regel jedoch auch Arbeit auf allen Seiten, insbesondere eine regelmäßige Kommunikation miteinander.
Eine wesentliche Voraussetzung für ein erfolgreiches agiles Projekt ist die Kommunikation auf Augenhöhe. Das bedeutet, dass sich Kunde und Agentur als ein Team verstehen, das gemeinsam ein Projekt bearbeitet und gegenseitig seine Stärken kennt und nutzt: Die Agentur ist in der Regel Experte für Strategie, User Experience, Design und technische Umsetzung; der Kunde kennt hingegen seine internen Prozesse und Anforderungen sowie die Zielgruppe besonders gut. Nur wenn dieses Wissen zusammenkommt, können nutzerzentrierte Produkte entstehen, die alle Stakeholder zufrieden stellen.
Dies bedeutet allerdings auch, dass es auf Kundenseite feste Ansprechpartner geben muss, die für das Projekt abgestellt sind und kurzfristig Fragen beantworten oder fehlendes Material bereitstellen können. Nicht jeder Kunde kann oder will jedoch so viel Zeit investieren, weil es ihm z.B. seine internen Arbeitsabläufe nicht erlauben.
Nach unserer Erfahrung merken Kunden im Projektverlauf in der Regel sehr früh, wie viel schneller sie durch die agile Zusammenarbeit Ergebnisse in hoher Qualität erhalten, die ihren Vorstellungen entsprechen, so dass sie diesen Zeitaufwand gerne auf sich nehmen.
8. Schaffe Räume für Teamarbeit
Agiles Arbeiten bedeutet interdisziplinäre Arbeit und häufige Kommunikation. Diese kann nur optimal funktionieren, wenn das agile Team zusammen sitzt und sich so jederzeit kurzfristig abstimmen kann. Im Bestfall gibt es pro Team einen eigenen Bereich, wo das Team ungestört arbeiten kann und selbst niemanden stört, z.B. wenn Designs oder Features diskutiert werden.
Häufig sieht man in Agenturen jedoch ein anderes Bild: Die Gruppierung von Mitarbeitern in Disziplinen. Das bedeutet etwa, dass in einer Ecke des Büros alle Designer sitzen, in einer anderen alle Entwickler, die Tester und die Account Manager vielleicht sogar in ganz anderen Räumen. Das ist zwar sinnvoll für den disziplins-internen Austausch, erschwert aber die Kommunikation innerhalb der Projektteams. Sich gegenseitig zu schreiben ist zwar möglich, dauert aber länger als kurz miteinander zu reden.
Noch schwieriger wird es, wenn alle Teammitglieder nicht einmal am selben Ort sitzen. Jeder weiß, wie schlimm Telefon- oder Videokonferenzen sind. Wer noch nicht häufig welche erleiden musste, dem sei dieses Video empfohlen:
9. Berücksichtige jede Disziplin und den kompletten Projekt-Prozess
Scrum entspringt aus der Software-Entwicklung, daher erscheint es bequem, nur die technische Umsetzung des Projekts agil durchzuführen und den Kreationsteil zu belassen wie bisher. Damit gewinnt man jedoch vergleichsweise wenig, da der Projekt-Wasserfall nur am Ende etwas aufgelöst wird.
Angenommen, das agile Team besteht nur aus Entwicklern, die Webseite für den Kunden wurde bereits fertig konzipiert und designt und mitten in der Entwicklung fällt auf, dass wichtige Zustände nicht definiert und gestaltet wurden. Die Kreation ist aber schon mit dem nächsten Projekt beschäftigt. Was nun? Leute aus dem anderen Projekt wieder abziehen? Die Software unfertig entwickeln? Hier gibt es keine einfache Lösung, außer gleich zu Projektbeginn alle involvierten Disziplinen in den agilen Workflow einzubeziehen.
Feedback, Feedback, Feedback
Eine große Stärke und ein wichtiger Grund, warum die Qualität agil entwickelter Software nach unserer Erfahrung höher ist als bei Wasserfall-Projekten mit klassischen Projektmanagement, ist die interdisziplinäre Zusammenarbeit und iterative Verbesserung des Produkts auf Basis von frühem und häufigem Feedback durch alle Beteiligten.
Vereinfacht gesagt bedeutet das: Jeder reviewt in jeder Projektphase alles.
- Die Kunden und das komplette Team geben dem Product Owner (PO) Feedback zu den User Stories
- UI Designer geben Feedback zu Wireframes und technischer Umsetzung
- UX Designer geben Feedback zum User Interface Design und der technischen Umsetzung
- Frontend-Entwickler geben Feedback zu den Wireframes, zum User Interface Design, zu Backend-Schnittstellen und ggfs. zur Backend-Implementierung
- Backend-Entwickler geben Feedback zu den Wireframes, zum User Interface Design und zur Frontend-Umsetzung
- Die Qualitätssicherung (QA) gibt Feedback zu Wireframes, zum User Interface Design und zur technischen Umsetzung
- Nutzer geben in Usability Tests Feedback während verschiedener Projektphasen (Wireframes, Design-Prototyp, Klickdummy, Frontend-Umsetzung)
- Der Kunde gibt im Sprint Review Meeting Feedback zu den umgesetzten User Stories
Häufiges Feedback ist das wichtigste Asset in der agilen Entwicklung und sorgt dafür, dass das Produkt in einer Qualität entwickelt wird, die alle Beteiligten zufrieden stellt. Das funktioniert natürlich nur, wenn alle Beteiligten in jeder Projektphase involviert sind.
10. Gehe nicht davon aus, dass alles sofort funktioniert (Mache Fehler und lerne daraus)
In den vorherigen Abschnitten ist hoffentlich deutlich geworden, dass auf vielen Ebenen ein Umdenken und anderes Vorgehen erforderlich wird als die eingespielten Prozesse, welche sich vielleicht über Jahre etabliert haben. Daher ist es wichtig zu verstehen, dass der Wandel zu agilem Arbeiten ein Prozess ist, der nicht einfach ist und kein fest definiertes Ende hat.
Die Umsetzung der in den vorherigen Abschnitten genannten Maßnahmen sorgt nicht automatisch dafür, dass man als Unternehmen agil wird. Ebenfalls wird es nicht ausreichen, nur „technische“ Maßnahmen durchzuführen wie die Einführung von Scrum. Viel essentieller ist der Wandel der Unternehmenskultur und die Schaffung von gemeinsamen agilen Wertevorstellungen und Prinzipien auf allen Hierarchieebenen.
Es wäre naiv zu erwarten, dass solche tiefgreifenden Änderungen sofort problemlos funktionieren. Die Veränderungen in den Unternehmensprozessen können ebenfalls als agiles Projekt verstanden und auch so umgesetzt werden: iterativ.
Das bedeutet vor allem, nicht alles auf einmal zu verändern, sondern eine Maßnahme nach der anderen umzusetzen. Dabei lernt man, was funktioniert und was nicht und kann darauf aufbauen. Falsch wäre es, an einer Maßnahme festzuhalten, mit der man sich nicht wohl fühlt, nur weil sie in einem Buch o.ä. empfohlen wurde.
Ein externes Coaching kann ebenfalls sinnvoll sein, um die richtigen Denkanstöße zu vermitteln. Wie bei allen anderen Maßnahmen auch kann man hiervon allerdings kein „Allheilmittel“ erwarten, nachdem man plötzlich agil ist.
Mindestens ebenso wichtig ist es, einen internen Wissens- und Erfahrungsaustausch zu etablieren und sich auf ein gemeinsames Vorgehen zu einigen. Dabei kann es hilfreich sein, sich regelmäßig die zwölf Prinzipien agilen Arbeitens anzusehen und zu prüfen, wie sehr man diese als Unternehmen schon verinnerlicht hat:
In unserem Team hat tatsächlich die strikte Befolgung der Richtlinien des Scrum-Frameworks am besten funktioniert. Jede Art und Weise, diese Prozesse zu verbiegen oder anzupassen, haben letztendlich zu Komplikationen oder Mehraufwand geführt. Das muss aber nicht bei jedem der Fall sein. Hier muss jede Firma selbst herausfinden, was für sie am besten funktioniert.
Fazit
Schon bevor ein Kundenprojekt überhaupt beginnt, können bestimmte in Agenturen übliche Rahmenbedingungen den Erfolg agiler Projekte gefährden oder sogar unmöglich machen. Hier ist eine neue Denkweise auf allen Ebenen und in allen Disziplinen in der Agentur gefragt, welche Änderungen mit sich bringt, die sich nicht von heute auf morgen umsetzen lassen.
Die im Artikel aufgeführten Punkte können als Leitfaden dienen, um Fallen und Probleme bei der Planung agiler Projekte schon vor Beginn zu erkennen und zu thematisieren.
Wie sind deine Erfahrungen zum Thema? Kennst du noch weitere Umstände, die agiles Arbeiten erschweren? Dann poste sie gerne als Kommentar unter diesem Artikel.
Weiterführende Quellen
Aperto Move - An IBM Company ist eine Berliner Agentur für digitale und mobile Services mit ca. 30 Mitarbeitern. Bald auch mit dir?
Folge uns: apertomove.de / Facebook / Twitter
