W tym odcinku razem z Magdą Firlit asdadbierzemy na warsztat Cel Produktu (Product Goal). Samo mięso – 6 sposobów jak Cel Produktu stworzyć.

asdasdasd

Jak wiadomo esencją podejścia empirycznego takiego, jak Scrum, są pętle zwrotne z rzeczywistością, które pozwalają nam potwierdzać lub obalać hipotezy biznesowe, jak i techniczne. UX i Scrum jako jedność zwiększają ilość pętli zwrotnych. Dają więcej okazji, aby zweryfikować, czy robimy właściwe rzeczy.

Opowiem Wam o różnych sposobach jak połączyć UX i Scrum. Przedstawię tak zwany UX+Scrum Maturity Model.

W ostatnim odcinku powiedziałem, czym tak naprawdę jest User Experience w skrócie UX, jak często jest to źle rozumiane pojęcie oraz dlaczego UX to fundament zwinności. Dzisiaj powiemy sobie jak „pożenić” Scruma z UXem.

Zanim przejdziemy do meritum, chciałbym najpierw powiedzieć, jakie problemy rozwiązujemy łącząc UX i Scrum. Zacznijmy od „Dlaczego?”. Innymi słowy, jeżeli połączymy UX i te problemy dalej występują – zastanowiłbym się czy, aby na pewno zrobiliśmy to dobrze?

1 Problem Scrum i UX

U moich klientów czasami widzę, że UX jest traktowany po macoszemu. Na poziomie deklaracji, mówi się, że jest ważny jednak w praktyce główny nacisk jest kładziony na pracę inżynieryjne i rozwiązania techniczne. Kwestie takie jak design produktu, czy spełnianie potrzeb przyszłych userów, wizja biznesowa czy w ogóle zasadność produktu są na drugim planie. Ważne że pracujemy w cool technologii i rozwiązujemy trudne inżynieryjne problemy, „Wszystko byłoby w porządku gdyby nie Ci userzy!”.

2 Problem Scrum i UX

Drugi problem, który często dostrzegam to powstanie dwóch oddzielnych silosów: UX i delivery. No i klasyka w przypadku jakichkolwiek silosów to większe prawdopodobieństwo konfliktów – UXowcy i Development się „żrą”. To co prawie zawsze występuje to skupienie każdej ze stron na swojej części, brak synergicznej współpracy.

Często słyszę od UXowców:

• „Każdy nasz pomysł jest blokowany”,
• „Ci developerzy nic nie rozumieją powinni siedzieć cicho i po prostu robić to co im każemy”,

Developerzy natomiast:

• „Pomysły tych UXowców są jakieś z kosmosu, kompletnie oderwane od rzeczywistości, w ogóle nie myślą o tym, że ktoś będzie musiał to zaimplementować”
  „• Znowu Ci UXowcy coś mieszają, Po co zmieniać coś co już działa? Lepiej robić nowe feature’y.”

3 Problem Scrum i UX

To długie Customer Lead Time’y – czyli czasy od momentu powstania pomysłu do momentu wdrożenia go na produkcję. Wydłużają się przez to pętle zwrotne i występuje spory koszt opóźnienia – każda sekunda kiedy user nie używa nowego feature to strata.

Generalnie esencją podejścia empirycznego takiego jak Scrum są pętle zwrotne z rzeczywistością. Które pozwalają nam potwierdzać lub obalać hipotezy biznesowe i również techniczne. Co niesamowicie ważne dodanie UX do Scruma zwiększa ilość pętli zwrotnych. Daje więcej okazji, aby walidować czy robimy właściwe rzeczy… i tutaj wbrew pozorom nie-taka-oczywista kwestia. Walidacja może odbywać się na różnych poziomach wiarygodności.

Przed jakąkolwiek walidacją jesteśmy w kompletnej – błogiej ignorancji. Kolejne kroki przedstawione na diagramie, pozwalają nam stopniowo coraz twardziej stąpać po ziemi, tak jakby przebudzać się.

Ważne!

Dużo walidacji można wykonać zanim powstanie jakikolwiek kod. Można robić wywiady z użytkownikami, prototypy papierowe albo w formie makiet, nawet można zastosować tak zwany „Wizard of Oz”. Polega to na tym, że user myśli, że używa ostatecznego produktu, ale tak naprawdę istnieje tylko wydmuszka za którą stoi człowiek. Przykładowo jak powstawała Alexa to na etapie „Wizard of Oz” userzy myśleli, że rozmawiają ze sztuczną inteligencją, a tak naprawdę rozmawiali z Mariolą z sąsiedniego pokoju która jest obdarzona jak najbardziej prawdziwą inteligencją.

Co bardzo ważne! Ta walidacja jest strasznie tania w stosunku do tworzenia oprogramowania. Kolejne etapy takie jak feedback userów oraz interesariuszy z użycia kolejnego inkrementu. Wydanie BETY, czy Release na rynek. Są już mega kosztowne. Pozwalają nam na dużo skuteczniejszą walidację, tylko może to być twardy kontakt z rzeczywistością. Możemy się połapać, że robimy niewłaściwy produkt, dopiero w momencie, gdy wydamy dużo pieniędzy.

Co równie ważne, nawet po releasie nie mamy ostatecznej walidacji, jeżeli nie zrobimy odpowiednich badań. To jest dopiero ostateczna walidacja.

Połączenie Scruma i UX może być na różnych poziomach dojrzałości – im wyższy poziom dojrzałości tym współpraca UXa i delivery jest lepsza. Powiedzmy, że Wam przedstawię teraz, taki ScrumUX Maturity Model.

#0 – Scrum bez UX

Poziom zero to w zasadzie sam Scrum bez UX. W tym podejściu UX nie istnieje, albo jest robiony na kolanie. Tutaj pół żartem pół serio mogę powiedzieć, że nie ma problemów komunikacyjnych pomiędzy UX i delivery, bo jest… tylko delivery. Ale już mówiąc bardziej poważnie należy zauważyć, że walidacja zaczyna się od działającego kodu. I nie ma najprawdopodobniej ostatecznej walidacji w formie badań produktu na rynku.

#1 UX Scrum Fall

Taki pierwszy poziom połączenia to UX Scrum Fall który nazywam czasami Big Bang UX. W tym przypadku UX poprzedza pracę developmentu. Zanim powstanie jakikolwiek kod już zrobiono wszystkie badania potrzeb userów i mamy gotowy Design aplikacji. Często są to makiety, które mają być zaimplementowane przez deweloperów z dokładnością, co do piksela. Najczęściej UX jest wykonany przez zewnętrzne firmy albo oddzielny dział.

Jak się łatwo domyśleć jest to prosty przepis na stworzenie podziałów „my VS oni” – tworzenie kultury „to ich wina!”. Dodatkowo zanim powstanie coś co może użyć user upłynie strasznie dużo czasu.

To co jest chyba jednak najgorsze, to fakt, że nie ma tutaj pętli zwrotnych discovery – delivery. Nie ma takiej możliwości, aby deweloperzy wzięli udział w decyzjach designerskich i zasugerować, że zaproponowane rozwiązanie jest bardzo trudne w realizacji. Przykładowo taki developer Androida nie ma okazji powiedzieć, że „takie rozwiązanie to 5 dni pracy, ale w zasadzie możemy to zrobić z użyciem gotowej biblioteki w 30 minut, ale musielibyśmy lekko zmienić wygląd”. Jakby obie strony do tego siadły to pewnie znaleźliby optymalne rozwiązanie.

#2 Sprinty Naprzemienne

