Na przestrzeni lat pracy jako lider i Scrum Master, słyszałem wiele na temat Scruma. Jak nie działa, jak wszystko komplikuje, czy jak przeszkadza. Jaki jest skomplikowany. I jak bardzo powinno się go pogrzebać kilka kilometrów pod ziemią, a wszelkie materiały o nim spalić lub przerobić na wszelkiego rodzaju dobra z materiałów odnawialnych. Wiele, wiele osób nienawidzi Scruma. Natomiast spora część tych osób - mówię z doświadczenia i bliskiej znajomości części z nich - nigdy w Scrumie nie pracowała, choć (niestety) ktoś im powiedział, że pracowali.

Podczas swojej prelekcji o Scrumie, na konferencji Agile by Example, Jurgen De Smet użył takiego stwierdzenia: “Największym wrogiem Scruma nie jest Waterfall, ale Zły Scrum”. Ron Jeffries, jeden z autorów Agile Manifesto, napisał post na swoim blogu o zjawisku Dark Scrum. Abominacji, która żyje w świecie IT, zrodzona z złych implementacji, używania i sprzedawania frameworka panów Sutherlanda i Schwabera - dwóch kolejnych “ojców” manifestu.

Z ręką na sercu przyznam się, że i swoją cegiełkę do tego przyłożyłem: na początku swojej kariery również skrzywdziłem pewnie kilku programistów, fatalnym zrozumieniem narzędzia i jego złą implementacją. Stąd pomysł na serię postów rozwiewających najczęściej spotykane przeze mnie nieprawd na temat Scruma. 

Każdy post rozpocznę od kilku stwierdzeń, które chciałbym, abyś czytelniku wpierw określił jako prawda lub fałsz, a dopiero później usiadł do reszty lektury - w celu sprawdzenia, jak dobrze znasz Scruma. Mam ich blisko dwadzieścia, a może i dzięki waszym komentarzom będzie ich więcej, więc zaczynamy.

  • Estymacja równa się zobowiązaniu wobec zadania - 👍 / 👎
  • Określenie celu sprintu nie jest obowiązkowe, liczy się zamknięcie wszystkiego, co w jest w sprint backlogu - 👍 / 👎
  • Nie można modyfikować sprint backlogu, jeśli już ruszymy z developmentem - 👍 / 👎
  • Scrum Team może zakończyć planowanie bez przypisanie każdemu zadaniu członka Dev Teamu i rozłożeniu zadań na podzadania - 👍 / 👎

Estymacja równa się zobowiązaniu wobec zadania

FAŁSZ! Wszyscy znamy klasyka wśród IT-memów, w którym to czarne charaktery z filmu Austin Powers złowieszczo się śmieją, a napisy mówią o traktowaniu estymacji zespołu, jako deadline’y, co równie dobrze można określić jako commitment (czyt. zobowiązanie).

Źródło: http://www.quickmeme.com/img/7a/7ac6c18b1bca53b88bbd8cd25a68a327396adce14cb999a7d7130cf76b07a4c6.jpg

Oczywiście, każda osoba z głową na karku, niezależnie, czy należy do zespołu developerskiego czy kierującego projektem, powinna wiedzieć, że szacunki to tylko szacunki. A ponieważ jako ludzie jesteśmy fatalni w przepowiadaniu przyszłości, nie powinniśmy polegać na naszych przepowiedniach.

Do czego możemy doprowadzić, jeśli potraktujemy estymację jak zobowiązanie? Lista potencjalnych problemów, jakie mogą wynikać z takowego działania jest spora i dotyka zarówno Product Ownera, jak i Dev Team. Dla tego pierwszego bardzo szybko pojawi się pokusa, aby zbudować sobie przepowiadające przyszłość Excele, które doprowadzą do stworzenia roadmap i milestone’ów….na rok do przodu. Oczywiście tego rodzaju plany z góry są skazane na porażkę. Za to Dev Team, widząc, że ich szacunki przeobrażają się w zobowiązania, zacznie być przesadnie-ostrożny w ich konstruowaniu, gubiąc istotę konwersacji i wspólnym zrozumieniu pracy do wykonania, które leżą u fundamentu szacowania.

Natomiast, estymować trzeba - nie będę wchodził w dyskusję na temat #noestimates, ale wiem, że istnieje i niespecjalnie ten ruch kupuje. Scrum guide wyraźnie mówi:

“Product Backlog items have the attributes of a description, order, ESTIMATE, and value”.

