Zwinność kulturowo rozmiękczona

Tu, nad Wisłą, ze zwinnością (agility) wydarzyło się coś niedobrego. Zapraszam to krótkiej rozkminki.

Weźmy taki cytat ze Scrum Guide (dotyczy on roli Product Ownera): "The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable."

I z polskiego tłumaczenia: "Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu, jednak to Właściciel Produktu pozostaje za nie odpowiedzialny"

Dostrzegasz coś intrygującego?

responsible vs. accountable

Responsible oznacza odpowiedzialność w takim sensie, że ktoś ma coś w swoich obowiązkach, bo na przykład zostały mu te obowiązki przydzielone.

Accountable oznacza mocniejszy rodzaj odpowiedzialności np. prawnej, czyli odpowiedzialności za konsekwencje.

Zatem tłumaczenie oddające sens angielskiego zdania powinno brzmieć: "Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu, jednak to Właściciel Produktu zostanie z nich rozliczony". Jedno słowo wiele zmienia, co?

Podobnie rzecz się ma Zespołem Deweloperskim: „Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.”

Zatem Zespół Deweloperski zostanie rozliczony za brak przyrostu (increment) produktu na koniec sprintu.

Niuans kulturowy

Moim zdaniem mamy tu do czynienia z różnicą kulturową. Anglosaska - jak mniemam - prosta i konkretna zasada rozliczenia została w polskim tłumaczeniu rozmyta i rozmiękczona w ogólną odpowiedzialność.

Zgaduję powód. Sęk w tym, że rozliczyć ma w języku polskim mocno pejoratywne konotacje. "Rozliczę cię" oznacza mniej więcej tyle: "Słuchaj gościu, jak coś pójdzie nie tak, to ty za to bekniesz. Poniał?"

Głębiej o accountability

Powiem więcej. "accountability" oznacza taki rodzaj (silnej) odpowiedzialności (za konsekwencje), który został przyjęty dobrowolnie. Na przykład CEO jest accountable za organizację i zostanie rozliczony za ew. sukcesy i nieprawidłowości. Ważne jest to, że on o tym wiedział od samego początku i zgodził się na to "rozliczanie" w momencie przyjęcia nominacji.

W tak rozumianym rozliczaniu nie ma nic negatywnego. Ktoś otrzymuje pełnię władzy: przywileje oraz konsekwencje. Prosty deal.

Czego chce Scrum?

Posługując się już przedefiniowanymi wyżej pojęciami, można powiedzieć, że Scrum chce od swojego praktyka pewnej dojrzałości.

Chce, aby PO, DevTeam czy SM, zanim podejmą decyzję, że używają Scruma, zatrzymali się na moment. Niech się zatrzymają, popatrzą na możliwe przywileje, na potencjalne konsekwencje i świadomie powiedziedzą: "Tak, chcę być rozliczony za swoją pracę."...albo nie.

Rzecz jasna możliwość rozliczania implikuje ze strony organizacji konieczność przydzielenia autonomii, decyzyjności i tak ogólnie nie wpieprzania się w paradę.

Kolorowy coach

Tu kudos dla Bartka za insight.

Weźmy jeszcze jeden cytat na temat tego, co tam Scrum Master powinien: "Coaching the Development Team in self-organization and cross-functionality"

I po polskiemu: "Coachując Zespół Deweloperski w zakresie wykorzystania zasad samoorganizacji i międzyfunkcyjności".

No więc rzucili się ludzie na kursy kołczigu i adżajkołczują. No, ale looknijmy sobie na OxfordDict czymże jest ten coaching?

O, żesz w mordę, madafaka! Co ja paczę???

• "Train or instruct (a team or player)"
• "Teach (a subject or sport) as a coach"
• "Give (someone) instructions as to what to do or say in a particular situation"
• "Give (someone) professional advice on how to attain their goals"

Zatem jeśli Scrum Master coach Zespół Deweloperski, to oznacza, że ten Scrum Master jest naumiany Scruma i generalnie ogarnia temat. Następnie jego zadanie polega na tym, aby nauczyć Scruma zespół. No i może ludzi poza zespołem, przynajmniej na takim poziomie, żeby kumali o co chodzi.

Nie oznacza to, że statutową metodą pracy Scrum Mastera jest "metoda coachingowa", czyli zadawanie pytań tak, aby delikwentom samo wyjajiło się, co im dolega. Może to robić, jak będzie ku temu powód. Moje doświadczenie podpowiada mi jednak, że takich chwil jest naprawdę niewiele.

Nawiasem mówiąc "metoda coachingowa" zakłada, że klient ma pełnię kompetencji do rozwiązania swoich problemów. No więc życzę powodzenia w pracy tą metodą, gdy zespół nie zna i nie umie Scruma.

Ej, a wiecie jak deweloperzy mówią na takich adżajlkołczów, co to w każdym próbują znaleźć wewnętrzne dziecko i proszeni czy nie proszeni serwują sesje coachingowe tuzinami? "Kolorowe pisaki"...sam słyszałem.

Także, ten...wyluzuj. Po prostu wyluzuj.

Continuous attention to technical excellence...

No więc jak taki #kolorowyCoach w pośpiechu przygotowuje się do certyfikatu, to czytając po łebkach adżajlmanifesto, skupia się tylko na wartościach, zapominając, że jest tam też parę bardziej szczegółowych wytycznych.

Między innymi taka: "Continuous attention to technical excellence and good design enhances agility". O co chodzi?

Coraz częściej dochodzę do wniosku, że pierwszym blokerem do uzwinnienia się jest architektura. Co z tego, że nasz supersystem powstał w sprintach i nawet miał wizję i rołdmapę, skoro to monolit liczący 2MLOC?

Gdzieś popełniliśmy błąd. W którymś momencie zwinność odkleiła się od technologii i stała się wyłącznie: kulturą, mindsetem i procesem.
Tak się nie da.

