8 Best Practices für eine erfolgreiche Skalierung agiler Entwicklung

    Die Herausforderungen agiler Skalierung Erfahren Sie mehr über 8 Best Practices für eine erfolgreiche Skalierung agiler Entwicklung in großen Unternehmen.

    Abonnieren Sie unseren Blog

    Viele Unternehmen haben bei der Entwicklung ihrer digitalen Anwendungen bereits auf agile Methoden wie Scrum oder Kanban umgestellt. Aufgrund der steigenden Beliebtheit dieser Anwendungen und den zunehmenden Erwartungen der Benutzer wachsen die Entwicklungsteams jedoch immer schneller, sodass auch die Notwendigkeit zunimmt, die agilen Methoden in größerem Maßstab anzuwenden. Daraus erwachsen viele Herausforderungen: Wie können Sie flexibel und effizient bleiben? Wie können Sie weiterhin hohe Qualität garantieren und dennoch berechenbare Ergebnisse liefern? Wie können Sie die Geschwindigkeit erhöhen? Nachstehend erläutere ich die Antworten auf diese Fragen anhand von 8 Best Practices für eine erfolgreiche Skalierung agiler Entwicklung.

    Dienende Führung

    Dienende Führung bedeutet eigentlich „dem Team dienen“. Stellen Sie sicher, dass Ihr Team so weit wie möglich von Managemententscheidungen/-beeinflussung ferngehalten wird. Investieren Sie Ihre Zeit in die Unterstützung anderer Teammitglieder bei Kommunikation, Koordination und Zusammenarbeit. Sorgen Sie ganz allgemein dafür, dass Ihr Team das Ziel erreichen kann. Das heißt auch, dass Sie Ihrem Team vertrauen müssen. Überlassen Sie es dem Team, sich selbst zu organisieren und zu leiten. Bieten Sie den Teams auch die Möglichkeit, Initiativen auszuprobieren. Unterstützen Sie das Team bei der Verteidigung dieser Initiativen gegenüber höheren Ebenen.

    Wachstum in Phasen

    Wenn der Bedarf hoch ist und der Druck auf das Team zur schnellen Skalierung immer größer wird, sollten Sie während des Wachstums darauf achten, dass alle noch ausreichend Luft haben. Diese Luft ist nötig, damit das Team nach jeder Änderung schnell wieder auf Hochtouren laufen kann. Sie brauchen jedoch auch Zeit, um zu reflektieren und auf die richtige Art und Weise weiter zu wachsen. Planen Sie jedes Mal einen Puffer für den nächsten Schritt ein. Verheizen Sie Ihre Mitarbeiter nicht. Senken Sie die Output-Vorgaben, indem Sie Raum für freie Zeit lassen. Diese Zeit kann für die Arbeit an Initiativen genutzt werden, die das Wachstum fördern. Versuchen Sie, das richtige Verhältnis zwischen Output (Ergebnisse) und Teamwachstum zu finden.

    Stabile Teams

    Die Mischung von Teams ist erlaubt und wird sogar empfohlen. Auf diese Weise können Sie sicherstellen, dass Entwickler mittendrin sind und lernen, mit allen zusammenzuarbeiten. Dadurch entwickeln sie sich zu multidisziplinären Teammitgliedern. Außerdem erhalten die Teams so die Möglichkeit, die Zusammenarbeit zu vertiefen, und die Entstehung isolierter Zellen wird vermieden. Sie sollten die Durchmischung jedoch nicht übertreiben. Wenn zu viel gemischt wird, kann sich dies kontraproduktiv auswirken. Mischen Sie die Teams nicht bei jedem Sprint, sondern lieber nur bei jedem Release, sodass die Teams für längere Zeit stabil bleiben.

    Tester als Teil des Teams

    Es darf sich keine Kluft zwischen den Entwicklern und Testern auftun. Ein separates Testteam ist daher offensichtlich keine gute Idee. Beteiligen Sie Ihre Tester an den Sprints, damit sie wissen, was gebaut wird und was getestet werden muss. Tester machen viel mehr als nur Testen und Programmfehler protokollieren. Sie sind Teil des Entwicklungsteams und arbeiten eng mit dem Produkteigentümer zusammen. Sie arbeiten mit allen Teammitgliedern zusammen, um das Produkt so früh wie möglich zu verbessern und für mehr Qualität zu sorgen. Durch die Kollaboration mit dem Produkteigentümer können die Tester mehr Details zu den Storys erfahren und so wird es für die Teams einfacher, die Akzeptanzkriterien zu erfüllen.

    Führen Sie spielerische Elemente ein!

    Um die Qualität hoch zu halten und Programmfehler weitgehend zu vermeiden, sollte die Zahl der Fehler pro Team sichtbar gemacht werden. Sie können beispielsweise die Zahl der kritischen Programmfehler pro Team auf einem großen Bildschirm anzeigen. Auf diese Weise fördern Sie den Wettbewerb zwischen den Teams, die daraufhin eher versuchen werden, zuerst die Programmfehler zu lösen, bevor sie mit der Entwicklung neuer Funktionen weitermachen. Geben Sie vor, dass höchstens drei Programmfehler offen sein dürfen, bevor die Entwicklung fortgesetzt werden kann.

    Eliminieren Sie Störungen

    Sorgen Sie dafür, dass Support-Probleme oder Störfälle nicht bei den Entwicklungsteams landen. Sie werden dadurch ihren Fokus verlieren und nicht mit den geplanten Entwicklungen für die Sprints fertig werden. Wenn erfahrene Mitarbeiter ständig um Rat gefragt werden, kommt es zu ungeplanten Prioritätsverschiebungen und unberechenbaren Lieferzeiten. Eliminieren Sie Störungen. Stellen Sie ein separates Team zusammen, das nur für solche Problem zuständig ist. Dieses Team kann sich um alle nach dem Release anstehenden Aufgaben kümmern, Ansprechpartner für externe Parteien sein, Probleme in Hotfixes oder externe Release-Fixes kategorisieren und den Status eines Fehlers klar kommunizieren. Darüber hinaus kann das Team strukturelle Überarbeitungen vornehmen (für das Wachstum erforderlich), die alle in einem technischen Backlog gesammelt werden. So sorgen Sie dafür, dass dieses Team konstant beschäftigt ist, auch in Zeiten, in denen weniger Probleme gemeldet werden.

    Schätzung in Story Points

    Das Problem bei Schätzungen in Manntagen ist, dass die Menschen zur Selbstüberschätzung neigen (vor allem jüngere Mitarbeiter). Dies führt häufig zu Budgetüberschreitungen. Durch die Schätzung in Story Points können Sie Ihre Mitarbeiter dazu zwingen, eine Schätzung anhand von relativen Werten vorzunehmen, die auf dem für die Implementierung des Backlog Item erforderlichen Gesamtaufwand basieren. Da sich die Teamgeschwindigkeit nach einigen Sprints stabilisieren wird, werden Sie einschätzen können, wie viele Manntage Ihr Team pro Story Point benötigt. Bei den nächsten Schätzungen können Sie die geschätzten Story Points leicht auf die Anzahl an Tagen umrechnen und auf diese Weise möglichst realistische Schätzungen erhalten.

    Strukturbereinigung

    Sobald die Nutzung Ihrer Anwendung einen großen Anstieg verzeichnet, ist die Chance groß, dass Ihre Codebasis und Anwendungsarchitektur nicht auf dieses Wachstum vorbereitet ist. Dadurch werden Jahre der Weiterverwendung zunichte gemacht. Sie können einen schlechten Code jedoch nicht skalieren. Nehmen Sie sich die Zeit für eine strukturelle Überarbeitung, um das Wachstum zu vereinfachen. Setzen Sie diese Überarbeitungsaktivitäten auf die Kanban-Tafel und lassen Sie das Support-Team daran arbeiten. Sie können auch die Zeit nutzen, die Sie als Puffer eingeplant hatten. So wird bei jedem Schritt die Einhaltung von Qualitätsstandards sichergestellt und eine hohe Geschwindigkeit und ein nachhaltiges Entwicklungstempo erzielt.

    Veröffentlicht auf    Zuletzt aktualisiert am 31/07/2018

    #Digitale Strategie, #Développement Web

    Über den Autor

    Dimitri Honlet is Project Manager at Amplexor Belgium. For the past 6 years, he’s been delivering successful projects for customers from A to Z, managing teams of skilled consultants and developers, controlling planning, scope, quality and budget. He has gained experience working on numerous projects in different technologies (SDL, AEM, Drupal, SharePoint) for customers active in the banking, manufacturing, retail or public sector. He’s passionate about exploring all new trends and methodologies in Project Management in order to continually improve delivering web development projects according to plan.

    SUBSCRIBE TO OUR BLOG