Kiedy myślimy o realizacji produktu w IT najczęściej do głowy przychodzą nam Scrum i Kanban jako ramy postępowania, które pomogą nam zorganizować pracę. Oba wspomniane rozwiązania świetnie się sprawdzają kiedy budujemy mały produkt. Wtedy kiedy mamy bezpośredni kontakt z klientem i pracujemy w niedużym zespole. Przykładowo, rekomendowana wielkość Scrum Teamu to 10 osób lub mniej. Oczywiście zespół może być większy, jeżeli jesteśmy w stanie efektywnie się komunikować i dostarczać Increment spełniający nasze Definition of Done i oczekiwania użytkowników. Jednak co zrobić kiedy mamy 20-30 osób w zespole? Czy wtedy Scrum się nam sprawdzi? Być może. Warto jednak pójść o krok dalej i zastanowić się nad rozwiązaniem, które będzie bardziej dostosowane do naszych potrzeb. Z pomocą przychodzą nam takie modele jak Nexus, SAFe, czy LeSS. Dziś skupimy się na tym ostatnim, czyli Large-Scale Scrum.
LeSS – krótka historia
Wszystko zaczęło się wspólnej podróży Bas Vodde’a i Craig Larman’a w Nokia Siemens Networks w 2005 roku. Podczas której panowie, znający doskonale zasady Scruma, stanęli przed wyzwaniem zaproponowania rozwiązania, które będzie działać nie tylko dla małego produktu, lecz dla dużego, złożonego systemu. Wykorzystując swoją wiedzę i doświadczenie stworzyli skalowalny model Scruma, który z sukcesem zaaplikowali zarówno dla dwóch zespołów jak i dla 2500 współpracujących wspólnie osób.
W 2014 Bas Vodde, Craig Larman, oraz Johan Schoenmaker oficjalnie otworzyli firmę. Jej celem jest promowanie LeSS, wsparcie treningowe i oferowanie certyfikatów potwierdzających wiedzę i zrozumienie frameworku.
LeSS – ogólne założenia
LeSS można wykorzystywać w pracy z dwunastoma osobami, setką ludzi, czy tysiącem. Nie ma tutaj ograniczeń, czy rekomendowanej ilości osób które mogą pracować nad produktem. Chciałoby się nawet powiedzieć “Sky is the limit”. Pojawia się jednak pojęcie magicznej ósemki, która teoretycznie wskazuje maksymalną ilość zespołów pracujących nad jednym produktem. W praktyce to graniczna liczba zespołów, przy której powinniśmy się zastanowić czy chcemy skalować Scrum zgodnie z zasadami Smaller LeSS czy LeSS Huge (powyżej ośmiu zespołów).
LeSS to nic innego jak zeskalowany Scrum. Mamy więc jednego Product Ownera, który jest odpowiedzialny za wizję produktu, priorytetyzację Product Backlogu skupionego na realizacji potrzeb użytkownika. Scrum Mastera, lub wielu, w zależności od ilości Scrum Teamów, oraz oczywiście Developerów. Wiele Scrum Teamów pracuje w Sprintach trwających od tygodnia do miesiąca, mając na uwadze, że pod koniec każdej iteracji powinni wypracować Increment potencjalnie gotowy do wydania. W LeSS mamy również:
- Jeden Product Backlog – bo jak wiadomo, PB jest definiowany dla jednego produktu, a nie dla zespołu;
- Wspólną Definicję Ukończenia (DoD);
- Jeden wspólny Sprint;
- Jeden wspólny Increment.
Przebieg wydarzeń w LeSS
W LeSS wydarzeniem rozpoczynającym Sprint jest Sprint Planning, podzielony na dwie części. Pierwsza część, czyli Sprint Planning 1, to okazja dla Product Ownera do rozpowszechnienia swojej wizji na kolejną iterację. W tej sesji biorą udział tylko wybrani członkowie poszczególnych Scrum Teamów. Wybierają oni spośród dostępnych PBIs zadania do realizacji w najbliższej iteracji. Zespoły samoorganizują się w tej kwestii. Rozmawiają o tym jak najlepiej podzielić się pracą, zwłaszcza jeżeli istnieją zależności pomiędzy Product Backlog Itemami, które będą realizowana przez różne zespoły. Następnie odbywa się Sprint Planning 2. To na nim poszczególne Scrum Teamy planują pracę na iterację zgodnie z zasadami opisanymi w Scrum Guide rozpoczyna się Sprint.
Podczas całego Sprintu Scrum Teamy ściśle współpracują ze sobą. Każdy z nich ma indywidualne Daily Scrum, jednakże koordynatorzy z innych zespołów uczestniczą jako obserwatorzy w pozostałych wydarzeniach aby zwiększyć transparentność informacji. Oczywiście jeden koordynator nie uczestniczy, przykładowo, w dwunastu Daily Scrumach! Zespoły, które się wzajemnie odwiedzają to te, pomiędzy których pracą występuje najwięcej korelacji.
W połowie trwania Sprintu zespoły skupiają się na pielęgnacji Product Backlogu. Refinementy, służą do pogłębiana wiedzy na temat PBIs i wstępnego podziału zadań pomiędzy Scrum Teamami, w ramach których członkowie pogłębiają później rozpoczętą dyskusję. Zazwyczaj dwa lub więcej Scrum Teamów pochyla się wspólnie nad zadaniami w ramach mniejszych Refinementów. Dzieje się tak zwłaszcza wtedy kiedy istnieją ścisłe zależności pomiędzy zadaniami.
Sprint Review i Retrospective
Koniec Sprintu to Sprint Review. Podczas tego wydarzenia Product Owner, pozostali członkowie Scrum Teamów oraz interesariusze spotykają się by pochylić się nad wypracowanym Incrementem. Dokonują inspekcji i adaptacji uzyskanych rezultatów. Drugi element celu Sprint Review jest szczególnie podkreślony przez Craiga i Basa. Wspominają, że celem tego wydarzenia nie jest dokonanie inspekcji i akceptacji, a właśnie adaptacji.
“Inspect-Adapt and not Inspect-Accept”
Sprint Review definition, LeSS
Chcą tym samym uniknąć pokusy statusowego charakteru tego spotkania. I tak zwanego “potakiwania” głową na wszystko co zostało zrobione. Wszyscy obecni mają ze sobą współpracować, omawiając wypracowane rezultaty i proponując ulepszenia.
W LeSS nie brakuje też miejsca na dokonanie inspekcji i adaptacji całości prac. We frameworku mamy Sprint Retrospective, które ponownie jest podzielone na dwie części. W pierwszej kolejności Scrum Teamy spotykają się na swoim regularnym retrospective. A następnie podczas Overall Retrospective wszyscy wspólnie pochylają się m.in. nad dotychczasowym procesem, rezultatami i usprawniają je tak aby osiągać coraz to lepsze efekty.
Podsumowanie
Jak widzicie LeSS nie różni się bardzo od Scrum. Jest to zeskalowana i rozszerzone wersja bardzo modnego sposobu wytwarzania oprogramowania, która daje możliwość współpracy wielu mniejszych zespołów nad jednym produktem. W zależności od tego nad jak złożonym produktem pracujemy adaptacja LeSS może potrwać nawet kilka lat. Oczywiście kwestią wyboru jest wersja LeSS. Sugerowana ilość Scrum Teamów przy, której należy przejść z podstawowej (opisanej wyżej) formy do rozszerzonej (Huge LeSS) to osiem. Informację opisane wyżej to zaledwie pigułka wiedzy o LeSS, zainteresowanych pogłębieniem wiedzy odsyłam na oficjalną stronę Craiga i Basa.
Zainteresowanych tematem skalowania Scruma odsyłam również do naszego poprzedniego wpisu o Nexusie.
Sprawdź nasze poprzednie wpisy:
