Aktualizacja Przewodnika po Scrumie

Stało się! Światło dzienne ujrzała najnowsza wersja Przewodnika po Scrumie która po raz kolejny jest “przełomowa”. Twórcy Scruma, Ken Schwaber oraz Jeff Sutherland, zaprezentowali  ją światu siódmego listopada  Co się zmieniło do poprzedniej wersji? O tym poniżej.

W telegraficznym skrócie: w najnowszej wersji Przewodnika po Scrumie pojawiła się informacja gdzie Scrum może znaleźć zastosowanie, doprecyzowano kosmetycznie zakres pracy Scrum Mastera, lekko zmieniła się definicja Daily Scrum, dookreślono pojęcie Przyrostu, rozprawiono się z podejściem do ram czasowych spotkań, poruszono temat częstotliwości wdrożeń oraz zasugerowano, aby wnioski z retrospektyw trafiały do backloga. I to byłoby na tyle. Przyjrzyjmy się zmianom nieco bliżej.

Punkt pierwszy, czyli gdzie tego Scruma w końcu można zastosować. Tak naprawdę, ten kto czytał książkę autorstwa Sutherlanda, Scrum, czyli jak robić dwa razy więcej, dwa razy szybciej, mógł już zaobserwować, że Scrum nie jest używany jedynie w świecie IT. Wyszedł daleko poza niego. Twórcy twierdzą, że nadaje się do każdej sytuacji, gdzie są wykonywane prace badawcze bądź rozwiązywane są złożone problemy. Nieważne czy to system IT, autonomiczny samochód czy prace rozwojowe nad nowym kremem na zmarszczki. Podstawą ku temu jest praca w iteracjach oraz oparcie o empiryzm – inspekcję i adaptację.

Punkt drugi. Scrum Master. Dopieszczono opis tej roli, podkreślając, że Scrum Master jest odpowiedzialny za promowanie i wspieranie Scruma, poprzez pomaganie wszystkim zrozumienia jego teorii, praktyki, zasad oraz wartości. Określono, że Scrum Master musi posiadać dobrze rozwinięte konkretne kompetencje takie jak, umiejętności organizacyjne, dyplomacja oraz cierpliwość, co pozwala mu walczyć z wiatrakami podczas transformacji Agile.

Daily Scrum, tu “rewolucja”. Okazało się, że święte trzy pytania są jedynie wskazówką, jak może zostać przeprowadzone te spotkanie. Skupiono się bardziej na tym, aby wspomóc, uwypuklić dostarczenie celu sprintu niż odpowiadać na sławetne pytania. Dodatkowo, zostało uwidocznione, że Daily Scrum to spotkanie dla Zespołu Deweloperskiego. Czyżby koniec Product Ownerów i managerów odbierających raporty?

Przyrost, czyli tzw. inkrement. W zasadzie zmiana jest tak drobna, że nie wymaga ona komentowania. Dookreślono, że jest on krokiem naprzód, aby osiągać wizję lub cel postawiony sobie przy starcie projektu. Jak wytłumaczyć tę zmianę? Być może nowy Przewodnik, podobnie jak prace na studiach musiał zawierać odpowiednią ilość znaków?

Rozprawiono się z ramami czasowymi poszczególnych wydarzeń . Nie, nie oznacza to, że je zlikwidowano. Dla wszystkich Zespołów, które już osiągnęły poziom RI i potrafią zaplanować 4 tygodniowy sprint w 30 minut, oznacza to, że nie muszą czekać, aż zaplanowany na planowanie czas się skończy. Uwypuklono, że wszelkie ramy czasowe jakie pojawiają się w Scrum Guide to maksymalny czas jaki powinno się poświęcić na dane spotkanie.

Co z wdrożeniami? Dodatkowo na slajdach dołączonych do webinara prowadzonego przez twórców Scruma została poruszona kwestia czy zespół może wdrażać tylko raz, na koniec sprintu? Nie. Twórcy Przewodnika po Scrumie opisali, że wdrożenie może odbyć się w każdym momencie wybranym przez Product Ownera, pod warunkiem, że jest to możliwe dla Zespołu. Dodatkowo opisano, że podejście Continuous Delivery jak najbardziej może być zastosowane w Scrumie. Podkreślono też ciekawą rzecz – nie należy obniżać jakości wymagań, aby wdrażać szybciej, bo Zespół zostanie przygnieciony przez dług technologiczny.

I ostatnia rzecz – do opisu Backlogu Sprintu dołożono sformułowanie, które ma zapewnić stały rozwój zespołu. Po każdej retrospektywie  powinna trafić do niego przynajmniej jedna rzecz, która usprawni proces. To powinno rozwiać częste wątpliwości co robić z listą rzeczy, które musimy zmienić. Teraz zapewne pojawi się pytanie, jakie zdrowe proporcje powinny być pomiędzy rozwojem zespołu, a rozwojem produktu.

Jak widać, powyższe zmiany nie stanowią rewolucji, a raczej ewolucję/dopieszczenie zasad.  Wielu z nas dotarło do tych wniosków wraz ze swoimi zespołami podczas codziennej j pracy. Powyższe zmiany to właśnie nasz głos, osób, które na co dzień pracują w Scrumie i podzieliły się swoimi propozycjami zmian poprzez stronę https://scrumguide.uservoice.com/