Samotny lider?

Implementacji roli lidera zespołu jest mniej więcej tyle ile organizacji, które definiują takie stanowisko. Inwazja zwinności wcale nie pomogła w skonkretyzowaniu cech lidera, wręcz utrudniła nam wszystkim rozumienie tej funkcji.



„Do pieca” dorzucił ostatnio mój kolega, którego niezmiernie szanuje, a który bije mnie liderszipowym doświadczeniem w wielu aspektach. Otóż stwierdził on, że lider to rola skazana na samotność i poruszył tym we mnie całe spektrum wątków myślowych krążących wokół tego tematu i analizujących jego każdy aspekt. Jako fundament tego stwierdzenia kolega zwrócił uwagę na fakt, że lider jest zarówno członkiem zespołu produkcyjnego, jak i zespołu liderszipowego. Jest między młotem a kowadłem. Osobiście uważam, że jest to najtrudniejsza rola menadżerska, ale o tym później. W związku z powyższym lider nie może być świetnym kolegą-członkiem zespołu, gdyż jako członek liderszipu uczestniczy w procesach, decyzjach organizacji nierzadko niepopularnych, czasem w pierwszej fazie tajemniczych, a przez to nie może być fajnym, otwartym kumplem. To prawda – nie może. Z drugiej strony, gdyby był fajnym kumplem, to nie mógłby możliwie obiektywnie uczestniczyć w procesach liderszipowych. To prawda – nie mógłby. W związku z powyższym lider skazany jest na samotność.

Nie do końca. Często powtarzam, że jestem radykalnym przeciwnikiem radykalizmu i w tym przypadku uważam, że gdzieś pomiędzy zespołem a liderszipem musi istnieć przestrzeń, która połączy te dwa światy, a jednocześnie pozwoli liderowi nawiązać bliższe relacje międzyludzkie. Od swoich pierwszych dni na omawianym stanowisku szukam dla siebie miejsca między tymi światami i od zawsze to miejsce odnajduję. To bardzo trudna droga, ale możliwa do przejścia. Kluczem jest wzięcie na siebie dodatkowej roli – osoby, która potrafi jednej stronie wytumaczyć działania i decyzje drugiej strony. Jako lider zawsze uważałem, że jednym z moich głównych, niepisanych obowiązków jest oswajanie specjalistów z decyzjami podejmowanymi na wysokim szczeblu. Nie ma nic gorszego niż zostawienie naszych ludzi z odgórną decyzją. Z drugiej strony kolejnym, niepisanym obowiązkiem lidera jest zapewnienie, że liderszip rozumie działania, decyzje, wątpliwości powstałe na poziomie zespołu. Podobnie jak ze SCRUM-em – proste zasady, które bardzo trudno wdrożyć. Jednakże jest to możliwe, gdy jest się człowiekiem zdeterminowanym i zmotywowanym. Dlatego właśnie uważam, że rola lidera jest najtrudniejszą rolą liderszipową – oczywiście tylko wtedy, gdy chce się ją wykonywać dobrze, z powołaniem, z poczuciem obowiązku. Lider nie musi być samotny w organizacji, może mieć świetny kontakt zarówno z liderszipem, jak i z zespołem – cierpi przez to czasem, ale efekty, jakie może tak uzyskać są czymś najbardziej pozytywnym co można uzyskać w sferze liderszipu.

Scrum Master w klasycznej organizacji

Mówiąc o klasycznej organizacji należy na pewno wspomnieć o klasycznym modelu zarządzania. Najczęściej mamy do czynienia z piramidą dyrektorów i różnego rodzaju kierowników na różnych poziomach. W tego typu organizacjach struktura menedżmentu często jest bardzo rozbudowana i nierzadko niepotrzebnie skomplikowana. Niestety też rzadko na tego typu stanowiskach znajdują się naprawdę kompetentne osoby. No ale zaraz... dlaczego piszę o menedżmencie we wpisie o Scrum Masterze? Step by step.

Różne organizacje różnie definiują rolę Scrum Mastera. Dotychczas spotkałem się z następującymi typami:

