GetResponse wskoczyło na żaglówki zwinności niewiele ponad rok temu. W obecnej chwili nasze łódki płyną już z dużą prędkością… W naszej firmie “Agile” nie jest tylko pustym hasłem, a idee zwinności rozprzestrzeniły się daleko poza IT. Postanowiliśmy więc podzielić się z Wami naszymi doświadczeniami i rozwiązaniami, jakie zastosowaliśmy.
Naszą serię zaczynamy od wywiadu z Michałem Błachnickim, wicedyrektorem IT, który jest szefem zespołu Scrum Masterów od początku jego istnienia. W tej krótkiej rozmowie poruszonych zostało wiele tematów, które będziemy rozwijać w kolejnych artykułach. Dajcie znać, co myślicie o sposobie wprowadzenia Agile w codzienną pracę GetResponse.
Agile w GetResponse – jak to się zaczęło?
Kiedy i dlaczego po raz pierwszy pomyśleliście o Agile?
Michał Błachincki: Jesienią 2014 roku. Dlaczego? Szukaliśmy jakiegoś rozwiązania, które byłoby odpowiedzią na fakt, że w dosyć krótkim czasie wymagania biznesowe mogą się zmieniać, bo w takim środowisku na co dzień się poruszaliśmy. Ponadto szukaliśmy czegoś, co usprawniłoby komunikację i zmniejszyło dystans pomiędzy product developmentem a IT. Zaczęliśmy interesować się Scrumem, a w międzyczasie nasze zainteresowanie podzielił właściciel firmy, Szymon. To on podjął decyzję: idziemy w tym kierunku. To było o tyle fajne, że od samego początku mieliśmy wsparcie “z samej góry”, w postaci prezesa i jednocześnie właściciela, który widział szansę dla firmy na pozytywna transformację. Również szef product developmentu i marketingu, Daniel Brzeziński, od samego początku wspierał tę ideę – wcześniej miał styczność z tym modelem pracy. To zrozumienie i wsparcie było dla nas niezwykle ważne.
Myślę, że dużą rolę w naszym wspólnym wyborze miały nie tylko zasady wprowadzane przez framework, ale również wartości które za tymi zasadami stoją. Okazało się, że są one bardzo bliskie wartościom wpisanym w kulturę naszej organizacji. To był znak mówiący – “polubicie się” 😉
Oczywiście, od momentu podjęcia decyzji do momentu jej realizacji minęło sporo czasu. Ważne jednak było to, że została ona podjęta, zakomunikowana i otworzyła nam drzwi do dalszych kroków.
Czy od początku myśleliście o Scrumie jako jedynej metodzie, czy zastanawialiście nad jakimiś innymi rozwiązaniami bazującymi na Agile’u?
MB: Zastanawialiśmy się nad kilkoma rozwiązaniami, ale od samego początku Scrum wydawał się najlepiej odpowiadać na nasze potrzeby – zmienność wymagań i usprawnienia w komunikacji. Oczywiście, nasze myślenie ewoluowało. Pierwszy pomysł był taki: robimy czystego Scruma, nie robimy żadnego “Scrum by GetResponse”, wszystko będzie tak jak powinno być “by the book”. Ale im dłużej się nad tym zastanawialiśmy, tym więcej mieliśmy wątpliwości. I tak powstał pomysł na implementację kultury Agile z zastosowaniem Scruma nie w całym obszarze IT, ale tam, gdzie przyniosłoby to najwięcej korzyści.
W międzyczasie poprosiliśmy Andy’ego Brandta o konsultacje. Mieliśmy już gotową koncepcję, którą chcieliśmy zweryfikować z punktu widzenia jego doświadczenia. Okazało się, że idziemy w dobrym kierunku 😉
Można powiedzieć, że zdecydowaliście się na stopniowy proces wdrażania Agile – ewolucyjny, a nie rewolucyjny?
MB: Transformacja ruszyła na poważnie jakieś pół roku od podjętych decyzji. Wcześniej podjęliśmy kilka kroków, które dawały namiastkę elementów wywodzących się z Agile’a czy też ze Scruma. Powstał pierwszy backlog dla części IT, za który był odpowiedzialny Product Development. Zaczęliśmy się spotykać i planować prace zgodnie ze wspólnie ustalonymi priorytetami.
To było dalekie od Scruma, ale już wtedy uzyskaliśmy widoczne efekty. Po pierwsze, Product Development decydował o tym, co jest realizowane i w jakiej kolejności. Po drugie, rozpoczęliśmy cykliczne rozmowy o tym jakie są oczekiwania i ich priorytety ale też jakie mamy możliwości ich realizacji. To współdziałanie pozwoliło nam na lepsze podejmowanie decyzji i wzajemnie zrozumienie wszystkich warunków, które na nie wpływały. Już to znacznie poprawiło współpracę i dało początek fajnemu, wspólnemu działaniu.
Wracając do procesu wdrożenia, na początku faktycznie rozważaliśmy dwa modele, zasadniczo klasyczne, wystartowanie jednego zespołu pilotażowego, albo pójście “na całość”. Przy czym co do pierwszego podejścia, wciąż mam w pamięci wywiad z jednym z menedżerów Allegro, który mówił o wnioskach z próby wdrażania Scruma za pomocą zespołu pilotażowego i nie były one zachęcające.
Od początku założyliśmy więc, że podzielimy nasz Produkt i dział IT na obszarowe Zespoły Scrumowe. Ale cały proces nie wydarzył się jednego dnia, to była “rewolucja przez ewolucję”, tak można to najlepiej opisać.
Poznajmy szczegóły
Jak wyglądał proces podziału aplikacji na obszary i przypisywania do nich Zespołów?
MB: Sporo czasu poświęciliśmy na znalezienie recepty na to jak sprawić, żeby zespoły w ramach danych obszarów były interdyscyplinarne. To było duże wyzwanie. Rozpoczęliśmy od rozmowy z Product Developmentem. Ustaliliśmy jakie są (i będą w najbliższej przyszłości) filary naszej aplikacji i to sprawiło, że powoli podział zaczął się krystalizować. W międzyczasie zatrudniliśmy dwóch Scrum Masterów i wraz z nimi omówiliśmy wstępne koncepcje wynikające ze wcześniejszych rozmów.
Pierwszy Zespół zbudowaliśmy wokół wspomnianego wcześniej backloga, nazwijmy go “ogólnoproduktowym”, który z czasem, wraz ze wzrostem kompetencji i liczebności wypączkował na dwa równoprawne Zespoły, opiekujące się konkretnymi fragmentami aplikacji. Utworzyliśmy też dwa kolejne zespoły dedykowane wypracowanym wcześniej obszarom.
Zaczynaliśmy od dwóch Scrum Masterów i dwóch Product Ownerów. Stopniowo powstawały dodatkowe Zespoły Scrumowe obejmujące nowe obszary produktu.
A co zdecydowało o tym, że nie ma i nie będzie tak zwanego “zespołu utrzymaniowego”? Ta mocno dyskusyjna jednostka istnieje w wielu organizacjach, również tych “agile’owych”.
MB: Od początku założyliśmy, że podzielimy nasz produkt i dział IT na obszarowe zespoły scrumowe, ale nie chcieliśmy wprowadzać do organizacji zespołu utrzymaniowego. Na to przekonanie składały się w znacznej mierze nasze wcześniejsze doświadczenia. To oczywiste, że nikt nie lubi zajmować się jedynie usuwaniem błędów, tym bardziej, jeśli są cudze. Z reguły trudno znaleźć chętnych do tego typu pracy, a rotacja pracowników w takich zespołach jest duża. Takie podejście źle wpływa także na inne zespoły, w których może powstać syndrom przyzwolenia na myślenie “najwyżej utrzymanie poprawi”. Co za tym idzie, cierpi jakość oddawanych produktów i rozwiązań.
Naturalną decyzją, było dla nas to, aby poszczególne zespoły odpowiadały za utrzymanie swoich obszarów. W proces zostali zaangażowani również Product Ownerzy jako osoby w pełni odpowiedzialne za produkt i mogące zdecydować czy realizujemy dzisiejszego dnia zgłoszenie błędu, czy też może on poczekać. Oczywiście sam proces usuwania poważnych awarii działa nadrzędnie i jeśli wystąpią, to są podejmowane natychmiast, ale pozostałe drobne błędy/zgłoszenia/sugestie trafiają do Product Ownerów i podlegają standardowej priorytetyzacji.
Podsumowując, z perspektywy czasu uważam, że brak zespołu utrzymaniowego to była bardzo dobra decyzja.
Jak te wszystkie zmiany były odbierane w organizacji? Jak radziliście sobie z niepewnością, nieufnością wobec zmian?
MB: Nie napotkaliśmy większych problemów. Myślę, że ludzie są zadowoleni ze zmian, które zaszły. Ale podstawą tego była dobra komunikacja. Wykonaliśmy na początku pracę u podstaw, zanim zaczęliśmy jakiekolwiek zmiany.
Po pierwsze, odbył się cykl szkoleń dla osób z kierownictwa, które w niektórych przypadkach zakończyły się certyfikacją PSM. Wiedzieliśmy, że te osoby nie będą Scrum Masterami, ale chcieliśmy, aby wszyscy dobrze zrozumieli zagadnienie, przynajmniej na poziomie teoretycznym.
Następnie, przedstawiciele Product Developmentu również odbyli szkolenia, skupione na roli Product Ownera. Wszyscy na styku procesu produkcji zaczęli wiedzieć “o co tu chodzi”. Oczywiście szkolenie przeszli także wszyscy deweloperzy IT, aby zmniejszyć próg wejścia do nowej rzeczywistości i zminimalizować obawy.
W każdym z tych przypadków wspomagaliśmy się zewnętrznym trenerem. Odbyliśmy również cykl spotkań kierownictwa z zespołem IT, gdzie na bieżąco omawialiśmy co się będzie działo i w jaki sposób.
To był proces, kształtował się etapami. Jak chcemy dzielić zespoły, jak pracować, jaki jest pomysł na samodzielność zespołów, jakie są jej granice, jak powinna wyglądać rola architekta, a jak kierownika. Zajmowaliśmy się po kolei każdym z tych zagadnień i szukaliśmy odpowiednich dla nas rozwiązań, na bieżąco komunikując je wszystkim zainteresowanym.
W jaki sposób rozwiązane zostały obawy osób na stanowiskach kierowniczych? Obawy przed tym, że wraz z wprowadzeniem nowego trybu pracy ich rola potencjalnie ulegnie zmniejszeniu lub ciężko im się będzie odnaleźć w nowych warunkach. Jak rozumiem, na te obawy miały odpowiadać szkolenia wewnętrzne i spotkania IT?
MB: Tak, przede wszystkim od samego początku rozmawialiśmy. Również indywidualnie, bo wątpliwości oczywiście były, podczas takich zmian nie sposób ich uniknąć. Założyliśmy jednak, że nie chcemy nikogo stracić, miejsce w organizacji znajdzie się dla wszystkich osób, bo są dla nas cenne.
Gdybyśmy podeszli do tego tematu książkowo, to tak naprawdę liczbę kierowników w IT powinniśmy ograniczyć do minimum. Ale z nikim nie chcieliśmy się rozstawać.
W efekcie – ofiar nie było 😉
Scrum Masterzy
Przejdźmy do tematu Scrum Masterów. Wszyscy, którzy zostali zatrudnieni na początku transformacji są osobami spoza organizacji. Skąd taka decyzja?
MB: Uznaliśmy, że nie warto wyważać drzwi, które już kiedyś ktoś wyważył. Warto skorzystać z doświadczeń osób, które w innych firmach już wdrażały Scruma. Liczyliśmy też, że te osoby wniosą pewien powiew świeżości do naszego sposobu myślenia. Na początku mieliśmy tylko wyobrażenia o tym, co chcemy osiągnąć, a ludzie z zewnątrz, którzy już pracowali w ten sposób, wnieśli praktykę i swoje doświadczenia. To była od początku przemyślana, świadoma decyzja.
Wspomniałeś, że od momentu decyzji i jej ogłoszenia, do oficjalnego rozpoczęcia transformacji minęło około pół roku. Czy to nie trwało za długo? Czy nie powstał problem “rozejścia się po kościach” tego tematu? I druga sprawa – czy nie nazbyt ryzykowne było na początku wprowadzenie tylko części elementów Scruma, jak backlog i planowanie sprintu?
MB: Nomenklatura była celowo wprowadzona od samego początku tak, żeby oswoić ludzi z tymi bytami, nawet jeśli to nie był – przykładowo – backlog w pełnym tego słowa znaczeniu. To było przygotowanie do uruchomienia pewnych procesów, zaczęło wszystko powoli porządkować i układać w naszych głowach.
Był oczywiście pewien efekt uboczny – ku naszemu zaskoczeniu – okazało się, że część osób traktowała to, co się działo już jako działający Scrum 😉
Ale wracając do pierwszego pytania – tak, zdecydowanie początkowy etap wdrożenia według mojej opinii powinien trwać krócej. Jednym z powodów jego wydłużenia było poszukiwanie dobrych Scrum Masterów, okazało się, że to wcale nie jest takie łatwe.
I co teraz?
Na jakim etapie obecnie jest transformacje Agile w GetResponse?
MB: Wiadomo, że proces wdrażania Agile to proces ciągły, który nie ma końca. Dołączają do nas nowi ludzie, zmieniają się uwarunkowania na rynku biznesowym…
Natomiast to miejsce, w którym jesteśmy teraz, mi się już bardzo podoba. Zespoły są coraz dojrzalsze i robią coraz większe postępy.
Aplikacja jest podzielona praktycznie w całości na obszary i objęta opieką dedykowanych zespołów. Wykonaliśmy też mnóstwo pracy związanej z samymi procesami technicznymi, wdrażaniem, obsługą testów, standardami kodowania i mierzeniem różnych aspektów aplikacji. Rezultaty są zgodne z tym, czego oczekiwaliśmy na tym etapie, a nawet lepsze. Wytwarzamy szybciej i bez dwóch zdań podniosła się jakość oddawanych produktów.
Na pewno mamy jeszcze dużo pracy w zakresie obsługi zależności i współpracy międzyzespołowej. Szczególnie, że firma rośnie, a wraz z nią rosną projekty które realizujemy.
Myślę, że jesteśmy na etapie, gdzie same zasady agile są już nieźle zakorzenione i działają. Co ważne, zarówno Product Development, jak i IT pozytywnie odbierają wprowadzone zmiany. Nie znam osoby w firmie, która byłaby niezadowolona. To jest najlepszy miernik tego, jak nam to poszło. Wiadomo, że firma to ludzie, oni są tu najważniejsi. Pozostaje nam nieustanne ulepszanie.
A na koniec…
Czyli – co dalej?
MB: Produkt dynamicznie się rozwija i wciąż powstają nowe zespoły. To już weszło nam w krew, gdy powstaje nowy obszar, powstaje również nowy, interdyscyplinarny zespół. Funkcjonujące już obszary przechodzą ewolucję, to wszystko się stopniowo rozwija i zmienia, w sposób naturalny. Proces po prostu tu działa.
W gronie Scrum Masterów cykliczne przeprowadzany jest przegląd bieżących przeszkód i problemów, takie nasze retrospektywy. Przed nami wciąż masa pracy i wdrażania nowych usprawnień. Niedawno w firmie została zatrudniona osoba na stanowisku Quality Manager, która bardzo mocno wspiera nasze działania i tworzenie nowych procesów po stronie Product Developmentu. To pomaga wszystko zorganizować i zsynchronizować.
Staramy się też jak najmocniej zwiększać nasze kompetencje techniczne, a jednocześnie budować w ludziach pozytywną energię i zaangażowanie. Chcemy, aby czuli się tu dobrze, jakkolwiek banalnie to nie zabrzmi.
Gdybyś miał rozpocząć taką transformację jeszcze raz, co byś zmienił? Co byś doradził osobom, które są na początku takich przemian?
MB: Trudne pytanie. Chyba nic bym nie zmienił. To musiało potrwać pewien czas… Czy popełniliśmy jakieś duże błędy? Chyba nie.
Może mogliśmy jeszcze zintensyfikować komunikację poza IT, na wszystkie działy firmy. Jak wspominałem, zespoły biznesowe, które stricte współpracują z IT, uczestniczyły w zmianach na bieżąco. Natomiast nie wszystkie obszary firmy były w pełni informowane. Wraz z pojawieniem się Scrum Masterów temat został rozwiązany. To oni zadbali o zaspokojenie ciekawości i propagowanie wiedzy oraz zwinnego sposobu myślenia.
Co bym doradził? Przede wszystkim korzystanie z dobrodziejstw Agile i wdrażanie kultury, która za nim stoi. Narzędzia to nie wszystko, ich wdrożenie powinno też nieść ze sobą zmianę sposobu myślenia o tym, w jaki sposób wytwarzamy i utrzymujemy nasze produkty.
W natłoku wydarzeń i zadań związanych z transformacją warto zawsze pamiętać o tym, że nie wszędzie wdrażanie Scruma ma sens i nie warto tego robić na siłę. W organizacji mogą funkcjonować zespoły, które znacznie lepiej odnajdą się w zupełnie innym trybie działania.
Co myślicie o naszym sposobie wprowadzania Agile? Chcecie wiedzieć więcej? Jakie są Wasze scrumowe doświadczenia? Dajcie znać w komentarzach poniżej.