Biznes dzieje się szybko. Żeby szybko produkować dla tego biznesu potrzeba metod, architektur, technologii i skilla, które umożliwią osiągnięcie tej szybkości. Bez tego zostają tylko kolorowe pisaki...

A na deser międzyfunkcjonalność

W oryginale: "Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment"

I w rodzimym dialekcie: "Zespoły Deweloperskie są międzyfunkcjonalne, w swoim składzie posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu produktu."

Nie wiem czy tylko ja wymiękam z tą "międzyfunkcjonalnością"?

Neologizm - jak przypuszczam - "międzyfunkcjonalność" należałoby rozumieć przez analogię do np. "międzywydziałowości", czyli jako coś co się dzieje "pomiędzy granicami wyznaczonymi przez funkcjonalności". Czy ja wiem?

Jeśli już kuć nowe słowa, to ideę oddawałoby "pełnokompetentny": "Zespoły Deweloperskie są pełnokompetentne, w swoim składzie posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu produktu." Ewentualnie "pełnoumne" :)

Jestem Scrum Masterem, co mam robić?

Śmieją się developerzy ze ScrumMasterów, że ci nic nie robią. Niby żartem, niby po przyjacielsku, ale boli. Gdy ScrumMaster zostaje ScrumMaster jedne z pierwszych pytań, które sobie zadaje to:

• No i co ja mam teraz robić?
  
• A co jeśli zapomnę jak się programuje?
  
• A co jeśli znudzi mi się programowanie
  

Jedna z dróg, którą może wybrać SM na wdrożenie Scruma wiedzie przez cztery następujące etapy:

1. Framework by Guide
   
2. Jakość techniczna
   
3. Wartości i wyjście poza zespół
   
4. Nieustanny tuning DoD
   

W tym modelu, SM może zająć się doprowadzeniem do zaistnienia następujących rzeczy:

1. Framework by Guide
   
   • Zaimplementowanie w pracy zespołu ról: SM, PO z biznesu, SM, DevTeam
     
   • Zaimplementowanie w pracy zespołu: sprintów stałej długości, DoD, Planningu, Review, Daily, Retro, regularnego refinementu PBL, Product Backloga, Spring Backloga
     
   • Biznesowe cele sprintów
     
   • Zaimplementowanie w pracy zespołu: biznesowego inkrementu produktu na koniec sprintu, współpracy między zespołem a PO, która nie wymaga sztywnego DoR
     
   • samoorganizacja Zespołu deweloperskiego
     
   • Doprowadzenie do tego, aby testerzy byli pełnoprawnymi członkami Zespołu scrumowego, a nie podzespołem w zespole
     
2. Jakość techniczna
   
   • Wdrożenie 1-3 metryk kodu oraz systematyczna praca nad ich poprawianiem; propozycja na początek CC oraz LOC na poziomie metod i klas
     
   • Zmierzenie długu technicznego, przygotowanie planu jego spłaty i wynegocjowanie tego z PO
     
   • Wdrożenie Continuous Integration -> Continuous Deployment -> Continuous Delivery
     
   • Wprowadzenie regularnego Code Review w zespole wraz z narzędziem, który je wspiera
     
   • Wdrożenie Test/Behaviour Driven Development
     
   • Wdrożenie automatycznych testów funkcjonalnych wraz z narzędziem, które je wspiera; nauczenie PO i/lub interesariuszy formułowania wymagań w formie scenariuszy
     
   • Wdrożenie Domain-Driven Design, nawiązanie współpracy z ekspertami domenowymi, wdrożenie Modelling Whirpool
     
   • Regularne Architectural Kata
     
   • Regularne Refactoring Kata
     
3. Wartości i wyjście poza zespół
   
   • Doprowadzenie do sytuacji, w której prace zespołu są niezależne od innych jednostek organizacji
     
   • Pomoc managerowi zespołu w na nowo zdefiniowaniu swojej roli w stosunku do zespołu scrumowego
     
   • Doprowadzenie do określenia zasad współpracy pomiędzy jego/jej zespołem a innymi zespołami i/lub jednostkami organizacyjnymi
     
   • Stymulowanie wewnętrznych inicjatyw typu "craftsmanship": wewnętrzne konferencje, warsztaty, szkolenia, mini-społeczności skupione w okół danych technologii albo ról (np. gildie)
     
   • Eksponowanie osiągnięć zespołu na zewnątrz organizacji: konferencje branżowe, artykuły w prasie i na portalach branżowych
     
   • Wdrażanie i promowanie empirycznego podejścia do pracy tj. wprowadzanie przejrzystych metryk przy jednoczesnym uczeniu organizacji jak z nich sensownie korzystać
     
4. Nieustanny tuning DoD
   
   • Doprowadzenie do sytuacji, w której "Done" oznacza "dostępne dla klientów"
     
   • Praca na skróceniem time to markiet, time to feedback
     
   • Dążenie do sytuacji, w której ani zespół ani organizacja nie potrzebują Scrum Mastera, gdyż jego obowiązki zostały osmotycznie przejęte przez członków zespołu i innych pracowników organizacji, którzy bezpośrednio dostarczają wartość dla jej klientów
     

Dzielenie User Stories z życia wzięte

Żona zakontraktowała ze mną poprawę sytuacji wieszaków na ubrania w garderobie.
Garderoba jest tak wygospodarowana za pomocą ścianek kartonowo-gipsowych z powierzchni mieszkania,
że znajduje się pod dość spadzistą częścią połaci dachu.

Konsekwencja tego była taka,
jedyne wieszaki na ubrania jakie miały tam rację bytu ,to takie samodzielnie stojące w liczbie dwa.

Zgodnie z zasadą safe-to-fail experiments zacząłem od najtańszych. I gdy połamał się czwarty, czy piąty,
a sumaryczny koszt wieszaków zbliżał się niebezpiecznie do 1kPLN otrzymałem, wspomniane zlecenie mojej PO.

