Scrum jest frameworkiem, który pomaga zespołom efektywnie tworzyć i rozwijać skomplikowane produkty. Po raz pierwszy został przedstawiony w 1995 roku i jest opisany w dokumencie "Przewodnik Scrum" ("The Scrum Guide"). Twórcy Scrum, Ken Schwaber i Jeff Sutherland to autorzy przewodnika.
Zgodnie z definicją "The Scrum Guide", Scrum jest ramą, która pomaga ludziom, zespołom i organizacjom generować wartość poprzez adaptacyjne rozwiązania dla złożonych problemów. Jest to najczęściej używany i najpopularniejszy framework wspierający podejście Agile.
Czym jest Agile? Czy poprawny termin to "metodyka Scrum"?
Termin "Agile", czyli "Zwinny", reprezentuje filozofię i ogólne podejście - zestaw zasad i wartości skoncentrowanych na zarządzaniu złożonymi projektami czy produktami. Podstawą Agile jest akceptacja eksperymentowania, stała wymiana informacji zwrotnych, ciągła nauka oraz ulepszanie procesu w trakcie postępów pracy.
Wartości Agile zostały przedstawione w "Manifeście Agile" ("Agile Manifesto"), opracowanym przez grupę doświadczonych programistów w 2001 roku. Są to przede wszystkim następujące zasady:
The "Agile Manifesto" also describes twelve principles that help teams work more flexibly by being able to adapt to changing requirements and quickly respond to feedback. Thanks to this approach, projects can be implemented more efficiently and productively, benefiting both customers and companies creating software.
"Manifest Agile" opisuje również dwanaście zasad, które pomagają zespołom pracować bardziej elastycznie dzięki umiejętności dostosowania do zmieniających się wymagań i szybkiej reakcji na feedback. Dzięki temu podejściu, projekty mogą być realizowane w sposób bardziej efektywny i produktywny, co przynosi korzyści zarówno klientom, jak i firmom tworzącym oprogramowanie.
Założeniem przyświecającym powstaniu frameworku było usprawnienie i poprawa efektywności systemu pracy przy tworzeniu oprogramowania.
 (1080 x 800 px) (1).png)
