Czy Agile to Scrum?

Transkrypcja

Dziś moim gościem jest Jerzy Cieśliński. Jerzy opowie nam o myśleniu agile’owym i o tym, czym właściwie są Agile i Scrum. Jędzy, dziękuję, że przyjąłeś moje zaproszenie na rozmowę.

Również dziękuję, to miło z Twojej strony, że mnie zaprosiłeś.

Czy możesz się przedstawić i powiedzieć, co łączy Cię z branżą IT?

Aż mnie kusi, by powiedzieć, że niewiele, poza tym, że w niej pracuje. W pewnym sensie pracuję w niej od niedawna, więc to by się zgadzało. Wcześniej przez 18 lat zajmowałem się sprzedażą,
próbowałem zmieniać branżę, ale zawsze do tej sprzedaży wracałem.

W międzyczasie raz pracowałem przez chwilę w jednym software housie. Tam poznałem takie hasło jak „Scrum”, zobaczyłam, że zespół pracuje w jakiś taki dziwny wtedy dla mnie sposób.

Potem wróciłem do sprzedaży, zacząłem iść w stronę szkoleń, coachingu (więc jestem też praktykującym trenerem i coachem biznesowym, głównie pracuję z przedsiębiorcami) i w pewnym momencie podjąłem decyzję, że tak, muszę się przebranżowić, to jest ten moment.

Po dłuższej analizie doszedłem wyszło mi na to, że Scrum Master jest rolą, która będzie odpowiednia dla mnie i że będzie to TEN sposób wejścia do branży IT. Chociaż bardziej interesowała mnie sama rola Scrum Mastera niż stricte branża IT. Ale tak się składa, że najwięcej Scrum Masterów jest w IT. I tak to wygląda.

Czym w ogóle są Agile i Scrum? Są to terminy często stosowane zamiennie. Czym jest jedno, a czym drugie?

Ale mamy tydzień na tę rozmowę czy tylko godzinkę?

Niestety nie mamy tygodnia, więc musisz trochę przyspieszyć – taki szybki kurs.

A ma być ortodoksyjnie czy tak po mojemu?

Może po Twojemu.

Po mojemu. Pytam o to, bo są różne podejścia i wywołuje to różne dyskusje – zresztą dzisiaj rano miałem na ten temat dyskusję w komentarzach pod jednym postem. To jest trochę tak jak z hasłem „buty sportowe”. Czy buty sportowe to są koniecznie te z trzema z paskami? Bo mamy zbiór butów sportowych i mamy wśród nich te z trzema paskami, z różnymi haczykami i innymi takimi. Ale
często kojarzymy, że nazwa, która kojarzy się z trzema paskami, ogólnie opisuje buty. A zdrowe odżywianie? Czy zdrowe odżywianie oznacza jedzenie samych warzyw? Niekoniecznie. Są różne metody na zdrowe odżywianie. Jest to analogia, którą można przełożyć tez na zwinność. Staram się używać polskich określeń, choć ostatnio słyszałem, wyobraź sobie, słowo „agilność” zamiast zwinność. W każdym razie wolę „zwinność”, czyli agility. Zwinność jest sposobem myślenia, podejściem do tworzenia produktów, rozwiązań czy po prostu do pracy, podczas gdy Scrum to pewne ramy postępowania – pewien sposób zastosowania zwinnego podejścia.

OK, to może pytanie dodatkowe: dlaczego często używa się tego zamiennie?

Odpowiedź jest dość prosta. State of Agile to badanie, które odbywa się chyba już po raz 16 w tym roku, zdaje się, że do końca października są zbierane odpowiedzi. To badanie dotyczy tego, jak zespoły uważają, że pracują – w jakiej metodzie zwinnej. W zeszłym roku 66% respondentów odpowiedziało, że pracuje w Scrumie, więc jest to najbardziej popularna (przynajmniej teoretycznie) metoda zwinna. Dziewięć procent to były tzw. „zespoły scrumujące” (bardzo lubię to określenie Radka Olszewskiego), czyli wykorzystujące sposoby oparte na Scrumie, ale zaadaptowane do ich potrzeb. Więc chyba z tego to wynika: że Agile to Scrum i idziemy w tym kierunku.

Wejdźmy trochę głębiej. Na czym polega „myślenie agilowe”? Czy możesz to wyjaśnić i podać kilka przykładów?

Żeby nie było ortodoksyjnie, a po mojemu: zacząłem się nad tym wszystkim bardziej zastanawiać. Zaczynałem od Scruma, ale jednocześnie patrzyłem na inne sposoby, ponieważ metod zwinnego postępowania / zwinnego prowadzenia projektu (różnych określeń się używa) jest podobno około 50.

Zacząłem rozglądać się ogólnie, co jest, i doszedłem do wniosku, że zwinność tak naprawdę leży w naszej ludzkiej naturze. Zawsze musieliśmy się adaptować do sytuacji, zmienności otoczenia,
do tych mamutów, które nas kiedyś ganiały (albo w drugą stronę). Więc jest to element naszej natury, natomiast teraz jest to opisane, ocertyfikowane i mówimy, że pracujemy zwinnie. To tak trochę z przymrużeniem oka, ale myślę, że to już pokazuje, że nie jest to nie wiadomo co (jakaś eureka), tylko jest to bardziej sformalizowane podejście do czegoś, co i tak na co dzień robimy.