Kolejny wyższy poziom połączenia UX i delivery to tak zwane „Sprinty naprzemienne” po angielsku Stagerred Sprints. W tym podejściu UX pracuje „sprint wstecz” w stosunku do delivery. No cóż… jest to ogromny postęp w stosunku do UX Scrum Falla. Wszystkie poprzednie problemy ulegają zmniejszeniu. Pojawia się współpraca delivery i discovery, silosy są mniej wyraźne i niewątpliwie Customer Lead Time zmniejsza się.

Desiree Sy i Lynn Miller czyli autorki tego podejścia zakładały, że UX i Developerzy będą pracowali jako jeden zespół. Jednak praktyka pokazuje inaczej. UX i Developerzy pracujący w Sprintach Naprzemiennych najczęściej tworzą dwa oddzielne zespoły, skupione po prostu na czymś innym.  Postęp jest, ale może być jeszcze lepiej.

#3 Discovery + Delivery = 1 Scrum Team

Najwyższy poziom maturity połączenia Scruma i UXa to jeden zespół Scrumowy składający się zarówno z delivery i discovery. W nomenklaturze scrumowej UXowcy stają się Developerami.

Takie połączenie może przybrać, różne formy. W końcu Scrum to framework dający duży poziom swobody. Najlepiej będzie chyba jak po prostu podam przykład.

Wzorcowy Przykład UX + Scrum

Kilku członków zespołu ma wysokie zdolności UX. Jednak jest powszechną praktyką, że w swoje niecne UXowe działania wciągają resztę Zespołu Scrumowego. Chociaż to właśnie UX experci najczęściej facylitują czyli prowadzą wszelkiego rodzaju UXowe warsztaty w których uczestniczy cały zespół. Część prac UX zawiera się w Product Backlog Refinement czyli czynności która sprawią, że Product Backlog itemy (PBi’e) można zaciągnąć na Sprint Planningu.

W tym przypadku, to wstępny wywiad z klientem i przetestowanie na potencjalnych użytkownikach prototypów, obojętnie – papierowych albo jakichś wireframe’ów. Jak wspominałem wcześniej UX experci zachęcają do uczestnictwa cały Scrum Team. W ramach Sprint Planningu następuje wspólne ostateczne doprecyzowanie designu.

Istnieje jeden Product Backlog, w ramach każdego PBi’a są do wykonania działania zarówno discovery jak i delivery. Tak więc praca UX jest częścią Definition of Done.

Sprinty mają długość dwóch tygodni. W każdy pierwszy czwartek Sprintu odbywają się wywiady i testy UX prototypów z potencjalnymi userami. Biorą w tych spotkaniach udział też niektórzy programiści i testerzy.

W każdy drugi wtorek, odbywa się walidacja gotowych feature’ów (z poprzednich Sprintów) na userach. Zamyka się usera w pokoju i cały zespół obserwuje jak user używa aplikacji. Mają podgląd na wszystkie jego akcje. Na tej podstawie powstają pomysły co można zmienić w aplikacji. Zostają stworzone nowe PBi’e i Product Owner określa ich kolejność w Product Backlogu.

W każdej chwili programiści mogą poprosić UX expertów o pomoc, gdy nie są pewni jak coś zrobić. Natomiast w tak zwanym międzyczasie UXowcy mierzą istotne dla produktu wartości. Np. stosują badania kohortowe czy określają retencje userów oraz robią A/B testy na userach.

W zależności od Sprintu stosunek czynności UXowych i delivery różni się, zdarzają się Sprinty, że większość czasu jest poświęcane na warsztaty UXowe z klientami i userami, są też takie, gdzie główny nacisk jest położony na pracę delivery.

Tak jak wspominałem wcześniej, to mój przykład i implementacja wspólnego UX i Scruma może wyglądać inaczej.

Pamiętajcie!

Wejście na wyższy poziom dojrzałości to często gigantyczna zmiana kulturowa. Proponuję tutaj podejście ewolucyjne. Jeżeli nigdy nie pracowaliście z UXem, nie zaczynajcie stosować wszystkich praktyk z przykładu od razu. Ze spokojem i po kolei. Jak to mawiał Pan Miyagi: „Najpierw naucz się stać, a potem latać”.

Druga sprawa bardzo często przed skutecznym użyciem moich klientów powstrzymuje pycha. Skuteczne stosowanie UX wymaga ogromnej pokory. Trzeba jasno powiedzieć na temat potrzeb userów i rynku: „Wiem, że nic nie wiem” przynajmniej do czasu, aż nie zrobi się odpowiednich badań.

To co może skutecznie powstrzymać sprawne działania UX to coś co nazywam syndromem myślenia projektowego. Czyli skupienie się na sukcesie projektu, z pominięciem sukcesu produktu. Jak kogoś interesuje tylko coraz wyższe velocity na koniec Sprintu to UX będzie tylko przeszkadzał. Po co weryfikować? Lepiej w tym czasie tworzyć więcej feature’ów!

Tym optymistycznym akcentem kończę

Jeżeli chcesz, aby Twój produkt odniósł sukces, koniecznie zadbaj o UX. Bez tego nie wygrasz z konkurencją!

Moje doświadczenie mi podpowiada, że jako branża IT mamy kilka gigantycznych problemów.

UX Problem 1

Powstaje wiele produktów za ogromne pieniądze które nie mają sensu. Nie realizują niczyich potrzeb nie rozwiązują niczyich problemów. W związku z tym nikt nie chce ich używać. Jak to mawiał klasyk:”Nie ma nic gorszego niż świetnie zrobiona niewłaściwa robota”

UX Problem 2

Powstają produkty które rozwiązują właściwe problemy w niewłaściwy sposób. Rozwiązania w nich zawarte są błędne albo najzwyczajniej w świecie są mega trudne w użyciu.

UX Problem 3

Powstają produkty które rozwiązują właściwe problemy we właściwy sposób ale nie są “sexy” w oczach userów. Z jakichś powodów userzy nie czują przyjemności z ich użycia

Wszystkie te 3 problemy adresuje tak zwany User Experience. Chociaż muszę powiedzieć, że jest to często mylone pojęcie. Wiele osób słysząc UX czyli User Experience ma na myśli, User Interface czyli interface użytkownika, a to tylko część prawdy! Projektowanie UI zawiera się w UX, ale UX to pojęcie o wiele, wiele szersze.

User Experience to postrzeganie przez użytkownika oraz reagowanie użytkownika na produkt, system albo usługę. Zawiera się w tym użyteczność, ale UX to również, albo przede wszystkim, emocje i nastawienie danej osoby do korzystania z określonego produktu, systemu lub usługi.

Jak już pojawiły się tutaj emocje to sami widzicie, że jest to mega trudna dziedzina. To co budzi pozytywne emocje jednego usera może się bardzo nie spodobać innemu. No i jak to z emocjami – bardzo często zmieniają się w czasie. Ktoś może się znudzić produktem, ktoś może się zdenerwować na produkt bo nie rozumie jak go użyć.

Aby tworzyć produkty spełniające potrzeby oraz oczekiwania userów. W ramach UXa wykonuje się wiele różnych działań!

#1 Badania User Experience (UX)

Nigdy absolutnie nigdy nie zakładajcie, że wiecie coś o potrzebach swoich userów dopóki tego nie potwierdzicie. Możecie się też bardzo zdziwić jak userzy używają Waszej aplikacji. Dlatego właśnie, w ramach UX wykonuje się liczne badania na userach. Tacy badacze czyli UX Researcherzy wykonują badania deklaratywne np. wywiady i ankiety – dowiadują się co sądzą userzy, ale również badania behavioralne, czyli dotyczące zachowań userów. Przykładowo obserwują jak często poszczególne części aplikacji są używane – tworzą tak zwane Heat Mapy. Mogą śledzić jak user sobie radzi z poszczególnymi funkcjonalnościami. Często też stosują A/B testy. A/B test to eksperyment na userach którego nie są świadomi. Polega na stworzeniu np. feature’a czy strony w dwóch wariantach. Część userów zobaczy feature/stronę A natomiast część userów zobaczy feature/stronę B. Wtedy można porównać na podstawie badania ich zachowań i określić co jest lepsze
np. gdzie dłużej zostają na stronie czy gdzie więcej klikają w reklamy.