Stosowane wcześniej tradycyjne metodyki zarządzania projektami IT (i nie tylko), takie jak Waterfall (zwany inaczej modelem kaskadowych) często opierają się na bardzo wczesnym i ścisłym zdefiniowaniu kolejnych etapów powstania produktu. Duży wysiłek, czas realizacji i budżet jest inwestowany w skrupulatne planowanie każdego kroku. O ile planowanie samo w sobie nie jest niczym niewłaściwym, to w przypadku złożonych, wieloetapowych celów, bardzo trudno jest na początkowym etapie przewidzieć wszystko, co może się wydarzyć, a potem elastycznie reagować na zmiany. Dlatego bardzo szczegółowe planowanie na samym początku tworzy ryzyko późniejszego braku dopasowania rzeczywistości do tego, co na wykresie Gantta. Skutkiem takiego podejścia często są opóźnienia, koszty dużo powyżej założonego budżetu oraz produkt końcowy niezgodny z oczekiwaniami interesariuszy.
Stosowane wcześniej tradycyjne metodyki zarządzania projektami IT (i nie tylko), takie jak Waterfall (zwany inaczej modelem kaskadowych) często opierają się na bardzo wczesnym i ścisłym zdefiniowaniu kolejnych etapów powstania produktu. Duży wysiłek, czas realizacji i budżet jest inwestowany w skrupulatne planowanie każdego kroku. O ile planowanie samo w sobie nie jest niczym niewłaściwym, to w przypadku złożonych, wieloetapowych celów, bardzo trudno jest na początkowym etapie przewidzieć wszystko, co może się wydarzyć, a potem elastycznie reagować na zmiany. Dlatego bardzo szczegółowe planowanie na samym początku tworzy ryzyko późniejszego braku dopasowania rzeczywistości do tego, co na wykresie Gantta. Skutkiem takiego podejścia często są opóźnienia, koszty dużo powyżej założonego budżetu oraz produkt końcowy niezgodny z oczekiwaniami interesariuszy.
Takie podejście pomaga też lepiej kontrolować ryzyko. Zamiast stawiać wszystko na jedną kartę na końcu produktu, zespoły regularnie dostarczają wartość dla klienta. To nie tylko daje klientowi szybszy zwrot z inwestycji, ale także umożliwia wcześniejsze wykrywanie i naprawianie problemów. Jeśli coś pójdzie nie tak, zespoły mogą szybko dostosować się i zmienić kierunek, zamiast tracić czas i zasoby na kontynuowanie niewłaściwej ścieżki.
Scrum zachęca do kreatywności i wzajemnej wymiany pomysłów, nie narzucając szczegółowych wytycznych co do sposobu pracy. To zbiorowa inteligencja osób go używających oraz ich wzajemne relacje i interakcje budują konkretny model współpracy dla danego zespołu lub organizacji. Framework ten angażuje grupy ludzi, którzy kolektywnie posiadają wszystkie umiejętności i ekspertyzę potrzebną do wykonania pracy i dzielą się nimi lub zdobywają je w razie potrzeby.
W przypadku popełnionych błędów, nie szuka się winnych, a stara usprawnić proces. Jeśli coś nie działa, przyglądamy się funkcjonowaniu całego zespołu. Framework nagradza pozytywne zachowania, skupiając się na współpracy oraz dostarczaniu produktów.
Nie. Planowanie jest istotne, pojawia się choćby na początku każdego Sprintu. Każde wydarzenie w Scrumie służy m.in. lepszemu planowaniu - zgodnie z powiedzeniem "plan jest niczym, planowanie - wszystkim". Istotną częścią pracy nad produktem jest stworzenie, porządkowanie i aktualizacja backlogu. Unika się tu jednak ślepego podążania za długoterminowym planem, a raczej przystosowuje się działania do zmieniających się okoliczności, przebiegu pracy i oczekiwań interesariuszy.
Scrum i Agile opierają się na empiryzmie i myśleniu Lean. Zgodnie z założeniem empiryzmu, wiedza pochodzi z doświadczenia i podejmowania decyzji na podstawie obserwacji. Lean Thinking redukuje straty i koncentruje się na istocie przynoszącej wartość.
Nacisk jest położony na to, w jaki sposób ludzie rzeczywiście pracują, a nie na to, jak zaplanowali swoją pracę. To system nieustannie ewoluujący, adaptacyjny i przeprowadzający autokorektę. Ramy, które tworzy, są zogniskowane wokół samego procesu uczenia się. Jest w nich dużo miejsca i akceptacji dla kreatywności oraz niepewności co do wyniku.
Scrum adaptuje koncepcję MVP (minimal viable product - produkt o kluczowej funkcjonalności). Dzięki podejściu "Inspect and Adapt" nieustannie poszukuje się w nim sposobów, aby praca przebiegała szybkiej i efektywniej. Podstawą jest częste zatrzymywanie się i zadanie sobie pytania: co robię, co zrobił_m, co jest jeszcze do zrobienia, czy na pewno wciąż muszę to robić i jak mogę to zrobić lepiej.
Sukces w pracy według frameworku Scrum zależy od tego, jak dobrze ludzie potrafią stosować pięć wartości: zaangażowanie, skupienie, otwartość, szacunek i odwagę..
Te wartości pokazują zespołowi, jak powinien pracować, jakie decyzje podejmować i jak się zachowywać. Wszystko, co robi zespół, powinno je wzmacniać. Oczywiście, nie jest to jedyny sposób rozumienia powyższych wartości - warto taką konwersacje poprowadzić u siebie w Zespole - jak ja rozumiem te wartości? Czym się przejawiają?
 (1080 x 800 px).png)