Dla mnie zwinność, zwinne myślenie to jest otwartość, chęć uczenia się, słuchania, adaptowania się do zmian, rozwoju, badania, sprawdzania, czy pracujemy sensownie (a może można jeszcze bardziej sensownie, może da się robić coś bardziej efektywnie?) – czyli takie stałe nastawienie, by pracować coraz lepiej, by wytwarzać coraz bardziej wartościowe produkty. Przy czym, jeśli będę dziś mówił „produkt”, to produktem jest cokolwiek, co Ty czy Twój zespół wytwarzacie. Może to być fizyczny produkt, może to być software czy usługa, która w pewnym sensie też jest produktem.

Czyli zwinność to takie nastawienie na stały rozwój i jednocześnie ograniczanie ryzyka przez częste sprawdzanie, czy idziemy w dobrym kierunku. Ja tak to rozumiem.

Jak wygląda zwinna komunikacja z klientem? Czego staramy się od niego dowiedzieć, by zoptymalizować pracę nad projektem? Często rozmowa z klientem jest trudna. W czym pomaga nam Agile?

Teoretycznie można powiedzieć, że zwiększa częstotliwość. W pewnym sensie wymusza częstszy kontakt z klientem, natomiast ja to odnoszę też do sprzedaży: w momencie, kiedy przyjmiesz to, co Ci mówi klient (znów – jeżeli dziś mówię „klient”, to mam na myśli kogokolwiek, kto jest po tej drugiej stronie, zamawia produkt, jest jego użytkownikiem itd.) i zaczniesz robić to według jego pomysłu i instrukcji, to może się to źle skończyć. Może się okazać, że rozumiecie się zupełnie inaczej – on miał na myśli coś innego niż Ty zrozumiałeś.

W sprzedaży ważne jest to, by dokładnie dowiedzieć się, dopytać, pogrzebać w potrzebach. W zwinności jest tak samo. W Scrumie na przykład – i to jest fajne – są konkretne spotkania (w pewnym sensie wymuszone), na których klient powinien się pojawić, żeby zachodził kontakt, częsty feedback. Praca nad wymaganiami i oczekiwaniami klienta też jest elementem zwinności, gdzie nie tylko przyjmujemy to, co ma być, ale też grzebiemy głębiej, by się upewnić, czy to właśnie jest to, czy tak się tylko klientowi wydaje.

Potem w regularnych odstępach czasu sprawdzamy z klientem, czy idziemy w dobrym kierunku, czy dobrze się zrozumieliśmy. Jeżeli nie, to jest jeszcze pora na zmianę kierunku: przestawienie wajchy i pójście pod innym kątem.

Nie wiem, czy to jest odpowiedni moment na zadanie takiego pytania, ale: jak „zmusić” tego klienta, żeby chciał spotykać się z nami często i odpowiadać na nasze pytania. Może się okazać, że jest on zirytowany, uważa, że wie lepiej i nie ma sensu tracić czasu. Czy z takim klientem nawiązujemy współpracę, jeśli pracujemy w Scrumie, czy mu dziękujemy?

Jak klient zobaczy, że traktujemy go poważnie, poczuje, że rzeczywiście chcemy się dowiedzieć, czego on potrzebuje, to myślę, że nie będzie się w ogóle zastanawiał. Oczywiście w ekstremalnych sytuacjach może być tak, że klient powie „róbcie, a ja przyjdę na koniec”. Obawiam się, że wtedy trzeba spróbować to zaakceptować i zobaczyć, co wyjdzie na końcu.

Natomiast całym zamysłem zwinności jest to, żeby w regularnych, krótkich odstępach czasu dostarczać klientowi wartość. Więc jeżeli przekonamy go „Drogi kliencie, spróbujmy, zobacz, co dostarczymy Ci w najbliższym czasie” (za dwa-trzy tygodnie) i klient zobaczy, że rzeczywiście dostał coś wartościowego i może od razu wpłynąć na kształt tego czegoś oraz na bieżąco go korygować, to jest duża szansa, że sam podłapie, że jest to wartościowe. Czyli: dostarczając mu wartość, powodujemy, że klient chętniej współpracuje w ten sposób.

To teraz podchwytliwe pytanie: jaka jest różnica między inkrementacyjnym a iteracyjnym podejściem do projektu i które z nich jest charakterystyczne dla Agile’a?

No właśnie, to jest podchwytliwe pytanie. Do wczoraj miałem na to jedną odpowiedź, potem zacząłem czytać pewną książkę i tam pojawiła się trochę inna odpowiedź. Mówi się, że Scrum w szczególności, a dla mnie zwinność – ale skupmy się na Scrumie – jest podejściem iteracyjno-inkrementalnym (jakieś dziwne słowa). Co do zasady increment, czyli „przyrost”, dotyczy samego produktu. Idea jest taka, by stworzyć coś, co już jakoś działa – niech to będzie prototyp z ograniczoną funkcjonalnością, który jednak klient może pomacać, posprawdzać i już coś o nim powiedzieć – i dokładać kolejne elementy, które będą coraz lepiej działały. Increment to jest właśnie ten przyrost: nadbudowujemy nad czymś, co już stworzyliśmy, bo sprawdziliśmy z klientem, że to jest fajne. Dobudowujemy więc kolejne części i cały czas sprawdzamy je z klientem.

