Journey to Agile: Wie Braze seinen Software-Projektmanagementprozess neu konzipierte

Einen Plan machen

Nach einigem Nachdenken entschieden wir uns für eine erprobte Methodik für Engineering-Teams – wir beschlossen, agiler zu werden.

Um diese neue Herausforderung anzugehen, wollten wir eine Gruppe zusammenstellen, die das Wissen unserer gesamten Produkt- und Engineering-Organisation repräsentiert und nutzt – also haben wir einen Ausschuss mit acht Mitgliedern gegründet, die Produktmanagement, Design und Engineering vertreten. Wir haben sowohl Manager als auch einzelne Mitwirkende sowie Personen mit unterschiedlichem Hintergrund, Dienstalter und Erfahrung im Bereich Agile eingeschlossen.

Dieses agile Komitee, wie wir es nannten, ging die Situation mit einigen Grundprinzipien fest im Hinterkopf an:

• Wir wollten nach Möglichkeit bewährte Lösungen verwenden, sowohl methoden- als auch softwareübergreifend. Es kostet viel Mühe, einzigartig zu sein, und wir wollten nur in notwendigen und strategischen Bereichen einzigartig sein. Wir wollten auch, dass die Leute in der Lage sind, Best Practices für die Verwaltung ihrer Arbeit von Google zu nutzen – oder, noch besser, Leute dazu bringen, Braze beizutreten, die bereits größtenteils wissen, wie es geht.
• Wir wollten, dass die Produktentwicklungsteams in Braze weitgehend einheitlich arbeiten, weil es wertvoll ist, dieselbe Sprache sprechen zu können.
• Wir wollten nichts dogmatisch oder unüberlegt machen. Nur eine Methode auszuwählen und sich dann an das Buch zu halten, war nicht gut genug; Uns war wichtig, dass gesunder Menschenverstand und durchdachte Iteration den Tag regierten.

Ausgerüstet mit diesen Richtlinien entschieden wir uns für Scrum, ein agiles Framework, das sich in vielen Organisationen bewährt hat. Es ist weithin bekannt, skalierbar und die sichere Standardwahl, wenn Sie einen agilen Prozess implementieren möchten.

Als nächstes standen wir vor zwei Hauptentscheidungen: (1) welche Tools wir verwenden sollten, um unseren neuen Prozess zu unterstützen, und (2) wie wir die Änderungen an unserem Prozess einführen sollten. Wir haben mehrere Softwarekomponenten besprochen, bewertet und vorgeführt – und letztendlich hat sich Jira von Atlassian als die richtige Wahl für uns erwiesen. Es ist eine bewährte Lösung, mehrere Leute in unserem Team hatten bereits Erfahrung damit, und andere Teams innerhalb von Braze nutzten sie bereits, was eine Möglichkeit für eine bessere teamübergreifende Zusammenarbeit eröffnete, da wir alle innerhalb eines Systems arbeiten würden.

Bei der Auswahl eines Einführungsplans für Agile mussten wir einige wichtige Entscheidungen treffen. Erstens, wie trainieren/befähigen wir das Team? Wir könnten einen Agile-Coach einstellen, Leute mit Erfahrung im Team die Arbeit der Schulung der anderen übernehmen lassen oder Berater zur Unterstützung hinzuziehen. Zweitens, sollten wir Teams innerhalb der Technik, die etwas Erfahrung mit Agile hatten, auf eine Schulung warten lassen, bevor sie es implementieren?

Am Ende entschieden wir uns, Teams, die mit Jira und Scrum vertraut waren, in dem Umfang beginnen zu lassen, in dem sie es für möglich hielten, und stellten einen Berater ein, um bei der unternehmensweiten Umstellung zu helfen. Wir waren nicht daran interessiert, dass Leute in unserem Team oder ein unabhängiger Spieler in erster Linie dafür verantwortlich sind, die Teammitglieder während des Übergangs zu coachen, weil:

• Wir wollten nicht, dass ein einzelnes Team darüber entscheidet, wie wir Agilität machen, und wir waren der Meinung, dass das Training besser angenommen und die Vorschläge umfassender wären, wenn sie von Dritten kommen würden
• Wir dachten, ein Beratungsunternehmen wäre stabiler und zuverlässiger als ein individueller Agile-Coach
• Wir wollten eine Grundschulung für die gesamte Engineering-Organisation haben und beginnen, ohne Annahmen über das Wissen zu treffen, das einzelne Mitglieder der Organisation in Bezug auf Agile haben
• Schließlich wollten wir die Trainer zu einem bestimmten Zeitpunkt gehen lassen, um deutlich zu machen, dass jeder in unserer Organisation dafür verantwortlich ist, den Prozess in Zukunft aufrechtzuerhalten

Ausführung des Plans

Nach ein paar Monaten der Planung hatten wir ein großes Dokument, in dem alles detailliert beschrieben war, was wir vorhatten, und wir teilten es der gesamten Organisation mit, um Feedback zu erhalten. Nachdem wir mehrere Anbieter evaluiert hatten, entschieden wir uns für Eliassen als Partner auf dem Weg zu Agile. Diese Reise begann mit einem zweitägigen Agile-Training, das von Eliassen durchgeführt wurde, gefolgt von einem dreimonatigen Agile-Coaching durch einen Experten, mit dem Eliassen uns verbunden hat.

