Choć na początku służył do tworzenia produktów informatycznych, ale dzięki swojej prostocie i skuteczności zdobywa coraz większą popularność. W przeciągu ponad dwóch dekad Scrum udowodnił, że świetnie nadaje się do pracy również poza IT, w tym sprzedaży, wsparciu klienta, produkcji sprzętu, czy edukacji. Jeżeli chcesz poznać konkretne przykłady to przeczytaj Case Study inFaktu, Codewise i Siemensa.
Scrum to Zwinne (Agile) podejście do tworzenia nowych produktów i usług. Produktem jest często oprogramowanie, ale może to być dowolna rzecz, która ma dla kogoś wartość. Na przykład kampania marketingowa, konferencja, podcast albo samochód. Scrum opiera się na dostarczaniu produktu w małych przyrostach. Dzięki temu, co kilka tygodni możemy go udostępnić naszym użytkownikom i dostać informację zwrotną (o zarabianiu już nawet nie wspomnę). Ten feedback pozwala nam na dostosowanie planów do rzeczywistości i reagowanie na zmiany na rynku i wykorzystanie nadarzających się okazji. Co więcej, takie podejście powoduje, że w dowolnym momencie dużo dokładniej wiemy gdzie jesteśmy niż w przypadku tradycyjnych technik zarządzania pracą.
Odpowiedzialności (role) w Scrumie
Scrum bazuje na pracy Zespołu, który ma wszystkie niezbędne umiejętności i zasoby, żeby ten produkt dostarczyć. A jak nie ma, to chcemy, żeby je zdobył. Czyli najczęściej członkowie Zespołu będą mieli różne, uzupełniające się kompetencje – na przykład analizy, projektowania, programowania i testowania. Członków tego Zespołu nazywamy Deweloperami (Developers), co może mylnie się kojarzyć z programistami, ale ma na celu podkreślić ich odpowiedzialność za dewelopowanie, czyli rozwój tego produktu. Pewnie nazwa „twórcy” albo „kreatorzy” byłaby mniej myląca (zobacz jak z grupy ludzi stworzyć zespół).
Oprócz Zespołu mamy również w Scrumie Właściciela Produktu (czyli Product Ownera, PO), który ma wizję swojego produktu i dzięki temu może decydować o tym, co jest w danym momencie najważniejsze (zobacz co robi Product Owner).
Ostatnią odpowiedzialnością jest Scrum Master (SM), który skupia się na tym jak działamy. Dzięki temu może się dzielić swoimi obserwacjami z pozostałymi i pomóc im zwiększyć efektywność współpracy (zobacz co robi Scrum Master).
Proces Scrum
Zespół dostarcza kolejne wersje (Przyrosty, albo Inkrementy) działającego produktu w krótkich cyklach zwanych Sprintami. Każdy ze Sprintów jest ograniczony czasowo i trwa maksymalnie miesiąc (zwykle od tygodnia do czterech, najpopularniejsze są Sprinty dwutygodniowe). Gwarantuje to Product Ownerowi, że wie ile pracy inwestuje i jeżeli coś złego się wydarzy, to nie straci więcej niż długość Sprintu. Tym samym nie ma ryzyka, że przez pół roku nie będzie miał pojęcia, co się dzieje z jego produktem i kiedy wreszcie zakończą się nad nim prace. Co więcej, Zespół wraz z PO ustala jednoznacznie, co to znaczy, że przyrost działa (Definicja Ukończenia, Definition of Done, DoD), żeby uniknąć niespodzianek tak często spotykanych szczególnie w tworzeniu oprogramowania (“No co? U mnie działa!”).
Product Owner umieszcza listę pomysłów i potrzeb użytkowników, klientów i interesariuszy w Backlogu Produktu (Product Backlog) w kolejności od najważniejszej do najmniej ważnej. Cel Produktu (Product Goal) pozwala się skupić na jednej najważniejszej rzeczy i uniknąć sytuacji, gdy wszystko wydaje się być ważne, przez co nic istotnego nie udaje się osiągnąć przez kilka miesięcy. PO chce na koniec każdego Sprintu zaprezentować nową wersję produktu swoim interesariuszom, klientom i użytkownikom, tak aby dostać od nich informację zwrotną. Dlatego na początku Sprintu Zespół ustala na czym się skupi, oraz co i w jaki sposób jest w stanie dostarczyć z Backlogu Produktu. To spotkanie nazywamy Planowaniem Sprintu (Sprint Planning) i nawet przy miesięcznych Sprintach nie powinno trwać dłużej niż jeden dzień. Sam plan natomiast nazywamy Backlogiem Sprintu (Sprint Backlog), żeby go odróżnić od Backlogu Produktu. Sprint również posiada swój cel (nazywany oczywiście Celem Sprintu, czyli Sprint Goal) pozwalający się skupić całemu Zespołowi na tym, co PO chce osiągnąć w danym cyklu. Ponieważ to Zespół stworzył plan, tak więc Zespół wie jak go zrealizować. Dlatego jego członkowie synchronizują się codziennie, żeby zobaczyć czy Cel Sprintu jest wciąż realny i jak poszczególni Developerzy mogą sobie nawzajem pomóc. To krótkie spotkanie nazywamy Codziennym Scrumem (Daily Scrum) i nie powinno przekraczać 15 minut. W trakcie Sprintu Zespół chce również przygotować się do następnych Sprintów poprzez przeglądnięcie, omówienie i uporządkowanie Backlogu Produktu. Na to porządkowanie Backlogu Produktu (Product Backlog refinement) Zespół najczęściej poświęca 5-10% całego czasu ze Sprintu.
Gdy upłynie czas zarezerwowany na Sprint to pora na informację zwrotną. Najpierw Zespół wraz z PO na Przeglądzie Sprintu (Sprint Review) pokaże co stworzył w trakcie Sprintu, żeby dowiedzieć się co o tym myślą interesariusze i użytkownicy. Na podstawie tej informacji zwrotnej PO zdecyduje o dalszym kierunku rozwoju produktu, aktualizując Backlog Produktu. Następnie w swoim gronie w trakcie Retrospektywy Sprintu (Sprint Retrospective) Developerzy z PO i Scrum Masterem ustalają w jaki sposób mogą pracować skuteczniej.
Jeżeli chcesz dokładniej poznać jak działa Scrum to przeczytaj o rolach, wydarzeniach, artefaktach i regułach Scruma.
Scrum Framework
Ken Schwaber i Jeff Sutherland, współtwórcy Scruma, określają go mianem „Ramy” (Framework). Tym samym Scrum nie jest rozbudowaną metodyką, a raczej zbiorem prostych reguł pozwalających na szybkie otrzymanie informacji zwrotnej co się dzieje z produktem i jak działa nasz proces. Jak jednak dodaje Ken „Scrum jest prosty, ale trudny”. Chociaż te reguły wydają się łatwe, stosowanie Scruma natychmiast uwidacznia problemy i dysfunkcje. Tym samym Scrum nie pozwala na chowanie głowy w piasek, spychotechnikę i zrzucanie winy na innych. Zamiast tego promuje otwartość, odwagę, szacunek i współpracę. Dlatego, zanim zaczniecie go stosować, warto zrozumieć konsekwencje wprowadzenia Scruma.
Filary Scruma
Scrum opiera się na trzech filarach Empiryzmu. Pierwszy to Przejrzystość (Transparency), która pozwala wszystkim zobaczyć co tak naprawdę się dzieje. Jeżeli Zespół mówi, że ukończył pracę nad funkcjonalnością, to znaczy, że naprawdę ukończył, ona działa i klient może z niej korzystać. Jeżeli pojawiają się opóźnienia w stosunku do ambitnych planów Product Ownera, to są one natychmiast widoczne. Jeżeli w organizacji jest jakaś dysfunkcja (np. członkowie różnych działów ze sobą nie współpracują), to również jest to wyciągane na powierzchnię. Przejrzystość umożliwia Inspekcję (Inspect), czyli przeanalizowanie co się dzieje w zespole, produkcie czy organizacji. Tym samym Scrum pozwala szybko zauważyć problemy (np. wolny czas odpowiedzi systemu) ale również okazje (np. nowa funkcjonalność otwierająca przed nami nowy rynek). Te mogą zostać zaadresowanie przez Adaptację (Adapt), czyli zmianę planów i dostosowanie procesu czy produktu do rzeczywistości. Może to być na przykład zmiana zakresu, technologii, czy sposobu działania zespołu.
Mój kolega, Peter Stevens mówi:
najskuteczniejszą metodą, żeby Scrum nie zadziałał jest unikanie przejrzystości (brak transparencji), informacji zwrotnej (brak inspekcji) i podejmowania decyzji na podstawie tych informacji (brak adaptacji).
Praktyka czyni mistrza
Udawanie, że grasz w szachy kiedy tak naprawdę nie grasz w szachy nikomu nie pomaga i tylko irytuje graczy