Na naradę strategiczną zaprosiłem sąsiada, który rychło przekonał mnie do wykonania pracy samodzielnie.

No i się zaczęło:

• nie ma gdzie się rozeprzeć drążkami
  
• prócz ciężaru ubrań na drążek będzie działać jeszcze szarpanie na boki, gdy ktoś nagle zapragnie
  wyciągnąć ubranie z samego końca składu - czyli karton-gipis nie wytrzyma szarpania
  
• i inne mniej poważne rozważania budowlane
  

Ostateczny plan działań rysował się następująco:

• usunąć listwę przypodłogową
  
• na ścianę nakleić sklejkę 18mm, dodatkowo poprawić wkrętami, sklejka ma być oparta o podłogę
  
• wieszak będzie przytwierdzony do sklejki i do podłogi
  

Raźno wziąłem się do pracy, a pomocny sąsiad zorganizował potrzebną sklejkę. Wyglądało to tak:

Jak to bywa, okazało się, że brakuje części, narzędzi i że praca zajmie kilka popołudni, zamiast jednego. Pokój przylegający do garderoby zaczął przypominać pobojowisko:

W tym momencie moja żona powiedziała STOP (nie jest to cytat dokładny). Okazało się, że bałagan w trakcie prac jest istotnym wymaganiem niefunkcjonalnym, które może położyć całe przedsięwzięcie.

A co na to agile?

Kocham wytwarzanie oprogramowania między innymi dlatego, że pomaga załatwiać ważkie sprawy codziennego życia. Takie jak chociażby montaż wieszaka w garderobie.

Optymalizuj proces wytwórczy "pod klienta"

Pierwsza zmiana w trybie pracy polegała na tym, by każdego wieczora po zakończeniu prac garderoba była gotowa do użytku, a pokój uprzątnięty. Mniej więcej tak:

Z mojej perspektywy taki tryb pracy wymagał więcej wysiłku i trwał dłużej, a zatem był droższy. Najchętniej przeniósłbym żonę z dzieciakami na kilka dni do teściowej, a sam ogarnął temat w trzy pacierze.

Z drugiej strony obecność rodziny dawała pewne korzyści:

• informacje od żony: czy za wysoko, czy za nisko, czy wystarczająco miejsca do poruszania się
  
• dzieciaki przeprowadzające testy obciążeniowe
  

Nieustanna obecność klienta pozwoliła mi podnieść jakość produktu (w oczach tego klienta, rzecz jasna) i uniknąć poprawek na samym końcu, a w skrajnym przypadku całkowitego demontażu niefunkcjonalnego wieszaka.

A zatem w kontekście całości przedsięwzięcia (łącznie z odbiorem produktu i sprzedażą) było szybciej i taniej. Ode mnie zaś wymagało to takiego sposobu pracy, aby był on całkowicie zrozumiały dla klientki.

Jak to zapisać w backlogu?

Ten bardzo naturalny sposób pracy nie został wymyślony - został zaobserwowany. Zespołom trudno wpaść w ten tryb, no bo jak to zapisać w backlogu?

Jedną z najistotniejszych rzeczy w zwinności jest rozwijanie produktu w taki sposób, aby klient mógł obserwować postęp prac i nie musiał mieć do tego żadnej magicznej wiedzy.

Zapisywanie tegoż jest ważne, ale wtórne. Jeśli pracowałbyś w ten sposób, a w backlogu umieszczał wpisy postaci:

• Montaż wieszaka w garderobie - etap 1
  
• Montaż wieszaka w garderobie - etap 2
  
• Montaż wieszaka w garderobie - etap 3
  
• Montaż wieszaka w garderobie - etap 4
  

to będzie OK. Może jakiś neofita zwymyśla Cię na forum. Ale Twój klient będzie wiedział o co chodzi, bo będzie widział co się dzieje, więc będzie miał wpływ na to, co wytwarzasz i będzie wiedział za co płaci. I to jest zwinność.

Czytelny backlog - większa przejrzystość

Sąsiedzi odnotowali dwie rzeczy: moją absencję na placu zabaw oraz hałasy dobiegające z naszego mieszkania. Dopytywali więc żonę, co się dzieje.

Mogła odpowiedzieć:

-Michał robi wieszak w garderobie i jest na etapie drugim.

Ale czy to by ich zadowoliło? Czy hałasy nie były zbyt niepokojące? Powstał więc problem z przejrzystością mojej pracy.

Dla jej poprawienia mógłbym nieco przeformułować wykonywane zadania:

• Jako Żona chcę zobaczyć różnicę między wieszakami stojącymi, a tym co robisz, żeby zrozumieć czy mi odpowiada pomysł
  
• Jako Żona chcę powiesić chociaż puste wieszaki, żeby przekonać się jak tego można używać
  
• Jako Żona chcę powiesić kilka lżejszych ubrań, żeby zobaczyć czy wygodnie się tego używa
  
• Jako Żona chcę samodzielnie powiesić mniej używane ubrania, żeby zobaczyć czy mam wystarczającą ilość miejsca do poruszania się w garderobie
  
• Jako Żona chcę powiesić tyle ubrań ile wlezie, żeby zweryfikować wytrzymałość wieszaka
  

Zauważ, jak bardzo przeformułowanie zadań poprawia przejrzystość prac nad wieszakiem. Zwłaszcza z perspektywy mojej żony oraz pośrednich interesariuszy (zainteresowanych hałasem) w postaci sąsiadów.

Dzięki tej przejrzystości moja żona mogłaby sprawniej komunikować się z sąsiadami, a oni mogliby nagle zachcieć mieć podobny wieszak u siebie, gdyż otrzymali bardzo jasne informacje na temat tego, co się dzieje i co można zyskać na poszczególnych etapach prac.

Czy to jest PSI?

