Od samego początku IT dostrzeżono potrzebę formalnego opisu w jaki sposób należy podejść do tematu projektów w tym sektorze. Stało się to praktycznie natychmiast, kiedy projekty IT stały się większe niż “Hello world”, gdy dostrzeżono jak trudne jest prowadzenie ich oraz jak wiele z nich się nie udaje. Dlatego dosyć szybko podjęto wiele wysiłku, aby od strony praktycznej projekty udawały się choć trochę częściej niż rzadko.
Najczęstszymi problemami z jakimi przychodziło się zmierzyć projektom były często zmieniające się wymagania i wysoka niepewność. Metody bazujące na waterfall’u zawodziły w tym względzie na całej linii. Nie dlatego, że dostarczały coś czego klient nie chciał, bo potrafiły (czasem) to dostarczyć. Problem polegał na tym, że często dostarczały to, czego klient wprawdzie chciał, ale czego tak naprawdę nie potrzebował. W odpowiedzi na te problemy pojawiły się metody zwinne, których najbardziej znanym reprezentantem jest Scrum.
Pojęcie Agile jest dosyć szerokie, obejmuje wiele bardziej szczegółowych podejść. Kiedy myślę Agile, zawsze przychodzi mi do głowy książka napisana przez Nassima Taleba pod tytułem “Antykruchość”. Książka nieco filozoficzna i niełatwa w lekturze ze względu na zastosowany język, jest pozycją o “rzeczach, którym służą wstrząsy”. Dzieli rzeczy na “kruche” – takie, które trwają dopóty nie wydarzy się jakiś wstrząs, który kładzie je na łopatki i niszczy, “odporne na kruchość”, czyli przykładowo duże organizacje posiadające mocne zabezpieczenie finansowe, które umożliwi im przetrwanie w sytuacji wstrząsu, no i właśnie na rzeczy “antykruche”. Te ostatnie to systemy bądź organizacje, które na wstrząsach zyskują, poprzez ciągłą inspekcję oraz ciągłą adaptację do zmieniających się warunków (do tej ciągłej inspekcji i adaptacji potrzebna jest transparentność). Taki właśnie w założeniach jest też Scrum, który jako pojęcie został wprowadzony w 1995 roku przez Kena Schwabera. Od tego czasu, Scrum w zarządzaniu projektami stał się jednym z bardziej rozpoznawalnych sposobów pracy w projektach IT. Nic dziwnego, że pojawiła się również dosyć spora biblioteka książek na jego temat.
Wydana przez PWN pozycja “Scrum i nie tylko. Teoria i praktyka w metodach Agile” autorstwa Krystiana Kaczora zasila ten pokaźny już zbiór, a nawet doczekała się już drugiego wydania. Jak wiele książek na temat Scruma zaczyna się paradoksalnie od omówienia waterfalla, ale chodzi w tym o to, aby uwypuklić różnice pomiędzy metodami stosowanymi kiedyś (często nadal) a zwinnymi. Tyle tytułem wstępu. To, co czeka nas dalej, to już w porównanie różnych metodyk.
Układ książki jest przemyślany. Autor wprowadza nas do pojęć najbardziej ogólnych, czyli co to w ogóle jest Agile, stopniowo poprzez Scrum, który jako rama wymaga konkretnych praktyk, ale nie narzucając szczegółów ich implementacji, aż po Extreme Programming, który dla odmiany składa się z samych konkretnych wytyczych. Jest to bardzo sensowne i jasne podejście, które w czytelniku zostawia dobre zrozumienie szerszego aspektu. Potem mamy już omówienie tytułowego meritum. Nie będę rozpisywać się o zawartym w książce opisie scrumowych eventów, ról czy artefaktów. Wszystko to jest i nie ma w tym nic odkrywczego. Jest też Scrum Guide. Choć pomimo uaktualnienia, książka odnosi się do wersji guide z roku 2013, możemy wniej znaleźć wartości Scruma, które pojawiły się później (lipiec 2016).
Osobiście w książkach na temat Scruma szukam tego, co jest dla mnie jego esencją, czyli sposobu myślenia. W pozycji “Scrum i nie tylko” to znalazłem. To nie jest książka napisana przez teoretyka, to jest książka napisana zdecydowanie przez osobę, która ma lata praktyki. To widać po przykładach, to widać wreszcie po tym, że jest w niej Scrumowy “mindset” (mentalność). Właścicielka bloga, na którym mam zaszczyt tylko gościć jako współautor, Karolina podeszła do egzaminu PSM I bez specjalnego przygotowania, ale mając ze sobą bagaż doświadczeń i właśnie ten “mindset”. Rezultat był pozytywny jak łatwo się domyślić, ale bardziej przemawiającym do mnie dowodem było widzenie zastosowania tego scrumowego sposobu myślenia w praktyce, nawet w sytuacjach, gdzie nie mieliśmy do czynienia z projektem typowo scrumowym.
Pamiętam, że kiedy zdawałam swój egzamin PSM I, to to, co najbardziej rzuciło mi się w oczy, to pytanie sprawdzające: “czy myślisz zwinnie?”. To jest esencja Scruma. Ta esencja jest w tej książce, dlatego gorąco polecam ją każdemu, kto chciałby pogłębić swoją wiedzę bądź przygotować się do egzaminu na Scrum Mastera na Scrum.org (uwaga, jest trochę trudniejszy od egzaminu Scrum Alliance). Co do samych egzaminów, w książce “Scrum i nie tylko” są wymienione pewne różnice pomiędzy dwoma odrębnymi organizacjami promującymi Scrum, czyli właśnie Scrum Alliance (obecnie prowadzony przez Jeff’a Sutherlanda) oraz Scrum.org (założony przez Kena Schweber’a po jego odejściu ze Scrum Alliance w 2009 roku).
Rozdział 12. książki “Scrum i nie tylko” ma kluczowe znaczenie nie tyle dla Scrum Mastera, ale dla osoby krytycznej dla powodzenia projektu czyli dla Właściciela Produktu. Jest sporo wiedzy oraz wskazówek o priorytetyzacji backlogu produktu, w postaci opisanych konkretnych technik takich jak Model Kano, ale nie tylko.
Skalowanie Scruma to trudny i osobny temat. Nawet jeśli Scrum został wprowadzony do organizacji, zwykle dotyczy tylko działów IT bądź pojedynczych zespołów projektowych. Poza tym bywają projekty zwyczajnie duże i skomplikowane. Scrum, oczywiście z racji swojej “adaptowalności”, wprowadzony szerzej zaadoptuje się z czasem do większych projektów, problemem jednak jest nie tylko ten czas. Problemem jest skala projektu, bo nagle mamy więcej niż jeden zespół projektowy. O ile proste (w znaczeniu mniej złożone) projekty jest łatwo doprowadzić do końca, o tyle im bardziej złożony projekt, tym jest trudniej. I zależność ta jest wykładnicza. Projekty składające się z kilku zespołów potrafią być wielokrotnie bardziej skomplikowane, natomiast organizacje chcące wprowadzić Scruma, zwykle chcą to zrobić szybko, korzystając już z gotowych rozwiązań.
Odpowiadając na te potrzeby, w książce “Scrum i nie tylko” zostało zaproponowanych kilka metod skalowania Scruma i na samym końcu znajdziemy opis podejścia do projektów tworzonych przez jeden niż więcej zespół. Temat jest po prostu trudny, dlatego powstało z czasem kilka propozycji. Jest omówiony LeSS (Large Scale Scrum). Jest promowany przez Kena Swchabera Nexus, oraz jeszcze trzy inne koncepcje, jedna promowana przez firmę Scrum Inc, Jeffa Sutherlanda Scrum at Scale, skomplikowany SAFe (Scaled Agile Framework) oraz chyba najbardziej ciekawe i idącej najdalej podejście Spotify (kojarząca się z serwisem muzycznym nazwa nie jest przypadkowa). Wszystko to dlatego, że ludzie ze Spotify byli tak Agile, że postanowili zmieniać wszystko ze Scrumem włącznie, wychodząc z założenia Agile jest większy niż Scrum (Agile>Scrum). Poświęcili Scruma, jawnie łamiąc jego zasady, ale nadal trzymając się filozofii Agile. W rezultacie Scrum zaczął ewoluować, zespoły Scrumowe przekształciły się w tzw. Squady, powstały dodatkowe części organizacji tzw. Tribes, a rola Scrum Mastera została zamieniona przez rolę Agile Coach.
Ponieważ Krystian Kaczor, autor pozycji “Scrum i nie tylko”, jak sprawdziłem jest oficjalnym trenerem, możemy być pewni rzetelnej wiedzy. Sam nie znalazłem niczego, z czym bym się nie zgodził. Wręcz przeciwnie, odnalazłem siebie na swojej własnej ścieżce Shu-Ha-Ri za co autorowi bardzo dziękuję.
Podsumowując, książka “Scrum i nie tylko” oferuje więcej niż obiecuje tytuł. Jest nieocenionym źródłem wiedzy dla przygotowujących się do certyfikatu Scrum Mastera, Product Ownera oraz osób faktycznie taką funkcję pełniących w projektach. W końcu powołując się również na zacytowany przez autora rezultat badań Standish Group, bardzo dużo projektów IT się po prostu nie udaje ze względu na to, że mamy do czynienia zwykle z systemami na tyle złożonymi, że aż ocierającymi się o chaos. Jedynie podejście zwinne jest w stanie pomóc poradzić sobie na tyle, na ile się da ze złożonością, z którą stykamy się w rzeczywistości. Jest to podejście, które Nassim Taleb określił jako zachowywanie się wędrownego włóczęgi, który mniej skupia się na planowaniu, a bardziej jest oportunistą, wykorzystującym nadarzające się okazje poprzez ciągłą inspekcję i adaptację do zmieniających się warunków.
Kilka słów od Karoliny:
Jak osoba publikująca wszystkie artykułu Kuby, przyznam, że miałam pokusę, aby skrócić ten tekst, ponieważ jako recenzja wydał mi się po prostu za długi. Takie wrażenie miałam po otrzymaniu go, jednak kiedy zaczęłam zagłębiać się w lekturę, moje zaciekawienie rosło! Znalazłam w tej recenzji – oprócz prawdziwej zachęty do sięgnięcia po książkę – tyle cennych informacji, ciekawych wniosków i przede wszystkim poczułam wspaniały klimat, że postanowiłam opublikować ją w oryginalnej wersji, żeby nie pozbawić Was niczego, co może być inspirujące :) Dzięki Kuba!
