Przygotowałam dla Was relację z czterech wybranych prezentacji, które uważam za ciekawe i warte uwagi. Dwie pierwsze (Tomisława Krężelewskiego i Jarosława Wójcińskiego) pochodzą z „Executive track”, dwie kolejne z „Enterprise track” (Agaty Landzwójczak) i „Product track” (Dariusza Knopińskiego).
„Executive track”, w ramach którego występowali Tomisław i Jarosław, dedykowany dla managerów wyższego szczebla, był dodatkowo biletowany. Podczas tych prezentacji pomyślałam, że szkoda, że inni uczestnicy konferencji nie mieli okazji ich wysłuchać. Obie poruszyły temat całościowego spojrzenia na proces kształtowania agile’owego środowiska pracy, w którym niebagatelną rolę pełnią przecież Scrum Masterzy, Product Ownerzy, liderzy, a tych brakowało na sali. Z jednej strony rozumiem, że „executives” potrzebują przestrzeni na dzielenie się swoimi doświadczeniami; z drugiej, uważam, że jedną z przyczyn quasi-agile’a, który funkcjonuje w wielu firmach, jest brak spójnego sposobu myślenia i dialogu pomiędzy tymi grupami, a ograniczanie takich prezentacji do zamkniętego tracka podczas konferencji, wpisuje się w to zjawisko.
Tomisław Krężelewski, CTO, Azimo – “Scrum Masters, What’s Wrong with You!”
Intrygujący tytuł, szczególnie dla Scrum Masterów. Tomisław rozpoczął wystąpienie od przywołania kilku rozmów z kandydatami podczas poszukiwań doświadczonych programistów do krakowskiej siedziby Azimo. Po latach pracy w agile’owym środowisku stanął przed wyzwaniem rozbudowania zespołu, który nie miał okazji pracować Scrumem, ani żadną inną zwinną metodą pracy. Obawiał się, że to może zniechęcić programistów do dołączenia do firmy, tymczasem okazał się jej atutem. Wielu z nich utożsamiało Scruma z długimi, bezwartościowymi spotkaniami i korpo-buzzwordami. Tomisław zaczął dociekać, czy to pojedyncze opinie, czy zjawisko o szerszej skali. Na bazie rozmów z kolejnymi developerami oraz wymiany doświadczeń z innymi managerami doszedł do wniosku, że Scrum ma złą famę wśród naprawdę sporej grupy developerów, którzy mieli okazję się z nim zetknąć. Zaczął też sobie i innym zadawać pytanie, co jest tego przyczyną. Tutaj pojawia się postać tytułowego Scrum Mastera, bo przecież kto mógł zawinić, jeśli nie właśnie on.
Jak się pewnie domyślacie, tytuł jest przewrotny; Tomisław opowiedział o tym, jak w toku poszukiwań „winnego” wyszedł od Scrum Mastera, następnie Product Ownera, żeby wreszcie zatrzymać się na roli managera i jego odpowiedzialności za to, w jaki sposób wprowadza się w firmie zwinne metody pracy. Na przytoczonym wyżej przykładzie omówił, dlaczego mechaniczne używanie Scruma bez kontekstu („po co się zmieniamy”) i zrozumienia wartości, jakie stoją za tą metodą pracy jest zgubne w skutkach. Ładnie zdefiniował przy okazji leadership jako „pomoc ludziom w mierzeniu się z problemami i wyzwaniami” oraz wyodrębnił 3 elementy, które, jego zdaniem, są niezbędnym tłem dla rzeczywistej transformacji firmy.
- Całościowe myślenie (ang. holistic thinking) – zmieniamy firmę, nie zespoły.
- Pokazanie ludziom kontekstu ich pracy.
- Zwrócenie uwagi na wartości i działanie w zgodzie z nimi.
Dlaczego uważam tę prezentację za ważną? Nie jest dla mnie zaskoczeniem, że wielu programistów uważa Scruma za „spowalniacza” ich pracy. Sama nieraz miałam okazję zetknąć się z osobami, które miały podobne doświadczenia – dogmatyczne traktowanie zdarzeń i ról Scrumowych bez zmiany sposobu myślenia, a tym samym realnego wpływu na efekty pracy. Istotna jest natomiast skala zjawiska i jej konsekwencje. Tomisław podsumował swoje wystąpienie stwierdzeniem, że dzisiaj zmienia organizację, w której pracuje, bazując na wartościach agile, dobrych praktykach, dopasowanych do potrzeb, a zarazem niekoniecznie używając, jak to ujął, w dużym stopniu „skompromitowanej” marki Scruma.
W abstrakcie jego prezentacji na stronie SD 2017 przeczytacie: Wszyscy pracujemy w agile’owych zespołach i firmach. A może to nieprawda. Bo wiesz, jeśli twoim jedynym narzędziem jest młotek, wszystko zaczyna wyglądać, jak gwoździe (ang. We all work in Agile teams and Agile companies. Or, maybe, it’s not true. Because, you know, if all you have is a hammer, everything looks like a nail.). Warto, myślę, od czasu do czasu zatrzymać się i zastanowić, ilu z nas przyczynia się do tej „kompromitacji”, za każdym razem, kiedy traktuje mechanicznie elementy Scruma bez zastanowienia nad tym, na ile odpowiadają na realne potrzeby.
Jarosław Wójciński, Head of IT Development, Lux Med – “From Project to Product. Multidimensional Transformation in IT”
Prezentacja Jarosława to obszerne, ciekawe studium przypadku wciąż trwającej, agile’owej transformacji o dużej skali (ponad 300 osób w IT rozwijających i utrzymujących ok 50 systemów). Decyzja o jej rozpoczęciu była spowodowana m.in. małą elastycznością wprowadzania zmian biznesowych i 3 miesięcznym okresem stabilizacji po każdym wdrożeniu projektu, co dla niektórych pracowników oznaczało nieprzespane noce i weekendy w pracy. Przed nią funkcjonowały w firmie pojedyncze zespoły Scrumowe, ale nie miały znacznego wpływu na całościową współpracę pomiędzy biznesem a IT. Dodatkowo mniej więcej raz w roku pojawiały się mniejsze lub większe zmiany organizacyjne w dziale, dlatego kluczowym zadaniem było przekonanie pracowników do tej kolejnej. Do listy ważniejszych wyzwań można dodać wyodrębnienie produktów w firmie, która dotychczas działała projektowo, automatyzację oraz działanie w środowisku o złożonych procesach i standardach. Poniżej opisuję dla Was w punktach streszczenie co ciekawszych tematów omówionych w trakcie prezentacji:
- Od początku w proces transformacji byli zaangażowani “apostołowie” – ochotnicy ze specjalnie powołanego projektu, w którym mógł wziąć udział każdy zainteresowany tematem. Zgłosiło się ok 30 osób, które po czasie Jarosław podzielił na 3 grupy – takich, którzy rzeczywiście chcieli zmienić ówczesne status quo oraz tych, którzy dołączyli z ciekawości albo lęku o utratę pozycji w firmie. W faktycznych zmianach aktywnie wzięło udział kilkanaście osób, odpowiedzialnych m.in. za: komunikację czy warsztaty dla całego IT wprowadzające w temat agile’owej transformacji.Zmiana została zaplanowana jako „big bang” – wielkie wdrożenie dla całego działu, pomimo świadomości wszelkich minusów i ryzyk, jakie się z tym wiążą, jak choćby stopień skomplikowania zmian organizacyjnych na taką skalę, czy okres potrzebny na adaptację nowych zasad pracy. Do konsultacji Jarosław zaprosił agile coachów z różnych firm i takie podejście kontynuuje, aby zapewnić sobie różnorodność opinii i perspektyw patrzenia na rozwój sytuacji w Lux Medzie. Praktykuje również wymianę doświadczeń z organizacjami, które przeprowadzają transformacje o podobnej skali, jak np. mBank.
- W firmie zastosowano domenowy podział na obszary biznesowe; do każdej z nich, na okres przejściowy został przypisany lider, który wspiera zespoły Scrumowe funkcjonujące w ramach danej domeny. Za decyzje biznesowe odpowiadają Program Managerowie, którym podlegają Product Ownerzy; Scrum Masterzy są poza struktuą domen. Kierunek działania wyznacza zespołom impakt mapa zaplanowana na rok, rozbita na 3-miesięczne story mapy. Dodatkowo, poza strukturą domen funkcjonują zespoły architektury korporacyjnej oraz standaryzacji i automatyzacji.
- Miarą, która pozwala monitorować, czy transformacja idzie w dobrym kierunku, jest czas, jaki mija od pojawienia się pomysłu do momentu, w którym rozwiązanie trafia do użytkownika końcowego. Podczas prezentacji Jarosław pokazał statystyki proporcji ilości zgłaszanych inicjatyw do wdrożonych na produkcję, obrazujące pozytywny wpływ transformacji na przewidywalność zespołów.
- Aktualnie okres stabilizacji po wdrożeniu wynosi 2-3 tyg (wyjściowo zajmował ok 3 mies); znacznie spadła również ilość bug fixów po wdrożeniu.
Najciekawsze w tej prezentacji było dla mnie pragmatyczne podejście do wszelkich decyzji podejmowanych w procesie transformacji – rozwiązania szyte na miarę firmy, a nie tego, jak bardzo „agile” chcemy być. Zmiana w Lux Medzie trwa, z chęcią usłyszę za jakiś czas, jakie wnioski pojawiły się po upływie dłuższego okresu i jakie decyzje za sobą pociągnęły.
Agata Landzwójczak, HR Business Partner, IT.integro – “Inspiring Co-creation. About SM/PO/HR Cooperation on People Processes”
Agata poruszyła ciekawy temat często igorowanego potencjału współpracy działu HR oraz osób zaangażowanych w agile’ową transformację organizacji i bieżącą pracę z zespołami (managerów, agentów zmiany, agile coachów, Scrum Masterów). Rozpoczęła wystąpienie od przywołania przykładowych uprzedzeń i wzajemnych opinii, z jakimi spotkała się w swojej pracy:
- HR jest daleko od realiów pracy zespołów, dlatego proponuje rozwiązania, które nie odpowiadają ich potrzebom,
- HR ma korporacyjny charakter – reprezentuje interesy managerów i biznesu, a nie szeregowych pracowników,
- Scrum Masterzy, współpracując z zespołami (coaching, rozwiązywanie konfliktów) przejmują część zadań realizowanych wcześniej przez HR,
- Zespoły Scrumowe tworzą własne reguły (niczym państwo w państwie), chcą być samowystarczalne, ignorując zasady panujące w organizacji.
Brzmi znajomo?:) Ta krótka lista nie sugeruje szerokiego pola do współpracy. Agata zaproponowała, aby spróbować odciąć się od tego typu skrótów myślowych (nawet jeśli bazują na negatywnych doświadczeniach) i spojrzeć na tę potencjalną współpracę w kategorii szans. Omówiła pokrótce, w jakich wybranych obszarach HR może wspierać dobre funkcjonowanie zespołów – np. zatrudnianie ludzi o potrzebnych kompetencjach (zarówno technicznych, jak społecznych), motywowanie, pomoc w trudnych sytuacjach, mediacjach, a także wsparcie dla managerów przy awansach czy zwalnianiu. Poniżej znajduje się jej interpretacja tego, w jaki sposób kompetencje agentów zmiany i HR mogą się wspierać i uzupełniać.
Sposób współpracy, czy wspólnie realizowane tematy (np. programy szkoleniowe, komunikacja podczas zmian organizacyjnych, open salary, zaszczepianie kultury feedbacku, współpraca przy budowaniu spójnej kultury organizacyjnej) zależą od skali firmy, czy etapu jej rozwoju. Z mojej perspektywy ta prezentacja jest ważna, ponieważ porusza temat nieoczywisty, często ignorowany. Mogłabym jej przesłanie sprowadzić do 2 zdań: HR i osoby kształtujące agile’owe środowisko pracy mają wspólny interes – prężnie działający biznes wspierany przez dobrze zorganizowane zespoły, w których pracują zadowoleni ludzie. Spójrzmy, jak to wygląda u nas w firmie – w jaki sposób warto ze sobą współpracować, aby mieć pewność, że faktycznie gramy do jednej bramki.
Dariusz Knopiński, Mobile Product Development Manager, Allegro – “How to Quantify Product Owners’ Workshop and Help Them Develop their Role and Skills”
Punktem wyjścia w prezentacji Dariusza były początki agile’a w Allegro i jego doświadczenia pracy jako Product Ownera jednego z pierwszych zespołów Scrumowych w organizacji. Rok po rozpoczęciu procesu transformacji został jednym z dwóch Product Managerów, przed którymi stanęło wyzwanie kierowania 10-12 osobowym zespołem Product Ownerów, z których każdy współpracował z jednym Zespołem Deweloperskim. W praktyce oznaczało to dla niego globalne planowanie kierunku rozwoju produktów, za które odpowiadał, ok 10 Sprint Review w tygodniu tak, aby być na bieżąco z tym, co dzieje się w każdym z zespołów oraz dbanie o rozwój i wsparcie dla podlegającego mu, całkiem licznego zespołu Product Ownerów. Dariusz wyjaśnił, jakimi obszarami powinna jego zdaniem zajmować się osoba pełniąca tę rolę tak, aby świadomie zarządzać produktem, za który odpowiada i dlaczego uważa jej zadania za duże wyzwanie. Tym samym dużym wyzwaniem było dla niego zadbanie o wartościowy feedback dla Product Ownerów i wsparcie ich w rozwoju. Tak pojawił się pomysł, aby stworzyć narzędzie, które pozwoli zebrać możliwie rzetelną informację zwrotną nt pracy Product Ownerów, i zarówno dla nich, jak i dla niego, stanie się źródłem informacji o ich mocnych stronach i kompetencjach, czy działaniach, którym powinni poświęcić więcej uwagi. Przygotował anonimową ankietę, wypełnianą kwartalnie przez członków Zespołu Scrumowego, zawierającą 23 pytania skupione wokół 5 obszarów, kluczowych jego zdaniem w pracy każdego Product Ownera. Poniżej znajdziecie obszary i przykładowe pytanie z każdego z nich.
| Obszar oceny | Przykładowe pytanie |
| 1. Backlog (jako narzędzie pracy Product Ownera) | Backlog jest przygotowany na 2 Sprinty do przodu (2 tyg Sprinty) i 4 dla 1-tyg Sprintu |
| 2. Znajomość produktu, którym zarządza | PO proponuje odpowiednie KPI, które odnoszą się do wartości biznesowej produktu |
| 3. Dostępność i obecność podczas zdarzeń Scrumowych | PO jest przygotowany do zdarzeń Scrumowych |
| 4. Współpraca z interesariuszami | PO jest punktem kontaktu dla interesariuszy |
| 5. Współpraca z zespołem | PO jest otwarty na propozycje zespołu |
Wnioski po ponad 2 latach korzystania z kwartalnych ankiet dotyczących ok 30 Product Ownerów:
- to proste narzędzie dało całościowy obraz kondycji kompetencji Product Ownerów w firmie i pomogło kompleksowo wspierać najważniejsze z nich np. poprzez odpowiednie programy szkoleniowe,
- jednocześnie pozwoliło wspierać indywidualny rozwój każdego z Product Ownerów (wybrać 2 obszary do rozwoju per kwartał), a w razie potrzeby zaangażować we wsparcie również Scrum Mastera Zespołu Scrumowego,
- wsparło kulturę feedbacku w organizacji.
Dariusz polecił korzystanie z tego typu narzędzi przede wszystkim w początkowej fazie transformacji, kiedy niezbędne jest intensywne wsparcie rozwoju nowych kompetencji w firmie. Szczególnie w dużych organizacjach, gdzie wiąże się to z zarządzaniem licznym zespołem.