No sam powiedz, czy to PSI?

Mamy tu jakiś fragment wieszaka: mocowanie do ściany, ramię do wieszania, podpora oraz mocowanie do podłogi. Czy to już wieszak? W jakimś sensie tak, nie do końca o to chodziło, ale pewien typ ubrań można wieszać.

W PSI ważna jest literka P - potencjalnie. Gdyby ktoś chciał, to potencjalnie mógłby tego użyć, akceptując ograniczenia tej funkcjonalności. Dla mnie osobiście "P" oznacza, że klient ma wystarczający obraz tego, jak wieszak będzie wyglądał na końcu, aby dać zielone światło i pieniądze na dalsze prace.

W tym sensie ułomny pół-wieszak robi na kliencie o wiele lepsze wrażenie niż bałagan w pokoju, a w tle przerażający pisk szlifierki kątowej.

PSI zmienia się w SI

SI, czyli shippable increment.

Czy tak trzeba, czy można robić?

W zeszłym roku remontowałem łazienkę na działce, a wyglądało to tak.

Żona i dzieci wypoczywali nad morzem. Żadnych szczegółowych wytycznych do łazienki nie było, prócz takiej, żeby ją w końcu naprawić. Więc rozoraliśmy z tatą pół domku, a po tygodniu łazienka była gotowa. Żadnego sprzątania na wieczór - proces wytwórczy zoptymalizowany "pod wykonawcę".

Podsumowując mamy dwa sposoby optymalizacji pracy nad oprogramowaniem:

• "montaż wieszaka w garderobie" - optymalizacja procesu wytwórczego "pod klienta"
  
• "remont łazienki na działce" - optymalizacja procesu wytwórczego "pod wykonawcę"
  

Który i kiedy wybrać? To będzie na deser ;)

Jak dostarczać przetestowane zadania?

Poniższe pytania i odpowiedzi są możliwie konkretne. Niestety im bardziej konkretna odpowiedź, tym mniejszy kontekst jej stosowalności. I jeszcze bardziej niestety duża szansa na zastosowanie odpowiedzi w niewłaściwym kontekście albo (z powodu nieuwagi autora) wyciągnięcie z tych odpowiedzi wniosków, których autor wcale nie miał na myśli.

Z w/w powodów proszę aby, jeśli wyciągniesz z poniższego tekstu wniosek, który jest sprzeczny ze zdrowym rozsądkiem, Twoim doświadczeniem, Scrum Guidem itp., niezwłocznie mnie o tym poinformuj w komentarzu – w miarę możliwości doprecyzuję tekst.

Problem:

• Sprint trwa 2 tygodnie
  
• Zespół planuje prace na cały sprint
  
• Po wykonaniu zadania PO zleca testy biznesowe osobom z biznesu i na tej podstawie odbiera zadania ze sprintu
  
• Bywa, że osoby z biznesu nie zdążają przetestować zadania przed sprint review i zadanie jest undone
  
• Jak zatem planować prace i współpracować, aby dostarczać zadania, które są done?
  

1. Czy powinniśmy zaplanować development tylko na 1. tydzień sprintu, dając tym samym biznesowi czas na przetestowanie w 2. tygodniu sprintu tego, co zrobiliśmy w 1. sprincie?

- Nie. Tydzień siedzenia i czekania jest stratą czasu i pieniędzy.

2. Czy w takim razie powinniśmy zorganizować prace tak, że testowanie biznesowe odbywa się w kolejnym sprincie?

- Nie. Poprawki zgłoszone do zadań z poprzedniego sprintu będą zaburzać wasze prace w bieżącym sprincie. Modelowo zespół pracuje time & material i otrzymuje wynagrodzenie na koniec sprintu za to, co dostarczył w sprincie. Z perspektywy zespołu nie ma sensu robić w sprincie pracy, która na koniec nie zostanie odebrana i opłacona.

Jednym z kluczowych przesłanek za pracą w iteracjach i inkrementach jest ta, że PO po każdym sprincie może zdecydować się na wstrzymanie prac programistycznych, aby skupić się na biznesowym zarabianiu na produkcie. Może też zdecydować, że już osiągnął to, co chciał i współpraca z zespołem dobiegła końca. Planowanie testów na kolejny sprint odbiera mu tę możliwość.

3. Ale nasz PO liczy mendeje, które spaliliśmy w sprincie. Musimy zaraportować prace na jakieś zadania.

- Dobrze, że je liczy. Powinien również liczyć zysk z dostarczonej pracy. Jeśli zysk jest, to w czym problem?

4. Wy tym, że przecież nie możemy przez dzień czy więcej siedzieć tylko i pić kawę.

- Częściowo to prawda. Chodzi nam o subtelną zmianę priorytetów: przestajemy dążyć do maksymalnej utylizacji Waszego czasu pracy, zaczynamy dążyć do maksymalnej wartości Waszej pracy. Jeśli zatem okazuje się, że wszystko jest done i macie jeszcze czas w sprincie, to warto zastanowić się nad zwiększeniem dostarczanej wartości np. poprzez planowanie większej ilości wartościowej pracy. Poza tym PO nie płaci za wykonane zadania/user story/funkcjonalności, lecz za osiągnięcie celu sprintu.

5. Przypuśćmy, że mamy taką sytuację: w pierwszym tygodniu sprintu zrobiliśmy zadania i poprosiliśmy PO o akceptację (a więc o biznesowe przetestowanie). Czym mam się zająć w następnej kolejności?

- Kolejnym zadaniem ze sprint backloga.

6. Ale wszystkie są już ‘in progress’

- Pomóż kolegom/koleżankom sprawniej uporać się z ich zadaniami, abyście szybciej osiągnęli cel sprintu.

7. Ale oni mówią, że w tej chwili nie potrzebują pomocy i że będziemy sobie przeszkadzać

- Zacznij testować zadania kolegów/koleżanek.

