blog.testowka.pl

Zmiany w Scrum

opublikowany przez 07, Sie, 2013, w kategoriach Agile, Scrum

Człowiek wraca sobie jak gdyby nigdy nic z wakacji, patrzy a tu zmienili mu Scrum. TAK – zmienili Scrum! Co prawda nie było jakiejś wielkiej rewolucji ale nowa wersja Scrum Guide zawiera kilka istotnych zmian wartych omówienia.

Pierwszą zasadniczą zmianę widzimy w opisie Sprintu, gdzie zniknął punk dotyczący zabraniania zmian składu zespołu w trakcie Sprintu. Zamiast tego zmianie uległ podpunkt mówiący o wprowadzaniu zmian. Zabronionym było zmienianie czegokolwiek co mogło „wpływać” na Cel Sprintu w tej chwili mowa jest o zmianach, które mogą „zagrozić” Celowi Sprintu. Na ile jest to istotna zmiana pozostawiam Waszej ocenie.

Obserwując to jak Scrum ewoluuje podejrzewam, że usunięcie podpunktu dotyczącego składu zespołu mogło być spowodowane tym, że coraz częściej zespoły korzystają z pomocy zewnętrznych ekspertów i specjalistów co daje bardzo dobre efekty. Dzięki tej zmianie w Scrum Guide teraz „legalnym” będzie dołączanie takich osób w miarę potrzeb do zespołu.

Druga zasadnicza zmiana w Scrum to usunięcie proporcji dla timeboxes w Sprintach krótszych niż jeden miesiąc. Tak na przykład Sprint Planning ma teraz timebox maksymalnie 8 godzin bez względu na długość Sprintu (chociaż zapisana została sugestia, że dla krótszych Sprintów czas ten powinien być krótszy). Osobiście tutaj obawiam się największych problemów – tak jak pisałem w „Mitach i problemach w Agile” wcześniej stosowany timebox, proporcjonalny do długości iteracji sprawdzał się w mojej ocenie bardzo dobrze. Był  minimalny i jednocześnie wystarczający. Obecne wydłużenie timeboxów dla krótszych Sprintów będzie w mojej ocenie polem do nadużyć, a w efekcie dla tygodniowej iteracji może pozostać nam zaledwie 2 i pół dnia na pracę…

Poczekamy zobaczymy. Może takie podejście pozwoli niektórym zespołom jeszcze lepiej planować i dzięki temu pracować efektywniej.

A jak już jesteśmy przy planowaniu to usunięty został sztywny podział czasowy Sprint Planning na dwie części. Teraz mamy jedno spotkanie podczas którego ustalamy co i jak będziemy robić w najbliższej iteracji, oraz po co będziemy to robić czyli Cel Sprintu.

Osobiście podoba mi się takie podejście – zresztą mówiło się o tym już od dawna i w praktyce właśnie tak wyglądały planningi zespołów którym pomagałem. Wcześniejszy podział na dwa timeboxy po 50% czasu na planowanie narzucał dużo ograniczeń i często był przyczyną marnotrawstwa.

Wzrosło też znaczenie samego Celu Sprintu. Do tej pory w Scrum skupialiśmy się na wykonywaniu pracy na zadanym poziomie jakości. Teraz istotnie podkreślone z punktu widzenia procesu zostało także wskazanie sensu wykonywanej pracy.

Wokół Celu Sprintu zostały także zbudowane nowe trzy pytania na Daily Scrum. W nowej wersji brzmią one następująco:

  • Co zrobiłem wczoraj by pomóc zespołowi developerskiemu w osiągnięciu Celu Sprintu?
  • Co będę robił dzisiaj by pomóc zespołowi developerskiemu osiągnąć Cel Sprintu?
  • Czy widzę jakieś przeszkody, które stoją na drodze mnie lub zespołowi i mogą nam przeszkodzić w osiągnięciu Celu Sprintu?

Według mnie ta zmiana ma duże znaczenie – być może takie podejście pomoże zespołom szybciej zrozumieć prawdziwy sens codziennych spotkań. Dzięki temu może wreszcie te spotkania przestaną być raportowaniem a staną się wspólną refleksją na temat tego dokąd zmierzamy i jaki jest nasz cel, oraz czy jesteśmy w stanie go osiągnąć. W wielu przypadkach wymusi to też na organizacjach regularne opracowywanie tychże celów (uwierzcie nie wszyscy mają Cel Sprintu)…

Również w celu zapobiegnięciu przeistaczania się Daily Scrum w spotkanie raportowe usunięte zostało zdanie mówiące o tym, że każdego dnia Development Team powinien być w stanie wytłumaczyć Product Ownerowi i Scrum Masterowi w jaki sposób zamierzają osiągnąć Cel Sprintu. Teraz mowa jest o tym, że zespól developerski powinien rozumieć to w jaki sposób zamierzają to osiągnąć.

Optymalizacja wartości – to kolejna istotna zmiana. W ogóle pojęcie wartości dopiero teraz pojawiło się w Scrum Guide. W nowej wersji pojawia się zwłaszcza w kontekście Sprint Review, gdzie to właśnie dostarczona wartość oraz plany dostarczenia jej jeszcze więcej powinny być głównymi tematami spotkania.

Scrum coraz bardziej wskazuje na transparencje. Nie tylko na przejrzystość tego jak pracuje zespół ale także na przejrzystość informacji na temat produktu i rynku. Dlatego też podczas Sprint Review wskazane jest omawianie także tego w jaki sposób stworzony właśnie Inkrement może zostać wykorzystany oraz tego jak wygląda budżet, najbliższe plany produktowe  i możliwości.

Kolejna wzmianka o wartości biznesowej pojawia się w kontekście Product Backlogu.  Twórcy Scrum sugerują to co ja opisywałem już miedzy innymi w „Mitach i problemach…” – elementy na Product Backlogu powinny oprócz estymatów mieć jeszcze określoną wartość biznesową. Dzięki temu transparentność zachodzi w obie strony.

Słowo Backlog Grooming zostało zamienione na Backlog Refinement z powodów o których nie warto wspominać :). Poza tym nic w tym kontekście zasadniczo się nie zmieniło.

W nowym Scrum Guide jeszcze bardziej podkreślona jest rola Scrum Mastera związana z zapewnianiem transparentności wszystkich artefaktów Scrum.

I to już w zasadzie chyba wszystkie istotne zmiany jakie udało mi się znaleźć w nowym Scrum Guide. Jeśli znaleźliście coś ciekawego o czym nie wspomniałem to w komentarzach jest dużo miejsca.

A i byłbym zapomniał – Scrum Guide ma teraz swoją własną, osobną stronę – www.scrumguides.org.


2 Comments for this entry

Skomentuj