• Scrum Master/Team Leader - taka osoba zarówno dba o proces SCRUMowy swojego zespołu, ale również piastuje standardową rolę menadżerską dla swojego zespołu. To on podejmuje kluczowe decyzje, to on odpowiada HRowo za członków zespołu.
• Scrum Master/Developer - specjalista pracujący w zespole jako dev lub QA jest jednocześnie Scrum Masterem. Nie ma roli menadżerskiej. Dba o proces SCRUMowy. Czasem jest to rola rotacyjna pomiędzy członkami zespołu.
• Pure Scrum Master - osoba zajmująca się tylko i wyłącznie procesem SCRUMowym w danym zespole. Nierzadko taka osoba jest HR Leaderem dla osób spoza zespołu lub developerem w innym zespole.

Co na to SCRUM? Nic. SCRUM nigdzie nie zakazuje tego typu konfiguracji. Zwraca jedynie uwagę, że rola Scrum Mastera, sama w sobie, nie jest rolą menadżerską. Tu wszystko pasuje, gdyż można być i Scrum Masterem i menadżerem. Zdrowa implementacja SCRUMa to implementacja dostosowana do realiów i potrzeb danego środowiska. Oj, zaraz ktoś zarzuci mni herezję i promowanie tzw. SCRUM-BUT. Celem przedsiębiorstwa jest zarabianie pieniędzy i należy takie frameworki jak SCRUM zastosować tak, by tych pieniędzy zarabiać więcej. Kiedyś chciałbym napisać o tym osobnego posta, gdyż temat jest bardzo szeroki. Ale wracając...

Który typ SM nadaje się dla klasycznej oranizacji? Zależy od etapu wdrożenia SCRUM w przedsiębiorstwie. Należy pamiętać, że w tego typu organizacji specjaliści nie są nauczeni samoorganizacji na poziomie zespołu. Procesy decyzyjne podejmowane są zawsze przez takiego czy innego menadżera. W doskonałym, krosfunkcjonalnym zespole SCRUMowym to zespół sam sobą zarządza. Dążenie do doskonalości musi potrwać i tak naprawdę nigdy się nie kończy. Tygodnie, miesiące, lata. To trudny proces, gdyż trzeba wpłynąć na mentalność specjalistów (zepsutą przez klasyczną organizację pracy) i na ich pewność siebie na poziomie zespołu. Moje doświadczenie mówi, że na pierwszym etapie wdrożenia SCRUMa w klasycznej organizacji należy zastosować pierwszy typ, czyli Scrum Master/Team Leader. Osoba taka przez pierwszych kilka tygodni, miesięcy uczy specjalistów czym jest proces SCRUMowy. Ważnym jest by SM od początku zaznaczał, że dążymy do czegoś innego i aktualny stan nie jest stanem docelowym. Specjaliści są różni, różnie nastawieni do zmian, różnie zmotywowani. Nie wolno z dnia na dzień obracać ich świata zawodowego do góry nogami. Nie wolno jednego dnia kazać im słuchać się jednego menadżera, by drugiego dnia kazać im samym sobą zarządzać. To trwa i trzeba mieć tego świadomość. Wyższy menedżment firmy musi mieć tego świadomość. W tym etapie wdrożenia rola Scrum Mastera jest niezwykle ważna i jednocześnie praca jaką musi wykonać jest bardzo trudna. Osobiście uważam, że powinna to być osoba z wewnątrz organizacji, która rozumie jak ona działa. Zatrudnianie wybitnego SM z zewnątrz może w tym wypadku skończyć się katastrofą. Warto więc wybrać osobę, która chce rozwijać się w roli SM i ma umiejętności menadżerskie, które przekaże, na przestrzeni czasu, zespołowi. 

Co dalej? Płynnie należy oddawać zarządzanie zespołowi. To temat na osobny wpis. Ważnym jest, by docelowo Scrum Master przestał być klasycznym menadżerem (podejmującym wszystkie decyzje) danego zespołu. 

Serwis (maintenance) oprogramowania a.. SCRUM - podejście pierwsze

