Małe zespoły Scrum, czyli porozmawiajmy o Small Scale Scrum

W dzisiejszym poście zajmiemy się małymi zespołami i jednym podejściem które mnie zainteresowało a chodzi tutaj o Small Scale Scrum. Z własnego doświadczenia wiem, że wiele organizacji zadaje sobie pytanie jakie podejście Agile wybrać dla zespołu, którego liczebność nie jest spójna ze Scrum Guide. Wiele osób od razu powie, że w takiej sytuacji można wykorzystać Kanbana, Scrum with Kanban, lub wielu innych rozwiązań. Jednym z nich jest właśnie Small Scale Scrum. Postaram się opisać to podejście, natomiast wnioski, czy można je wykorzystać czy nie pozostawię Wam. 

Small Scale Scrum – co to jest? 

W wielu źródłach pojawia się jedno powtarzalne określenie na Small Scale Scrum – jest to „Struktura oparta na ludziach, zdefiniowana przez małe zespoły (maksymalnie trzy osoby) i dla nich przeznaczona, wspierająca planowanie, opracowywanie i dostarczanie rozwiązań oprogramowania o wysokiej jakości”. 

Podejście Small Scale Scrum wpisuje się również w manifest Agile i autorzy tego frameworka również ułożyli swoje założenia: 

  1. Wide communication over narrow communication – szeroka komunikacja jest tutaj bardzo ważna, aby zaangażować w projekt (tak projekt, nie produkt) osoby, które mają na niego wpływ. Taka komunikacja obejmuje również w tym wypadku właściciela produktu, Scrum Mastera i Developerów. 
  2. Team feature delivery over individual responsibility – w tym podejściu praca zespołowa odgrywa ważną rolę, a członkowie zespołu pracują razem jako pojedynczy jednostki, aby zapewnić sukces projektu od podstaw. Można to osiągnąć dzięki, sprawiedliwemu obciążenie pracą, pair programming oraz przeglądowi kodu (code review). 
  3. Quality delivery over speed of development – szybki rozwój i wysoka jakość dostaw produktu to oczekiwania przy każdym projekcie/produkcie. Chociaż szybkość rozwoju jest ważna, jakość dostarczania ma znacznie większy wpływ na ciągły sukces projektu.
  4. Multiple project responsibilities over fixed assignment – w standardowym podejściu Agile mamy zespół, który posiada różne kompetencje BE, FE, UI, UX, Tester. W podejściu Small Scale Scrum prawdziwa wartość dla małych zespołów wynika z przejmowania danych ról przez członków zespołów (w granicach rozsądku). Pomysł za tym podejściem polega na zapewnieniu, że mały zespół jest jak najbardziej samowystarczalny. Aby małe zespoły mogły przyjąć wiele obowiązków, obciążenie pracą musi być sprawiedliwe. Można to osiągnąć poprzez ciągłe przeglądanie i doskonalenie warunków pracy oraz uproszczenie procesów, aby pomóc zespołowi skupić się na dostarczaniu.
  5. Accelerating innovation over marginal request-driven thinking – w takich przedsięwzięciach klient jest jedynym interesariuszem, a jego pogląd i głos są przestrzegane co do joty. Innowacja ma kluczowe znaczenie dla skłonienia zespołu i klientów do myślenia poza zdefiniowanymi wymaganiami projektu, aby mogli wyobrazić sobie ostateczne rozwiązanie
  6. Customer growth over customer engagement – jedną z ważniejszych zasad współpracy pomiędzy Developerami a klientem jest nastawienie na współpracę w celu zapewnienia sukcesu biznesowego klienta. Rozwój oraz tworzenie biznesu są najważniejsze dla klienta dlatego też tak samo ważna powinna być dla developerów. 

Small Scale Scrum – zasady (pryncypia)