Natomiast iteracja dotyczy samego procesu wytwarzania tego produktu. Jest to założenie, że pracujemy w pewnych cyklach. Mnie się to w Scrumie bardzo podoba – że narzuca rytm pracy. Mamy pewne terminy, przedziały czasowe, w których pracujemy, czyli sprinty (najczęściej z jakiegoś powodu 2-tygodniowe, ale to nie reguła). To jest właśnie iteracja, czyli kolejny cykl, w którym coś wytworzyliśmy i dodatkowo jeszcze przyglądamy się temu: czy robiliśmy to – pod względem procesowym – efektywnie, czy może możemy jeszcze coś zmienić.

Reasumując: increment dotyczy produktu, iteracja dotyczy procesu.

Wróćmy teraz do tego naszego klienta. Interesuje go czas wykonania projektu, poniesione koszty i dowieziona wartość. Jakie zalety dla biznesu w tym zakresie ma Agile?

Pytanie pomocnicze powinno jeszcze brzmieć: czy mamy stuprocentową pewność, że ten efekt, o którym klient mówi, jest rzeczywiście tym, który ma zostać dostarczony? Nie chciałbym wchodzić w dyskusję, czy lepsze jest tradycyjne podejście do prowadzenia projektów (tzw. waterfallowe czy kaskadowe) czy zwinne. Nie ma jednej odpowiedzi. Trochę zależy to od rodzaju projektu.

Zwinne podejście natomiast pozwala na niemarnowanie czasu, na minimalizowanie niepotrzebnej pracy. Mniejsze jest ryzyko, że wykonamy pracę, która jest niepotrzebna – gdzie się potem okaże, że klient tego nie potrzebował. Okazuje się, że jeśli spojrzeć na projekty – typu różnego rodzaju aplikacje – to można stwierdzić, że 20% funkcjonalności, które zostały wytworzone, jest używane na pewno, a około 50% w ogóle nie jest używane przez użytkowników tych aplikacji. Jeżeli więc tworzysz coś, czego połowa nie jest używana, to połowa Twojej pracy w pewnym sensie poszła na marne (no OK, zarobiłeś). W procesie zwinnego wytwarzania produktu może się okazać, że tej pracy unikniemy, ponieważ w międzyczasie dojdziemy z klientem do wniosku, że OK, on to w wymaganiach na początku podał, ale potem klient wywnioskuje, że „bez tego to nawet lepiej”.

Więc to pozwala częściej z klientem sprawdzać, czy na pewno robimy to, czego on potrzebuje, i czy wszystko jest tam konieczne. Przy czym chcę być dobrze zrozumiany: nie mówię, że waterfallowe podejście jest absolutnie złe i nikt nie powinien tego robić. Nie. Tam też są metody na sprawdzanie, czy idziemy w dobrą stronę i są okazje do wprowadzania zmian, natomiast podejście do całości projektu wygląda trochę inaczej.

Wydaje mi się, że podejście zwinne jest bardziej związane z tym, jak wyglądają dzisiejsze czasy: szybko, już, teraz. I to jest rozwiązanie, które pojawiło się dlatego, że tak wygląda obecnie życie. Dlatego waterfall to dawne czasy.

Trochę tak, a z drugiej strony Agile, zwinność, pozwala szybciej otrzymać produkt mający jakąś wartość, z którym można coś zrobić. Nawet niech to będzie prototyp, ale to jest już coś, co można np. puścić jakiejś grupie klientów do przetestowania – i niech oni się wypowiedzą, czy ma to szansę zaistnieć na rynku. Przeciwieństwem jest sytuacja, w której mamy wspaniały pomysł, tworzymy genialny produkt, zajmuje nam to 2 lata, wypuszczamy produkt na rynek, a rynek już dawno tego nie potrzebuje.

Jak można zacząć myśleć zwinnie? Co byś poradził juniorowi przed zdobyciem pierwszej pracy w IT?

Może być zaskoczeniem, że poradziłbym najpierw przyjrzeć się sobie. Czy można zacząć myśleć agile’owo? Poniekąd, tak jak powiedziałem, jest to gdzieś w głębi naszej natury. Co mam natomiast na myśli, mówiąc o przyjrzeniu się sobie?

Ja zrobiłem test Gallupa – to test dotyczący mocnych stron, po polsku tłumaczonych jako „talenty”. Jest wiele tego typu badań, natomiast Gallup to badanie prowadzone już od ponad 40 lat. Można na jego podstawie dojść do bardzo ciekawych wniosków. W każdym razie: w wyniku tego testu dostajesz uszeregowane w odpowiedni sposób mocne strony (to nie jest szufladkowanie). To pozwala zobaczyć, że robienie rzeczy, które wymagają takich i takich talentów, będzie w moim przypadku bardziej efektywnym wykorzystaniem energii niż coś innego.

Przykład: są tam 34 cechy. Na samym końcu mam coś takiego jak achiver, co jest ewidentnie związane np. ze sprzedażą. I właśnie wtedy mnie olśniło, że przez 18 lat robiłem coś, co wymaga ode mnie dużo więcej energii, niż powinno, bo jest to bardzo daleko na mojej liście mocnych stron, podczas gdy na samym początku mam takie rzeczy jak odkrywczość, kreatywność, wyszukiwanie informacji, pomaganie ludziom, uczenie. To są rzeczy bardziej dla mnie naturalne. To mi pomogło podjąć decyzję o wejściu do IT.

