Journey to Agile: Jak firma Braze przeprojektowała swój proces zarządzania projektami oprogramowania

Tworzenie planu

Po krótkiej refleksji zdecydowaliśmy się przejść w kierunku wypróbowanej i prawdziwej metodologii dla zespołów inżynierskich — zdecydowaliśmy, że chcemy stać się bardziej zwinni.

Aby podejść do tego nowego wyzwania, chcieliśmy stworzyć grupę, która reprezentowałaby i wykorzystywałaby wiedzę całej naszej organizacji zajmującej się produktami i inżynierią — dlatego utworzyliśmy komitet składający się z ośmiu członków reprezentujących zarządzanie produktem, projektowanie i inżynierię. Uwzględniliśmy zarówno menedżerów, jak i indywidualnych współpracowników, a także osoby o różnym poziomie wykształcenia Agile, stażu pracy i doświadczenia.

Ten Komitet Agile, jak go nazwaliśmy, podszedł do sytuacji, mając na uwadze kilka kluczowych zasad:

• Chcieliśmy korzystać ze sprawdzonych rozwiązań tam, gdzie to możliwe, zarówno w zakresie metodologii, jak i oprogramowania. Bycie wyjątkowym wymaga wiele wysiłku i chcieliśmy być wyjątkowi tylko w koniecznych i strategicznych obszarach. Chcieliśmy również, aby ludzie mogli zapoznać się z najlepszymi praktykami Google dotyczącymi zarządzania swoją pracą — lub, jeszcze lepiej, aby ludzie dołączyli do Braze już wiedząc głównie, jak to zrobić.
• Chcieliśmy, aby zespoły inżynierów produktu w Braze były w dużej mierze spójne w sposobie działania, ponieważ umiejętność mówienia tym samym językiem jest cenna.
• Nie chcieliśmy robić niczego dogmatycznie, bez przemyślenia. Samo wybranie metody, a następnie podążanie za książką nie było wystarczająco dobre; ważne było dla nas, aby zdrowy rozsądek i przemyślane iteracje rządziły tym dniem.

Uzbrojeni w te wytyczne, postanowiliśmy wykorzystać Scrum, który jest frameworkiem Agile, który okazał się skuteczny w wielu organizacjach. Jest powszechnie znany, skalowalny i jest bezpiecznym, domyślnym wyborem, gdy chcesz zaimplementować proces Agile.

Następnie stanęliśmy przed dwiema głównymi decyzjami: (1) jakich narzędzi powinniśmy użyć, aby wesprzeć nasz nowy proces oraz (2) jak powinniśmy wprowadzić zmiany w naszym procesie. Rozmawialiśmy o kilku programach, ocenialiśmy je i prezentowaliśmy w wersji demonstracyjnej — ostatecznie Jira firmy Atlassian okazała się dla nas właściwym wyborem. Jest to sprawdzone rozwiązanie, kilka osób w naszym zespole miało już doświadczenie w jego używaniu, a inne zespoły w Braze już z niego korzystały, co otwiera możliwość lepszej współpracy między zespołami, ponieważ wszyscy pracowalibyśmy w ramach jednego systemu.

Jeśli chodzi o wybór planu wdrożenia Agile, musieliśmy podjąć kilka kluczowych decyzji. Po pierwsze, jak szkolimy/udostępniamy zespół? Moglibyśmy zatrudnić trenera Agile, zatrudnić osoby z doświadczeniem w zespole do pracy nad szkoleniem innych lub pozyskać konsultantów do pomocy. Po drugie, czy powinniśmy sprawić, by zespoły inżynierów, które miały pewne doświadczenie w Agile, czekały na szkolenie przed jego wdrożeniem?

W końcu postanowiliśmy pozwolić zespołom, które były zaznajomione z Jira i Scrumem, zacząć w takim stopniu, w jakim czują się na siłach, i zatrudniliśmy konsultanta, który pomógłby w przejściu całej organizacji. Nie byliśmy zainteresowani tym, aby ludzie z naszego zespołu lub niezależny gracz byli głównie odpowiedzialni za szkolenie członków zespołu podczas przejścia, ponieważ:

• Nie chcieliśmy, aby jakikolwiek indywidualny zespół był właścicielem tego, jak robimy Agile i czuliśmy, że szkolenie będzie lepiej odbierane, a sugestie będą bardziej wyczerpujące, jeśli pochodzą od strony trzeciej
• Pomyśleliśmy, że biznes konsultingowy będzie stabilniejszy i bardziej niezawodny niż indywidualny trener Agile
• Chcieliśmy odbyć podstawowe szkolenie dla całej organizacji inżynierskiej i zacząć bez żadnych założeń co do wiedzy, jaką poszczególni członkowie organizacji posiadali na temat Agile
• Na koniec chcieliśmy, aby trenerzy odeszli w pewnym momencie, aby było jasne, że wszyscy w naszej organizacji są odpowiedzialni za utrzymanie procesu w przyszłości

Realizacja planu

Po kilku miesiącach planowania otrzymaliśmy duży dokument opisujący wszystko, co zamierzaliśmy zrobić — i udostępniliśmy go całej organizacji w celu uzyskania opinii. Następnie, po ocenie kilku dostawców, wybraliśmy Eliassen do współpracy z nami w drodze do Agile. Ta podróż rozpoczęła się od dwudniowego treningu Agile prowadzonego przez Eliassen, po którym nastąpiły trzy miesiące coachingu Agile od eksperta, z którym połączył nas Eliassen.