Stosowanie frameworku Scrum sprzyja skupieniu na wartości. To z kolei sprawia, że ludzie priorytetyzują najważniejszą pracę, zadania leżące w magicznym obszarze 20% przynoszącym 80% rezultatów. Osoby włączone w projekt widzą nie tylko należący do nich kawałek, ale końcowy cel do osiągnięcia i robią wszystko, aby go osiągnąć.
Aby jednak móc skupić się na najważniejszych zadaniach, niezbędna jest eliminacja przeszkód i marnotrawstwa, które występują w procesie. Zyski po wyeliminowaniu tych dwóch spowalniaczy są olbrzymie. Mimo tego, organizacje często nie decydują się na wprowadzenie zmian, ponieważ sama zgoda na przyjrzenie się przebiegowi dotychczasowych procesów wymaga dużej dozy szczerości wobec siebie i innych.
Empiryczny proces kontroli w Scrum opiera się na trzech filarach: przejrzystości, inspekcji i adaptacji.
1. Przejrzystość (Transparencja) - wszystko, co robimy, musi być jasne dla osób, które pracują nad produktem oraz dla tych, którzy będą z niego korzystać.
Dla skutecznego funkcjonowania zespołu niezbędna jest pełna przejrzystość procesów i postępów. Zapewnia to kompletny obraz sytuacji, umożliwiając dokładną analizę i dostosowanie działań opartych na jak najszerszym zakresie dostępnych danych. Istotna jest również transparentność w rozmowach z interesariuszami, którzy powinni być zaangażowani w proces tworzenia produktu nie tylko przez dzielenie się swoimi opiniami, ale także przez dostarczanie wartościowych informacji, na przykład z rynku. Wspiera to dostosowanie produktu do realnych potrzeb klientów. Nie mówimy o tym, że każdy musi wszystko wiedzieć - transparencja kładzie nacisk na wspólne zrozumienie w kontekście budowania jakościowego produktu. Wiemy jaki jest Cel Produktu, jaką mamy wizję aby go osiągnąć, jak może wyglądać development, wspólnie budujemy backlog produktu (product backlog) itd.
2. Inspekcja - pomaga nam regularnie i dokładnie sprawdzać narzędzia pracy i postępy w osiąganiu celów, żeby zauważyć problemy lub odchylenia od planu.
Inspekcja to sposób na weryfikację, czy elementy Scrum, takie jak Backlog Produktu, Backlog Sprintu oraz Przyrost, a także ogólny postęp pracy, są zgodne z ustalonymi planami i oczekiwaniami. Jej celem jest identyfikacja wszelkich niezgodności lub braków, które następnie mogą być odpowiednio skorygowane. W duchu Lean, wspiera identyfikacje i eliminację marnotrastwa..
3. Adaptacja - jeśli coś w procesie pracy nie idzie tak jak powinno, lub jeśli produkt nie spełnia oczekiwań, musimy dostosować proces lub produkt.
Gdy jakiś element procesu przekracza ustalone granice tolerancji lub rezultat pracy okazuje się nieodpowiedni, konieczne jest dokonanie odpowiednich korekt w stosowanych metodach lub produkowanych materiałach. Ważne, aby wprowadzać te zmiany możliwie jak najszybciej i tym samym ograniczyć ryzyko dalszych odchyleń. Proces adaptacji może być utrudniony, jeśli osoby zaangażowane w projekt nie posiadają odpowiednich uprawnień lub zdolności do samodzielnego zarządzania. Oczekuje się, że zespół Scrum w odpowienim czasie wprowadzi niezbędne zmiany po otrzymaniu nowych informacji wynikających z procesu inspekcji. Kazdy kolejny Sprint jest sposobem na lepszą adaptację i budowanie jakościowego produktu.
Artefakty w Scrumie to kluczowe informacje wykorzystywane przez zespół Scrum. Pomagają zdefiniować produkt i prace, które należy wykonać, by go dostarczyć. W Scrum istnieją trzy główne artefakty: Backlog Produktu, Backlog Sprintu i Przyrost(Increment).
Scrum definiuje trzy kluczowe odpowiedzialności: Właściciela Produktu (Product Owner), Deweloperów i Scrum Mastera. Każda z tych ról ma swoje unikalne obowiązki i odpowiedzialności.
Właściciel Produktu jest osobą odpowiedzialną za maksymalizację wartości Backlogu Produktu. To on decyduje, które funkcje produktu są najważniejsze i w jakiej kolejności powinny być realizowane. Właściciel Produktu musi dobrze rozumieć potrzeby klientów i biznesu, aby móc podejmować właściwe decyzje. Jego celem jest maksymalizacja wartości produktu.
Deweloperzy to profesjonaliści odpowiedzialni za wykonanie pracy. To grupa osób, które faktycznie tworzą produkt. Mogą to być programiści, testerzy, projektanci,prawnicy, analitycy i inni specjaliści, w zależności od potrzeb produktu. Zespół analizuje całość pracy i dobiera zadania tak, aby podczas każdego Sprintu uzyskać wzrost wartości produktu. Członkowie zespołu pracują razem, aby dostarczyć wysokiej jakości produkt na koniec każdego Sprintu. Zespół Scrum jest samozarządzający i interdyscyplinarny.
To odpowiedzialność, co do której pojawia się zazwyczaj najwięcej wątpliwości. Co właściwie robi Scrum Master? Kim jest Scrum Master? To osoba, która pomaga zarówno Product Ownerowi, jak i Zespołowi Scrum w zrozumieniu i stosowaniu Scruma. Scrum Master dba o to, aby zespół pracował efektywnie i bez przeszkód. Pomaga również w utrzymaniu dobrej komunikacji między zespołem a Właścicielem Produktu oraz innymi interesariuszami. Jego nadrzędnym celem jest upewnienie się, że Scrum jest rozumiany i stosowany w organizacji tak aby dostarczyć jak najlepszy jakościowo Produkt, odpowiadający na potrzeby klienta/użytkownika.
Wszystkie trzy odpowiedzialności są niezbędne do skutecznego stosowania Scruma. Właściciel Produktu określa co ma być zrobione, Deweloperzy wykonują pracę, a Scrum Master zapewnia, że proces przebiega płynnie. Wszyscy członkowie zespołu współpracują ze sobą, aby dostarczyć wartościowy produkt dla klienta.
Zespoły Scrum (Scrum Teams) są interdyscyplinarne, co oznacza, że posiadają różne umiejętności potrzebne do pracy nad projektem. Sami decydują, kto co robi, kiedy i jak. Zespół Scrum jest na tyle mały, żeby łatwo się nim zarządzać, ale na tyle duży, żeby osiągać realne wyniki podczas Sprintu. Zespół składa się zazwyczaj z 10 lub mniejszej liczby osób. Jeśli zespół jest za duży, można go podzielić na kilka mniejszych zespołów, które pracują nad tym samym produktem.
Scrum stawia ludzi na pierwszym miejscu. Organizuje projekty, korzystając z wielofunkcyjnych zespołów, które posiadają umiejętności i kompetencje niezbędne do dostarczenia całego fragmentu funkcjonalności - od pomysłu do realizacji. Celem Scrum jest wsparcie zespołu we wspólnej pracy, która, w efekcie końcowym, ma zachwycić klientów.
Zespół Scrum odpowiada za wszystko, co związane z produktem. Od rozmów z interesariuszami, przez sprawdzanie jakości, utrzymanie produktu, aż po badania i rozwój. Zespół decyduje o swojej pracy i organizuje ją sam. Cały Zespół Scrum odpowiada za to, żeby na koniec każdego Sprintu powstał gotowy wartościowy produkt.
Najlepsze zespoły charakteryzuje:
Małe zespoły (do 10 osób) często uważa się za lepsze dla realizacji celu Sprintu ze względu na kilka zmiennych:
Jedną z kluczowych cech zespołu Scrum, która łączy wszystkie elementy, jest zaufanie. Jeśli zaufanie nie jest obecne, prawdopodobnie pojawią się napięcia i przeszkody na drodze do wykonania pracy. Wartości Scrum są szczególnie ważne w środowiskach, gdzie eksperymentowanie jest kluczowe dla postępu.
 (1080 x 800 px) (1080 x 1080 px).png)