Pamiętajcie użytkownicy mówią jedno, robią drugie a kupują trzecie. Nie można im wierzyć na słowo. Aby zbudować właściwy produkt trzeba zbadać jak się zachowują!

Badania UX często dotykają poziomu strategii biznesowej i wizji biznesowej. Pozwalają na wczesną walidacja wielu biznesowych hipotez. Dobry badacz może zaoszczędzić nam ogromną ilość pieniędzy, Scrum weryfikuje hipotezy biznesowe przez działający soft, natomiast taki UXowiec może pokazać, że produkt nie ma sensu zanim napiszemy choćby jedną linię kodu, robiąc odpowiednie badania rynku czy naszej przyszłej konkurencji!

#2 Design Produktu

Kolejny ważny obszar to szeroko rozumiany “Design produktu” na poziomie wizualnym, rozmieszczenia informacji oraz interakcji z userem. Chodzi tutaj o projektowanie tego co user otrzymuje jako produkt, czyli w przypadku strony internetowej jest dokładnie zaprojektowane co user widzi i klika. Nie chodzi tylko o to aby produkt wyglądał estetycznie – to tylko mała część sukcesu. Również trzeba zapewnić, aby user łatwo znajdował to co dla niego ważne i żeby mógł wykonać łatwo to co powinien np. łatwo mógł kupić towar na Allegro

Często celem designu UX jest wzbudzenie w użytkowniku pożądanych emocji. Aby przywiązać go emocjonalnie do produktu lub usługi
albo, aby emocje pomogły mu podjąć decyzję odnośnie pożądanej przez nas akcji.

Design to prawdziwa gra strategiczna. Kiedyś zobaczyłem, ekran strony do kupowania biletów lotniczych. Ttak sobie mówię: „Słabo zaprojektowana ta strona. Nie da się wszystkiego łatwo załatwić trochę trzeba wszystkiego szukać, nie na tyle aby mnie to zniechęciło, ale jednak marnuje się czas usera!”. Dopiero później UX Designer wytłumaczył mi, że od kiedy wprowadzili obecny układ to ludzie klikają 2 razy częściej w reklamy! No, Nieźle!

#3 Usability Testing

Kolejnym obszarem jest weryfikacja użyteczności produktu który tworzymy. To określenie czy to co stworzyliśmy jest rzeczywiście używane tak jak byśmy sobie tego życzyli. To tak zwane “Usability testing”. Warto przetestować jak nasz produkt jest używany przez poszczególne grupy userów.

Pamiętaj, że jak jedna osoba ma problem z Twoją aplikacją, to ona ma problem. Jak dwie osoby mają problem z Twoją aplikacją to Ty masz problem! Czasami może się okazać, że warto dokonać kilku zmian. Wiecie tak inspekcja i adaptacja Usability testing to genialna pętla zwrotna!

#4 Prototypowanie

Ten obszar bardzo mocno się łączy z poprzednimi, jednak postanowiłem go wydzielić, dlatego, że jest taki cenny. Chodzi o prototypowanie produktu. Oczywiście są różne metody prototypowania. Taki UXowiec jest czasami w stanie stworzyć prototyp z papieru i zdobyć feedback zanim w ogóle zaczniemy prace deweloperskie! Bardzo to zwiększa prawdopodobieństwo, że zrobimy właściwy produkt. No i umówmy się to jest naprawdę cool!

Jak sami widzicie temat UX jest dosyć szeroki. Zazwyczaj różne osoby zajmują się różnymi obszarami. Czasami w każdym z tych obszarów są dodatkowe podspecjalizacje. Dokonałem w tym poście dużych uproszczeń. Jednak pamiętajcie o jednym! Jak ktoś Wam powie, że zajmuje się UXem w aplikacji to nie mówcie czegoś w stylu: „A to Ty jesteś grafikiem w tym projekcie.” Ja tak kiedyś powiedziałem przez przypadek jak się okazało do UX Researchera. Nie odzywał się do mnie dwa dni!

Szeroko rozumiany UX jest bardzo wartościowy przy tworzeniu produktów. Warto, aby był traktowany naprawdę poważnie. Weźmy np. takiego Apple’a. To jest firma gdzie UX to część ich DNA. Jest dla nich na pierwszym miejscu. Trzeba przyznać, że daje to świetne efekty.Rok temu zamieniłem iPhone’a na najnowszego Huaweya, który jest pod każdym możliwym technicznym względem, o dwie generacje lepszy. Jednak muszę przyznać, że po prostu go nie lubię. Tęsknię za moim starym iPhonem. Powiedzcie mi jakie tęgie głowy musiały tworzyć iPhone, że ludzie mają emocje w stosunku do swoich telefonów! To jest niesamowite!

W najbliższym czasie powstanie odcinek o tym jak połączyć UX czyli User Experience ze Scrumem. O tym jak pracę wszelkiej maści UXowców połączyć z pracą Developerów.

Na dzisiaj to jednak wszystko

Powiemy Wam o trzech rzeczach. Czym jest CEL PRODUKTU?

Wyjaśnimy. Jaki problem rozwiązuje czyli jaką wartość wnosi?

Chociaż Magda Firlit jest weganką, na koniec będzie samo mięso. Podamy 6 przykładowych sposobów na stworzenie Celu Produktu.

Polecam kanał Magdy Firlit: https://www.youtube.com/c/MagdalenaFi…​

Niektórzy Product Ownerzy tworzyli sobie i używali Celu Produktu od bardzo dawna. Jednak Dopiero w Scrum Guidzie z 2020 roku Product Goal stał się formalnie częścią Scruma. Opisuje przyszły stan produktu, który może służyć jako cel, względem którego Zespół Scrumowy może planować. Cel produktowy znajduje się w Backlogu produktu. W Scrum Guidzie z 2020 roku każdy artefakt ma swoje zobowiązanie: Product Goal jest zobowiązaniem wobec Product Backloga.

Warto sobie powiedzieć w zasadzie, dlaczego warto stawiać sobie produktowe cele i formalnie je definiować? Generalnie wzmacnia to mindset Produktowy a nie Projektowy. Czyli skupia nas na tym, aby dostarczać więcej wartości.

Warto też spojrzeć na cebulę planistyczną. Wcześniej Scrum pokrywał, obszary do Planowania Releasu włącznie. Organizacje zazwyczaj mają jakąś swoją wizję oraz strategię. Natomiast bardzo często powstawała tak zwana próżnia produktowa. Wizja produktu oraz strategia produktu były zaniedbane. Product Goal ma za zadanie wypełnić tą pustkę.

Warto chyba dodać słowa Chrisa Lukassena czyli Produktowego Samuraja, który jest niczym japoński poeta:
„Myśl o CELACH PRODUKTU, jak o kamieniach po których stąpasz w rzece złożoności”. Trzeba przyznać to było głębokie!

Mięso!

Przechodząc do konkretów. Przedstawimy Wam 6 sposobów na stworzenie Celów Produktu. Pamiętajcie to 6 spośród nieskończonej liczby sposobów!

1. Impact Mapping
2. EVO – Evolutionary Project Management
3. Evidence Based Management
4. Analiza Kohortowa
5. Goal Oriented Road Map
6. Metryki Pirackie – AARRR

