This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Framework within which people can address complex problems and productively and creatively develop products of the highest possible value.
Scrum jest obecny w Polsce. Firmy różnej skali, branż, pochodzeniu kapitału. Offshoring, nearshoring, rodzime. Od kilku lat. Wszędzie. Skąd się wziął? Inicjatywą pracowników 41%*, kierownictwa średniego szczebla 30%*, rzadziej naczelnego kierownictwa 29%*. Jest głównie promowany przez zespoły projektowe 70%*, czasem postrzegany jako wymóg branży 33%*, rzadziej jest to dopust boży: decyzja kierownictwa 26%* czy wymóg klienta 15%*. Czy to przejaw samoorganizacji?
Pomaga. Krótszy czas wprowadzenia produktu na rynek 63%*, lepsza zdolność do absorbowania zmian 86%*, wzrost produktywności 86%*, wzrost jakości produktu 71%*, poprawa komunikacji 93%*, wzrost morale 78%*, spadek ryzyka niepowodzenia projektu 63%*, neutralny wpływ na koszty realizacji projektu. 41%* wskazuje na pełny sukces realizowanych projektów. Sielanka?
Złożone środowisko. Chaotyczne otoczenie. Technologia. Domena. Ludzie. Zmienność. To oznacza brak możliwości precyzyjnego planowania, błędy i czas konieczny do wyciągnięcia wniosków i skorygowania wyników. Empiryzm. W nieprzewidywalnym środowisku pozostaje nam bezustanne powtarzanie cyklu: działanie-kontrola-adaptacja. Ciągłe doskonalenie.
Szybka reakcja na dynamikę otoczenia. Skrócenie czasu podejmowania decyzji. Lepsze rozpoznanie potrzeb, lepsze dopasowanie nakładów do potrzeb. Wzrost motywacji. Synergia.
Osłabienie kontroli, ograniczenie ingerencji kierownictwa. Większa swoboda w zamian za obietnicę zwiększonego zaangażowania, przejęcie inicjatywy i dbałości o rezultaty.
§ Wzajemna kontrola? Tak (100%) § Wpływ na godziny pracy? Tak (89%) § Skład zespołu? Tu gorzej. Rzadko możemy dobierać kolegów
do zespołu (45%), rzadko możemy ich wykluczać (41%) § Czyżby ktoś wciąż planował ilu “zasobów” jest
potrzebnych? § A może autonomia w doborze ról wewnątrz zespołu?
Nieźle, ale zbyt rzadko (63%) § Czy mamy wpływ na długość sprintu? Hmm. Choć często
ustala ją Scrum Master (70%), przynajmniej konsultuje z zespołem (63%), czasem także z Product Ownerem (48%). Zbyt często (33%) robi to za nas kierownictwo.
§ Pracujemy zespołowo? Nie bardzo. Notorycznie zaniedbujemy drugą część Sprint Planningu i przypisujemy historie członkom zespołu już podczas pierwszej części, w dodatku zbyt często prowadzonej przez Scrum Mastera 55%, a zbyt rzadko przez Product Ownera 37%.
§ W efekcie 60% czasu w sprincie pracujemy indywidualnie, a jedynie 19% w parach (pozostałe 21% spędzamy na zebraniach).
§ Tylko połowa respondentów uaktualnia codziennie liczbę godzin pozostałych do zakończenia swoich zadań, w sumie nie mamy o czym ze sobą gadać w trakcie sprintu
§ Czy będzie dziś stand-up? Zaledwie 40% deklaruje codzienność, aż 85% wskazuje ScrumMastera jako osobę prowadzącą.
§ Robimy retrospektywę? Aż 63% ankietowanych przyznaje, że retrospektywy nie odbywają się regularnie.
§ Założeniem procesu empirycznego jest fakt, że przedmiotem podlegającym częstej kontroli jest coś zrozumiałego dla wszystkich zainteresowanych, coś podlegającego wszechstronnej ocenie.
§ Nie abstrakt (dokument, formularz, projekt, procent zaawansowania, procent zgodności z planem czy procesem). Konkret. Dowód.
§ Czy formułujemy cel sprintu? Rzadko. Ktoś w ogóle pamięta, że jest taka scrumowa praktyka?
§ Czy mamy zespołowe, aktywnie wykorzystywane Definition of Done? Strach pytać. Jeśli nawet definicja jest, mało kto wie gdzie i kiedy ktoś do niej ostatnio zaglądał.
§ Czy dostarczamy co sprint? Nie. Bo choć prawie wszyscy deklarują, że generalnie byłoby to możliwe, tylko co czwarty zespół faktycznie to robi. Efekt?
§ Prawie, zasadniczo, właściwie, generalnie, praktycznie, w
90% skończone. Niedorobione. Potrafimy podrasować burndown, potrafimy go zlikwidować, ba potrafimy nawet zlikwidować całą tablicę żeby nie było widać piętrzących się na niej karteczek.
Ograniczanie dostępu do informacji. Brak bezpośredniego kontaktu z klientem lub osobami, które go reprezentują. Brak wglądu w długofalowe plany. (wkrada się kaskadowość) Ograniczanie swobody. Narzucony proces. Długa i zawiła ścieżka decyzyjna. (wkrada się kaskadowość) Ograniczanie interdyscyplinarności. Osoby o różnych kompetencjach zaangażowane w przedsięwzięcie pracują w izolacji od siebie. Potrzebni pośrednicy i koordynatorzy. (wkrada się kaskadowość) Ograniczanie autonomii. Grupa pracownicza a zespół pracowniczy. Rozdzielanie zadań / wymuszanie zobowiązania. Planowanie zasobów. (wkrada się kaskadowość) Pod presją szukamy prostych, gotowych rozwiązań. Wpadamy w koleiny. Czytamy “framework” myślimy “proces”.
§ Odwołanie do procesu/planu. Zabijamy kreatywność. W najlepszym przypadku otrzymujemy perfekcyjnie wykonaną przeciętność.
§ Przyzwyczajenie. Zawsze tak robiliśmy. Postępuję tak jak moi przełożeni. Taką mamy kulturę pracy.
§ Pułapka odpowiedzialności. Jestem za to odpowiedzialny, powierzono mi te obowiązki. Muszę się upewnić, że wszystko będzie wykonane prawidłowo.
§ Po prostu powiem im jak/kto/kiedy ma to zrobić. Mikro-zarządzanie jest (wydaje się być?) łatwiejsze niż przywództwo i zarządzanie poprzez cel. Za to jest bardziej angażujące i daje znacznie gorsze rezultaty długofalowe.
§ Arogancja i/lub ignorancja. Tymi przypadkami nie chcę się zajmować…
Paradoksalnie, dopiero kiedy jest naprawdę tragicznie postępujemy właściwie – zbieramy zespół i odwołując się do nadrzędnego celu prosimy o inicjatywę, pomoc i zaangażowanie, deklarując pełne wsparcie.
Są problemy. Współpraca z klientem 71%, opór przed zmianą 60%, brak doświadczenia 52%, brak wsparcia kierownictwa 25% Nie zawsze jest jasne czy źródłem problemów jest brak woli przyznania autonomii, czy brak woli podjęcia odpowiedzialności z nią związanej
Zwykle sposób myślenia muszą zmienić obie strony (czasem więcej niż dwie)
u podstaw biznesowej potrzeby gwarancji i pewności leży potrzeba osiągania rezultatów zaspokajając potrzebę osiągania rezultatów, zaspokajamy również potrzebę pewności możemy zatem skupić się na planowaniu strategicznym, planowaniu pod kątem systematycznie osiąganej wartości a nie jedynie planowaniu związanym z utrzymywaniem w ryzach kosztów i ryzyka przestajemy myśleć o planowaniu zadań, zaczynamy myśleć w kategoriach produktu i funkcjonalności
[email protected] http://www.poddrzewem.pl http://www.linkedin.com/in/wlodarek On our loss of wisdom, Barry Schwartz, TED talk http://www.ted.com/talks/barry_schwartz_on_our_loss_of_wisdom.html
The child-driven education, Sugata Mitra, TED talk http://www.ted.com/talks/sugata_mitra_the_child_driven_education.html
Scrum Guide. K.Schwaber, J.Sutherland Scrum w Polsce. Raport z badań. red. dr M.Ćwiklicki, UEK, 2009
Metodyka Scrum w Polsce w świetle badań. M.Ćwiklicki, T.Włodarek, kwartalnik Nauka i gospodarka, 2010
Agile Software Development with Scrum. K.Schwaber, M.Beedle