Ach ten serwis... zawsze problematyczny, zawsze nieprzewidziany, zawsze niepokojący. Każda firma wytwarzająca oprogramowanie musi je również utrzymywać. Jest to bardzo trudny etap w cyklu życia produktu i przysparza wielu problemów i kosztów. A co na to SCRUM? Czy można zastosować tą metodykę do poukładania maintenance'u, do jego zorganizowania? W jaki sposób uwzględnić serwis w scrumowym procesie wytwarzania?

Znów, wszystko zależy od organizacji firmy, od tego jak na wysokim poziomie abstrakcji firma ma poukładaną odpowiedzialność za poszczególne etapy procesu produkcji oprogramowania. Modele są różne. Możemy spotkać firmy, w których jeden zespół/dział analizuje, projektuje, programuje itd aż do serwisuje, a są też firmy, również klasyczne, które mają dedykowane zespoły/działy odpowiedzialne za każdy etap produkcji.

Często stosuje się też dwu- lub trzyliniowy front serwisowy. Pierwsza linia wsparcia to najmniej doświadczeni specjaliści, którzy odbierają zgłoszenia od użytkowników, ale rzadko kiedy potrafią je rozwiązać, więc przekazują je do drugiej linii. Ten poziom to albo stały zespół całkiem niezłych specjalistów, albo zespół dyżurujących programistów. Trzeci poziom to programiści, którzy wytwarzają oprogramowanie, do którego zgłoszono błąd. Przy takiej organizacji naszemu klasycznego SCRUMowi jest łatwiej, gdyż na 3cią linię wpada tych zgłoszeń niewiele, przy założeniu, że wcześniejsze linie wsparcia są dość kompetentne.

Gorzej niestety temat wygląda tam gdzie zespół scrumowy zajmuje się całym lub większością serwisu. SCRUM nie jest na to gotowy, a dlaczego? Gdyż SCRUM nie jest metodyką przeznaczoną do organizacji maintenence'u softu. SCRUM możemy zastosować tam, gdzie możemy zaplanować pracę, gdzie ta praca jest przewidywalna, gdzie mamy zdefiniowane cele na przyszłość. Serwis takim celem nie jest, gdyż, tak jak napisałem na początku, jest nieprzewidywalny.

No dobrze... ale jak żyć? Najpewniej sposobów radzenia sobie w takiej sytuacji jest wiele. Jako Scrum Master wyszedłem serwisowi naprzeciw i jeszcze raz zadałem pytanie o przewidywalność serwisu. Odpowiedź była wciąż ta sama - serwis jest nieprzewidywalny. Ale... jego wielkość... JEST przewidywalna. Korzystając z archiwów serwisowych możemy w bardzo prosty sposób stwierdzić ile czasu cały nasz zespół i jego konkretni członkowie poświęcali w przeszłości na serwis.

Dla przykładu, w jednym z zespołów weryfikowałem ile czasu każdy ze specjalistów poświęcił na serwis w każdym z ostatnich 3 miesięcy. Wyliczałem średnią. Korelowałem ją z nadchodzącym miesiącem (np czy nie jest to miesiąc, w którym standardowo, z jakiegoś powodu, użytkownik zgłasza więcej problemów) i miałem współczynnik, przez który mnożyłem czas dostępny na nadchodzący sprint. To tyle, nic więcej nie potrzebowałem. W wyniku takiej analizy otrzymywałem czas, który mogliśmy zaplanować danemu specjaliście w danym sprincie. Możliwym również jest stosowanie bardziej interesujących metod analizy serwisu, np trend czy algorytmy predykcji.

Jak zastosowanie tej metody wpłynęło na mój zespół? Bardzo dobrze - dzięki niej zyskaliśmy przybliżoną wiedzę o dostępnej mocy przerobowej każdego specjalisty - wcześniej było to niemożliwe, gdyż podczas planowania zostawialiśmy bliżej nieokreślony bufor na serwis, co często skutkowało nierealizowaniem zaplanowanych zadań LUB 'pustymi' godzinami roboczymi, które przecież można byłoby zapełnić innymi zadaniami z Product Backlogu.