Skalowanie Scruma dokładnie oznacza, zwiększenie liczby zespołów Scrumowych, współpracujących przy wytwarzaniu jednego konkretnego produktu. Skalowanie powinno dać więcej wykonanej pracy w jednostce czasu, nazwijmy to wyższą przepustowością albo wyższym velocity. Jest to koncepcja bardzo różna od skalowania Metody Kanban, ale o tym chyba powstanie chyba oddzielny odcinek

#1 Skalowanie Scruma to Ostateczność

Bardzo ważny i równie oczywisty fakt to, że skalowanie Scruma to bardzo kosztowna sprawa – więcej ludzi równa się więcej pieniędzy. Równie ważna kwestia, ale już mnie oczywista, to fakt, że Scrum w większej skali staje się coraz mniej efektywny. Skalowanie powoduje, że dowozimy średnio coraz mniej na jednego pracownika. 20 zsynchronizowanych zespołów nie dowiezie 20 razy tyle co jeden zespół. W skrajnych przypadkach może się okazać, że 20 zespołów dowozi mniej niż np. 15 zespołów!

Dodatkowo czas dostarczania pojedynczego zadania najprawdopodobniej się wydłuży! A przewidywalność postępu prac prawie na pewno spadnie. Wraz ze skalą powstaje coraz większy tłuszczyk procesowy czyli nakład na proces. Powiedzmy, że od skalowania trzeba zapłacić podatek Wynika to głównie z synchronizacji coraz większej liczby osób. Przy skalowaniu jest też ryzyko, że przy tym samym velocity, będzie mniej wartości biznesowej. Łatwiej stracić wizję produktu z oczu.

Decydujcie się na skalowanie gdy już nie widzicie, absolutnie żadnych innych sposobów optymalizacji efektywności. Musicie mieć naprawdę dobre uzasadnienie biznesowe.

Zapraszam na odcinek o “5 Focusing Steps” gdzie skalowanie było by dopiero 4 krokiem:#2 5 Focusing Steps – Teoria Ograniczeń w Praktyce

#2 Jeżeli chcesz skalować Scruma musisz mieć Scruma

Jeżeli jeszcze Was nie zniechęciłem do skalowania scruma to pora na drugą zasadę skalowania. Jeżeli nie masz Scruma dobrze zaimplementowanego to proponuję się najpierw zatrzymać i zrobić porządnego Scruma którego później będzie można rozwijać w skali. Dlaczego to takie ważne? Moje doświadczenie, mówi, że wszelkiego rodzaju Scrum Buty są najczęściej ułomne i powodują problemy. Wszystkie nieudolności procesowe które objawiają się w małej skali w dużej wzrosną wykładniczo, mówiąc bardziej bezpośrednio: “Będzie jeszcze większy burdel”.

#3 Skalowany Scrum to dalej w 100% Scrum

Skalowanie Scruma to nie jest przejście w coś innego niż Scrum. Pamiętajcie Skalowany Scrum to dalej w 100% Scrum! Wszystkie zasady ze Scrum Guida dalej obowiązują. Ja jestem z tym zupełnie OK, że ktoś nie chce pracować w Scrumie – są inne narzędzia. Jeżeli jednak się na niego decydujemy, to warto robić go porządnie Gmeranie przy definicji frameworka, zwłaszcza w skali to moim zdaniem bardzo ryzykowny pomysł – nie warto.

#4 Skracaj pętle zwrotne

Jak wspominałem większa skala to więcej problemów które wystąpią. Musimy o nich jak najszybciej się dowiadywać! Niezbędny jest tutaj empiryzm czyli system nerwowy który jak najszybciej pozwoli nam te problem zauważyć. Skracanie pętli zwrotnych oznacza np. częstsza synchronizacja pomiędzy zespołami, czy chociażby częstsza integracja ich pracy. Jednak najlepiej jakby udało się częściej robić releasy na produkcję. Niestety często widzę tendencję odwrotną, nie dość, że nie ma tendencji do przyspieszania releasów to nawet nie kończy się Sprintów z Incrementami które są gruntownie przetestowane, zintegrowane i używalne – czyli takimi które nie nadają się do releasu. To proszenie się o poważne kłopoty.

#5 Jeden Produkt jeden Produkt Owner

Struktury z wieloma Product Ownerami z mojego doświadczenia zawsze kończą się źle. Mówiłem o tym więcej w odcinku:

• #32 6 Product Ownerów Zniszczy Produkt
• #14 Tragedia w Czterech Słowach: Scrum Master Zespołu API

#6 Uwaga na przeciążenie Product Ownera

Jak już wspominałem Product Owner może być tylko jeden i to on/ona ma ostatnie słowo odnośnie produktu. Jednak może mieć do pomocy cały sztab ludzi którym może delegować swoją pracę. Idealnie też przekazywać jak najwięcej obowiązków Developerom.

#7 Mierz Efektywność

Warto wiedzieć jak wraz ze skalą zmienia się efektywność prac, najlepiej pokazać to na liczbach. Bardzo fajnie mogą się tutaj przydać metryki Evidence Based Management opisane w odcinku #27 Evidence Based Management – Zarządzanie w Oparciu o Dowody.

#8 Rośnij Ewolucyjnie

Jeżeli to możliwe. Wraz ze wzrostem pojawia się dużo nowych problemów. Duży, nagły wzrost to dużo nowych problemów do rozwiązania równocześnie.

#9 Zastosuj Gotowy Framework

Przy więcej niż dwóch zespołach warto się zastanowić czy nie zastosować jakiegoś gotowego frameworka do stosowania Scruma, np. Nexusa, Less’a and Scrum at Scale. Tak tylko dodam, że bardzo popularny SAFe to nie jest skalowany Scrum.

#10 Zwiększaj Interdyscyplinarność Zespołów

Byłoby super jakby udało się dojść do feature teamów – czyli zespołów gdzie każdy jest w stanie tworzyć releasowalny inkrement bez pomocy innych zespołów. Im mniej zależności między zespołami tym lepiej.
Dużo więcej na ten temat mówię w odcinku #15 Od Waterfalla do Developerów renesansu – 6 Poziomów Interdyscyplinarności

#11 Unikaj Rozproszonych Zespołów

Rozproszone zespoły to dodatkowy poziom skomplikowania oraz dodatkowy narzut na komunikację. Wiadomo jak mus to mus – ale warto mieć na uwadze redukcję różnych stref czasowe i lokalizacji. Idealnie jakby wszyscy Developerzy, Scrum Masterzy i Product Owner pracowali w jednym biurze.

Na dzisiaj to tyle

Bardzo lubię powiedzienie, że w święta Święty Mikołaj może mieć do pomocy ogromną liczbę elfów. Jednak jest tylko jeden Święty Mikołaj na całe święta. Podobnie sytuacja ma się z Product Ownerem. Product Owner może mieć do pomocy sztab ludzi. Jednak może być tylko jeden Product Owner. Kiedy zaczynam pracę z nowym klientem czasami słyszę od niego: „My nie stosujemy się do Scruma książkowo, tylko podchodzimy do niego tak, wiesz, bardziej praktycznie”

Zawsze w takich przypadkach bardzo budzi moją ciekawość co tym razem klient postanowił “usprawnić”, zmieniając zasady Scruma. Jakiś czas temu jeden z moich klientów pracujących w Scrumie. Nie mógł dojść do tego dlaczego mają tyle problemów z produktem, procesem i konfliktami. Sytuacja stała się dla mnie jasna dosyć szybko, jak tylko powiedziano mi, że aby uprościć strukturę. Z zespołem deweloperskim pracuje bezpośrednio 6 Product Ownerów. I każdy z nich reprezentuje interesy swojego działu!

