Nie możesz skalować czegoś, czego nie masz. Dlatego, aby skalować Scruma twoja organizacja musi rozumieć dlaczego i w jaki sposób działają poszczególne jego elementy. Tylko wtedy będzie w stanie osiągnąć te same rezultaty korzystając z reguł definiujących ramy Scruma. LeSS (czyli Large Scale Scrum) bazuje na tych samych zasadach i wartościach co Scrum. Jego celem jest zastosowanie ich dla grup kilkudziesięciu, kilkuset, a nawet kilku tysięcy ludzi.
Dwa Szablony do Budowania Zwinnej Organizacji.
Zwinne tworzenie oprogramowania przy pomocy Scruma często wymaga zmiany organizacji. Dlatego nie należy traktować Scruma jako jedynie zbiór praktyk, ale bardziej jako sposób transformowania organizacji. Bas Vodde i Craig Larman stworzyli model wykorzystania Scruma dla dużych organizacji w oparciu o swoje doświadczenia m. in. z Ericson i JPMorgan. Model zawiera dwa szablony (frameworks):
- LeSS: dla kilku zespołów (do ok. 50 osób)
- LeSS Huge: dla większych organizacji
Jeżeli potraktujemy Scruma jako LeSS dla jednego zespołu to otrzymamy trzy szablony. Każdy z nich jest skupiony na dostarczaniu największej wartości dla klienta przez małe, autonomiczne, pracujące w jednym miejscu zespoły.
LeSS jest Scrumem
LeSS zachowuje wszystkie zasady Scruma i Agile:
- Jeżeli jest jeden produkt, to jest jeden Backlog Produktu (Product Backlog, PB)
- Jednym Rejestrem Produktu zarządza jeden Product Owner (PO)
- Przynajmniej na końcu każdego Sprintu musimy mieć jeden Przyrost Produktu Przygotowany do Dostarczenia (Potentially Shippable Product Increment)
- W tym celu potrzebujemy mieć jedną Definicję Ukończenia (Definition-of-Done, DoD) jedną Definicję Ukończenia
- Oraz jeden Sprint
- Elementy Backlogu Produktu (Product Backlog Item, PBI) są dostarczane przez wiele małych, interdyscyplinarnych i autonomicznych Zespołów
- Zespoły same ustalają swoje procesy, w tym sposoby współpracy i komunikacji. Nie ma pośredników mających na celu przekazywanie informacji. Decyzje są podejmowane przez Zespół, a nie przez osoby z zewnątrz.
Co jeszcze jest potrzebne?
- Planowanie Sprintu część 1 (Sprint Planning part 1): Ma na celu uzgodnienie “Co” chcemy dostarczyć w trakcie Sprintu. Bierze w nim udział Product Owner i reprezentanci wszystkich Zespołów. Członkowie zespołów ustalają między sobą, które Elementy Backlogu Produktu zostaną wykonane przez kolejne Zespoły. Szukają również obszarów współpracy, zwłaszcza dla powiązanych ze sobą elementów.
- Planowanie Sprintu część 2 (Sprint Planning part 2): Ma na celu uzgodnienie “Jak” chcemy dostarczyć w trakcie Sprintu. Każdy Zespół niezależnie (i najczęściej równocześnie) analizuje wybrane Elementy Backlogu Produktu. Czasami, dla łatwiejszej koordynacji i wymiany informacji, kilka zespołów może przeprowadzić to spotkanie w jednej sali (w różnych jej częściach).
- Codzienny Scrum (Daily Scrum): Są przeprowadzane niezależnie przez Zespoły, chociaż członkowie jednego zespołu mogą przyglądać się spotkaniu innego zespołu, żeby zwiększyć wymianę wiedzy.
- Koordynacja: Jest wykonywana głównie przez rozmowy (Just Talk) i na poziomie kodu (Communicate in Code). Częstymi praktykami są też Podróżnicy (Travelers), Technika Otwartej Przestrzenii (Open Space) i Społeczności (Communities).
- Wspólne Porządkowanie Backlogu Produktu (Overall PBR): przydatne może być opcjonalne i najczęściej krótkie spotkanie, na którym Product Owner i reprezentanci zespołów decydują, które zespoły prawdopodobnie dostarczą poszczególne Elementy Backlogu Produktu. Te elementy będą potem analizowane w trakcie Porządkowania Backlogu Produktu przez Zespoły. To spotkanie pomaga również uzgodnić cele i długoterminowe plany (Mapę Drogową).
- Porządkowanie Backlogu Produktu (Product Backlog Requirement): może być wykonywane na poziomie Zespołu, tak jak w Scrumie. Jednak częstym sposobem jest wielo-Zespołowe Porządkowanie Backlogu Produktu, gdzie dwa lub więcej zespołów w jednym pokoju analizuje Elementy Rejestru. Usprawnia to koordynację i pomaga w dzieleniu się wiedzą.
- Przegląd Sprintu (Sprint Review): Ponieważ dostarczany jest jeden produkt, to wszystkie zespoły i PO uczestniczą w jednym Przeglądzie Sprintu. Poza nimi na spotkaniu są obecni interesariusze, użytkownicy i klienci. W przypadku wielu zespołów rozważ “bazar”, gdzie każdy zespół ma swoje wyznaczone stanowisko, na którym pokazuje i omawia dokonane przez siebie zmiany.
- Wspólna Retrospektywa (Overall Retrospective): To nowe spotkanie, nie mające miejsca w Scrumie, gdzie reprezentanci zespołów, Scrum Masterzy i Product Owner nie skupiają się tylko na jednym zespole, ale analizują cały system. Przyglądają się problemom występującym w wielu zespołach, lub na ich styku.