Kiedy technologia umożliwia pracę z dowolnego miejsca na świecie, coraz więcej firm decyduje się na tworzenie rozproszonych zespołów. W kontekście Scruma, mówimy o rozproszonym zespole Scrum, gdy jego członkowie nie pracują w jednym miejscu, ale są rozproszeni geograficznie.
Komunikacja jest w takich przypadkach jednym z największych wyzwań - zarówno w zakresie jasności przekazu, jak i różnic czasowych między członkami zespołu. Inne wyzwania to budowanie zaufania i wspólnoty, a także koordynowanie i synchronizowanie pracy.
Istnieją jednak strategie, które mogą pomóc rozproszonym zespołom Scrum efektywnie pracować razem. Przypomnijmy, że Scrum nie narzuca jednego sposobu pracy, a jedynie pomaga stworzyć ramy postępowania w zależności od zmieniających się warunków. Szczególnie istotne w pracy na odległość są więc:
Wydarzenia w Scrumie to okazja, żeby spojrzeć na to, co zespół robi i w jaki sposób. Dzięki temu można lepiej zrozumieć swoją pracę i dostosować działania do aktualnej sytuacji.
Spotkania w Scrumie mają regularny harmonogram, co pomaga zespołowi lepiej się zorganizować. Najlepiej, gdy odbywają się one o tej samej porze i w tym samym miejscu, bo to ułatwia planowanie i ogranicza zamieszanie.
Wszystkie wydarzenia w Scrumie odbywają się w ramach Sprintu. Sprinty są kluczowym składnikiem frameworku Scrum. Są to okresy pracy zespołu, w których pomysły zamieniają się w wartościowe rozwiązania.
Pojedynczy Sprint trwa maksymalnie miesiąc. Gdy jeden Sprint się kończy, od razu zaczyna się kolejny. Podczas Sprintu odbywają się wszystkie niezbędne prace służące do osiągnięcia Celu Sprintu. Ważne, by podczas Sprintu nie wprowadzać zmian, które mogą zakłócić plany..
Elements of Sprint in Scrum. Read morePlanowanie Sprintu (Sprint Planning) to pierwszy etap każdego Sprintu. Właściciel Produktu opowiada Deweloperom swoją wizję an ten Cel, wyrażoną poprzez uszeregowanie elementów Backlogu Produktu, a następnie Zespół wybiera zadania, które są w stanie zrealizować w nadchodzącym Sprincie.
Daily Scrum (czasem błędnie nazywany Daily Stand-up kopiując nomenklaturę XP) to krótkie, codzienne spotkanie zespołu, mające na celu koordynację pracy i identyfikację potencjalnych przeszkód. Jednym z możliwych sposobów rozmowy jest informacja o tym co deweloperzy zrobili poprzedniego dnia, co planują zrobić dzisiaj i jakie przeszkody napotkali w kontekście Celu Sprintu.
Przegląd Sprintu to spotkanie na koniec Sprintu, podczas którego Zespół przedstawia efekty swojej pracy, prezentuje swoje osiągnięcia i omawia postępy. Jest to głównie okazja do dyskusji i feedbacku.
Retrospektywa Sprintu (Sprint Retrospective) to ostatnie spotkanie w Sprincie, podczas którego zespół ocenia co poszło dobrze, co mogło pójść lepiej i jakie zmiany można wprowadzić w przyszłych Sprintach.
Tablica Scrum to narzędzie wspomagające realizację projektów. Jej głównym celem jest wizualizacja pracy, która ma zostać wykonana, oraz postępu zespołu pracującego nad produktem czy projektem. Nie jest to w żaden sposób wymagany element Scrum, bardziej komplementarna praktyka wspierająca wizualizację prac.
Podział tablicy na kolumny stanów realizacji to kluczowy element, który pozwala śledzić postęp prac. Najczęściej spotykane kolumny to:
Każde zadanie reprezentowane jest przez kartkę (fizyczną lub wirtualną), która zawiera krótki opis tego, co należy zrobić. Dodatkowo może zawierać informacje takie jak osoba odpowiedzialna, szacowany czas potrzebny do wykonania, priorytet czy wszelkie inne użyteczne notatki.
Termin Scrum pochodzi z artykułu Harvard Business Review z 1986 roku, w którym autorzy Hirotaka Takeuchi i Ikujiro Nonaka porównali wysokowydajne, wielofunkcyjne zespoły do formacji scrum używanej przez drużyny rugby.
Chociaż Scrum ma swoje korzenie w rozwoju oprogramowania, dziś stosowany jest w bardzo wielu dziedzinach. Może być przydatny wszędzie, gdzie celem jest dostarczanie złożonych, innowacyjnych produktów i usług.
Role przypisane do Scruma, czyli Budowniczy (Developers), Właściciel Produktu (Product Owner) oraz Scrum Master wywodzą się więc ze środowiska związanego z produktami oprogramowania, ale można je zastąpić terminami z innych branż, pamiętając jednak o ścisłym przestrzeganiu samych zasad Scruma.
Zarówno Scrum, jak i Kanban, to konkretne ramy w zarządzaniu pracą, zgodne z filozofią Agile. Scrum jest na tyle mocno kojarzony z Agile, że terminy Agile i Scrum często bywają (błędnie) utożsamiane..
Zarówno Scrum, jak i Kanban korzystają z wizualnych narzędzi do śledzenia postępów, takich jak tablica Scrum czy tablica Kanban. W obu metodach priorytetem jest efektywność i rozbijanie skomplikowanych zadań na mniejsze, łatwiejsze do zarządzania fragmenty, ale podejście do osiągnięcia tego celu jest różne.
Scrum skupia się na krótkich iteracjach o stałej długości. Po określeniu czasu trwania Sprintu, wybiera się elementy backlogu produktu, które można zrealizować podczas danego cyklu sprintu. Z drugiej strony, w Kanbanie liczba zadań lub prac w toku (limit WIP) do realizacji w ramach bieżącego cyklu jest na początku ustalona a następnie adaptowana w miarę rozwoju dojrzałości zespołu.
Kanban w podejściu ProKanban nie jest tak sformalizowany jak Scrum. Poza limitem prac w toku, ten model daje dużą swobodę interpretacji. Natomiast Scrum opiera się na kilku konkretnych zasadach, takich jak przegląd Sprintu, Retrospekcja, Daily Scrum itp.
W tym modelu podkreśla się również interdyscyplinarność, czyli zdolność zespołu Scrum do samodzielnego osiągnięcia celu bez zewnętrznych członków. Zgromadzenie takiego zespołu nie jest łatwe. W tym kontekście Kanban jest łatwiejszy do wdrożenia, natomiast Scrum jest postrzegany jako fundamentalna zmiana w sposobie myślenia i pracy Deweloperów.
Kanban pomaga we wdrażaniu zmian w sposób ewolucyjnym - zacznij z tym co masz, natomiast Scrum w tym kontekście jest binarny: albo masz wszystkie elementy Scrum, albo to Scrumem nie jest.
 (1080 x 800 px) (1080 x 1080 px) (1).png)