Pracują nad jednym produktem. I na jednym Product Backlogu. Bez owijania w bawełnę i bez przesady: uważam, że zawsze kończy się to tragicznie. Kompletny armagedon! W tym odcinku powiem jakie problemy spotkałem we wspomnianym case’ie.  Niestety są one dosyć charakterystyczne przy wielu product ownerach.

Dzisiaj odpowiemy sobie na zasadnicze pytanie, czym się różni mindset PROJEKTOWY od mindsetu PRODUKTOWEGO (Produkt vs Projekt). Projekt czy produkt? Oto jest pytanie!

Projekt

Projekt jest to tymczasowe przedsięwzięcie! Jego rezultatem jest unikatowy produkt, usługa lub rezultat. Tymczasowość to nic innego jak początek i koniec Ale żeby nie było różowo mamy też trójkąt ograniczeń czas, budżet i zakres! Mamy projekty technologiczne, infrastrukturalne, budowlane, finansowe, medyczne, organizacyjne, typowo biznesowe. Projektem jest przygotowanie dzisiejszego odcinka, a produkt właśnie czytacie!

Produkt

Produkt to coś co spełnia potrzeby i oczekiwania użytkowników Coś co dostarcza im wartość Mamy produkty fizyczne jak: krzesła, samochody czy kiełbasy. Mamy też produkty cyfrowe, takie jak: Youtube, Power Point czy Nasza Klasa.

Usługa też może być produktem. Produktami które ja dostarczam na rynek są szkolenia ze Scruma i Kanbana, jak również moje usługi konsultacyjne.

Project Manager, Product Manager i Product Owner

Skoro już wiemy przynajmniej w teorii czym się różni projekt od produktu to pojawia się pytanie o PROJECT Managera oraz PRODUCT Managera albo PRODUCT Ownera. Każda z tych ról ponosi inną odpowiedzialność i robi inną robotę. Project Manager odpowiada za sukces projektu, czyli umowne dowiezienie produktu czy usługi. Natomiast Produkt Manager oraz Product Owner odpowiada za permanentny sukces produktu oraz za maksymalizację wartości produktu, czyli za jego sukces na rynku. Dlatego interesy obu tych grup mogą być ze sobą spójne, ale mogą się także antagonizować!

Kiedyś na moim szkoleniu pracownicy jednego z ministerstw nie potrafili zrozumieć jaka jest różnica pomiędzy Project Managerem I Product Ownerem. Powiedziałem im wtedy, że Project Manager nie może spać po nocach bo Nie uda mu się zrealizować zakresu, w określonym czasie i budżecie. Natomiast Product Owner nie może spać po nocach bo Pani Krysia użytkowniczka, nie jest w stanie w krótkim czasie za pomocą aplikacji zrealizować swoich potrzeb.

Samo myślenie projektowe nie jest niczym złym, spójrzmy na Scruma – każdy Sprint możemy traktować jako krótki projekt. Jednak jeżeli ktoś zaczyna myśleć tylko o projekcie a zapomina o produkcie najprawdopodobniej nic wartościowego z tego nie powstanie. Coś na zasadzie “operacja się udała, pacjent zmarł”. Dowieźliśmy na czas, w zakresie i budżecie (sukces!), tylko mamy nikomu niepotrzebny produkt.

Przytoczę teraz kilka antywzorców projektu bez produktu!

#1 Fabryka Features

Na pierwszy ogień weźmy Scruma. Moim ulubionym antywzorcem jest mierzenie prędkości zespołu, czyli velocity i nie zwracanie uwagi na wartość jaką dowozimy. Ten antywzorzec nazywam: „Fabryką Ficzersów”, bez składu i ładu, bez wizji, bez celu i maksymalizacji wartości produktu, ale za to w niezłym tempie. W tym wypadku więcej nie znaczy lepiej!

#2 Zakres wyryty w kamieniu

Kolejnym antywzorcem który często widzę jest sztywne trzymanie się ustalonego początkowo zakresu. Nawet jeżeli widać, że rzeczywistość się mocno zmieniła i że potrzeby które ma realizować produkt uległy zmianie. Pomimo tego, że widzimy, że to co robimy jest średnio sensowne, dokończymy bo tak jest w harmonogramie Kiedyś jednemu PMowi powiedziałem, że zaproponowane zmiany są dobre dla produktu, odpowiedział: Może i są dobre dla produktu, ale nie są dobre dla harmonogramu!

#3 Predykcja zamiast empiryzmu

To kolejny antywzorzec. Polega na tym, że ustalamy z góry bardzo długi horyzont czasowy. Może minąć nawet  2 lata prac przed pierwszym wdrożeniem. W tym czasie nie mamy w ogóle żadnego feedbacku biznesowego i technicznego. Najczęściej powstaje produkt który dostarczył by ogromną wartość, gdyby powstał 2 lata temu. Niestety po 2 latach użytkownicy mają już inne potrzeby, rynek się zmienił, 2 lata to dużo czasu.

#4 „Klepnęli nam to niech się martwią”

Kiedyś sprzątałem w projekcie, którego efektem miał być produkt, aplikacja dla footbalistów amerykańskich Osateczny klient na końcu mówi, że przecież wykonana aplikacja jest niezgodna z zasadami footbalu amerykańskiego. Na to PM z rozbrajającą szczerością, „Przecież nie jest napisane w kontrakcie, że ma być zgodna”. To co powstało miała zerową wartość biznesową. Tego typu podejście bardzo często widać również w zamówieniach publicznych. To zabawne dopóki nie uświadomimy sobie, że to jest finansowane z naszych podatków.

#5 Sztywne Procedury Organizacyjne

Najgorsze co może spotkać lidera zmiany czyli człowieka czynu, to procedury organizacyjne. Deming podobno mawiał, że: „Zły system zawsze pokona dobrego człowieka Nawet największego wizjonera na ziemię sprowadza mój ulubiony dowód audytowy i zapis w procedurze! Umówmy się procedury nie są złe, standaryzują procesy, pomagają podjąć następne kroki oraz zapewniają zgodność. Jednak jeśli stawiamy je ponad produkt i wartość, to mamy problem i kolejny antywzorzec.

Produkt vs Projekt

Pamiętajcie, że dobrego Project Managera czy dobrego Product Ownera poznamy po owocach ich pracy. Owocem pracy każdego z nich, zawsze jest produkt, który spełnia lub nie spełnia potrzeb i oczekiwań użytkowników! Apeluję do wszystkich. Dostarczajcie Wartość!

To na dzisiaj tyle

Samoorganizacja

W dzisiejszym odcinku powiemy sobie co to jest samoorganizacja oraz samozarządzanie. Jaką wartość daje praca w ten sposób oraz najważniejsze – co można zrobić aby samoorganizacja i samozarządzanie rozkwitły. Samoorganizacja oznacza, że grupa ludzi albo zespół decyduje w jaki sposób najlepiej wykonać swoją pracę, zamiast polegać na poleceniach z zewnątrz. Oznacza to, że to oni, wewnętrznie decydują kto co robi, kiedy i w jaki sposób. Co ciekawe samoorganizacja występuje w najróżniejszych układach złożonych. Można ją zaobserwować w niektórych zespołach deweloperskich, ale również w… roju mrówek, mrówki nie mają managera. W ruchu samochodowym – kierowcy spontanicznie zaczynają się samoorganizować jak jest korek albo jedzie karetka. Akcje komandosów też opierają się na samoorganizacji.

Samozarządzanie

Samoorganizacja to oczywiście elementarna część Scruma, nosi w nim od nazwę – samozarządzania. Jednak trzeba jasno powiedzieć,
samoorganizacja jest stosowana również poza scrumem! na przykład bez samoorganizacji nie możemy mówić o dojrzałym Kanbanie. Jedna z corowych zasad Metody Kanban mówi:

„Manage the work; let people self-organize around it.”