8. Ale oni już zaczęli swoje testy deweloperskie?

- Zacznij testować biznesowo.

9. Ale to analitycy z biznesu mają się tym zająć.

- A kto ma otrzymać wynagrodzenie za pracę, która jest done – Wy czy analitycy z biznesu?

10. Czyli analitycy mają nie testować biznesowo?

- Nie wiem jak jest ułożona Wasza współpraca. Może i mają testować, ale odpowiedzialność za dostarczenie celu sprintu spoczywa na zespole.

11. Ale nie mamy żadnej metody, żeby ich zmusić do testowania na czas

- Co do zasady, to da się zmusić współpracowników do pewnego zachowania, ale wtedy cały czas musisz podtrzymywać bodziec przymuszający np. zagrożenie eskalacją. Ostatnie 40 lat doświadczeń wskazuje, że postawienie na współpracę, budowanie relacji i podejście win-win daje w typowym środowisku biznesowym lepsze efekty.

12. A co zrobić jeśli analitycy nie mają czasu na testowanie?

- Zgłosić PO. Jeśli nie mają czasu odebrać zadania, to nie jest ono wystarczająco ważne albo nie zostało przez nich wycenione biznesowo. Osobiście rozważyłbym niebranie na sprint zadań, co do których nie ma zobowiązania, że zostaną odebrane.

13. Mówiliśmy im, że mają się zobowiązać, ale oni mówią, żeby ze sporym wyprzedzeniem podać kiedy mają testować bo muszą zaplanować swoje prace, a my nie jesteśmy w stanie tego przewidzieć

- Czyli chcecie, aby biznes zaplanował swoją pracę „pod Was”, bo wy nie jesteście w stanie zaplanować swojej?

14. To nie tak. Nie da się patrząc na zadanie podać nawet ‘mniej więcej’ kiedy będzie gotowe do testowania.

- Prawdopodobnie zadania są zbyt duże. Prawdopodobnie należy się przyjrzeć refinementowi.

15. Nie da się ich bardziej podzielić.

- Da się. Zróbmy warsztat na ten temat. Byle na Waszych przypadkach nie na ogólnych schematach.

16. Powiedzmy, że chciałbym testować biznesowo, ale nie wiem jak, nie mam potrzebnej wiedzy.

- Zapytaj analityków z biznesu.

17. Mówią, że nie mają czasu.

- Zapytaj jeszcze raz.

18. Znów nie mają czasu.

- Pytaj aż do skutku. Wpadnij na kawę, na lunch. Popracuj na ich piętrze.

19. Nawet jeśli się czegoś dowiem, to testowanie idzie mi wolno nie wyrobię się do końca sprintu.

- Do końca tego sprintu może i nie, ale za 2-3 może nabierzesz wprawy.

20. A co jeśli do końca sprintu zostało 2 dni, czekamy tylko na wyniki testów biznesowych. Czy możemy zacząć nowe zadanie?

- Zanim to zrobisz, to poświęć chwilę na refinement, poprawę jakości kodu, dopisanie koniecznych testów, spłatę długu technologicznego.

21. Już to wszystko zrobiliśmy…

- To dobierzcie zadanie z product backloga. Unikajcie w trakcie planingu wrzucania do sprint backloga zadań rezerwowych.

22. Dlaczego? Przecież i tak dobieramy z backloga?

- Ale z produktowego, a nie z napchanego sprint backloga.

23. Co za różnica?

- Taka, że jeśli na początku napchacie sprint backlog rezerwowymi zadaniami, to na koniec sprintu prawie na pewno zostaną Wam niewykonane zadania.

24. Ale przecież chodzi o osiągnięcie celu sprintu, a nie o wykonanie wszystkich zadań.

- To prawda. Jeśli cel jest osiągnięty i zostały jakieś zadania, to nie ma dramatu. Mimo to ludzie lepiej się czują jeśli zrobią wszystko, co sobie zaplanowali. Nawet jeśli doskonale rozumieją, że nie jest to celem, to niepusty sprint backlog ich ‘uwiera’.

25. Czyli mamy planować tak, aby wykonać wszystkie zadania ze sprintu?

- Nie. Tego nie powiedziałem. Powiedziałem tylko, żebyście unikali napychania sprint backloga rezerwowymi zadaniami. Tylko tyle. Popełniasz błąd wnioskowania polegający na niewłaściwym odwróceniu implikacji. Poczytaj o błędach poznawczych. np. Sztuka myślenia

26. Przypuśćmy zatem, że dobierzemy jakieś zdanie z product backloga. W takim razie te zadania nie zostaną przetestowane biznesowo do końca sprintu.

- To podzielcie na mniejsze i sami testujcie biznesowo.

27. No, to powiedzmy, że zostało 2h do końca sprintu, dobrałem zadanie i na pewno nie zostanie ono przetestowane biznesowo do końca sprintu.

- No, prawdopodobnie nie zostanie.

28. Ale wcześniej napisałeś, żeby nie robić takich zadań, bo jak skończymy współpracę na tym sprincie, to nam nie zapłacą za nieodebrane zadania.

- Istnieje takie ryzyko. Zmniejszasz je dobierając zdania z wierzchu product backloga w nadziei, że kolejny sprint jednak ruszy, dokończysz to zadanie i otrzymasz zapłatę.

Lecz zanim zdecydujesz się rozgrzebać zadanie, które będziesz kontynuował w kolejnym sprincie, najpierw przeprowadź w/w 27-punktowy ciąg rozumowania ;)

Conversation Patterns: A User Story Template Revisited

This article is part of my work on Conversation Patterns for Software Professionals

---

This is well known user story template:

As a [role]
I want [feature]
so that [benefit]

But I noticed that because of this template teams focus mostly on features. What is wrong with that? However, discovering the right features is the goal of user stories, but at the same time a benefit part is neglected.

