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.