Czyli zarządzaj pracą – pozwól ludziom się samoorganizować. Samoorganizacja może też występować gdy zarządza Project Manager w projektach nie prowadzonych zwinnie. Samoorganizacja jest naprawdę cool, jednak warto wiedzieć precyzyjnie jaką wartość ma nam przynieść jej stosowanie.

Zaangażowanie

Nie znam lepszego sposobu na zwiększenie zaangażowania pracowników niż samoorganizacja. Uwielbiam oglądać jak ludzie którzy początkowo są zarządzani nawet sterowani przechodzą w tryb samozarządzania. To jest po prostu ogień! Super widzieć ak bardzo zaczyna im zależeć i jak stają się odpowiedzialni. Zaangażowanie bezpośrednio wpływa na efektywność. Dzięki samoorganizacji zespoły dostarczają szybciej i więcej w jednostce czasu. Też o wiele lepiej radzą sobie w sytuacjach niespodziewanych a nawet krytycznych.

Kreatywność

Zespoły samoorganizujące się często aż kipią nowymi pomysłami. Chcą usprawniać swój workflow oraz stosować nowe narzędzia. Samodzielnie rozwiązywać swoje problemy. Co jednak najważniejsze dla mnie, zaczynają się mocno udzielać przy decyzjach produktowych. Raz przejąłem zespół który zawsze był zarządzany za pomocą mikromanagementu. W rezultacie ten zespół miał mind set:”W sumie to nie ma sensu to co robimy, no ale klient powiedział, że tak chce. Co nas to obchodzi?”. Krok po kroku wprowadziliśmy w nim samoorganizację. Już po miesiącu podczas rozmowy z klientem jeden z deweloperów powiedział: „Markus, wiesz możemy zrobić tak jak Ty mówisz, ale może lepiej użyjmy natywnych rozwiązań androidowych? 5 razy mniej roboty, I userzy będą bardziej zadowoleni.”. To są te momenty, kiedy moje zwinne serce zaczyna bić szybciej i widzę, że moja robota ma sens

Oszczędność

Kolejny powód jest taki, że jak już mamy samoorganizację to jest ona po prostu tańsza niż mikromanagement. Używając nomenklatury Metody Kanban, samoorganizacja to świetny sposób na redukcję kosztów koordynacyjnych. Praca osób zarządzających procesem np. Scrum Mastera, Flow Mastera czy Project Managera kosztuje – to chyba jasne. Moje obserwacje są takie, że np. PM który uprawia micromanagement powiedzmy na 10 osobach w modelu samoorgazacyjnym może w tym samym czasie pracować nawet z ponad 20 osobami.

Zadowolenie Pracowników

Rynek IT to ewidentnie rynek pracownika. Firmy prześcigają się w tym jak jeszcze bardziej rozpieścić swoich programistów. Kiedyś wystarczyła owocowa środa i multisport – dzisiaj to standard Ale słuchajcie, moje doświadczenie mówi, że zespoły samoorganizujące się, odznaczają się o wiele wyższym poziomem zadowolenia. Gdybym miał sobie teraz wyobrazić 5 najbardziej zmotywowanych zespołów z jakimi miałem do czynienia to wszystkie miały bardzo zaawansowaną samoorganizację.

Tak tylko dodam, że bez zadowolonych ludzi nie ma mowy o wartościowym produkcie Pamiętajcie, że warto mówić wprost o zaletach samoorganizacji, gdy chcemy do niej przekonać management.

Teraz, przede mną najtrudniejsza część, powiem Wam co się musi zadziać aby samoorganizacja się zadziała.

Jasne Ramy

Po pierwsze musicie pamiętać, że samoorganizacja nie ma nic wspólnego z anarchią. Porządek musi być! Muszą być jasno określone ramy samoorganizacji. Bez precyzyjnych ram, samoorganizacja nie powstanie. Zespół musi dokładnie zozumieć za co jest odpowiedzialny, a za co nie jest odpowiedzialny. Przykładowo:

• Sami decydujecie o rozwiązaniach technicznych i sami zarządzacie przydziałem zadań.
• Natomiast za ustalanie priorytetów w Product Backlogu jest odpowiedzialny Product Owner.
• Jeżeli macie natomiast jakiś fajny pomysł na feature albo usprawnienie techniczne, powiedzcie o tym Product Ownerowi.

Muszą też być bardzo jasno określone zasady współpracy. Przykładowo każdy w zespole musi dokładnie wiedzieć jaki jest work flow prac, a już na pewno jakie jest Definition of Done. Bez jasno określonych zasad współpracy, zespół pewnie nie będzie się samoorganizował.

Bezpieczeństwo

Rzeczą bezwzględnie konieczną do powstania samoorganizacji jest poczucie psychologicznego bezpieczeństwa. Każdy członek zespołu musi czuć się bezpiecznie. Atmosfera jaka panuje w zespole musi być pozytywna. Każdy powinien też móc liczyć na wsparcie innych członków zespołu. Zabiegi budujące zespół na pewno są wskazane, można pójść razem na piwo, na laser taga itp. Każdy musi też wiedzieć, że ma wsparcie organizacji. Trzeba zaszczepić mindset „safe to fail”. Czyli każdy musi być przekonany o tym, że jeżeli podejmie decyzję jego zdaniem optymalną w danej sytuacji – nawet ryzykowną to nie zostanie za to ukarany, jeżeli skutki okażą się negatywne.

Przykładowo zespół po tygodniowym researchu rozwiązań zdecydował się użyć określonej biblioteki programistycznej. Jednak okazało się, po Sprincie, że corowe rzeczy z jej użyciem nie są możliwe do zaimplementowania. Złe podejście które zburzy bezpieczeństwo w zespole to opierdzielić ich od góry do dołu. Innymi słowy zastosować tzw. Blame Storming czyli szukania winnych. Niestety takie podejście widzę często. Pozytywne dla samoorganizacji rozwiązanie to po prostu szczera rozmowa i skupienie się na znalezieniu przez zespół rozwiązania.

Jasny Cel

Kolejnym warunkiem koniecznym powstania samoorganizacji jest posiadanie przez zespół jasnego celu. Każdy członek teamu musi rozumieć krótko i długoterminowe cele oraz mieć świadomość tego jakie są oczekiwane rezultaty prac. Scrum tutaj bardzo fajnie pomaga. Mamy jasną prognozę co zespół planuje zrobić w czasie Sprintu i mamy Cel Sprintu czyli Sprint Goal. Na wyższym poziomie abstrakcji mamy cel Produktu czyli Prodcut Goal. Jeżeli ktoś nie pracuje w Scrumie I chce samoorganizacji, musi cele pracy określić jakoś inaczej

Presja

Kolejny element budowania samoorganizacji to presja/ciśnienie. To coś co popycha zespół do działania. W Scrumie taki element skupienia osiągany jest przez timeboxing. Zespół prognozuje co zrobi np. w tygodniowym Sprincie.

Ewolucja

Kolejna kwestia jest taka, że samoorganizacja powinna być wprowadzana stopniowo. No i co ważne samoorganizację o wiele łatwiej poczuć niż opisać słowami. Ja często do zespołu najpierw wpuszczam bakcyla samoorganizacji. Zespół powinien doświadczyć samoorganizacji, żeby pracować w taki sposób. Można z zespołem zrobić jakieś warsztaty z samoorganizacji albo dać im jakieś zadanie nie obarczone dużym ryzykiem np. samodzielne zaprezentowanie rezultatów prac interesariuszom.

Potem po osiągnięciu kolejnego poziomu można zespół zachęcać do poszerzania obszaru samoorganizacji Takim mega wysokim poziomem jest to, że zespół jest w stanie sam sobie przeprowadzić skuteczną retrospektywę.