Aczkolwiek nigdzie w Scrum Guide nie jest napisane, że estymacja zespołu jest jego zobowiązanie. Zobowiązanie, będąc jedną z wartości Scruma, użyta w instrukcji frameworka jest następująco: “People personally commit to achieving the goals of the Scrum Team”. Pod commitment zatem podpinamy osiągnięcie celu sprintu oraz działający inkrement na jego koniec - nie mniej, nie więcej.
A zatem, jeśli w waszych zespołach Scrumowych estymacje traktowane są przez PO czy menedżera, jako zobowiązanie, to pamiętajcie, że żaden z niego Product Owner, a z waszego procesu żaden Scrum. Słowa estimate i commitment, choć znajdują się w SG, nigdy nie występują obok siebie. I pamiętacie jeszcze o jednym: szacowanie zadań to robota i własność Dev Teamu. nikogo innego.

Określenie celu sprintu nie jest obowiązkowe, liczy się zamknięcie wszystkiego, co w jest w sprint backlogu

FAŁSZ! Jednym z najczęstszych zakończeń planowania sprintu, w jakich dane mi było uczestniczyć, było: określenie celu sprintu. Zespół i dumny Product Owner, wspólnie spoglądają w stronę sprint backlogu i uruchamiają moc kreatywności: jak ze skrzętnie wybranych user story, kilku bugów (dla statystyk jakości) oraz jednego refactor’u (zespół bardzo prosił) ulepić sensowny, jednozdaniowy cel sprintu? Na domiar złego pracują na JIRZE, która ma limit znaków w polu przeznaczonym dla celu, więc poziom trudności jest wysoki. A przecież Sprint Goal to nie koniec planowania, a jego początek.

Scrum Guide opisuje Cel sprintu jako coś, co zespół scrumowy wypracowuje w trakcie planowania (“During Sprint Planning the Scrum Team also crafts a Sprint Goal.”) i (prawdopodobnie) przez to większośc podejść do jego określenia wygląda podobnie do przedstawionego, akapit wyżej, przykładu. Gdy staram się w zespole zaszczepić odpowiednie jego postrzeganie, robię to poprzez odwoływanie się do niego jako wypadkową inputu, z którym na planowanie przychodzi Product Owner oraz wybranych przez zespół zadań z Product Backlogu. Jedno nadaje kierunek drugiemu i WSPÓLNIE tworzą cel. Uzupełniając się wzajemnie.

Dlaczego jest to zatem istotny?

W regułach gry Scruma, zwrot Sprint Goal występuje dwadzieścia siedem razy, co szesnasto-stronicowy dokument, jest pokaźnym wynikiem. Jest tak, ponieważ cel sprintu wykorzystywany jest przez wszystkie człony Zespołu Scrumowego, na większości spotkań, a także (od ostatniej aktualizacji) stał się fundamentem szablonu proponowanych pytań na daily: What did I do yesterday that helped the Development Team meet the… / What will I do today to help the Development Team meet the… / Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal? Cel sprintu pozwala zespołowi podejmować decyzje w trakcie sprintu. Jeśli np. coś nie idzie po myśli zespołu lub (wręcz przeciwnie) idzie tak dobrze, decyzje o wrzuceniu czegoś z zakresu sprintu lub dodaniu do niego z Product Backlogu, są ŁATWIEJSZE i efektywniejsze, z jasno określonym celem tego, co w tych dwóch tygodniach chcemy osiągnąć dla produktu.

Natomiast jeśli cel Sprintu jest tylko i wyłącznie uzasadnieniem doboru zadań z backlogu podczas planowania to każdy z następujących po nim elementów Scruma staje się trudniejszy. Zespół uznaje, że jedno z zadań w sprint backlogu nie zostało odpowiednio przemyślane i zaczyna angażować Product Ownera w dyskusje o jego podmianie lub zmianie, ponieważ nie ma wystarczających informacji (kierunku dla decyzji), aby samodzielnie poradzić sobie w sytuacji. Na standupach wracamy do rozmów o ukończeniu (swoich) tasków. Na review, które jest miszmaszem funkcjonalności trudno ocenić, czy zakończony sprint pomógł produktowi podążać w obranym przez organizację kierunku - trudno się dziwić, skoro to kierunek nadają taski, a nie na odwrót.

Nie można modyfikować sprint backlogu, jeśli już ruszymy z developmentem

