Wprowadzenie kultury Agile i zasad Scruma w GetResponse rozpoczęliśmy tradycyjnie, od działu IT i biznesu (a w naszym przypadku: Product Developmentu). Od samego początku wiedzieliśmy jednak, jak istotne jest przedstawienie tych idei w całej organizacji.
Odarcie ich z tajemniczości, zdemitologizowanie/odczarowanie, ale przede wszystkim pokazanie jako ciekawy trend i nowoczesny sposób pracy, wykraczający daleko poza dział IT i wytwarzanie oprogramowania, który świetnie sprawdza się we współczesnym świecie. Pokazanie, że jest to system umożliwiający uzyskanie bardzo dobrych efektów pracy, jej przewidywalności i zapewniający znakomity przepływ informacji. A wszystko to w przyjaznej atmosferze.
Od czego zaczęliśmy?
W efekcie – współpracując z działem Employer Branding, odpowiedzialnym za cały cykl wprowadzenia nowych pracowników – do szkoleń, które przechodzi każda nowo zatrudniona osoba (niezależnie od działu i charakteru wykonywanej pracy), dodaliśmy godzinne szkolenie, które nazwaliśmy “Scrum Workshop”. I zabraliśmy się za przygotowanie agendy.
Pierwsza przygotowana przez nas wersja szkolenia miała formułę prezentacji. Przedstawialiśmy Agile Manifesto, wraz z jego historią. Dosyć dokładnie (niemalże pół szkolenia) omawialiśmy Scruma, a następnie przedstawialiśmy nasze zespoły, zakres ich obowiązków i obszary kompetencji. Prezentowaliśmy też wszystkich Product Ownerów, chcąc przedstawić, do kogo należy się zgłosić, mając jakieś pytania/uwagi odnośnie obszaru. Całość kończyliśmy ekspresowym wprowadzeniem do JIRY – prezentując backlogi i sposoby zgłaszania wymagań. Sporo. Chcieliśmy omawiać jeszcze Kanbana, z czego ostatecznie zrezygnowaliśmy.
Inspekcja i adaptacja
Pół roku później dokonaliśmy ewaluacji prowadzonych szkoleń. Okazało się, że podeszliśmy do tematu zbyt emocjonalnie.
Pewni siebie i pełni agile’owego entuzjazmu, chcieliśmy przekazać jak najwięcej i jak najmocniej zaszczepić ten sposób pracy u innych. Jak pokazały nam jednak ankiety przeprowadzone po szkoleniu, uczestnicy, którzy trafiali do pracy do działów mających niewiele styczności z IT, choć szkolenie oceniali dobrze, to nie wiedzieli tak naprawdę po co jest im to wszystko przekazywane i nie widzieli możliwości użycia przekazywanej wiedzy w praktyce. Czy faktycznie księgowa, bądź prawnik muszą wiedzieć co to jest Daily Scrum? Było w tym wszystkim za dużo materiału teoretycznego, a za mało praktyki. Ba, ćwiczeń nie było w ogóle.
W gronie Scrum Masterów usiedliśmy do tematu raz jeszcze. Postawiliśmy sobie kilka celów:
-
przygotowanie bardziej przyjaznego i ciekawszego szkolenia dla uczestników. Jak najwięcej “po co mi to”, “dlaczego powinienem o tym wiedzieć”, “dlaczego to jest ważne”, “dlaczego mnie to też dotyczy”;
-
wzbudzenie zainteresowania kulturą Agile i frameworkiem Scrum – z naciskiem na “dlaczego nie jest to coś, co zatrzymuje się na poziomie działu IT”;
-
przekazanie uczestnikom najważniejszej wiedzy z punktu widzenia współpracy z IT – czyli “odczarowanie” IT;
-
pokazanie, kto może pomóc w przypadku kontaktów/współpracy/zlecenia zadania do IT.
Jako sposób na zmierzenie osiągnięcia powyższych celów, wybraliśmy znaczące podwyższenie średniej otrzymywanych ocen i całkowite wyeliminowanie uwag negatywnych oraz sugerujących, że temat na danym stanowisku nie jest do niczego potrzebny. Całość dopracowaliśmy jeszcze z naszym zespołem Employer Branding.
Zmiany, zmiany, zmiany
Zmieniliśmy nazwę szkolenia na “Agile @ GR – introduction” i skróciliśmy jego czas do 45 minut. I jak to teraz wygląda?
Na samym początku podkreślamy cel spotkania i tłumaczymy, dlaczego warto wiedzieć czym jest Agile, dlaczego warto się tym tematem zainteresować, gdzie mogę to spotkać i do czego wykorzystać. Postawiliśmy na całkowite wyeliminowanie formy prezentacji na rzecz własnoręcznych rysunków/schematów, z działaniami aktywizującymi uczestników oraz pokazanie pewnych elementów w praktyce.
Wyeliminowaliśmy również kwestie, które z biegiem czasu są postrzegane zarówno przez nas, jak i uczestników jako mało istotne. Z samego procesu Scruma – ról, zdarzeń i artefaktów – skupiliśmy się tylko na elementach istotnych dla wszystkich (rola Product Ownera, zespoły w IT, backlogi, przeglądy sprintu). A wszystko to pokazujemy w interaktywny sposób, wykorzystując planszę jako cykl Scrumowy i pionki, reprezentujące poszczególne role.
Od samego początku zachęcamy też uczestników do działania. Zaczynamy od ćwiczenia, polegającego na ułożeniu Manifestu Agile. Na czym polega to zadanie?
Tasujemy karty, na których wypisane są wartości z Manifestu i rozdajemy je uczestnikom szkolenia. Następnie prosimy o ułożenie ich w kompletny manifest, ze wskazaniem hierarchii tych wartości. Zachęcamy uczestników do dyskusji i wymiany poglądów dotyczących tych wartości. Słuchamy, czy dobrze je rozumieją. Można poprosić grupę o wyjaśnienie, dlaczego np. dana wartość po lewej jest bardziej wartościowa od tej po prawej. To proste ćwiczenia sprawdza nam się znakomicie i stanowi dobry punkt wyjścia do dalszych rozważań.
Na końcu do wszystkich uczestników jest wysyłany zestaw ciekawych linków i materiałów, zarówno zewnętrznych, jak i naszych.
Co się udało?
W efekcie ewolucyjnych zmian udało nam się osiągnąć postawione cele. A co ważne – dzięki temu szkoleniu – z czasem zaczęły zgłaszać się do nas osoby z różnych działów firmy z pytaniami, jak Agile może pomóc im w codziennej pracy, jak mogą go wykorzystać w swoim obszarze.
W następnym wpisie opiszemy drugą część tego szkolenia, którą przeprowadzamy już tylko dla osób z IT.
Co myślisz o naszym szkoleniu? Czy w swojej organizacji prowadzicie podobne kursy dla nowych pracowników? W jaki sposób dzielicie się kulturą Agile? Podziel się swoim doświadczeniem w komentarzach.