Consider following (anti)stories:

• As a User I want to login, so that I use a system
• As a User I want to print report, so that I can do my job
• As a User I want to click RMB, so that I choose wanted option from the context menu

These are examples of stories where a benefit part was not clarified enough. Again, what is a big deal?

In general a benefit is a need and another type of a need is a problem to be solved. So, a role wants a feature because one requires a benefit or problem solution. This is natural feature - business need relation.

A feature is a way to satisfy business need by the software functionality. Having need clearly defined a team and PO are able to discover set of features satisfying business need and choose the best one.

But using a given user story template we start a conversation from a feature without talking about a business need first.

Then we want to fill a template so it is possible to put some general benefit instead of, you know, the "real" one.

My solution is: use a slightly different user story template:


In order to [benefit/problem to be solved]
I want [feature]
Being a [role]


---

UPDATED@10/03/2014
Upon further study I decided to redesign the given template as follows:

In order to avoid [problem to be solved]/In order to achieve [expected benefit]
As a [role]
I want [feature]

So now we have two US templates for each of stakeholder's need favour.

---

This template helps to focus on business need first. When the one is clearly defined you may start discovering possible features to satisfy the need.

Niezadowolenie ma sens

Product Owner, który "odpuszcza" w trakcie demo, działa przeciw zespołowi. O co chodzi?

Iteracja była trudna. Wyskoczyło sporo bugów, związanych z niezaplanowaną refaktoryzacją dawno zapomnianego kawałka systemu. Zespół pracował na najwyższych obrotach, a schodki na burn-up chart zdawały się nie mieć końca. W ostatnim tygodniu wszyscy z utęsknieniem czekali na piątek, a gdy już nadszedł, od samego rana czuć było podekscytowanie zbliżającym się demo.

Wysprzątany pokój, rozstawiony rzutnik, zespół w świątecznym nastroju. Brakuje tylko czerwonych goździków dla zasłużonych. Wszyscy z uwagą śledzą rozmowę PO z jednym z programistów, prezentującym implementacje poszczególnych historyjek. Scenariusz po scenariuszu idą jak z płatka i nagle..&^@%!@

W tym momencie w zgodzie z niektórymi teoriami Wszechświat się rozgałęzia i mogą wydarzyć się co najmniej dwa scenariusze.

Scenariusz A

Następuje chwila niezręcznej ciszy, podczas której PO patrzy na napięte twarze zespołu, na których między wielkimi, jak u Puszka Okruszka oczami, powiększa się nabiegły łzami znak zapytania.

Ktoś powiedział, że największe boje w historii ludzkości wydarzają się w zakamarkach ludzkiej duszy. Nie inaczej jest teraz. Po długiej jak wieczność chwili, na twarzy PO pojawia się miękki uśmiech.
- Ok - rzuca ciepło - powiedzmy, że jest zrobione. Dokończycie w międzyczasie ("międzyczas" - niepotwierdzony żadną poważną teorią bufor czasowy, w którym da się wykonać więcej pracy, niż w całym projekcie łącznie).

Wszyscy oddychają z ulgą. Znów jest miło. Po zakończonym demo ludzie w pośpiechu wymykają się z biura. Już weekend. Można odsapnąć i zająć się czymś innym niż to natrętne, kołaczące na skraju świadomości odczucie wewnętrznego "fuj".

Niestety historia lubi się powtarzać, więc i ta się powtórzyła. Po trzeciej podobnej repecie, idąc na demo ludzie zaczynają włączać autopilota itd., itd., itd.

---

Scenariusz A'

Nastąpiła pełna napięcia cisza. Cisza. Przeciągająca się cisza. PO wziął głęboki oddech i:
- Przykro mi, ale to jest DONE. Nie zgodnie z tym, co ustaliliśmy jako DONE.
- Ale przecież jest to tylko kwestia kosmetyki. Parę godzin i będzie gotowe. A ta druga historyjka jest gotowa, tylko jeszcze nie wdrożona. Projekt nam się za długo buduje.
PO popatrzył na rozmówcę wzrokiem Johna Wayne'a i powiedział:
- Gdybyś miał za tę pracę zapłacić z własnych pieniędzy, to zapłaciłbyś?

Niemal w tej samej chwili, Piotrek wybiegł z sali trzasnąwszy drzwiami, a w reszcie grupy, wybuchła gorąca dyskusja, od czasu do czasu ocierająca się o kłótnie.
- Nie - powtórzył twardo PO - Nie jest DONE. Nie odbieram.
Na tym dyskusja się zakończyła.

Gdy pył opadł, zespół zasiadł do retrospekcji. Mieli nad czym dyskutować, więc ledwo zmieścili się w założonym czasie. Ustalono, że: Paweł z Marcinem rozpoznają temat serwera CI i one-click building, koncept zadania zawsze będzie analizowany zespołowo, blokery będą omawiane na forum i w razie potrzeby zespół decyduje się na swarming, historyjki z najbliższego sprintu zostaną ponownie przeszacowane, refaktoring będzie robiony zawsze parami.

Ludzie wychodzili z biura w znakomitym nastroju. PO ich cholernie wkurzył, ale znaleźli rozwiązanie. Zawsze znajdują. Wprowadzili do swojej pracy niezbędne modyfikacje. To się już nie powtórzy. Nie ma prawa się powtórzyć. Po weekendzie zaczyna się nowy sprint. Każdy z programistów już widzi najbliższe demo i PO śpiewającego peany na ich cześć.

---

Wniosek

Czasem, nie chcąc sprawiać komuś przykrości, robimy mu krzywdę.

Niejednorodny zespół

Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule - napisali niegdyś mądrzy ludzie i zespół w tej postaci jest super. Jednakże robiąc przegląd inwentarza, możesz dojść do wniosku, że stan rzeczy rzeczy w Twoim zespole oraz zasoby, którymi dysponujesz, odbiegają od tego docelowego obrazka. Co wtedy?