Żeby zacząć myśleć zwinnie konieczna jest otwartość, chęć eksperymentowania, błądzenia, pytania, podejmowania prób i popełniania błędów oraz rozmawiania z osobami z IT. Jeżeli masz możliwość, to pogadaj z kimś, kto już robi to, nad czym Ty się zastanawiasz (możesz pogadać np. z Mateuszem, jeśli chcesz być programistą). Pamiętaj, że głupie pytania wcale nie są głupie, bo mogą prowadzić Cię do odpowiedzi, którą będzie albo „tak, idziemy w tym kierunku”, albo „nie, to nie jest ten kierunek”.

Nie wiem, czy pamiętasz, Mateusz, kiedyś z Tobą rozmawiałem. Chciałem być programistą, nawet prawie zapisałem się na mentoring u Ciebie. Ale potem przeanalizowałem, że to zupełnie nie leży w mojej naturze, że to nie jest ten kierunek. Bardzo się cieszę, że mieliśmy okazję pogadać – opowiedziałeś mi trochę, jak ten cały proces wygląda – i ja podjąłem decyzję, że idę w innym kierunku. To bym polecał juniorom, którzy chcą się np. przebranżowić.

No to mnie teraz zabiłeś tym, że rozmawialiśmy. Nie kojarzyłem. Całkiem przypadkowo trafiłem na Ciebie potem drugi raz. Kiedy to było?

Ze dwa lata temu.

No to możesz mi wybaczyć.

Wybaczam.

Dziękuję, dziękuję.

OK, to przejdźmy dalej. Wiemy już, że Scrum to framework, więc pewnie są jakieś wytyczne. Czy istnieje dokumentacja dla Scruma?

Na szczęście istnieje i jest to bardzo okrojona dokumentacja. Jest coś takiego jak Scrum Guide – warto poszukać. Jest on ogólnie dostępny, np. na scrumguide.org czy w dowolnym innym miejscu. Można nawet posłuchać Scrum Guide’a czytanego przez Krystynę Czubównę, w ramach ciekawostki.

Co więcej, sam planuję nagrać Scrum Guide’a, ale w kawałkach, ponieważ większość tych materiałów, nawet do słuchania, istnieje w całości, co trudniej przyswoić. Ja chcę zrobić z tego małe plasterki – ale to pieśń bliskiej przyszłości.

To, co mi się podoba, i jednocześnie jest swego rodzaju problemem, to że Scrum Guide ma 13 stron, a jeszcze jakiś czas temu miał ich 17, co oznacza, że są to takie rzeczy, które absolutnie muszą się tam znaleźć – te wytyczne, bez których Scrum prawdopodobnie już by tak dobrze nie działał. Chyba że za parę lat wytną coś jeszcze, bo stwierdzą, że jest zupełnie niepotrzebne. Jest to w każdym razie zestaw zasad, które stanowią podstawę do budowania zespołu w oparciu o Scrum i zwinne podejście.

To, co jest ważne: każdy zespół powinien zaadaptować Scruma do swojej specyfiki, produktu, swojego składu poprzez eksperymentowanie. Cały czas natomiast bazujemy na tym, co jest w Scrum Guidzie. Nie jest to swego rodzaju Biblia, którą się trzeba zasłaniać i podpierać, lecz jest to zbiór zasad, którymi powinniśmy się kierować.

Wspomniałeś o tym, że chcesz ponagrywać parę wyjaśnień, to teraz dobry moment na próbę. Czy mógłbyś pokrótce przybliżyć nam 3 artefakty Scruma?

Czuję się jak na rozmowie kwalifikacyjnej (śmiech).

Ja nie oceniam.

To dobrze, całe szczęście. Kiedyś, gdy byłem na jakiejś rozmowie, padło pytanie o 3 wartości Scruma, a ja zacząłem mówić o artefaktach albo na odwrót – nie pamiętam. Tak to jest, gdy jesteś teoretykiem i próbujesz udawać, że wiesz, o czym mówisz. Naczytałem się, natomiast nie bardzo wiedziałem, do czego to przyłożyć.

Trzy artefakty w Scrumie: masz pewnie na myśli backlog produktu, backlog sprintu i tzw. przyrost. Backlog produktu to – w największym uproszczeniu – zbiór pomysłów na to, co w produkcie powinno się znaleźć. Zajmuje się nim Product Owner. Jest to osoba odpowiedzialna za to, żeby z tego zbioru wybrać rzeczy, którymi powinniśmy zająć się w pierwszej kolejności, w najbliższych sprintach. Dba także o to, aby maksymalnie doprecyzować pomysły z klientem. Product Owner to jedna z ról w Scrumie – współpracuje z klientem, aby ustalić, co ma w tym produkcie być, i przygotowuje element backlogu, aby zespół mógł się nim zająć.

Dopytam: taka osoba odpowiedzialna jest w naszym zespole, czy jest to osoba oddelegowana przez klienta?

Nie ma reguły. Co ważne, powinna (chciałem powiedzieć: musi, ale – powinna) być to osoba, która ma pewną władzę, pewną decyzyjność odnośnie do tego, co rzeczywiście robimy, w jakiej kolejności wytwarzamy produkt. Często Product Owner jest po stronie zespołu, bo firma wykonująca dany produkt organizuje cały zespół, w tym Product Ownera.

Ale są też sytuacje (i to jest całkiem niezły pomysł), aby Product Owner był po stronie klienta, ponieważ to on jest tym zamawiającym i on też wie, o co mu chodzi. Tam ma wówczas cały zespół, tzw. biznes, z którym ustala detale. Więc praktykuje się i tak, i tak. Co jest lepsze? Nie wiem. Pewnie chciałoby się powiedzieć: to zależy.