Od samego początku byliśmy dość ostrożni przy przechodzeniu do Jira i Scruma. Zarówno Internet, jak i osobiste doświadczenia naszego zespołu były pełne ostrzegawczych opowieści o niebezpieczeństwach nadmiernie dogmatycznych podejść, o tym, jak Jira może funkcjonować jako „antywzorzec” io wszystkich sposobach, w jakie Scrum może nie działać w organizacjach. Zostaliśmy ostrzeżeni przez osoby, z którymi się konsultowaliśmy, że te zmiany prawdopodobnie zajmą trochę czasu i że zanim zobaczymy prawdziwe korzyści z Agile, mogą pojawić się problemy.

Na szczęście od razu znaleźliśmy wartość w nowym procesie. Jedną z miłych rzeczy w tym przejściu jest to, że nigdy nie czuliśmy żadnej presji, by ślepo podążać za jakimś konkretnym aspektem Scruma; aby wszystko działało lepiej, co kilka tygodni robiliśmy retrospektywę tego, jak się sprawy miały, a następnie modyfikowaliśmy to, co wymagało modyfikacji. W ciągu trzech miesięcy coachingu wdrożyliśmy gruntowne zmiany w całej organizacji inżynierskiej:

• Wszyscy nauczyli się pisać, pielęgnować, wskazywać, rozkładać i podnosić historyjki użytkowników
• Standupy znalazły nowe skupienie, gdy przyszło do ukończenia pracy pod ręką
• Produkty, projektowanie i inżynieria nauczyły się mówić tymi samymi językami, a interfejsy były coraz lepiej zaprojektowane

Wyniki

Teraz, gdy jesteśmy po drugiej stronie tego mniej więcej półrocznego wysiłku, zmiany są wyraźne – i dramatyczne. Zauważyliśmy znaczną redukcję problemów, które doprowadziły do ​​tego wysiłku. Dzięki Agile mamy teraz jasną i łatwą do zrozumienia mechanikę zatwierdzania, współpracy, tworzenia zaległości i pielęgnacji, a także regularnie przeprowadzamy retrospektywy dotyczące tego, co należy ulepszyć.

Mamy również znacznie bardziej spójne lokalizacje dla artefaktów projektowych, a także lepiej dopasowane oczekiwania dotyczące tego, co naprawdę „zrobione” jest dla danego projektu. Zobaczenie, nad czym pracują inne zespoły, stało się łatwe, a ludzie łatwiej niż kiedykolwiek wcześniej rozumieją, jak dobrze ze sobą współpracować.

Coś, co zauważyłem pod koniec tego przejścia, to fakt, że całkowita liczba otwartych żądań pull w organizacji w danym momencie spadła, nawet jeśli robiliśmy więcej i zwiększaliśmy rozmiar naszego zespołu. Pracując w mniejszych krokach i skupiając się na wykańczaniu rzeczy, liczba przedmiotów w locie znacznie się zmniejszyła.

Sukces, jaki odnieśliśmy w naszej organizacji, zainspirował także innych. Zaczynamy widzieć zespoły w innych działach Braze rozpoczynające własne transformacje Agile, więc wkrótce więcej osób będzie mówić tym samym językiem i mieć narzędzia, których potrzebują do definiowania i ulepszania współpracy.

Na wynos

Dwa główne elementy naszego wysiłku zapewniły jego sukces.

Po pierwsze, fakt, że był on kierowany przez komitet przedstawicielski, był niezbędny do uzyskania informacji z całej organizacji inżynierskiej iz różnych perspektyw. W całej firmie ludzie czuli się wysłuchani i reprezentowani w kwestii, która wpłynie na ich codzienną pracę. Późniejsze stworzenie dokładnego dokumentu przedstawiającego motywacje i plany przejścia na Agile, które można było udostępnić zespołowi, było również bardzo przydatne. Wierzymy w pokazywanie, w jaki sposób podejmowane są decyzje i wprowadzanie jasnych ścieżek dla informacji zwrotnej — ponieważ zapewnia to kontekst i tworzy artefakt, na podstawie którego można przekazać informację zwrotną.

Po drugie, decyzja o pozyskaniu osoby trzeciej do pomocy w trenowaniu naszego zespołu była niezbędna. Posiadanie obiektywnego, doświadczonego partnera dało nam możliwość szybkiego wprowadzenia licznych usprawnień w naszym procesie. Nasz trener wiedział, jak wygląda dobro i był w stanie formułować zalecenia bez uprzedzeń. Kilka razy byliśmy w stanie zapytać: „Jak zespoły normalnie robiłyby X?”. i uzyskaj natychmiastowe, praktyczne rozwiązanie. Z drugiej strony, gdybyśmy korzystali z zasobów wewnętrznych, narazilibyśmy się na ryzyko, że otrzymana przez nas informacja zwrotna pochodziła od stronniczej strony i zwiększyła rywalizację o zasoby z istniejącymi obowiązkami.

Coś jeszcze?

Jeśli chcesz dowiedzieć się więcej o tym, jak myślimy o naszym produkcie i pracy włożonej w jego wykonanie, sprawdź Building Braze. Chcesz dołączyć do naszego zespołu? Sprawdź nasze aktualne oferty pracy.