Co jest?

Może się dla przykładu okazać, że "dostałeś" pięciu programistów, trzech testerów, analityka oraz Scrum Mastera z nadania, który ostatnimi czasy poświęcał się wyłącznie zarządzaniu.

W takiej konstelacji możesz się spodziewać następujących objawów:

• Polaryzacja między testerami a programistami; nie piszę "wrogość", lecz właśnie polaryzacja my-wy: wy zrobiliście błąd, wy skopaliście testy, my coś zaimplementowaliśmy, itp.
• Programiści mają chroniczny opór przed testowaniem
• Testerzy biorą znikomy udział w planowaniu
• Analityk nie za bardzo może znaleźć swoje miejsce w zespole
• Pojawia się zastanawiająco dużo spadów z poprzednich sprintów

Może się okazać, że po przeprowadzeniu małego śledztwa, ma miejsce następujący związek przyczyn i skutków:

Jak mogłoby być?

Długoterminowym celem mogłoby być oczywiście doprowadzenie do sytuacji, w której każdy jest wspomnianym "developerem", ale o tym na początku lepiej nie mówić głośno:)

Co pomiędzy?

Sądzę, że w takiej sytuacji kluczowe jest, nie tyle męczyć ludzi, aby byli idealnym zespołem, co wydobyć tu i teraz to, co najlepsze. Bardzo dobrym początkiem będzie przeorganizowanie sposobu planowania. Otóż:

• Planujcie podgrupami dzielonymi względem testerów, np. tester+2*programista
• Każda grupa otrzymuje swoje US, które dzieli na zadania
• Analityk chodzi i doradza :)
• Wyodrębniajcie zadania: programistyczne, testerskie, analityczne
• Po zakończeniu dekomponowania grupa przedstawia swoje US, a reszta zadaje pytania kontrolne Czy uwzględniliście to, a to? i jeśli nie, to dodajemy kolejne zadania (uwaga celowo jest tu odwrócenie: grupa nie przedstawia swoich zadań, lecz odpowiada na pytania kontrolne zespołu, gdyż w przeciwnym razie zamęczycie się i zanudzicie

Pytania retrospekcyjne po wprowadzeniu w/w zmiany (po jednej bądź dwóch iteracjach):

• Jak oceniam współpracę między testerami a programistami?
• Czy wciąż mówimy o sobie my-wy?
• Czy będziemy mieli spady w najbliższej iteracji?
• Jak dużo zadań doszło w trakcie iteracji? Jakiego rodzaju były to zadania?

Kilka słów o roli analityka
Analityk bywa w Scrumie czasem zagubiony. W jaką rolę ma się wcielić Proxy Product Owner, Scrum Master, Product Owner? Jedną z powtarzanych przyczyn zmieszania analityka są te cholerne straty w projekcie. No bo jeśli jedyna wartością jest "działające oprogramowanie", reszta to strata, a jemu kazali pisać dokumentację, to ma poczucie, że wykonuje bezsensowną i bezwartościową pracę.

Myślę, że te "straty" wymagają małego komentarza. Analityku, jeśli w założeniach projektu stoi napisane, że ma być dokumentacja analityczna w projekcie, bo tak wymaga klient, ustawa czy ktokolwiek inny, to dokumentacja również jest wartością w projekcie i również dodaje punty do business value.

Przykładowe zadania, w których analityk może wspierać zespół:

• współpraca i mediacje:) z PO
• backlog grooming
• prowadzenie Product Canvas; ciekawe linki: tutaj, tutaj i tutaj.

Ćwiczenie dla zespołu

Retrospekcje dość często opierają się na wrażeniach. Dyskutujemy o naszych spostrzeżeniach i o zmianach. Wrażenia dają wiele informacji, lecz dla równowagi chciałbym zaproponować Twojemu zespołowi retrospekcję opartą na liczbach.

W najbliższej iteracji podejmijcie jedną praktykę: ilekroć karteczka trafi do kolumny IN PROGRESS, oznacz datę umieszczenia w tej kolumnie oraz datę umieszczenia w kolumnie DONE.
Podczas retrospekcji wybierzcie zadania, które przebywały w IN PROGRESS maksymalnie jeden dzień (typ A) oraz te, które przebywały tam trzy dni i więcej (typ Z), i odpowiedzcie na następujące pytania:

• Ile było zadań typu A? Ile było zadań typu Z?
• Na ile początkowo były szacowane zadania typu A oraz Z?
• Dla których zadań, A czy Z, błąd oszacowania jest mniejszy?
• Czy zadania typu A są sformułowane inaczej niż zadania typu Z? Na czym konkretnie polega różnica?
• Które z zadań są formułowane pełnym zdaniem? (z czasownikiem i rzeczownikiem)
• Czy któreś z zadań sformułowane jest w trybie rozkazującym?
• Które z zadań przechodzą Test Copy-Paste?*

I na koniec wnioski: w jaki sposób następnym razem należy formułować zadania.


*) Test Copy Paste - to dość dobry sposób weryfikowania konkretności zadania. Jeśli przeniesiesz swoje zdanie do innego kontekstu i wciąż ma ono sens, to prawdopodobnie jest mało konkretne. Na przykład zadania: Napisz test, Przygotuj dokumentację, Zaimplementuj serwis wyszukujący pasują wszędzie. Nieważne czy pracujesz nad CRM, portalem e-bankowości, czy sterownikiem klapy od sedesu - te zadania mają sens, w każdym z wymienionych kontekstów. Aż się prosi o ich zdekomponowanie.

