Skalowanie Scruma

If a problem cannot be solved, enlarge it.

–Dwight D. Eisenhower

”

“

Scrum w dużej skali

enterprise agility

© 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

1.02.12 bnd

Tomek Włodarek

scrum /skrʌm/


Scrum is just a simple framework that will identify everything in an organization that gets

in the way of optimally building software. –K. Schwaber, J. Sutherland

Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust

”

“

scrum /skrʌm/

”

“ Scrum will only help you to fail in 30 days or less. It’s a framework within which people can address

complex problems. –K. Schwaber


1–4 tygodnie Scrum w wytwarzaniu oprogramowania

Scrum Guide, Ken Schwaber, Jeff Sutherland (http://www.scrum.org/Scrum-Guides)

Role (Scrum Team) Product Owner

Zespół Deweloperski

Scrum Master

Artefakty Przyrost

Product Backlog

Sprint Backlog

Wydarzenia Sprint

Sprint Planning (1) i (2)

Codzienny Scrum (Daily Scrum)

Sprint Review

Retrospektywa (Retrospective)

Przygotowanie (opcjonalne) (1) Product Owner uczestniczy w przygotowaniu wizji produktu, roadmappingu, wstępnym budżetowaniu (2) Product Owner przygotowuje założenia wydania i tworzy zręby Product Backlogu. Sprint Planning (4h + 4h) (1) Product Backlog jest omawiany zgodnie z porzadkiem nadanym przez Product Ownera (2) Zespół Deweloperski przygotowuje Sprint Backlog, czyli określa zakres i plan prac na bieżący Sprint.

Przebieg Sprintu Zespół Deweloperski realizuje Przyrost, zgodnie z ustalonymi standardami (DoD), poddając plan prac codziennej kontroli i adaptacji (Daily Scrum).

Sprint Review (4h) Produkt poddawany jest wspólnej (angażującej Zespół Scrumowy i interesariuszy) inspekcji. Na jej podstawie dokonuje się adaptacji Product Backloga a Product Owner omawia plan kolejne Sprinty (projekcja).

Scrum Master stoi na straży przejrzystości, przestrzegania reguł i efektywności wykorzystania Scruma.


Sprint Retrospective (3h) Zespół Scrumowy dokonuje inspekcji i adaptacji procesu wytwórczego (narzędzi i technik) oraz relacji w zespole.


Czy w skład Zespołu Scrumowego wchodzą: ... Product Owner odpowiedzialny za Product Backlog? (jedna osoba) ... Scrum Master odpowiedzialny za poprawne rozumienie i wykorzystanie Scruma? ... interdyscyplinarny, samoorganizujący się Zespół Deweloperski? Czy istnieją: ... przejrzysty i uporządkowany Product Backlog? ... Sprint Backlog pokazujący w każdym dniu Sprintu ile pracy pozostało do wykonania? ... Sprinty o ustalonym i nieprzekraczalnym czasie trwania, maksymalnie 1 miesiąc? (otwierane planowaniem i zamykane retrospektywą) ... użyteczne, gotowe do potencjalnego wdrożenia oprogramowanie po każdym Sprincie (Przyrost)?

Czy Zespół Scrumowy: … podczas Planowania Sprintu tworzy Sprint Backlog zawierający przewidywany zakres prac wraz planem na ich wykonanie? Czy Zespół Deweloperski: ... podczas Codziennego Scruma analizuje postęp i plan prac i wprowadza niezbędne korekty do Sprint Backlogu? Czy w każdym Sprincie: ... odbywa się Przegląd Sprintu podczas którego interesariusze dokonują inspekcji Przyrostu? ... odbywa się Retrospektywa Sprintu angażująca cały Zespół Scrumowy?


W zmaganiach między tobą a rzeczywistością,

rzeczywistość zdaje się mieć przewagę. –Ja

”

“

There is a tendency in enterprises to overplan and to overthink. This is not the Scrum way. Scrum requires action, evaluation, learning,

elimination of impediments, and more action in order to create things of value. –K. Schwaber, J. Sutherland


empiryzm (kontrola–adaptacja–przejrzystość)

”© 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

“

Scrum exposes every cultural dysfunction that impedes developing software […]

It is not an approach or process that can be modified to fit the existing organizational culture;

the culture must change to enable Scrum. –K. Schwaber, J. Sutherland

Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust ”

“ © 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

empiryzm (kontrola–adaptacja–przejrzystość)

przejrzystość

The great thing about fact–based decisions is that they can overrule the hierarchy.

–Jeff Bezos Amazon.com

”© 2012 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

“

samoorganizacja

[...] study by Nonaka has shown that Japanese companies with a self–organizing characteristic

tend to have higher performance records [...] –K. Imai, I. Nonaka, H. Takeuchi

Managing the New Product Development Process: How Japanese Companies Learn and Unlearn

”


In a relay someone says: my job is done, now you take it from here. But that’s not right.

Everyone has to run the entire distance. Like in rugby, every member of the team runs together

[…] and dashes toward the goal. –K. Imai, I. Nonaka, H. Takeuchi

Managing the New Product Development Process: How Japanese Companies Learn and Unlearn ”


współodpowiedzialność


Scrum is a disruptive technology, that if you implement it well, your competition

can’t compete. You will put your competitors out of business.

–Jeff Sutherland

”

“

Dlaczego warto rozważać zwinne podejście

Stan bieżący •  Opóźnienia w realizacji projektów, długie cykle produkcyjne,

późna kapitalizacja. Innowacja staje się imitacją •  Planowanie i utrzymanie planu wydaje się zabierać zbyt dużo

czasu •  Odstępstwo od planu jest kosztowne, wprowadzanie zmian w

trakcie realizacji projektu jest trudne •  Jakość tworzonego oprogramowania się pogarsza, faza

stabilizacji przed wydaniem się wydłuża •  Produkty stają się coraz droższe w utrzymaniu i rozwijaniu •  Energia tracona jest na walkę wewnątrz firmy (pomiędzy

działami, pionami, sektorami) a nie z rynkiem •  Niezadowoleni, zrażeni współpracą klienci/odbiorcy •  Marsze śmierci* obniżają morale, rośnie frustracja, występuje

przerzucanie się odpowiedzialnością i szukanie kozłów ofiarnych

*Edward Yourdon, Marsz ku klęsce, WNT 2007

Agile •  Umiejętność dokonywania szybkiej zmiany, łatwość jej

realizowania

•  Zwiększona produktywność i jakość •  Wczesna eliminacja ryzyka

•  Wczesne uzyskiwanie wartości •  Zwiększona świadomość odnośnie aktualnego stanu prac

(umiejscowienie w cyklu produkcyjnym)

•  Ograniczone marnotrawstwo

•  Odchudzone (lean) produkty, szybciej i precyzyjniej zdobywające rynek

•  Poprawa relacji z klientami/odbiorcami

•  Zaangażowani i zmotywowani pracownicy •  Obniżone całkowite koszty realizacji (produkcji, wdrożenia

i utrzymania oprogramowania)


jaka jest twoja motywacja?

•  przeterminowane pomysły i zawiedzione oczekiwania

•  zagrożenie pozycji rynkowej

•  biurokratyczny kolaps*

•  wysokie koszty utrzymania i rozwoju oprogramowania

•  wysokie koszty towarzyszące (koordynacja, komunikacja)

•  niskie morale, zmęczenie i wypalenie pracowników

•  pseudo–agile/scrum–fall (zawiedzione nadzieje)**

*http://blog.zacharyvoase.com/2009/06/20/bureaucratic-breakdown/ **http://www.halfarsedagilemanifesto.org/



poscrumianie organizacji

Scrum stymuluje zmianę w sposobie pracy w zespołach, pracy z klientem, praktykach inżyn ie r sk ich , procesach wytwórczych, technologi i , m e t o d a c h z a r z ą d z a n i a produktem, projektem, portfolio projektów. Słowem – wszędzie.

Wyzwanie rzucane jest o b e c n e j k u l t u r z e organizacyjnej i zasadom ładu korporacyjnego.



modele wdrażania §  działania oddolne, partyzanckie (ograniczony zasięg i korzyści, zwykle

okupione dużym wysiłkiem i stresem)

§  doraźne zastosowanie w odpowiedzi na palącą potrzebę (zasięg i korzyści ograniczone do konkretnego projektu/obszaru)

§  pilotażowe wdrożenie (wydzielona część organizacji)

§  pełne wdrożenie, pełne wsparcie

kontekst jest ważny §  od chaosu do Scruma

§  od waterfalla do Scruma

§  od water-Scrum-falla do Scruma

nie da się

marchewkowo–pomarańczowy proszę...


It is quite difficult for a highly structured and seniority–based organization to mobilize itself

for change, especially under noncrisis conditions. The effort collapses somewhere in

the hierarchy. –K. Imai, I. Nonaka, H. Takeuchi

Managing the New Product Development Process: How Japanese Companies Learn and Unlearn

”

“

brak czasu

pożar, wszędzie pożar…


Many workplaces are unsafe. Political agendas and hidden purposes pervert transparency.

Furthermore, many managers are skilled in managing the status quo but not

in managing change. –K. Schwaber, J. Sutherland


“


powód wyjaśnienie potencjalny rezultat

chwilowa moda wszyscy wokół to robią, trzeba się dostosować

mało z tego zwinności, dużo zamieszania

krytyczna sytuacja/problem

kluczowy projekt ma kłopoty, trzeba znaleźć sposób na jego uzdrowienie

sytuacja/problem rozwiązany (nie bez trudności), korzyści doraźne, ulotne

dogłębna ocena sytuacji firmy

stan aktualny (status–quo) nie jest akceptowalny, zwinność wydaje się niezbędna do utrzymania pozycji firmy

znaczące, długotrwałe korzyści, poprawa zdolności konkurencyjnej; wiele wariantów wdrożeniowych, każdy o swojej specyfice

© 2012-2014 Tomasz Włodarek. Pragmatyczne metody wytwarzania oprogramowania. Materiał udostępniany na licencji Creative Commons (by-nc-nd).

Scrum Scrum+ Scrum++ Scrum+++ Scrum++++ Scrum+++++

4–6 m-cy 8–12 m-cy 12–18 m-cy 18–24 m-cy …–30 m-cy …–36 m-cy

Process (Scrum OOTB*)

Productivity Quality Enterprise Value Stała przewaga konkurencyjna

Wprowadzenie i stosowanie podstawowych reguł: role, artefakty, wydarzenia

Scrum oraz: ujednolicenie i konsekwencja stosowania reguł, zespoły międzyfunkcjonalne, samoorganizacja, zastosowanie definicji ukończenia, przejrzyste raportowanie postępów, kolejno wprowadzane zmiany w sferze narzędziowej i procesowej produkcji oprogramowania

Scrum+1 oraz: dług techniczny zidentyfikowany i powstrzymany, zdefiniowanie i stosowanie dobrych praktyk inżynierskich (clean code, emergent architecture), spójne podejście do testów, ukończone = gotowe do wydania, kolokowane prawdziwie międzyfunkcjonalne zespoły, retrospektywy napędzające zmianę, skupienie i uważność (np. praca w sprintach nie jest przerywana)

Scrum+2 oraz: zgodność ze strategią organizacji, coraz pełniejsza komunikacja i przejrzystość, decyzje podejmowane w odpowiedzi na fakty, samoorganizacja rozciągająca się ponad i poza zespoły (społeczności), oddolnie inicjowane zmiany składów zespołów w odpowiedzi na konkretną potrzebę, wytyczone nowe ścieżki rozwoju kariery, sprzedaż angażowana w proces rozwoju produktu

Scrum+3 oraz: zarządzanie sterowane wartością, zastosowanie wskaźników opisujących wartość, świadomość całkowitych kosztów posiadania (TCO), wydania punktowe (funkcjonalne) bez konieczności przeprowadzania stabilizacji, bliska współpraca i zaufanie między Product Ownerem, zespołem deweloperskim a interesariuszami, usunięte przeszkody zewnętrzne

Scrum+4 oraz: przedefiniowana rola lub brak managementu, nowe wartości stają u podstaw działania firmy, pełna samoorganizacja i partycypacja (np. wolny rynek/giełda pracowników, zespołów i projektów), premie zależne od rzeczywistej wydajności zespołów, zmiany w strukturach organizacji i departamentów także dotychczas niezaangażowanych

*out–of–the–box

8 kroków procesu wprowadzania zmiany

1.  Wzbudzenie poczucia pilności – co nam grozi jeśli nic się nie zmieni?

2.  Ustanowienie i utrzymanie koalicji liderów przewodzących procesowi zmian – grupa osób z odpowiednią pozycją, doświadczeniem, autorytetem, zaufaniem i umiejętnościami przywódczymi

3.  Stworzenie wizji stanu docelowego i strategii – jeśli zmianę uda się wprowadzić, jak będzie to wyglądać?

4.  Komunikacja – wykorzystanie wszelkich możliwych środków i kanałów informacyjnych w celu rozpropagowania wizji

5.  Angażowanie i usuwanie barier – uprawnienie i zachęcanie pracowników do podejmowania ryzyka związanego ze stosowaniem nowego podejścia, zbieranie informacji zwrotnej, eliminowanie napotkanych przeszkód

6.  Krótkookresowe sukcesy – natychmiastowe, widoczne sukcesy wynikające z nowego sposobu działania są celebrowane

7.  Konsolidacja uzyskanych korzyści i zwiększenie zakresu zmiany – promowanie liderów i zwolenników zmian

8.  Zakotwiczanie nowego podejścia w kulturze organizacyjnej – zmiana zaniknie jeśli nie będzie podtrzymywana

Jak przeprowadzić transformację firmy, John P. Kotter, Onepress 2007 Gdy góra lodowa topnieje. Wprowadzanie zmian w każdych okolicznościach, John P. Kotter, Onepress, 2008 §  Nie opuszczaj żadnego kroku §  Nie zatrzymuj się w pół kroku, nie

ignoruj potrzeby solidnego zakotwiczenia zmiany

§  Wykorzystuj osiągnięte już rezultaty do wzmocnienia kierunku zmian

§  Zakotwiczenie zmiany w kulturze zabiera lata



8 kroków staje się procesami XLR8. Accelerate: Building strategic agility for faster-moving world, John P. Kotter, HBR Press 2014

THE BIG IDEA ACCELERATE!

CREATE A SENSE OF URGENCY

AROUND A SINGLE BIG

OPPORTUNITY.

Build and maintain a guiding coalition.

THE BIG IDEA ACCELERATE!

Celebrate visible, signifi cant short-

term wins.

upon which all else is built. In my original work 15 years ago, I found that ridding an organization of complacency was important. In my more recent work, I’ve seen ongoing urgency emerge as a strong competitive advantage. It can galvanize a volunteer army and keep the dual operating system in good working order. It moves managers to focus on oppor-tunities and allow the network to grow for the ben-efi t of the organization. Without an abiding sense of urgency, no chance of creating a grander business will survive.

For clients, my team has begun by having the ex-ecutive committee take a fi rst pass at articulating the strategic opportunity. This makes sense because its members are in a position to see the big picture and because their role in nurturing the dual structure is vital—particularly in the early days, when it is most vulnerable to the forces of resistance. (For the story of how one sales executive at a technology fi rm cre-ated urgency, see the sidebar “The Dual Operating System in Practice.”)

2. Build and maintain a guiding coalition. The core of a strategy network is the guiding co-alition (GC), which is made up of volunteers from throughout the organization. In my work with cli-ents, people fill out applications to be on the GC. With a suffi cient sense of urgency, you may get 10 times as many applications as there are roles in the network’s core.

The GC is selected to represent each of the hier-archy’s departments and levels, with a broad range of skills. It must be made up of people whom the leadership trusts, and must include at least a few outstanding leaders and managers. This ensures that the GC can gather and process information as no hierarchy ever could.

All members of the GC are equal; no internal hi-erarchy slows down the transfer of information. The coalition can see inside and outside the enterprise, knows the details and the big picture, and uses all this information to make good enterprisewide de-cisions about which strategic initiatives to launch and how best to do so. The social dynamics of the GC may be uncomfortable at fi rst, but once a team learns how to operate well, most members seem to love being part of it.

3. Formulate a strategic vision and develop change initiatives designed to capitalize on the big opportunity. The vision will serve as a strate-gic true north for the dual operating system. A well-formulated vision is focused on taking advantage of a big make-or-break opportunity. (If no such oppor-tunity exists, because you operate in a rare pocket of competitive stability, you may not need this system quite yet. But keep your eyes open: That situation won’t last.) The right vision is feasible and easy to communicate. It is emotionally appealing as well as strategically smart. And it gives the GC a picture of success and enough information and direction to make consequential decisions on the fly, without having to seek permission at every turn.

In creating one company’s vision statement, the guiding coalition sought input from top manage-ment, a consultant’s report, and colleagues through-out the organization. The vision statement described what the sales group, which was dealing with mar-ket losses, could look like in a year if it accelerated toward a big opportunity. It outlined pragmatic goals but framed them with emotional resonance, using words such as “proud,” “passionate,” and “ad-mired.” As a result, the group vowed to work better with partners, double growth in emerging markets,

Formulate a strategic vision and develop change initiatives

designed to capitalize on the big opportunity.

Communicate the vision and the strategy

to create buy-in and attract a growing “volunteer army.”“volunteer army.”

Accelerate movement toward the vision and the

opportunity by ensuring that the network removes

barriers.

Never let up. Keep learning

from experience. Don’t declare victory

too soon.

Institutionalize strategic changes

in the culture.

The Eight AcceleratorsThe processes that enable the strategy network to function

52 Harvard Business Review November 2012

HBR.ORG

8 błędów popełnianych podczas wprowadzania zmiany

1.  Niedostateczne uświadomienie pracownikom konieczności dokonania zmian

2.  Stworzenie niedostatecznie silnej koalicji liderów

3.  Brak wizji 4.  Nieadekwatna komunikacja wizji 5.  Nieusunięcie przeszkód utrudniających

realizację wizji 6.  Brak systematycznego planowania i

kreowania krótkookresowych sukcesów

7.  Zbyt wczesne świętowanie zwycięstwa

8.  Brak zakotwiczenia zamian w kulturze organizacyjnej

Jak przeprowadzić transformację firmy, John P. Kotter, Onepress 2007

Przewodzenie procesowi zmian: przyczyny niepowodzeń, John P. Kotter, HBRP nr 17, lipiec 2004

XLR8. Accelerate: Building strategic agility for faster-moving world, John P. Kotter, HBR Press 2014


organizacja, podobnie jak wytwarzany przez nią software to złożony problem


The degree of success you have with empirical software development largely depends on the leadership in your organization and how they

lead everyone in the […] changes. –K. Schwaber, J. Sutherland


”

“

4 tygodnie

Agility Guide, Ken Schwaber, Scrum.org (http://ebmgt.org/Agility-Guide)

Role Zespół tranzycyjny (Enterprise Agility Team) Zespoły domenowe (Domain Agility Teams) Zespoły robocze (Development Scrum Teams)

Artefakty Agility Product Backlog – zawiera propozycję zmian, zasilany przez przeszkody odkrywane przez zespoły domenowe i robocze –nieefektywności, konflikty, dysfunkcje a także inspirowany przez osiągane stopniowo możliwości

Zdarzenia Zespół tranzycyjny oraz zespoły domenowe wykorzystują Scruma (Daily Scrum → Weekly Scrum)

Inicjacja procesu zmian Enterprise Product Owner przygotowuje wizję i strategię wprowadzania zmian. Formowany jest zespół 3-6 osób umocowanych odpowiednio do przeprowadzenia transformacji organizacji. Pod przewodnictwem Enterprise Product Ownera konstruowane są wstępne założenia backlogu tranzycyjnego. Sprint Planning Z Agility Product Backlogu dobierany jest realistyczny zakres aktywności na najbliższy okres; uruchamiane są Sprinty zespołów domenowych (wdrażających zmianę).

Sprint Review Uzyskane w zespołach domenowych i zespole tranzycyjnym rezultaty poddawane są inspekcji, Agility Product Backlog jest przeglądany, uzupełniany, a Enterprise Product Owner ustala kolejność

Scrum Masterzy stoją na straży przejrzystości, przestrzegania reguł i efektywności wykorzystania Scruma.

Realizacja Sprintu Zespoły domenowe implementują zmiany w organizacji Przedstawiciele zespołów domenowych biorą udział w cotygodniowych Scrumach zespołu tranzycyjnego. Backlog tranzycyjny jest ciągle uzupełniany o nowe wpisy.

Scrumowanie Scruma, poscrumianie organizacji


Sprint Retrospective Zespół tranzycyjny i zespoły domenowe poddają analizie efektywność swojego sposobu pracy.

decydując się na zmianę należy być przygotowanym na:

§  Pierwszych 3–9 miesięcy będzie szczególnie trudne dla wszystkich, całość zajmie od 2 do 6 lat §  Fluktuację kadr (chęć zmiany zespołu, odejścia z firmy spowodowane trudnościami w odnalezieniu

się w nowym modelu lub brakiem akceptacji zachodzących zmian)

§  Cała organizacja zostanie poddana stresowi i wytrącona ze stanu równowagi – pojawią się animozje, kolizja światopoglądów, tarcia i konflikty prowadzące do zmiany

§  Dewelopment stanie się odpowiedzialny za utrzymanie jakości, co może spowodować ograniczenie tempa i zakresu prac; prawdopodobna jest reewaluacja prowadzonych projektów

§  Zmieni się praca menedżerów – środek ciężkości przesunie się z wyznaczania i rozliczania na przywództwo i wspieranie – będzie inaczej i trudniej

§  Polityka oceny i wynagradzania pracowników może ulec zmianie

§  Przejrzystość redukuje możliwości realizowania osobistych, egoistycznych celów – niektórym może się to nie podobać

§  Zidentyfikowane zostaną słabe i wstydliwe strony organizacji – braki kompetencji, zbędna biurokracja, nieefektywności struktury organizacyjnej

§  W sytuacjach kryzysowych wracać będą stare zachowania §  Scrum jest piekielnie trudny, reguły będą naciągane/łamane, zacznie się poszukiwanie

„lepszych” (czyt. mniej wymagających) metod


backlog tranzycyjny – przykładowe elementy §  Określić potrzeby i oczekiwania, obszary, zdefiniować zestaw miar i sposób pomiaru procesu zmiany §  Przygotować i przeprowadzić program komunikacji zmian w organizacji

§  Zaprojektować i dostarczyć programy szkoleniowe

§  Zaprojektować sposób zbierania informacji zwrotnej, zadawania pytań i rozwiązywania kwestii związanych z wdrożeniem Scruma i wpływem tej zmiany na pracowników

§  Zidentyfikować potencjalnych Scrum Masterów, Product Ownerów i stworzyć mechanizmy wsparcia pracowników w nowych rolach (dodatkowe szkolenia, coaching, mentoring)

§  Ustalić warunki wstępne (wymagane) do wdrożenia Scruma w grupie, zespole, projekcie (np. ujednolicone Definition of Done, harmonogram Sprintów, liczebność i skład zespołów)

§  Zdefiniować oczekiwania odnośnie sposobów raportowania kondycji zespołów i projektów realizowanych przy użyciu Scruma

§  Przeprowadzić ewaluację narzędzi do zarządzania backlogami

§  Identyfikacja pierwszych grup, zespołów, projektów w których zastosowany zostanie Scrum

§  Zaprojektować zestaw miar, sposobów ich gromadzenia oraz wykorzystywania – odnośnie poszczególnych projektów realizowanych Scrumem

§  Przeprowadzić ewaluację portfolio projektów/produktów, utworzyć organizacyjny backlog inicjatyw, zaprojektować sposób jego utrzymywania

§  Przeprowadzić rewizję struktury organizacyjnej i schematu wynagradzania pracowników w celu promowania pracy zespołowej, wspierania samoorganizacji i podejmowania odpowiedzialności

§  Przeprowadzić analizę procesu produkcji i wydawania oprogramowania (development pipeline)



Scrum Scrum+ Scrum++ Scrum+++ Scrum++++ Scrum+++++

4–6 m-cy 8–12 m-cy 12–18 m-cy 18–24 m-cy …–30 m-cy …–36 m-cy

Process (Scrum OOTB*)

Productivity Quality Enterprise Value Stała przewaga konkurencyjna

Wprowadzenie i stosowanie podstawowych reguł: role, artefakty, wydarzenia

Scrum oraz: ujednolicenie i konsekwencja stosowania reguł, zespoły międzyfunkcjonalne, samoorganizacja, zastosowanie definicji ukończenia, przejrzyste raportowanie postępów, kolejno wprowadzane zmiany w sferze narzędziowej i procesowej produkcji oprogramowania

Scrum+1 oraz: dług techniczny zidentyfikowany i powstrzymany, zdefiniowanie i stosowanie dobrych praktyk inżynierskich (clean code, emergent architecture), spójne podejście do testów, ukończone = gotowe do wydania, kolokowane prawdziwie międzyfunkcjonalne zespoły, retrospektywy napędzające zmianę, skupienie i uważność (np. praca w sprintach nie jest przerywana)

Scrum+2 oraz: zgodność ze strategią organizacji, coraz pełniejsza komunikacja i przejrzystość, decyzje podejmowane w odpowiedzi na fakty, samoorganizacja rozciągająca się ponad i poza zespoły (społeczności), oddolnie inicjowane zmiany składów zespołów w odpowiedzi na konkretną potrzebę, wytyczone nowe ścieżki rozwoju kariery, sprzedaż angażowana w proces rozwoju produktu

Scrum+3 oraz: zarządzanie sterowane wartością, zastosowanie wskaźników opisujących wartość, świadomość całkowitych kosztów posiadania (TCO), wydania punktowe (funkcjonalne) bez konieczności przeprowadzania stabilizacji, bliska współpraca i zaufanie między Product Ownerem, zespołem deweloperskim a interesariuszami, usunięte przeszkody zewnętrzne

Scrum+4 oraz: przedefiniowana rola lub brak managementu, nowe wartości stają u podstaw działania firmy, pełna samoorganizacja i partycypacja (np. wolny rynek/giełda pracowników, zespołów i projektów), premie zależne od rzeczywistej wydajności zespołów, zmiany w strukturach organizacji i departamentów także dotychczas niezaangażowanych

*out–of–the–box

skalowanie ról i zespołów

Don’t build teams, let teams emerge.

–Tobias Mayer http://agileanarchy.tumblr.com/post/18364399411/dont-build-teams

”

“


skalowanie narzędzi


skalowanie wydarzeń


nie czekaj, po prostu zacznij* http://scrum.jeffsutherland.com/2012/07/dont-wait-just-begin.html


You cannot identify all impediments up front as

they are embedded in the organization and therefore too familiar to be identified easily.

–K. Schwaber, J. Sutherland Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers,

And Leave Competitors In the Dust

”

“

wyzwanie Scrum Mastera

Szukając zbiorowej inteligencji, możesz

natknąć się na zbiorową ignorancję. –Ja

”

“


…natychmiast pojawiają się wykręty – ScrumButs. ScrumButs to „powody”, dla których nie można w pełni wykorzystać Scruma, by rozwiązywać problemy, usprawniać działanie organizacji i realizować spodziewanych korzyści.

ScreamM

aster podczas wdrażania Scruma…


(Wykręt)(Powód)(Alternatywa) Scrumujemy, ale (nasz Product Owner nie ma czasu)(bo jest bardzo zajęty swoimi sprawami)(więc Product Backlog jest zarządzany przez sekretarkę/Project Managera/Scrum Mastera/nie ma backlogu) Scrumujemy, ale (Product Backlog jest zamrożony)(bo nasz Project Manager wymaga od nas deklaracji co do zakresu i czasu)(więc jak zwykle ścinamy zakręty i nie robimy testów, żeby wyrobić się na koniec Sprintu/wydania/projektu) Scrumujemy, ale (granice sprintów są umowne)(bo i tak ciągle wchodzi coś pilniejszego)(więc po prostu lecimy z robotą; i nazywamy to kanbanem)


(Wykręt)(Powód)(Alternatywa) Scrumujemy, ale (nie oddajemy gotowego software’u co Sprint)(bo nie mamy testera w zespole, a zresztą i tak żeby testować trzeba by się integrować z innymi zespołami)(więc tester – jak zdąży – robi testy wszystkiego na koniec projektu) Scrumujemy, ale (nie robimy Sprint Review)(bo i tak nikt nie rozumie jak dłubiemy coś w backendzie/frameworku/protokołach)(więc pokazujemy użyteczny software raz na pół roku) Scrumujemy, ale (retrospektywy to strata czasu)(bo i tak się nic nie zmienia)(więc po prostu ich nie robimy)


Scrum, ale... Water–scrum–fall. WAGILE*. Pseudo–Scrum. Prawie–Scrum. “Elementy Scruma”. Quasi–agile. Flaccid Scrum. Kanban? *waterfall agile (sic!)

ScrumButs to przejawy wypracowanych przez lata postaw, tradycyjnie stosowanych praktyk i przyzwyczajeń. U nas wygląda to tak… Kultura organizacyjna.



dość pieszczot. terapia szokowa* http://scrum.jeffsutherland.com/2012/01/scrum-shock-therapy-how-to-change-teams.html

When I join a team as their Scrum Master, I issue a few non–negotiable rules. Gently if

possible, firmly if necessary. –Scott Downey

http://rapidscrum.com/Agile2009-ShockTherapy.pdf

”

“


KEEP OUT. SPRINT IN PROGRESS

test na prawdziwość założeń


One of Scrum's best features is the information it provides. Even in the worst case, where the

team doesn't deliver anything, they have delivered valuable information about what is and

isn't possible. Management can use this information to maximize value and control risk.

–K. Schwaber, J. Sutherland Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers,

And Leave Competitors In the Dust ”

“


sztuka dostrzegania możliwości

Transparency is neither good or bad. Things and increments just are. They may not be what

you want, but that means hard decisions are required. You have to have a firm grasp of the

real facts to make solid decision. –K. Schwaber, J. Sutherland


“


Scrum exposes every cultural dysfunction that impedes developing software […]

It is not an approach or process that can be modified to fit the existing organizational culture;

the culture must change to enable Scrum. –K. Schwaber, J. Sutherland


”

“

test na inteligencję i siłę charakteru



Scrum pomaga nam ciągle podnosić poprzeczkę. Przedtem nie wiedzieliśmy, że w

ogóle jest jakaś poprzeczka, nie wspominając nawet o jej podnoszeniu.

–Prezes zarządu

”

“



Cenię Scruma za porządek i rytm jaki wprowadza w organizacji. Zamiast drętwych

raportów, polityki i pustych obietnic, mam pewność, że co dwa tygodnie każdy zespół

przygotuje nowe wydanie. –Prezes zarządu ”

“



Używając poprzednich procesów kuśtykaliśmy. Po wprowadzeniu niektórych elementów Scruma

zaczęliśmy kuśtykać nieco szybciej. A teraz musimy zacząć biegać. –Dyrektor dewelopmentu

”

“

dziękuję! Tomek Włodarek [email protected]

@poddrzewem

http://www.linkedin.com/in/wlodarek

http://www.poddrzewem.pl http://www.scrum.org Scrum Guide. Ken Schwaber, Jeff Sutherland, 2011 The New New Product Development Game. Hirotaka Takeuchi, Ikujiro Nonaka, Harvard Business Review, Jan-Feb 1986 Software In 30 Days. Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust. Ken Schwaber, Jeff Sutherland, Wiley 2012

Succeeding with Agile: Software Development Using Scrum. Mike Cohn, Addison–Wesley 2009 Allegro's Journey Into Agility. Jakub Szczepanik, Jacek Wieczorek (http://vimeo.com/album/1977617/video/44331906)


Pytania?


Skalowanie Scruma

Business

Transcript of Skalowanie Scruma