Technika Scrum of Scrums jest stosowana, jeśli niezbędne jest skoordynowanie pracy wielu zespołów Scrumowych pracujących nad tym samym produktem, Jest szczególnie przydatna, gdy mamy do czynienia z dużymi produkami, które wymagają zaangażowania wielu zespołów.
W tradycyjnym Scrumie, codzienny Scrum (Daily Scrum) są okazją dla zespołu do omówienia postępów i planów na najbliższy dzień. W Scrum of Scrums, reprezentanci każdego zespołu Scrumowego spotykają się regularnie (na przykład raz dziennie ), aby omówić postępy całego rozwoju produktu.
Podczas spotkania Scrum of Scrums, reprezentant każdego zespołu informuje o::
Celem Scrum of Scrums jest zapewnienie przejrzystości i koordynacji między różnymi zespołami, a także identyfikacja i rozwiązywanie problemów, które mogą wpływać na więcej niż jeden zespół. Dzięki temu, wszystkie zespoły mogą pracować razem efektywnie i skutecznie dążąc do wspólnego celu.
Bycie efektywnym w Scrumie to coś więcej niż tylko przestrzeganie zasad frameworku. Czasami Zespoły Scrumowe wpadają w rutynę prostego odhaczania wymaganych elementów zwanego potocznie "zombie Scrum". Profesjonalny Scrum wymaga jednak zmiany mentalności w sposobach pracy, przyjęcia Wartości Scrum oraz środowiska, które taką zmianę zmienia.
Uzyskanie certyfikatu wydawanego przez Scrum.org jest znaczącym krokiem w profesjonalnej karierze każdego, kto pracuje w ramach frameworku Scrum. Certyfikaty te są uznawane na całym świecie i pokazują, że osoba posiada solidne i sprawdzone umiejętności oraz wiedzę na temat Scruma.
Certyfikat potwierdza zdolność do skutecznego zarządzania projektami w ramach Scrum. Pokazuje, że rozumiesz zasady Scruma i jesteś w stanie je zastosować w praktyce. Proces zdobywania certyfikatu Scrum jest sam w sobie wartościowym doświadczeniem edukacyjnym. Kursy i egzaminy wymagają od uczestników dogłębnego zrozumienia Scruma, co pomaga utrwalić i rozszerzyć ich wiedzę. To może przynieść bezpośrednie korzyści w codziennej pracy, pomagając lepiej zarządzać projektami i efektywniej współpracować z zespołem.