Czyli w zasadzie backlog to zbiór zadań – można by tak powiedzieć?

Powiedziałbym: zbiór pomysłów. Na wierzchu tego zbioru pomysłów robi się zbiór zadań. One się tam krystalizują, są układane i wybierane przez Product Ownera. Te najbardziej doprecyzowane możemy stamtąd brać i przenosić do backlogu sprintu, który jest drugim artefaktem.

Backlog sprintu to te zadania z tych „gotowych do pracy”, które zespół wybiera jako te, nad którymi będzie pracować w najbliższym sprincie, żeby zrealizować cel sprintu. Nie chcę aż tak głęboko w Scrum wchodzić, lecz każdy sprint ma jeden określony cel. Wybieramy elementy backlogu, które pozwolą nam ten cel osiągnąć. W ten sposób powstaje backlog sprintu. Na koniec sprintu ma powstać przyrost, czyli trzeci artefakt, o którym już trochę mówiliśmy przy okazji iteracyjno-inkrementalnego podejścia.

Czy zawsze na końcu pojawia się przyrost?

Zasadniczo powinien, choć zawsze może coś pójść nie tak i przyrost się nie pojawi. Sprint jest takim żywym organizmem – cały czas odkrywamy produkt, dowiadujemy się nowych rzeczy. Nie musimy wszystkiego wiedzieć na 5 lat do przodu, na cały czas trwania projektu. W trakcie pracy pojawiają się nowe niespodzianki, o których np. analitycy w ogóle nie pomyśleli, bo mieli za małą wiedzę. Developerzy także w trakcie pracy zdobywają wiedzę na temat produktu, który tworzą. Tak że czasem przyrost może, niestety, nie powstać.

Zastanawiam się, czy możemy interpretować przyrost jako usunięcie danej funkcjonalności, np. jako poprawę, optymalizację działania produktu przez usunięcie jakiejś rzeczy. Inkrementacja wówczas nie spowodowałaby „fizycznego” przyrostu, ale pojawiłoby się polepszenie.

Ma to sens. Jeśli celem sprintu będzie spowodowanie jakiejś optymalizacji i ma do tego doprowadzić usunięcie danego elementu, to będzie to przyrost. Czyli efektem pracy w sprincie w pewnym sensie jest ten przyrost: nowa, coraz lepsza wersja produktu.

Zanim przejdziemy dalej, zacznijmy może od nieprawidłowego wdrożenia Sruma. Czym jest Dark Scrum i jakie ma konsekwencje dla zespołu i klienta?

Wchodzimy na bardzo grząski grunt – tu jest najwięcej dyskusji na ten temat. Chyba jest moda na Scrum, więc wiele różnych podejść nazywanych jest Scrumem, podczas gdy wcale Scrumem nie są. To powoduje dużo zamieszania; to powoduje, że powstaje jakaś opinia na rynku – czarny PR i tak dalej.

Czym jest Dark Scrum? To jest Scrum w pewnym sensie wynaturzony, tak zmodyfikowany przez zespół, że właściwie nie wiadomo czasem, co to jest. Są różne sytuacje. Ciekaw jestem, czy istnieje w Polsce firma, która stosuje Scrum w stu procentach, taki czysty Srum, jak to się mówi. Nie wiem.

Zauważyłem, że mamy tendencję do mówienia „my tu mamy Scrum, ale taki po naszemu”. W ten sposób powstają dziwne sytuacje, w których ktoś coś komuś narzuca, ktoś mówi, że „w Scrum Guidzie tak jest i tak musimy robić” i tak dalej. Dark Scrum to są właśnie wszystkie te sytuacje, w których powstają, powiedzmy, nieprawidłowości, a w efekcie potem człowiek wychodzi z takiego zespołu i mówi wszystkim, że „Scrum nie działa. Ja pracowałem w zespole scrumowym i to jest do chrzanu”. Ja to tak rozumiem. Pewnie można by przeczytać definicję Dark Scruma. Nie pamiętam nazwiska gościa, który to opisał. To jest jednak moje zrozumienie Dark Scruma: „nazwijmy to Scrumem, ale zróbmy wszystko po swojemu”.

Jak w takim razie wprowadzamy Scrum do zespołu? Jak to zrobić dobrze?

A po co wprowadzać Scrum do zespołu? Zacznijmy od pytania: czy na pewno ten Scrum jest tam potrzebny? Trochę takich różnych prób i błędów popełniłem. Wiem, i sam tego doświadczyłem, że przychodzi zespół i mówi: „potrzebujemy Scrum Mastera, bo mamy Scrum, ale coś nie działa”. Potem przychodzisz, przyglądasz się – a to właściwie koło Scruma nie leżało. Ale modnie jest powiedzieć, że pracujemy w Scrumie, a teraz trzeba jeszcze wziąć Scrum Mastera (który powinien być tam od początku by the way), który pomoże posprzątać.

Tak czy tak, trzeba zacząć od tego, dlaczego ma być akurat Scrum, co ma z tego wyniknąć, co ma to dać zespołowi, czy na pewno zespół wytwarza coś, co da się wytworzyć scrumowym podejściem. Bo może zespół pracuje nad, nazwijmy to, utrzymaniowymi rzeczami, a może robi rzeczy, które są ciągłym powtarzalnym procesem, gdzie nie powstaje de facto nic nowego, tylko jest to np. call center czy cokolwiek innego – wtedy Scrum wcale nie jest najlepszym podejściem.

Najpierw więc trzeba ustalić, czy Scrum jest potrzebny. Potem są dwie metody:

• Krok po kroku wprowadzamy poszczególne elementy – to ma sens, jeśli zespół do tej pory pracował w dany sposób, a chcemy zacząć testować, czy Scrum jest dla nas. Wówczas zaczynamy np. od daily albo retrospektywy. Wprowadzamy poszczególne elementy Scruma, żeby zobaczyć, co to da. Potem dokładamy kolejne i w końcu pracujemy scrumowo.
• Są też tak odważne zespoły, które odcinają grubą kreską: od dzisiaj pracujemy w pełni w Scrumie. I też jest to podobno wykonalne, natomiast ważna jest otwartość,
  gotowość zespołu, dojrzałość – także do wzięcia odpowiedzialności za efekty. Jeśli coś pójdzie nie tak, to my jako zespół bierzemy za to odpowiedzialność, bo zdecydowaliśmy się na taki krok.

Słyszałem też o metodzie, gdzie zespół w ogóle nie chciał Scruma – tych „durnych spotkań”, których jest za dużo – i potrzebna była (jak to jeden z moich poprzednich szefów powiedział) twarda scrum masterska robota. Zespół niekoniecznie musi wiedzieć, co to znaczy, że pracuje w Scrumie. Wówczas Scrum Master mimo sprzeciwów czy delikatnych oporów musi powiedzieć: „słuchajcie, zróbmy tak i sprawdźmy”. Rolą Scrum Mastera jest poprowadzenie zespołu i bycie razem z zespołem.

Wyjaśnij nam jeszcze, proszę, czym jest daily i retrospekcja.

Daily to codzienne spotkanie, przy czym bardzo często błędem jest założenie, że to rodzaj statusu – zapraszamy managera, przed którym się spowiadamy: co robiliśmy, co będziemy robić i tak dalej. Nie. Daily to spotkanie dla zespołu. W Scrum Guidzie jest słowo „developerzy”, „zespół developerski” – czyli wszystkie te osoby, które pracują nad produktem.

Głównym celem daily jest ustalenie, czy idziemy w kierunku celu sprintu, czy mamy szansę go zrealizować. Jak do tego dojdziemy, o czym będziemy gadać – to nie jest już jasno określone. Kiedyś była taka metoda 3 pytań: wczoraj pracowałem nad tym, dzisiaj będę pracować nad tym i mam w tym takie i takie blokery (przeszkody), których się spodziewam. To wprowadziło mechaniczność. Chodzi o dyskusję nad tym, czy nadal mamy szansę zrealizować cel sprintu, a jeśli nie, to znajdźmy rozwiązanie, żeby jednak go zrealizować.

Co do retrospektywy – kiedyś na rekrutacji zadano mi pytanie: jeśli miałbym zostawić tylko jedno ze spotkań scrumowych, to które. Odpowiedziałem, że retrospektywę, ponieważ retrospektywa to na końcu sprintu taki czas, w którym w pewnym sensie odstawiamy produkt na bok i przyglądamy się procesowi pracy – temu, jak pracowaliśmy: czy robiliśmy to efektywnie, dlaczego pojawiły się dane trudności i jak ich uniknąć w przyszłości. Patrzymy na swoją pracę, na to jak pracowaliśmy, żeby pracować lepiej. To jest retrospektywa.

A jak Scrum wpływa na pracę developerów? Czy pracuje im się łatwiej?

Zasadniczo tak – poprzez większą klarowność, transparentność pracy. Cały zespół jest odpowiedzialny za produkt (jeśli podejście scrumowe jest prawidłowo zastosowane) i widzi, co robi reszta, np. poprzez daily – tę codzienną synchronizację.

To jest trochę tak: jeśli jesteśmy do czegoś przyzwyczajeni i oczekuje się, że zaczniemy robić to trochę inaczej, to raczej się bronimy. Tu jest coś, co znamy, tam jest coś, czego nie znamy. Przy czym może się okazać, że jeśli zrobimy coś, czego nie znamy, to będzie nam jeszcze lepiej, niż było do tej pory.

Jeżeli developerzy pozwolą sobie z otwartością i odpowiedzialnością podejść do tego zagadnienia, to może się okazać, że Scrum lub inne agile’owe podejście pozwoli im lepiej pracować: bardziej efektywnie, mieć więcej czasu lub większą satysfakcję z pracy. Wymaga to jednak przeskoczenia etapu negowania np. z braku zrozumienia.

Odpowiadając na Twoje pytanie: Scrum pomaga zespołowi efektywniej pracować. Warto jednak zacząć od dobrego zrozumienia: co to ma nam dać, jak to będzie przebiegało, co znaczy „zwinny sposób myślenia” versus „przecież zawsze tak robiliśmy”. To jest trochę taki proces, w którym zadaniem Scrum Mastera jest pomóc zespołowi ten proces przejść.

Już kilka razy zaznaczałeś, że czasem nie warto tego Scruma wdrażać. Do czego Scrum się nie nadaje?

Nie chciałbym kategorycznie odpowiadać: tu tak, a tu nie. Natomiast największy sens Scrum ma tam, gdzie coś wytwarzamy i nie do końca wiemy, co ma być rezultatem. W związku z czym, odwracając to, jeżeli nie powstaje jakiś produkt, coś, co wytwarzamy i rozwijamy, to zastanawiałbym się, czy Scrum jest na pewno dobrą metodą. Mówię o sytuacji, w której pracujemy nad jakimś wdrożeniem, albo o sytuacji, gdzie jest stały proces, cykliczne, „utrzymaniowe” tematy.