Odpowiedzialność po stronie zespołu

Ważne też, aby mieć postawę ogrodnika. Należy zapewnić dobrą glebę i zasiać. Ale samoorganizacja już musi rozwinąć się sama. Trzeba też przekazać odpowiedzialność zespołowi za ich działania. Jak poczują, że jej nie mają to lipa. Niestety dla wielu Scrum Masterów to trudna sztuka

I to na dzisiaj tyle!

Ken Schwaber & Jeff Sutherland w 1995 roku na konferencji OOPSLA pierwszy raz zaprezentowali Scruma. Dopiero w 2010 roku powstała pierwsza wersja Scrum Guida. Czyli dokumentu definiującego czym Scrum jest – to spisana definicja. Od czasu do czasu powstaje nowa wersja Scrum Guida z mniejszymi lub większymi zmianami. W ten oto sposób Scrum ewoluuje, rozwija się. Co bardzo ważne, właśnie wyszła nowa wersja: Scrum Guide 2020. Powiem Wam co się zmieniło i co ja o tym myślę.

Minimalistyczny Scrum Guid 2020

Albert Einstein mawiał:

„Wszystko powinno być tak proste, jak to tylko możliwe, ale nie prostsze.”.

To jedno z głównych założeń definicji Scruma. Jak wiecie Scrum jest frameworkiem czyli ramą, takim jakby szkieletem na którym należy zbudować cały proces empiryczny. Jest to minimalny zestaw idei. Jeżeli chcemy zastosować Scruma, to musimy je wszystkie zaimplementować. Nadać Scrumowi realną formę. Obudowując ten minimalistyczny „szkielet” własnymi rozwiązaniami.  Oczywiście takimi które będą optymalne dla naszych potrzeb.

Przez ostatnich parę lat Scrum stawał się powoli coraz bardziej sztywny i ograniczający Autorzy Postanowili więc, że jego definicja będzie zredukowana. Bardziej minimalistyczna, dająca więcej swobody. Ja kocham ten pomysł!  Dzięki niemu Scrum staje się bardziej… zwinny i bardziej leanowy – czyli odchudzony.

Przykładowo:

Odnośnie Product Backloga Itemów czyli PBIków nie ma już wytycznych, że muszą zawierać: opis, estymatę i wartość. Podobnie Backlog Refinement nie ma już sugestii, że powinien nie przekraczać 10%. Do Sprint Backloga nie trzeba już dodawać chciaż jednej akcji z retro.
Jest tylko sugestia, że można. Również kwestia anulowania sprintu została uproszczona „Sprint może być przerwany, gdy cel Sprintu jest przestarzały. Tylko Product Owner może o tym decydować.” – koniec tematu. Wcześniej było pół strony, o tym co trzeba zrobić oraz co powinno się zrobić. Inkrement nie ma już jasnych wymagań, że musi być gruntownie przetestowany. Chociaż musi być dalej używalny. Nawet kultowe 3 pytania na Daily już nie są nawet sugestią. Nie ma po nich śladu Swoją drogą chyba te pytania w świecie Scruma stają się lekko passe

Developers zamiast Development Teamu

Do tej pory Scrum Team składał się z Development Teamu, Scrum Mastera i Product Ownera. Zdaniem autorów, zespół wewnątrz zespołu prowadzi do podziału na „My i Oni” .Coś chyba w tym jest, bardzo często spotykam się z sytuacją, że Product Owner jest traktowany, jako ktoś obcy. Nawet w wielu przypadkach nie zaprasza się go na retro. Niby to antywzorzec Scruma, jednak często występujący. Dlatego właśnie zrezygnowano z pojęcia Development Teamu. Teraz są po prostu Deweloperzy. Jak mówimy zespół, to chodzi o Product Ownera, Scrum Mastera i Deweloperów.

Aby uwypuklić “nową” zespołowość, podaje się sugerowaną wielkość Scrum Teamu jako całości. Co ciekawe ta wielkość wynosi 10 lub mniej dla całego Scrum Teamu. Czyli oprócz Deweloperów liczony jest Scrum Master i Product Owner. Jeżeli zarówno Product Owner jak i Scrum Master nie są Deweloperemi, to sugeruje się ośmiu lub mniej Deweloperów. Nie od 3 do 9 jak wcześniej. Sugestia odnośnie wielkości jest też o wiele, wiele lżej napisana niż w poprzednim guidzie.

Ja uważam, że to rewelacyjny krok, rzeczywiście prawie każdy mówiąc „zespół” nie myślał o Scrum Masterze i Product Ownerze. Mam szczerą nadzieję, że to ulegnie zmianie. Jak się pewnie domyślacie, my trenerzy Scruma dużo rozmawiamy ze sobą o nowym guidzie. Kasia Hobler z rodu Terleckich przykładowo uważa, że jej zdaniem zmiany powinny iść dalej. Deweloperzy w 9 przypadkach na 10 kojarzą się z programistami, a przecież w Scrumie Deweloper to absolutnie każdy, kto przyłożył się do stworzenia kolejnej wersji inkrementu. Czemu nie nazwać ich kreatorami albo coś w tym stylu. No to byłby genialny pomysł.

Cel Produktu

A teraz prawdziwy HIT! Do Scruma dodano Cel Produktu. Czyli oprócz Sprint Goala będzie jeszcze Product Goal. Wszystkie elementy jakie są w Product Backlogu czyli PBI’ki mają służyć osiągnięciu tego celu. Opisuje on przyszły stan produktu do którego dążymy.

Powiem szczerze, że przez lata brakowało mi czegoś ważnego w Scrumie. Teraz już wiem, że właśnie Celu Produktu. Będzie to silny nacisk, na robienie produktu, a nie na prowadzenie projektu. W końcu zakres jest wtórny w stosunku do wartości.

Oczywiście minimalistyczny Scrum Guide nie daje precyzyjnych wytycznych jak definiować Cel Produktu. Można na pewno użyć Evolutionary Project Management i określić poziom pożądanego impactu na potrzeby interesariusz. Oczywiście można też zastosować prostsze rozwiązania np. Impact Mapping autorstwa Gojko Jokić albo modne obecnie OKRy.

Commitments – Zobowiązania

W poprzedniej wersji Scrum Guida, Definition of Done i Sprint Goal były takie trochę osierocone. To nie artefakty, ale niby z nimi związane. Scrum Guide 2020 to konkret. Sprint Goal jest częścią Sprint Backloga. Nowy Product Goal jest częścią Product Backloga. Natomiast Definition of Done, chociaż nie jest częścią Inkrementu, to jest w Guidzie napisane czarno na białym “Work cannot be considered part of an increment unless it meets the Definition of Done”.

BTW jest też jaśniejsze wyjaśnienie czym jest Definition of Done. Jest napisane wprost, że to stan jakości inkrementu wymagany dla produktu. Bardzo często musiałem kursantom tłumaczyć, czym się różni DoD od kryteriów akceptacji. Moje życie stanie się teraz łatwiejsze!

• Sprint Goal,
• Product Goal,
• Definition of Done,

nazywane teraz są Zobowiązaniami (Commitments). Zostały silnie połączone z odpowiadającymi im artefaktami. Uważam, że to bardzo dobry krok, który przyniesie dużo wartości.

Sprint Planning

Zmianie uległa formuła Sprint Planningu do tej pory, należało na nim poruszyć 2 tematy:

• Co możemy zrobić w Sprincie?,
• Jak zostanie to zrobione?

Teraz jest jeszcze 3 obowiązkowy temat do poruszenia:

• Dlaczego ten Sprint jest wartościowy?

Product Owner musi zaproponować jak Inkrement Produktu może po tym Sprincie zwiększyć wartość produktu. Dla mnie bomba. Większość implementacji Scruma jakie ja widzę, to fabryka features. Nie ważne co robimy, ważne jak dużo. Liczę, że jakoś to wpłynie na tą sytuację. Mam nadzieję, że zredukuje to myślenie projektowe, a zwiększy focus na produkt.

Sprint Goal

Jest też mała, ale znacząca modyfikacja: “The Sprint Goal must be finalized prior to the end of Sprint Planning”. Połowa osób na moich scrumowych szkoleniach uważała, że cel Sprintu to fajny dodatek do Scruma. No nie, to bardzo wartościowa i obowiązkowa część Scruma. Moim zdaniem to super, że jest to tak wytłuszczone.

Self-Management zamiast Self-Organization

W scrumie są trzy managerskie role:

• Scrum Master zarządzający procesem,
• Product Owner zarządzający produktem,
• Deweloperzy zarządzający swoją pracą i tym jak tworzoną inkrement,

Aby to uwypuklić to, że Deweloperzy są bytem zarządzającym swoją pracą, usunięto ze Scrum Guida pojęcie samoorganizacji. Teraz jest samo-zarządzanie – Self-Management, dotyczy całego zespołu scrumowego. Osobiście nie mam wyrobionego zdania czy to dobrze, czy źle. Samoorganizacja to taka kultowa dla Scruma idea, trochę szkoda. Z drugiej strony dajmy szansę nowemu pojęciu.

Refactoring Tekstu

Może Was zaskoczę, ale kiedyś zajmowałem się uczciwą robotą. Byłem programistą Javy. W każdym razie, z tego względu bardzo doceniam kolejną zmianę jaką dokonano w Scrum Guidze. Zrobiono porządny refactoring tekstu. Scrum Guide 2020 został w całości przeredagowany. Może wyjdę na heretyka, ale uważam, że w poprzedniej wersji, było dużo zbędnego pitolenia. Czasami też trudno było zrozumieć o co chodzi autorowi. Teraz jest krótko, zwięźle i na temat!

O wiele łatwiej jest teraz zrozumieć co jest napisane w Scrum Guidzie. Coś czuję, że jako Trener Scruma będę miał teraz łatwiejszą robotę. Więcej rzeczy będzie jasne dla uczestników i będę musiał tłumaczyć mniej pojęć uczestnikom. Zwyczajnie sami zrozumieją więcej idei płynących ze Scrum Guida.

Co ważne Guide został też skutecznie odchudzony. Wcześniej zajmował 19 stron, Teraz tylko 14. Chyba wezmę z niego przykład i też schudnę. To taki suchy żart:)

Niezależność od IT

Scrum w nowej wersji staje się niezależny od IT. Nie ma już odwołań do IT. Przykładowo nie ma w nim już naszego słownictwa Nie ma: testowania, wymagań, systemów, designu itp..  Jest dzięki temu bardziej dostępny dla szerszej grupy docelowej. To chyba dobrze

Scrum Master Zostaje

To trochę śmieszne, ale Scrum Master w politycznie poprawnej Ameryce, kojarzy się niektórym z ich niechlubnym okresem niewolnictwa. “Master” w odpowiednim kontekście to pan niewolników. Pojawiały się naciski na autorów, aby zmienili tę nazwę. Dla mnie dziwne jest, że autorzy w ogóle tłumaczyli się, z tego, że nie nastąpiła taka zmiana. W każdym razie dobrze, że koniec końców Scrum Master został. Gdyby ulegli naciskom, odebrałbym to jakie złamanie scrumowej wartości “Odwaga”.

Oczko w Stronę Leana

Zauważyłem w nowym Scrum Guidzie ciekawą rzecz, w sumie szczegół ale mnie cieszy. To takie oczko puszczone do Leanowców …
no i w sumie do Kanbanowców też. „Scrum is founded on empiricism and … lean thinking”. Zwróćcie uwagę, że ludzie od Kanbana często myślą o sobie, że są lean, a nie agile. Niby to praktycznie to samo, ale jest to kwestia tożsamości i odrębności. Jest też coś takiego: “Scrum provides cadence in the form of its five events”. “Cadence” to słownictwo silnie powiązane z Kanbanem, to kanbanowy synonim “event”. Scrum.org stworzył, rok temu własnego Kanbana i chyba widzi w nim potencjał

Serca Bicie

Zawsze sobie żartowałem z wyrażenia “Sercem Scruma jest Sprint”. Trochę moim zdaniem zbyt poetyckie stwierdzenie Schwaber i Sutherland postanowili to jednak usunąć. Na moje szczęście, będę mógł sobie żartować z nowego stwierdzenia. W Scrum Guide 2020 jest info, że sprinty są serca-biciem Scruma. Myślę, że Scrum org powinien płacić tantiemy potomkom Andrzeja Zauchy.

(Nie) Żywy Artefakt

Usunięto też moje ulubione stwierdzenie, że Product Backlog jest żywym artefaktem. Wielka szkoda. To ułatwiało zrozumienie idei Product Backloga.

Scrum Guide 2020 jest w porządku

Na koniec chciałbym napisać, że ja jestem bardzo zadowolony ze zmian w Scrum Guidzie. Kolejny inkrement Scruma wygląda całkiem sensownie. Scrum dalej jest Scrumem, ale lepszym.

I to na dzisiaj tyle

Ostatnio opowiadałem dlaczego warto podejmować decyzje w oparciu o fakty i dowody. Opowiadałem równieżo ruchu społecznym Evidence Based Management. Natomiast dzisiaj opowiem o scrum.orgowym frameworku – który również nosi nazwę Evidence Based Management (EBM).

Ten framework wspiera mocno zarządzanie organizacją oraz produktem. Pozwala na countinous improvement. W taki sposób, aby w przyszłości było jak najwięcej więcej wartości biznesowej. Czyli wspiera model zarządzania firmą po przez wykonywanie dobrej roboty dla klienta. EBM jako framework zawiera silnik do wprowadzania zmian. Bazujący na wyznaczaniu sobie mierzalnych celów oraz na stawianiu hipotez. Hipotezy natomiast zaleca walidować za pomocą przeprowadzania eksperymentów. Zmiany powinny być wprowadzane małymi krokami. Jest też coś tygrysy lubią najbardziej! Dużo mierzenia!

4 Obszary Evidence Based Management

Bardzo często na szkoleniach mówię o moim ulubionym filmie … o „Predatorze”. Tytułowy Predator to myśliwy z kosmosu który popełnił błąd i walczy z Arnoldem Shwarzenegerem. Ten kosmita ma bardzo specyficzny tryb widzenia – podczerwień. EBM to też bardzo specyficzny tryb widzenia rzeczywistości. Skupia naszą uwagę na 4 obszary organizacji. Co ważne każdy taki obszar każe nam dokładnie zmierzyć!Każdy taki obszar powinien mieć zestaw miar zwanych potocznie metrykami

O ile framework pozostawia pełną swobodę w doborze metryk do każdego obszaru, to daje również zestaw w sumie 30 gotowych miar
Jest z czego wybierać!

Pierwszy obszar to Current Value. Czyli wartość jaką dostarcza nasza organizacja DZISIAJ. Klientom oraz interesariuszom. Ta wartość dostarczana jest za pomocą produktu albo serwisu. Można ją mierzyć na różne sposoby, oczywiście można zastosować podejście z Evolutionary Project Management czyli Impact Estimation: zmierzyć w jakim zakresie jest spełniona potrzeba usera albo interesariusza, ale na poziomie wymagań niefunkcjonalnych. Przykładowo nasze biletomaty pozwalają kupić pasażerowi bilet w 10 sekund.

Oto link do Evidence Based Management guida:
https://scrumorg-website-prod.s3.amaz…