Blog

Scrum jak każda metoda z całą pewnością nie jest metodą „do wszystkiego” (jest takie powiedzenie, że rzeczy „do wszystkiego” są do niczego). Zatem, logicznie wynika z tego, że są jakieś tematy, sprawy, rodzaje pracy czy produktów, do których Scrum się dobrze nadaje – oraz inne, do których się nie nadaje.

Spróbujmy zatem zakreślić „granice”, zastanowić się w jakich sytuacjach Scrum z pewnością ma sens jako metoda zarządzania. Myśląc o tym wyróżniłem następujące istotne cechy:

1. Duża zmienność wymagań/oczekiwań/warunków – czyli sytuacja w której im dalej wybiegamy w przyszłość od chwili obecnej tym trudniej przewidzieć jakie funkcje czy cechy produktu będą potrzebne, przy czym mówimy tu o horyzoncie tygodni czy miesięcy, a nie lat. W związku z tym konieczne jest bieżące sterowanie rozwojem produktu w oparciu o ciągłe sprawdzanie jego dostosowania do aktualnych warunków i identyfikację najważniejszych potrzeb, następnie realizację paru z nich i ponowne sprawdzenie. Zatem konieczny jest empiryzm w rozwijaniu produktu.
2. Słaba powtarzalność pracy – pracochłonność zadań pozornie podobnych do realizowanych w przeszłości okazuje się w rzeczywistości być istotnie różna, przy czym jest to na tyle częste, że zasadniczo utrudnia prognozowanie i planowanie w oparciu o dekompozycję pracy i jej szacowanie.
3. Wysoki koszt przekazywania pracy – przekazywanie pracy między pracownikami różnych specjalności prowadzi do utraty istotnej części informacji, co powoduje obniżenie jakości i spowolnienie pracy. Dodatkowo, relatywnie często konieczne jest by jednostki pracy przechodziły wiele razy pomiędzy różnymi specjalnościami. W sytuacji kiedy próbujemy ułożyć sekwencyjny proces (kaskadowy?) prowadzi to do wracania jednostek „pod prąd” co znacząco spowalnia przepływ przez cały proces. Dla efektywnego działania konieczna jest zatem wspólnota pracy – to znaczy codzienna, bliska współpraca osób o różnych specjalnościach nad jedną jednostką pracy aż do jej ukończenia. Scrum zawiera wiele mechanizmów stymulujących wspólnotę pracy.
4. Możliwość wykonywania całości pracy przez niewielki zespół – bez tego nie tylko trudno zbudować wspólnotę pracy, ale przede wszystkim ciężko wynieść korzyści w postaci zwiększenia przepływu przez proces czyli tempa oddawania kolejnych jednostek pracy. Warunkiem takiego działania przy większych produktach jest możliwość ich dekompozycji na mniejsze elementy, które zdolne są do samodzielnego niezależnego działania. Rzecz możliwa w przypadku większości maszyn – i oczywiście oprogramowania, wszelako wymaga przyjęcia takiego założenia architektonicznego niemal od początku. Jest zatem bardzo trudne przy tak zwanej architekturze monolitycznej.
5. Możliwość wykonywania pracy w sposób inkrementalny – a więc oddawania efektów etapów pracy w postaci w pełni działających, a najczęściej także używalnych i wartościowych wersji produktu. Bez tej właściwości ciężko o empiryczne sterowanie procesem (punkt 1). Rzadko możliwe przy tworzeniu obiektów fizycznych – możliwe bardzo często w oprogramowaniu.

Warto tu zauważyć, że współcześnie budowanie oprogramowania spełnia wszystkie powyższe punkty. Zarazem, oprogramowanie jest dzisiaj obecne w takiej czy innej formie właściwie wszędzie – ciężko w ogóle wyobrazić sobie firmę, która działałaby na skalę szerszą niż sklepik osiedlowy czy mały warsztat bez oprogramowania. A im większa firma tym bardziej niezbędne jest w niej oprogramowanie dedykowane, dostosowane konkretnie do niej – a co za tym idzie zmieniane, dopasowywane bardzo szybko wraz ze zmianą rynku i samej firmy. Stąd bierze się popularność metod Agile, w tym oczywiście Scruma. Owszem, trochę jest w tym bezmyślnego naśladownictwa (elegnacko się to nazywa „moda”), ale coraz częściej także uświadomionej konieczności.

Wracając do tytułowego pytania: nie ma sensu używać Scruma jeśli sytuacja, którą zarządzamy nie posiada wszystkich wymienionych cech. Scrum nie będzie „pasował”. Czym to się będzie objawiać? Brak będzie widocznych benefitów. Zdarzenia, artefakty, reguły metody będą mniej lub bardziej ewidentnie „uwierać”, wydawać się bez sensu.

Przykład: jeśli nie ma wspólnoty pracy Daily Scrum nie ma sensu, po co mam stać i gadać o tym co robię, skoro inni robią co innego, co nie wpływa na moją pracę? Podobnie Cel Sprintu – jeśli nie budujemy czegoś co jest jednym działającym artefaktem ów cel albo w ogóle nie będzie istniał albo będzie swoją karykaturą skupioną na ilości elementów („dowieźć wszystko” to nie jest cel sprintu).

Co zatem jeśli nie Scrum? Jeśli nie jest prawdą punkt 3 (a także 4 i 5) dobrym sposobem na zarządzanie procesem może być metoda Kanban. Jeśli nie są prawdą punkty 1, 2 i 5 to rozsądne będzie użycie podejścia projektowego.

To, co tu napisałem jest oczywiście bardzo skrótowe. Myślę jednak, że jest istotne aby po pierwsze zdać sobie sprawę, że nie ma sensu stosować Scrum wszędzie w organizacji, a po drugie by być otwartym na inne sposoby zarządzania pracą. Najważniejsze jednak to pamiętać, że dobieramy metody zarządzania do sytuacji a nie na odwrót!