Na przykład w analizach biznesowych, tam gdzie teraz pracuję, są krótkie projekty, które potrafią trwać 2 tygodnie / miesiąc / 2 miesiące, więc tam stosowanie Scruma w pełni nie do końca ma sens, bo np. brakuje zmienności i okazji do odkrywania produktu. Po prostu wiemy od A do Z, co ma być wykonane. Wówczas Scrum będzie stosowany na siłę.

Są różne teorie. Do budowania budynków Scruma raczej bym nie stosował. Oczywiście są przykłady, gdzie ktoś np. budował dom scrumowo i rysował kredą na fundamencie. Czy to też można nazwać Scrumem? Nie wiem.

Albo szkolenie – jeżeli projektowałbym szkolenie i chciałbym podejść do tego scrumowo, musiałbym się zastanowić, czy jestem w stanie stworzyć małą próbkę szkolenia, która będzie miała wartość dla klienta. Klient tego doświadczy i da mi informację zwrotną. Jeśli tak, to mógłbym spróbować Scruma. Ale to może być trochę na siłę.

Wracam do tego, co wcześniej: jeśli coś nie jest Scrumem, to czy musimy to nazywać Scrumem? Po prostu pracujmy zwinnie. Bardziej liczy się podejście i sposób myślenia.

Czyli mocno wkracza tu ten element otwartości. Nie musimy się trzymać sztywnych reguł, ale nie możemy przesadzać, bo wtedy wejdzie Dark Scrum.

No tak, policja scrumowa i takie rzeczy.

To pilnujcie się.

Tak jest.

Czy jeśli pracujemy sami, bez zespołu, to możemy stosować Scrum? Czy to już kwalifikuje się pod „nie nazywajmy Scrumem czegoś, co nim nie jest”.

Otóż tak: nikt Ci tego nie zabroni. Możesz pracować scrumowo, z czym chcesz. Pytanie, czy to nadal jest Scrum, bo np. w Scrum Guidzie zespół to od 3 do 9 osób. W związku z tym, gdy pracujesz sam, to nie tworzysz zespołu. Czy sam ze sobą będziesz robił daily, żeby się ze sobą synchronizować? Już ten element powoduje, że nie do końca pracujemy scrumowo.

Możemy jednak, pracując sami, stosować podejście zwinne. Na przykład ja ze swoim zespołem (bo jestem perkusistą i mam zespół) podeszliśmy zwinnie do nagrywania utworów. Nie zrobiliśmy tak, że przygotowaliśmy cały materiał, weszliśmy do studia i nagraliśmy, tylko nagraliśmy pierwszą piosenkę, potem drugą – już wyciągając wnioski po tej pierwszej trochę lepiej ustawiliśmy mikrofony i tak dalej. W ten sposób doszliśmy do coraz lepszych rezultatów. Czy to był Scrum? Chyba nie. Ale zwinne podejście: nastawienie na naukę, odkrywanie, eksperymentowanie, otwartość.

Wspomniałeś, że osoba, która jest zainteresowana podejściem zwinnym, może np. zacząć od poznania Kanbana.

Tak, na przykład. Kanban w najprostszej formie – dla tych, którzy nie wiedzą – to pewna forma uwidaczniania naszej pracy na jakiejś tablicy. Mówię „pewna”, „jakaś”, bo to też nie jest jasno określone. Ale jeżeli korzystasz np. z Trello, to jest to forma Kanbanu. Wszystko, co masz do zrobienia, jest w jednym miejscu; to, co robisz, jest w drugim miejscu; a to co zrobiłeś – w trzecim. To jest najprostsza forma.

Tak samo podszedłem z moim synem do organizacji jego urodzin. Zrobiliśmy prostą tablicę z karteczkami przylepnymi i tam wrzucaliśmy rzeczy, które mają się wydarzyć – żeby wziął on większą odpowiedzialność za tę imprezę. Jest to kanbanowe podejście.

Jakie błędy, o których jeszcze nie powiedzieliśmy, zauważasz w pracy ze Scrumem?

Myślę, że kolejnym błędem jest przerost formy nad treścią – sztywne trzymanie się: „Scrum Guide mówi, że ma być tak i tak, więc musimy robić tak, choć lepiej byłoby trochę inaczej, ale robimy tak”. Brak zrozumienia, mechaniczność w tym postępowaniu – to też się z tym wiąże. Jeżeli nie zrozumiemy, czym jest zwinność, a chcemy mieć Scruma i robimy daily (ogóle nie wiadomo, po co ono jest), robimy review (nie wiadomo, po co), bo tak jest napisane w Scrum Guidzie. Ma trwać 15 minut, więc trwa 15 minut. Jak trwa 10 minut, to się niepokoimy, dlaczego tylko 10 itd. Czyli mechaniczne podejście to częsty błąd.

Pasowałoby tutaj określenie „policji scrumowej”, o której wcześniej wspominałem. Mamy gościa, który pilnuje, żeby wszystko było zgodnie z książką.

Jednocześnie błędem jest zbyt wybiórcze podejście, na zasadzie: „Pracujemy w Scrumie, bo mamy sprinty, więc jesteśmy Agile”. No i co jeszcze? „No sprinty mamy. A reszta to bez sensu. Daily to strata czasu, przecież my i tak wiemy, co robimy. A retro raz na pół roku – robimy sobie integrację i rozmawiamy o tym, jak się nam pracuje”. To też jest błąd. To nie jest Scrum i być może nie jest nawet zwinne.