Jak każdy framework tak i ten posiada posiada swoje zasady/pryncypia. W tym przypadku znajdujemy cztery: 

  1. Value-based Communication – zawiera wewnętrzną i zewnętrzną komunikację, ale o taką komunikację, która ma przynieść wartość zarówno dla osób budujących rozwiązanie, jaki i naszych klientów. Zrozumienie rozwiązania, jego celu i pożądanej funkcjonalności zależy od skutecznej komunikacji. Inicjowanie i utrzymywanie komunikacji między stronami wymaga otwartości i poświęcenia w poszukiwaniu najlepszego rozwiązania dla danej funkcjonalności lub poprawki budowanego produktu/projektu.
  2. Quality-first Development – ta zasada skupia się na jakościowym podejściu do tworzenia oprogramowania podczas każdego Sprintu. Oznacza to zapewnienie, że funkcje są dostarczane zgodnie z kryteriami akceptacji, rozwiązanie jest wolne od błędów (lub przynajmniej wolne od wszelkich ewidentnych błędów), wszelkie niespójności w oprogramowaniu są usuwane, rozwiązanie zostało przetestowane, a wszelkie skrajne błędy i pomijane funkcje są zgłaszane, rejestrowane i rozważane przez klienta. 
  3. Delivery Ownership – dotyczy zespołu programistów przejmującego inicjatywę w zakresie dostarczania oprogramowania na zasadzie Sprint-to-Sprint. Umożliwienie zespołowi bezpośredniej konsultacji z klientem pozytywnie wpływa na ogólną wydajność zespołu i satysfakcję samego klienta. Eliminacja wszelkich barier związanych z mikrozarządzaniem ma kluczowe znaczenie dla umożliwienia zespołowi przejęcia odpowiedzialności za dostarczanie rozwiązań programowych.
  4. Iterative Sign Off – koncentruje się na zmniejszaniu długu technicznego i identyfikowaniu luk w wymaganiach poprzez iteracyjne podejście do akceptacji funkcjonalności. W przypadku rozwoju iteracyjnego, części produktu/projektu dostarczane w ramach Sprintu powinny zostać zaakceptowana po jego zakończeniu. Podobnie wymagania dotyczące nadchodzącego Sprintu powinny zostać zaakceptowane przed jego rozpoczęciem.
Small Scale Scrum Framework, Leigh Griffin & Agnieszka Gancarczyk

Small Scale Scrum – Framework

Small Scale Scrum opiera się na założeniach Scrum, jednak z pewnymi wyjątkami. Poniżej opiszę Wam różnice:

  1. Project Backlog zamiast Product Backlog – mimo, iż nazwy są różne, to sens jest ten sam. Project Backlog jest to lista wszystkich funkcjonalności wymaganych w projekcie. Jest on tworzony również przed rozpoczęcie pierwszego Sprintu, ale utrzymywany przez Developerów. Project Backlog zawiera zadania programistyczne oraz wymagania dotyczące projektu/produktu. 
  2. Sprint Planning – posiada wcześniej ustalone ramy czasowe oraz koncentruje się na przyszłej pracy. Nie ma tutaj facylitatora w postaci Scrum Master, natomiast sami Developerzy dbają o to, aby spotkanie przebiegało w możliwie jak najbardziej efektywny sposób. Pojemność zespołu (Capacity), zwykle mierzona jako prędkość (velocity), w tym podejściu jest pomijana. Prędkość (Velocity), którą można wykorzystać pojawia się nie wcześniej niż po trzech Sprintach, co zwykle następuje po zakończeniu projektu w Small Scale Scrum. 
  3. Proof of Concept / Demo – to realizacja pracy wykonanej w Sprincie, aby pokazać postęp prac. Wszelkie odchylenia lub niekompletna praca są omawiane podczas POC / demo.
  4. Sprint review – spotkanie organizowane i prowadzone jest przez Developerów oraz Project Managera (pod warunkiem, że jest zaangażowany w projekt) i klienta. Tak jak w przypadku Scrum omawiany jest Sprint odnośnie zakresu prac, pracy ukończonej oraz nieukończonej, problemów które Developerzy napotkali na swej drodze. 
  5. Sprint Retrospective – spotkanie organizowane i prowadzone jest przez Developerów oraz Project Managera (pod warunkiem że jest zaangażowany w projekt). I tutaj mamy ciekawostkę. W retrospektywie może uczestniczyć klient. Dodatkowo, biorąc pod uwagę wielkość zespołu do 3 osób spotkanie jest dość krótkie. 
  6. Sprint Review, Sprint Retrospective i Sprint Planning mogą zostać połączone w jedno spotkanie. Czas takiego spotkania to maksymalnie 90 min. 
  7. Wielkość zespołu – nie więcej niż 3 osoby. Skomponowany jest z Developerów oraz Project Managera.
  8. First/Final Release – jest to rezultat projektu. Developerzy przeprowadzają testy, sprawdzają rozwiązanie. następnie klient akceptuje rozwiązanie i jest ono dodawane do systemu produkcyjnego. 
Small Scale Scrum Framework, Leigh Griffin & Agnieszka Gancarczyk

Podsumowanie

Tutaj trochę Was zaskoczę – tak, jak w większości swoich artykułów w podsumowaniu dodawałem swoje zdanie, tak tutaj chcę zostawić Wam miejsce na przemyślenia tego podejścia. Jeżeli jesteście ciekawi tego podejścia to pełny opis możecie znaleźć tutaj