FAŁSZ! Mit ten spowodował tyle problemów, że odpowiedzialni za Scrum Guide, musieli wprowadzić jego aktualizację, która zamieniała nadużycie słowa commitment (zobowiązanie), na forecast (prognozę). Wszystko, aby uwypuklić, że wybrane przez zespół zakres pracy w sprincie, jest prognozą zespołu na dostarczenie celu sprintu, a nie zobowiązaniem - gdzie wraca, niczym bumerang, istota posiadania celu sprintu z prawdziwego zdarzenia. Oznacza to, że zespół deweloperski może lawirować zadaniami, jakie będzie wykonywał w ramach sprintu, jednak nienaruszalnym elementem jest Sprint Goal i wszystkie działania muszą być z nim zgodne. Przykładowo: przedwczesne zakończenie sprintu może się zadziać, tylko i wyłącznie wtedy, jeśli PO zadecyduje, że cel sprintu nie jest wart kontynuowania, a nie dlatego, że coś jest nie tak ze sprint backlogiem.

Jednym z objawów traktowania tego mitu jako prawdę objawioną jest naruszenie poprawnie wyglądającego stosunku kosztów, czasu i zakresu, co bezpośrednio odbija się na JAKOŚCI. Z racji występowania konieczności zmiany, w wyniku nieoczekiwanych okoliczności czy zmian wymagań, zespół zmuszony jest ciąć na jakości dostarczanego kodu, czy to omijając testy, czy olewając dobre praktyki. Inne następstwa to nieodpowiedzialne wydłużanie sprintów czy (popularne) dzielenie zadań na części, zamykanie niegotowych tasków i dokańczanie ich w kolejnych sprintach, co powoduje szereg kolejnych problemów.
Scrum, jako framework empiryczny polega na nieustannym procesie inspekcji i adaptacji, a więc podejmowaniu decyzji na bazie obserwacji, faktów i danych. U swoich fundamentów, opartych na Manifeście Agile, zakłada, że nie jesteśmy w stanie stworzyć idealnych planów, więc musimy jak najczęściej (min. raz dziennie) planować wspólnie dalsze kroki w produkcji. A zatem “wyrycie Sprintu Backlogu w kamieniu” po planowaniu, mija się z istotą i założeniami Scruma.

Scrum Team może zakończyć planowanie bez przypisanie każdemu zadaniu członka Dev Teamu i rozłożeniu zadań na podzadania

PRAWDA! PIerwsza ‘prawda’ tego wpisu, więc zostawiłem sobie ją na koniec. Otóż kolejnymi, zaobserwowanymi klasykami planowania sprintu są: dopychanie go pod korek oraz skrupulatne rozkładania np. historyjek na sub-taski. Najlepiej od razu wybierając, kto i czym będzie się zajmował, przypisując momentalnie odpowiedzialność na User Story konkretnej osobie - a JIRA znów nam w tym pomaga pozwalając wybrać tylko jedną osobę przypisaną do zadania, ku chwale uwielbianego przez biznes: ownershipu.

Tymczasem, po spojrzeniu w Scrum Guide i opis planowania sprintu, znajdziemy:

“…enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint.”

Prawda jest taka, że jeśli zawsze wypełniamy sprint zespołu pod korek albo (co jest jeszcze większą patologią) planujemy zadania ponad dostarczalność (dla motywacji - serio takie coś widziałem), to z czasem produktywność teamu spadnie. Osiągnięcie celu sprintu, zostanie zastąpione zakończeniem swoich zadań. Zespół zejdzie do poziomu jednostek. Nie będzie miejsca na szukanie alternatywnych rozwiązań w razie problemów, bo nie będzie czasu np. na pair programming.

Zatem, jak powinno wyglądać planowanie w Scrumie? Guide rozdziela je na dwie części: kompozycja Sprint Backlogu i zaplanowanie pierwszych kroków. O pierwszej części napisałem już nieco wcześniej, albowiem ta część mocno związana jest z celem sprintu i zbudowaniem, przez PO oraz Dev Team, realnej prognozy na dostarczony inkrement. Z drugą związany jest nasz mit, albowiem to w tej części zespół gra pierwsze skrzypce planowania i powinien skupić się na rozłożeniu części zadań, wystarczająco dużo, aby rozpocząć sprint. Nie więcej.

“Work planned for the first days of the Sprint by the Development Team is decomposed“ - tak przedstawia to Scrum Guide.

Resztę zespół może rozłożyć w trakcie sprintu, będąc mądrzejszym i wnioski z zakończonych zadań, co minimalizuje ryzyko strat (w rozumieniu kanbanowym) w sprincie.

I to by było na tyle z pierwszej części serii o mitach i legendach, krążących w świecie IT o Scrumie. Do zobaczenia następnym razem! A, i pamiętajcie:

“Scrum is simple, just use it as is!!” - Ken Schwaber