Scrum – dwa razy więcej, dwa razy szybciej

Ten chwytliwy tytuł jest parafrazą książki Jeffa Sutherlanda “Scrum, czyli jak robić dwa razy więcej, dwa razy szybciej” i często przyświeca ona wszystkim zmianom, które dokonują się ostatnimi czasy w firmach IT. Zmianom, w których gubi się jednak to, po co tak właściwie Scrum został wymyślony i gdzie tak naprawdę leżą wartości, którymi należy się kierować. Zdanie, które dzisiaj budzi wiele dysput i kontrowersji na różnych szczeblach prowadzonych rozmów, nie jest sprzeczne z wynikami, które da się osiągnąć w Scrumie. Wymaga jednak odrobiny komentarza, który pozwoli w pełni zrozumieć co jego twórca miał na myśli umieszczając je na okładce.

W 1951 r. Joseph Juran, amerykański teoretyk zarządzania, opublikował Zasadę Pareta, znaną też jako Zasadę 80/20. Zgodnie z którą 20% badanych obiektów związanych jest z 80% pewnych zasobów. Spiesząc z przykładami - choćby 20% ludzkości odpowiada za 80% światowego dochodu (dokładnie to 82,70%), ale też 20% ubrań nosimy przez 80% czasu, czy koniec końców 20% nakładów przynosi 80% efektów. A więc w dużym uproszczeniu w przełożeniu na świat IT – 20% wymagań biznesowych pokrywa 80% rzeczywistych wymagań klienta. Nie jest to sztywny podział, ale wyliczenia statystyczne pokazują, że z reguły podział ten przebiega właśnie w okolicy 80 na 20.

I tu zaczyna się Scrum, a właściwie to, po co Scrum został stworzony. Choć jak mawiają złośliwi: “tam, gdzie pojawia się Scrum, tam pojawiają się problemy”, bo metodologia ta niejako burzy ustabilizowany porządek świata. Przyrostowe wytwarzanie oprogramowania - wywracające do góry nogami dotychczasowe metody pracy - pozwala odnieść się do zasady Pareta i zrobić to na dużo wcześniejszym etapie, zwiększając zadowolenie klienta i przyspieszając realizację postawionych celów.

Załóżmy więc, że chcemy umożliwić wygenerowanie raportu kwartalnego na potrzeby bliżej nieokreślonych rozliczeń. Raport ten mógłby zostać wyeksportowany do kilku różnych formatów, a dodatkowo jego poziom szczegółowości będzie możliwy do skonfigurowania. Prześledźmy więc sobie te założenia na schematycznym rysunku wymagań biznesowych.:

Czarny kwadrat oznacza nam pełen zakres wymagań, które klient przedstawił w ramach rozwoju produktu. Wiemy już jednak, że powinna istnieć część tych wymagań, która pozwoli zrealizować większość jego potrzeb - ta oznaczona została kolorem czerwonym. Schematycznie, znając podstawowe metryki zespołów Scrumowych takie jak ich prędkość czy pojemność jesteśmy w stanie już na początkowym etapie prac zwizualizować jak mogą one przebiegać w ramach kolejnych sprintów w formie kwadratów:

Wiemy już zatem, że realizując ćwiartki 1 i 2 pokryjemy największe potrzeby klienta, a przynajmniej te funkcjonalności, z których odbiorcy końcowi będą najczęściej korzystać. W naszym przypadku byłyby to na przykład raporty w formacie CSV czy HTML, które to są częściej generowane niż sporadyczne przypadki wygenerowania zestawień zgodnych choćby z konkretnym ISO. Realizując sprint po sprincie kolejne ćwiartki pozwalamy klientowi po każdym z nich zastanowić się czy chce ponosić koszty dokładania kolejnych funkcjonalności, z których korzysta mniej osób, czy woli poszukać alternatywy dla tych konkretnych przypadków, a dostępny budżet przeznaczyć na realizację czegoś zupełnie innego np. kolejnych usprawnień, z których skorzysta 80% użytkowników.

Możliwość wielokrotnej inspekcji stawianych celów i zadanie sobie kilkukrotnie pytania czy to, co właściwie robimy jest tym co powinniśmy robić pozwala zwiększyć wartość, którą osiągamy - bez względu na to, w jakiej dziedzinie naszego życia się poruszamy.

Realizując projekt w modelu waterfallowym klient musiałby czekać na koniec projektu i nie miałby możliwości reagowania na różnych etapach jego produkcji. W tym przypadku widzimy, że połowa prac, za które by zapłacił klient nie przyniosłyby tyle korzyści, które mógł zakładać na wczesnym etapie rozwoju produktu.

W obu przypadkach - realizując wymagania biznesowe, zarówno przyrostowo, jak i kaskadowo, może okazać się, że dojdziemy do tego samego punktu końcowego. Jednak dopiero możliwość inspekcji i adaptacji pozwala nam osiągnąć więcej, a tym samym budować pozytywne relacje, niejednokrotnie przekładające się na długotrwałą i owocną współpracę.

Jak zatem należy rozumieć zdanie “Scrum, czyli jak robić dwa razy więcej, dwa razy szybciej”? Ostatecznie jedyne co klient dostanie w połowie prac to dwa razy mniejszy zakres biznesowy - choć realizujący zdecydowaną większość jego faktycznych potrzeb. Tu decyzja należy już bezpośrednio do klienta, bo być może będzie chciał dostać dwa razy więcej wartości biznesowej, dwa razy szybciej niż współpracując waterfallowo.

Samą książkę Sutherlanda polecam przeczytać, bo jest ona napisana językiem przystępnym i entuzjastycznie odpowiada na pytanie dlaczego warto pracować Scrumem. Nie daje jednak ona samych wskazówek, będąc raczej zbieraniną opowiastek, które posłużyły wymyśleniu Scruma. Może być ona inspiracją, może pchnąć do dalszego działania, choć powinna być tylko jednym z wielu elementów, które pozwolą w pełni zrozumieć po co i dlaczego warto stosować Scruma.