Serwisu nie można się bać. Serwis trzeba analizować w każdy możliwy sposób. Podobnie jak stosowany w zespole SCRUM. Nigdy nie jest tak, że usprawnienia, które wprowadziliście będą działały zawsze - idea zwinności odnosi się nie tylko do podmiotu, który organizuje SCRUM, ale również do samego procesu stosowania tej metodyki.

Jak zacząć?

No właśnie! Jak zacząć wdrażanie metodyki Scrum w firmie, w której mamy do czynienia z klasyczną organizacją? Nie odpowiem Wam wprost na to pytanie, gdyż sformułowanie "klasyczna organizacja" dla każdego może oznaczać co innego. Postaram się więc na wstępie określić czym charakteryzuje się, według mnie, taka organizacja:

• kaskadowy model prowadzenia produkcji oprogramowania (tzw. waterfall) - mówiąc w skrócie, oprogramowanie tworzymy poprzez kolejne etapy: analiza, projekt, implementacja, testowanie, wdrożenie serwis. Często niektóre z tych etapów są pomijane, lub mieszane z innymi
• schemat organizacyjny firmy - klasyczne firmy często podzielone są na duże działy (od 15 nawet do 100 osób) co negatywnie wpływa na wymianę informacji między specjalistami. Trudno też w takim schemacie jest sensownie planować prace, a już na pewno trudno nadzorować prowadzone projekty
• pracownicy... o dziwo w takich organizacjach pracownicy często są bardzo przywiązani do aktualnej organizacji firmy, w której pracują, która nie zmienia się od wieków. Wielu z takich pracowników jest zdemotywowanych do jakichkolwiek zmian czy usprawnień.

Najpewniej można byłoby zdefiniować jeszcze kilka takich podpunktów, jednakże wydaje mi się, że te 3 są najważniejsze i mają największy wpływ na proces wdrożenia Scrum.

OK, skoro wiemy już z czym chcemy sobie poradzić, to rozpracujmy każdy ze zdefiniowanych problemów. Kaskadowy model prowadzenia produkcji oprogramowania - najtrudniejsze zagadnienie ze wszystkich, gdyż wprowadzając Scrum chcemy całkowicie ten proces odmienić. No właśnie, czy na pewno całkowicie? Nie do końca. Pamiętajmy, że etapy waterfall to również etapy Scrum, ale inaczej poukładane. Nasza zwinna metodyka również wykorzystuje wszystkie te etapy z tą różnicą, że są one wykonywane iteracyjnie i obejmują dużo mniejsze zakresy funkcjonalności niż w przypadku kaskady. To ważne by o tym pamiętać, gdyż wdrażając Scrum nie wprowadzamy jakiegoś kosmosu, a jedynie inaczej układamy klasyczne etapy produkcji oprogramowania i je formalizujemy. Bardzo życiowo pokazuje to poniższy obrazek korzystający ze znanego wszystkim specjalistom IT komiksu z projektem huśtawki :)

Iteracja jest błogosławieństwem. 

Klasyczny schemat organizacyjny opiera się na dużych działach. Pisząc "duże" mam na myśli o wiele większe niż zespół scrumowy. Niestety, wprowadzenie tej metodyki musi wiązać się z większą lub mniejszą reorganizacją firmy. Zespoły scrumowe nie mogą gromadzić tak dużych zasobów ludzkich, gdyż zatracimy wtedy wiele pozytywów jakie daje nam ta metodyka. Książka mówi o maksymalnie 9-osobowym zespole. Moim zdaniem totalnym maksimum jest 12 osób w zespole, ale to wszystko zależy i od organizacji i od umiejętności Scrum Mastera / Team Leadera. Jak przeorganizować schemat by lepiej dopasować go do wymogów wdrażanej zwinności? Można to zrobić na wiele sposobów, przykładowo:

• struktura płaska - rezygnujemy z działów, dzielimy wszystkich ludzi na zespoły scrumowe, oczywiście odpowiednio zorganizowane pod kątem specjalistów. Dobra opcja dla niedużych firm.
• struktura klasyczna - zostawiamy działy i w ramach działów tworzymy zespoły scrumowe. Dobra opcja dla wielu firm. Umożliwia ona uzyskanie kontroli nad grupą zespołów. W dużej firmie, w której przykładowo musielibyśmy utworzyć 20 zespołów nigdy nie będziemy w stanie postawić nad nimi jednej osoby (kierownika, dyrektora), która zapanuje nad wszystkimi. Dlatego w takiej sytuacji dobrze jest pogrupować zespoły w działy i postawić na ich czele sensownych menadżerów (o sensownych menadżerach opowiem kiedy indziej:) )

Dochodzimy do najważniejszego elementu i największego bogactwa każdej firmy - pracownicy. Jak wspomniałem wcześniej, pracownicy tego typu firm są najczęściej oporni na jakiekolwiek zmiany. Są również nieufni w stosunku do zmian ich sposobu pracy, myślenia, czy właśnie organizacji produkcji oprogramowania. Tu musicie wykazać się dużym wachlarzem kompetencji miękkich i umiejętnościami w motywowaniu. Musicie stać się zarówno specjalistami od marketingu jak i kaznodziejami :) Pamiętajcie o kilku podstawowych elementach:

• szkolenie - każdy pracownik musi zostać przeszkolony z metodyki SCRUM. W zależności od możliwości firmy pracowników można wysłać na akredytowane szkolenia lub przeszkolić we własnym zakresie. Druga opcja jest trudniejsza, gdyż wymaga doświadczonego w tej metodyce trenera potrafiącego sensownie przekazywać informacje i uczyć
• nie wolno się śpieszyć - zmiana klasycznej organizacji na jakąkolwiek nowoczesną organizację pracy to bardzo trudny proces zarówno dla firmy jak i jej pracowników. Nie polecam wrzucać zespołów od razu na głęboką wodę i kazać im np na pierwszym planowaniu wykorzystywać Scrum Pokera do estymacji zadań. Wprowadźmy podstawę, a później rozszerzajmy zakres
• ludzie zmienią nastawienie do zmian dopiero jak zobaczą efekty, dlatego nie należy się zniechęcać gdy pierwsze eventy scrumowe będą wyglądały jak stypy. Zarówno Wy jak i pracownicy musicie przez to przebrnąć. Nie ma większej radości dla wdrażającego jak słowa sceptyka, który potwierdza, że Scrum przyniósł efekty :)
• bez tajemnic - nie ukrywajcie przed pracownikami swoich kolejnych kroków w etapach wdrożenia. Nie ma nic gorszego niż tajemnice przy procesie reorganizacji - przez to rodzi się niepewność, brak zaufania a nawet bojaźń. Co więcej, podczas wdrożenia warto pewne aspekty omawiać z samymi pracownikami lub ich przedstawicielami (np Team Leaderami). 

Tyle na początek. Myślę, że moja rady są dość uniwersalne, co pozwoli zastosować je w wielu typach klasycznej organizacji.

Witajcie zwinni wędrowcy!

Cześć!

Tak, pierwszy post na własnym blogu! 

... mam nadzieję, że nie ostatni...

Od dawien dawna mam silną potrzebę uzewnętrznienia siebie i swoich doświadczeń w temacie wdrażania SCRUM w tzw. klasycznej organizacji - trochę o powodach i o mojej historii przeczytacie tu: O klasycznym Scrum masterze.

Chcę Wam, drodzy Czytelnicy, nie tylko przekazać wiedzę i doświadczenie, ale również zmotywować Was w waszych dążeniach do wdrażania metodyk zwinnych nie tylko w klasycznych organizacjach, ale również tam, gdzie wszyscy rzucają Wam kłody pod nogi. Nie zrozumcie mnie źle - nie jestem jakimś fanatykiem - uważam, że nie wszędzie można wdrożyć metodyki Agile. Uważam natomiast, że wszędzie warto spróbować. Tyle tytułem wstępu - na dniach udostępnię pierwszy swój wpis merytoryczny :)

Pozdrawiam

Karol