Von Anfang an waren wir ziemlich vorsichtig mit dem Umstieg auf Jira und Scrum. Sowohl das Internet als auch die persönlichen Erfahrungen unseres Teams waren voller warnender Geschichten über die Gefahren übermäßig dogmatischer Ansätze, darüber, wie Jira als „Anti-Pattern“ fungieren kann, und über all die Möglichkeiten, wie Scrum in Organisationen schief gehen kann. Wir wurden von Leuten, die wir konsultierten, stark davor gewarnt, dass diese Änderungen wahrscheinlich Zeit brauchen würden und dass es durchaus Wachstumsschmerzen geben könnte, bevor wir echte Vorteile von Agile sehen.

Zum Glück haben wir sofort den Wert des neuen Prozesses erkannt. Eines der schönen Dinge an diesem Übergang ist, dass wir nie den Druck verspürten, blind einem bestimmten Aspekt von Scrum zu folgen; Damit die Dinge besser liefen, machten wir alle paar Wochen eine Retrospektive darüber, wie die Dinge liefen, und änderten dann, was geändert werden musste. Und während des dreimonatigen Coachings haben wir umfassende Änderungen in der gesamten Engineering-Organisation vorgenommen:

• Jeder hat gelernt, User Stories zu schreiben, zu pflegen, zu zeigen, aufzuschlüsseln und aufzugreifen
• Standups fanden einen neuen Fokus, wenn es darum ging, die anstehende Arbeit zu beenden
• Produkt, Design und Technik lernten alle, die gleichen Sprachen zu sprechen, und Schnittstellen wurden immer besser gestaltet

Die Ergebnisse

Jetzt, da wir uns auf der anderen Seite dieser ungefähr sechsmonatigen Bemühungen befinden, sind die Veränderungen klar – und dramatisch. Wir haben eine deutliche Verringerung der Probleme festgestellt, die zu dieser Anstrengung geführt haben. Mit Agile haben wir jetzt klare und leicht verständliche Mechanismen für Signoff, Zusammenarbeit, Backlog-Erstellung und Grooming, und wir führen regelmäßig Retrospektiven darüber durch, was verbessert werden kann.

Wir haben auch deutlich konsistentere Orte für Designartefakte sowie besser abgestimmte Erwartungen darüber, was für ein bestimmtes Projekt wirklich „fertig“ ist. Es ist einfach geworden, zu sehen, woran andere Teams arbeiten, und es ist für die Leute einfacher als je zuvor, zu verstehen, wie man gut zusammenarbeitet.

Etwas, das mir am Ende dieses Übergangs aufgefallen ist, ist, dass die Gesamtzahl der offenen Pull-Anforderungen in der Organisation zu einem bestimmten Zeitpunkt zurückgegangen ist, obwohl wir mehr getan haben und unser Team größer wurde. Durch die Arbeit in kleineren Schritten und die Fokussierung auf die Fertigstellung der Dinge ist die Anzahl der Artikel im Flug erheblich geschrumpft.

Der Erfolg, den wir in unserer Organisation hatten, hat auch andere inspiriert. Wir sehen allmählich Teams in anderen Abteilungen bei Braze, die ihre eigenen Agile-Transformationen beginnen, sodass bald mehr Leute dieselbe Sprache sprechen und über die Tools verfügen, die sie benötigen, um die Zusammenarbeit zu definieren und zu verbessern.

Imbiss

Zwei Hauptelemente unserer Bemühungen haben den Erfolg sichergestellt.

Erstens war die Tatsache, dass es von einem repräsentativen Ausschuss geleitet wurde, wesentlich, um Beiträge aus der gesamten Ingenieurorganisation und aus einer Vielzahl unterschiedlicher Perspektiven zu erhalten. Im gesamten Unternehmen fühlten sich die Mitarbeiter bei einem Thema gehört und vertreten, das sich auf ihre tägliche Arbeit auswirken würde. Die anschließende Erstellung eines ausführlichen Dokuments mit den Beweggründen und Plänen für einen agilen Übergang, das mit dem Team geteilt werden konnte, war ebenfalls sehr nützlich. Wir glauben daran, zu zeigen, wie Entscheidungen getroffen werden, und klare Pfade für Feedback einzuführen – weil es Kontext liefert und ein Artefakt etabliert, zu dem Feedback gegeben werden kann.

Zweitens war die Entscheidung, einen Dritten als Trainer für unser Team zu gewinnen, von entscheidender Bedeutung. Einen objektiven, erfahrenen Partner zu haben, gab uns die Möglichkeit, schnell zahlreiche Verbesserungen an unserem Prozess vorzunehmen. Unser Trainer wusste, wie gut aussah, und konnte unvoreingenommene Empfehlungen aussprechen. Einige Male konnten wir fragen: „Wie würden Teams X normalerweise abschneiden?“ und erhalten Sie eine sofortige, praktikable Lösung. Wenn wir andererseits interne Ressourcen genutzt hätten, wären wir Gefahr gelaufen, dass das Feedback, das wir erhielten, von einer voreingenommenen Partei kam und die Ressourcenkonkurrenz mit bestehenden Verantwortlichkeiten verstärkte.

Noch etwas?

Wenn Sie mehr darüber erfahren möchten, wie wir über unser Produkt denken und wie viel Arbeit in seine Herstellung gesteckt wird, schauen Sie sich Building Braze an. Interessiert, unserem Team beizutreten? Schauen Sie sich unsere aktuellen Stellenausschreibungen an.