Lecz zadania: Napisz test do porównywania dochodów klienta na wniosku z danymi biura nieruchomości, Zaimplementuj podgląd wniosku windykacyjnego zdefiniowanego w BAF po przeniesieniu do innej przestrzeni problemu tracą swój sens. Tracą go ponieważ ich sformułowanie jest na tyle związane z tym konkretnym kontekstem, że bez niego trudno jest zadania zrozumieć. Takie zadania mają bardzo wysokie actionability, są na tyle konkretne, że łatwo je wykonać OD RAZU. Oczywiście Test Copy-Paste nie jest zero-jedynkowy, lecz wyznacza pewne continuum konkretności i actionabilitności :) zadań.

Scrum jest trudny...

Sam nie wiem od czego zacząć:) Może najpierw przeczytaj artykuł Kiedy Agile nie zadziała

Zawsze gdy chciałbym z pełną odpowiedzialnością powiedzieć Tak, Scrum Wam pomoże. Go! mam pewien dreszcz niepewności. Wynika on stąd, że osoba która jest odpowiedzialna za wdrożenie Scruma chciałaby wiedzieć: po czym konkretnie poznam, że Scrum działa? po czym konkretnie poznam, że jest lepiej niż poprzednio? jak długo potrwa zanim zobaczę konkretne efekty? no i, ile to mnie będzie kosztować?.

Może się zdarzyć, że po wdrożeniu w jednym zespole, w drugim oraz po przeszkoleniu, jak to się ładnie mówi" propagatorów zmiany, nic się nie dzieje. Dlaczego? Mam parę tropów.

Samoorganizujący się zespół

Samorganizujacy się zespół jest możliwy. Nawet dwa czy trzy takie zespoły w życiu widziałem, a w jednym miałem przyjemność pracować. Ale to jest naprawdę duże wyzwanie stworzyć samoorganizujacy się zespół. Aby zespół się samoorganizował najpierw trzeba go świadomie zaprojektować, wyhodować. Mimo dużej wiary w ludzi trzeba uznać, że nie wszyscy ludzie w zespole mają jednakowe kompetencje. Nie każdy zespół, nie każdy jego członek podejmie odpowiedzialność.

Samoorganizujace zespoły się zdarzają. Najczęściej dziwnym zbiegiem okoliczności odpowiedni ludzie spotkają się w odpowiednim miejscu, gdyż tak jak wspomniałem, rzadko kiedy konstruuje się zespół w planowy sposób nie tyle pod kątem kompetencji technicznych, lecz pod kątem kompetencji "zespołowych" właśnie. Konstruowanie zespołu to kosztowna akcja wymagająca zaawansowanej wiedzy HRowej albo superwymiatacza z doświadczeniem, który zrobi to "na wyczucie".

Zawiązywanie się zespołu, przejście procesu grupowego to jakieś trzy miesiące. Scrum nastawia się na hodowanie zespołów i przydzielanie do nich projektów. W ilu organizacjach proces biznesowy jest tak ustawiony, że to jest możliwe? A w ilu zespół jest powoływany per projekt i rozwiązywany zanim jeszcze zdąży okrzepnąć.

Samoorganizaujacy się zespół to naprawdę wspaniała idea. I w dodatku idea, która bardzo dobrze działa. Ale to jest trudne...

Iteracje

Gdy zapytałem jednego kolegę w trakcie szkolenia, czy nie może odmawiać wykonywania zadań spoza iteracji (wszak Odwaga to jedna z wartości Agile), odpowiedział następująco: "Kiedyś próbowałem, ale mój manager powiedział ::Ok, pośmialiśmy się, a teraz do roboty::".

Iteracje pozwalają na wybranie najistotniejszych rzeczy "na teraz", dostarczenie ich z możliwością używania. Acha, no właśnie: potentially shippable increment - czy Twoi klienci rzeczywiście używają funkcjonalności w swojej pracy, od razu gdy im dostarczysz? Czy pracują może "na starym" a "testowy" używają do poklikania?
Albo jak często zdarzają się wrzutki w trakcie iteracji i co one powodują? Jak bardzo można skrócić iteracje, aby być bardziej responsywnym? Na ile można je skracać, zanim się okaże, że testy, testy regresji itd. są zbyt kosztowne przy tak krótkich iteracjach?

Praca w zamkniętych iteracjach jest świetna. W dodatku to naprawdę działa w niektórych organizacjach. Ale to jest trudne...

Dlaczego trudny?

Dlatego, że wymaga dość dużych zmian organizacyjnych, nie mówiąc już zmianie w sposobie myślenia. Scrum daje gotowy framework, który należy zaaplikować. A co ze skalowaniem? Tak, wiem, że wymyślono dobrze brzmiące nazwy. Ale skalowanie Scruma jest wciąż w powijakach. Czasem w ogóle się nie udaje i Scrum jest tylko z nazwy, czasem udaje się wystarczająco dobrze z pewną pomocą Prince2 albo PMI, a czasem udaje się znakomicie. Tak, są organizacje, którym udało się przeskalować Scruma. Ale to jest trudne...

Zmiany organizacyjne są długie, kosztowne i mogą się nie udać. Tak jak napisałem, Scrum jest naprawdę super, ale często okazuje się zbyt trudny do wdrożenia z zachowaniem oczekiwanych rezultatów.

A może Lean?. Nie chcę przypinać się do konkretnej implementacji Lean w wytwarzaniu oprogramowania, więc piszę po prostu Lean.
Punktem skupienia Lean jest optymalizacja procesu dostarczania, nie gotowy proces do wdrożenia, lecz jego optymalizowanie. Wychodzi nam, że dużo łatwiej zespołowi przestawić się na Lean. Ok, zespół jest również ważny, ale skupienie się na procesie dostarczania, pozwala jakoś żyć gdy zespół jednak trudno się samozorganizuje. Zazwyczaj pierwszym kluczowym krokiem jest przekonanie zainteresowanych do zredukowania WIP i coś już zaczyna działać. Gwoli wyjaśnienia: Lean nie jest oczywiście remedium na całe zło, ale po prostu start jest łatwiejszy niż ze Scrumem.