To są chyba najczęstsze błędy. Na pewno można by znaleźć jeszcze wiele innych. Może ci ze słuchaczy, którzy już doświadczyli Scruma, mogą w komentarzach coś podpowiedzieć. Chętnie potem poczytam.

To zapraszamy do zamieszczania tych wszystkich ciekawych historii.

A na koniec: jaką książkę polecisz osobie, która chce lepiej poznać Agile i Scrum, może nawet zaproponować je w swoim zespole?

Oczywiście Scrum Guide to jest coś, co warto czytać regularnie, bo się potem po pół roku okazuje, że znajdujesz tam rzeczy, które ktoś jakimś cudem musiał dopisać, bo ich tam wcześniej nie było. To rzeczywiście bardzo krótka forma, lecz warto poczytać ze zrozumieniem, małymi plasterkami.

Bardzo polecam moje ostatnie, ponowne odkrycie: książka Scrum. A smart travel companion Gunthera Verheyena. To człowiek, który od prawie 20 lat pracuje zwinnie. Pracował w Scrumie, jak jeszcze nie było nazywane to Scrumem. Napisał on taką bardzo cienką książeczkę (dosyć trudno ją się czyta, bo jest bardzo mądrze napisana), w której bardzo głęboko wchodzi w to, czym jest zrozumienie zwinnego podejścia. Bardzo polecam tę książkę. Po polsku niedługo powinna się ukazać, ale po angielski bez problemu można ją kupić.

Co więcej (tu szczypta autoreklamy) na moim kanale na YouTubie, do którego link znajdziecie w opisie tego odcinka, jest krótki wywiad z serii „3 pytania do Scrum Mastera”. Jest tam rozmowa właśnie z Ginterem. Zaskoczył mnie tym, co tam mówi. Zadałem mu 3 proste pytania, a on naprawdę mądrze do tego podszedł. Polecam go posłuchać.

Książka Jacka Wieczorka Labirynty Scruma – też polecam. To fajna książka, w której można czytać małe fragmenciki, konkretne przypadki. Jeśli masz z czymś problem, to znajdujesz go w spisie treści i czytasz, jak do tego warto podejść.

Jest bardzo dużo różnych książek. Przestrzegam ludzi, którzy chcą się przebranżowić przed czymś takim, że „czytamy, szkolimy się, chodzimy na meet upy” itd., ale jednocześnie mamy zero praktyki. Trzeba jednocześnie zacząć próbować to ćwiczyć, żeby nie przegiąć. A jak już zaczniesz pracować w Scrumie – to takie moje ostatnie odkrycie – warto czytać książki z kierunku NVC, czyli Porozumienia bez Przemocy. To, można powiedzieć, taki nurt komunikacji (nie chcę za bardzo w to wchodzić). Polecam książkę Przestańmy być grzeczni, bądźmy sobą. Taki tytuł trochę biorący pod włos. Bardzo fajna książka, jeśli chcemy nauczyć się lepiej współpracować z ludźmi.

I moje ostatnie odkrycie: książka Mały Książę wyobraź sobie. Jakoś tak wpadłem na pomysł, aby przeczytać ją jeszcze raz. I to naprawdę strasznie mądra książka o nas: o tym, jak myślimy, jak działamy. Więc na tym etapie, gdy zaczynasz pracować z zespołem i masz do czynienia z ludźmi, którzy robią różne dziwne rzeczy, warto w tym kierunku pójść.

Powiem Ci, że Mały Książę pojawia się dość często. Może nie u mnie w podcaście, ale ogólnie wiele osób wraca do niego i mocno chwali. Zastanawiam się, czy ta książka w ogóle powinna być w szkole. Czy nie jest „za mądra” na ten okres?

Myślę, że nie jest za mądra, bo jest też napisana dla młodych ludzi, dla dzieci, ale zupełnie inaczej ją się odbiera na innym etapie życia.

Gdzie możemy Cię znaleźć w sieci?

Najłatwiej znaleźć mnie na Linkedinie pod moim prawdziwym imieniem i nazwiskiem (nie ukrywam się nigdzie): Jerzy Cieśliński. Tam jest zdjęcie gościa, który trzyma coś w rodzaju pucharu – to ja.

Możecie też wpisać na YouTubie „Coach Up” (z przerwą, bo jak wpiszecie razem, to wyskakuje jakaś stronka z futbolem amerykańskim). Będzie tam dopisek „Agile, coaching, biznes” – po tym to poznacie. Jest całe 80 subskrybentów, więc miło, jeśli Was trochę przybędzie. Jest tam trochę materiałów na temat „3 pytań do Scrum Mastera”. Zdradzę, że niedługo dorzucę tam 3 nowe. Będą bardzo ciekawe… Coraz ciekawsze materiały się tam znajdują.

Więc to są takie dwa główne miejsce, gdzie można się ze mną spotkać i zagadnąć mnie o cokolwiek chcecie. Zapraszam.

Ja również zapraszam. Subskrybujcie, lajkujcie te wszystkie materiały, żeby Jerzy miał co robić.

Dziękuję.

A ja bardzo dziękuję Ci, Jerzy, za dzisiejszą rozmowę i podzielenie się z nami swoją wiedzą.

Dzięki wielkie za zaproszenie. To była fajna okazja do przemyślenia sobie jeszcze raz tych wszystkich pytań. Dzięki wielkie.