Pułapka optymalizowania procesu

Usprawnianie procesu, nacisk położony na wszelkie kwestie organizacyjne – to znamy wszyscy. A co ze stroną produktową? Co z robieniem właściwych rzeczy zamiast ciągłego skupiania się na „polerowaniu” procesu i na pracy we właściwy sposób? Czy da się zrównoważyć te kwestie i poświęcić więcej uwagi samemu produktowi? O tym w 21. odcinku podcastu Porządny Agile.

Zobacz wersję wideo

Dodatkowe materiały

• #010 – Product Discovery
• #020 – Porządny Sprint
• Książka „The Principles of Product Development Flow: Second Generation Lean Product Development„ Donalda Reinertsena

TRANSKRYPCJA

Kuba: Jakiś czas temu, w trakcie wspólnego szkolenia mieliśmy taką dłuższą dyskusję na temat tego, jak usprawniać proces, jak dobrze realizować Scruma, jak w dobry sposób pracować zwinnie i taka refleksja, która nas wspólnie z Jackiem po wszystkim naszła i którą chcemy się podzielić w ramach tego odcinka, to to, że dostrzegamy bardzo duże skupienie na tej stronie optymalnego procesu, optymalnego sposobu pracy, optymalnego sposobu funkcjonowania w sposób zwinny, jeśli chodzi o przestrzeganie pewnych reguł, a za mało skupienia czy za mało uwagi na tą stronę produktową. Mówiąc w skrócie – dużo uwagi idzie na to, czy pracujemy we właściwy sposób, a nie na to, czy robimy właściwe rzeczy.

Jacek: I generalnie, jakbym tak się miał zastanowić, jakie pytania słyszę najczęściej, to zwykle są to pytania, które bardzo mocno skupiają się na samym procesie wytwarzania, natomiast mało pytań, bądź w ogóle te pytania się nie pojawiają, dotyczy tego, czy tak naprawdę sensownie wykorzystujemy np. Scruma czy podejście zwinne do budowania właściwych produktów. Tej rozmowy nie ma. Myślę, że powodów jest wiele i nie chciałbym teraz w nie wchodzić, natomiast w dzisiejszym odcinku chcielibyśmy skupić się na tym, jak sensownie wykorzystać proces, ale tak, żeby nie zgubić tego, co dostarczamy przy użyciu tego procesu, czyli właściwego produktu.

Kuba: Ale w pierwszej części odcinka opowiemy trochę, co mamy na myśli, gdy mówimy, że nadmiernie skupiamy się na procesie. Zwłaszcza Scrum Master może czuć, że w zasadzie cały sens istnienia jego roli, to jest: żeby zespół nauczył się Scruma, żeby go przestrzegał, żeby w sposób zwinny cała tutaj grupa produktowa pracowała. No, problemy czy przykłady tego, co mamy na myśli, że tu jest za dużo uwagi na proces, to np. nadmierne skupienie się na velocity. Mnóstwo osób patrzy na miary procesowe, miary wynikające z procesu pracy, takie bardziej generyczne albo miary procesowe wynikające z już konkretnie praktyk wokół Scruma czy w „Scrum Guidzie” zawartych. No i np. velocity zespołu staje się jedną z rzeczy, która jest omawiana na każdym Sprint Review, analizowana na każdej Retrospektywie i gdzieś tam cała gra skupiona wokół tego, czy na wykresie się wszystko dobrze poukładało, czy te Story Pointy się dobrze ułożyły w jakiś trend, a może trend jest gorszy, a może trend jest lepszy? I, okej, fajnie jest o tym porozmawiać, natomiast niech to nie będzie sztuką dla sztuki czy i jak nam się buduje wykres.

Jacek: Innym przykładem takiej miary może być miara mówiąca o przewidywalności Zespołu Deweloperskiego, czyli stosunek tej ilości Story Pointów, którą zespół zaplanował czy zaprognozował na Planowaniu w stosunku do tego, co dało się dostarczyć. Co do zasady, w pewnych firmach, dla pewnych zespołów obserwowanie tej miary może być sensowne. Natomiast zbytnie skupianie się na tym, żeby tam się zawsze sumowało do stu procent może spowodować, że położymy akcent nie na to miejsce, na które byśmy chcieli.

Kuba: Podobnym problemem czy podobnym przykładem skupienia się na procesie jest to, co już wspomniałem o roli Scrum Mastera, czyli jakieś takie zafiksowanie się czy zbytnie skupianie się na tym, czy na pewno jesteśmy zgodni ze Scrumem czy super przestrzegamy „Scrum Guide’a”. No i tutaj, jakby, mogą być takie ekstremalne przypadki – ale spotykałem je w życiu – że np. Product Owner odkrywa jakąś nową, ważną okazję, która może wpływać na to, jak zespół może pracować. Może to jest jakieś nowe odkrycie interesariuszy, może jakiś użytkownik coś podpowiedział, a Scrum Master mówi: „Nie, nie ma możliwości wpływania na zespół, nie możemy z nimi rozmawiać, do zobaczenia na następnym Planowaniu Sprintu”. Czyli gdzieś tam nad wartość biznesową przedkładamy to, że musimy wypełniać w każdym możliwym przypadku – włącznie z jakimiś rzadkimi, kryzysowymi sytuacjami – musimy przestrzegać tego, jak my rozumiemy czy interpretujemy Scruma.

Jacek: I to w szczególności osoby, które nie do końca są fanami zmian toczących się w firmie czy samego tutaj konkretnie frameworka, no, bardzo łatwo, myślę, mogą też to wypunktować, ale tak naprawdę dyskusja toczy się o tym, czy to jest książkowy Scrum czy może jakiegoś aspektu Scruma nie wypełniamy, a tak naprawdę nie to jest najważniejsze w obliczu tego, czy dostarczamy wartość dla naszych klientów czy nie.

Kuba: No i obracając to – niejeden Scrum Master z zadowoleniem stwierdzi: „Mam absolutnie czystego Scruma”, a zespół dostarcza kiszkę, absolutnie nie korzysta z tego, żeby powiększać wartość, eksperymentować, kreatywnie rozwiązywać problemy biznesowe. No, to może się nie dziać, nawet jeśli mamy czystego Scruma. To znaczy, ten czysty Scrum, cokolwiek to znaczy, nie załatwia nam tematu tego, czy maksymalizujemy wartość.

Jacek: Inny przykład tego, co chcemy dzisiaj uchwycić w odcinku, jest taka przesadna zgodność proceduralna bądź zgodność z pewnymi ustaleniami bądź sposobem, w jaki firmy funkcjonują. Przykład, który mi tutaj przychodzi do głowy, to np. sposób planowania rozwoju produktu, czyli tworzymy roadmapę, jakieś takie kolejne kroki, jak będziemy rozwijać produkt. No i to, że ten plan został potwierdzony, zaakceptowany, powoduje że zaczynamy bardziej skupiać się na tym, żeby używać naszego sposobu pracy, żeby zrealizować tą założoną roadmapę, przez co trochę tracimy czujność na to, że być może w danym momencie pojawia się jakaś szansa rynkowa, pojawia się jakiś fajny pomysł, albo trzeba szybko zareagować na to, co się dzieje na rynku, no ale poprzez to, że jesteśmy ekstremalnie skupieni na roadmapie i mówimy: „To obiecaliśmy i przez najbliższy rok będziemy realizować dokładnie te rzeczy”, powoduje znów, że to wykorzystanie… proces przesłania nam to, co tak naprawdę moglibyśmy dostarczyć.

Kuba: I ta zgodność proceduralna tutaj już nie ma nic wspólnego z jakimkolwiek frameworkiem, podejściem czy praktykami zwinnymi, a bardziej jest związane z kulturą organizacyjną, no i sam byłem zarówno pracownikiem, jak i później też świadkiem – już jako konsultant takich organizacji – w których racjonalna perspektywa, że coś jest ważne, wartościowe, czasem stoi w sprzeczności z tym, że trzeba przestrzegać zasad. No i wiadomo, że są zasady, których przestrzegać trzeba, ale to np. jak właśnie roadmapa na rok wprzód obiecana na jakimś gremium ważnych osób staje się absolutnie wymówką, że jeśli przyjdzie nam do głowy cokolwiek zmieniać, to nie, bo ktoś nas później rozliczy z tego, czy wykonaliśmy roadmapę, a nie czy dostarczyliśmy maksymalną możliwą wartość, gdzie w rzeczywistości później się okazuje tak, że tą maksymalną wartością byłoby spełnienie, nie wiem, 1/3, 2/3 roadmapy, a resztę reagowaliśmy elastycznie w trakcie, odpowiadaliśmy na pojawiające się potrzeby.

Jacek: Takim domykającym przykładem jest przykład, gdzie zespół czy cała organizacja skupia się ekstremalnie na usprawnieniach procesowych, co oczywiście – co do zasady – jest bardzo sensownym podejściem, ale znów: to skupienie na usprawnianiu procesu powoduje, że to, co dostarczamy tym procesem, schodzi na drugi plan i bardzo fajnie zespół się usprawnia, zwiększa się efektywność, całe marnotrawstwo, które zespół jest w stanie zidentyfikować, jest usuwane, natomiast w tym wszystkim, poprzez to ekstremalne skupienie na procesie ginie nam produkt, no i rezultaty nie są takie, jak byśmy chcieli.

Kuba: I to jest bardzo ważny temat, zwłaszcza przestroga np. na Retrospektywy. Może się okazać, że takie „polerowanie” naszego procesu pracy, jako zespół, no, ma swój sufit, ma swoje skończone możliwości. Próbując zamienić to w taki pewien wzór matematyczny, no, jeśli zespół pracuje obecnie na 75% swojej mocy maksymalnej efektywności, no to poprawienie tej efektywności o kolejnych 5 punktów procentowych da nam 80% efektywności. A jeśli do danego zespołu – na ten zespół, na te moce przerobowe – damy, nie wiem, wytworzymy produkt o wartości 2, 3, 4-krotnie większej, to nawet jeśli ta wartość będzie realizowana w sposób bardzo nieefektywny, to i tak będzie wyższa niż słaba wartość realizowana przez bardzo efektywny zespół. I to bardzo mocno wiąże się z myślą, która jest promowana m.in. przez Donalda Reinertsena w książce „Flow Lean Product Development”, w której mocno Donald to właśnie zamienia w taki wzór i pokazuje, że ta strona produktowa jest o wiele ważniejsza niż efektywność procesu wytwarzania tego produktu. To jest zarówno strona ryzyk produktowych, które są o wiele groźniejsze niż ryzyka procesowe, jak i też takie korzyści z wytworzenia właściwego produktu są o niebo większe i warto w nie inwestować, niż korzyści z tego, że robimy byle jaki produkt, ale w bardzo słaby sposób. Zamieniając to w takie może chwytliwe hasło: „Idealny proces, w którym wytwarzamy nieprzemyślany produkt, to jest raczej przegrana. Nieoptymalny proces, ale tworzący przemyślany produkt, ma bardzo dużą szansę na wygraną”.

Jacek: I ta myśl generalnie, ona ze mną mocno rezonuje, bo to… ja to czytam, jako takie podejście: „Zacznij robić właściwe rzeczy, nawet jeśli czujesz, że nie jesteś jakoś perfekcyjnie przygotowany, nie czekaj na to, aż wszystko będzie świetnie opracowane i zapięte na ostatni guzik, tylko raczej zrób pierwszy krok, zobaczysz, czy te twoje założenia funkcjonują, zrób kolejny krok, czegoś się nauczysz, usprawnij proces. Kolejny krok, zobacz, co działa, co nie działa, zoptymalizuj”, czyli raczej zacznij z tym, co masz, tak trochę kanbanowo niż perfekcyjnie się przygotuj przez pół roku i wystartuj, no bo… to znowu może być taka sytuacja, że pół roku wielkich przygotowań, wpuszczamy nasz produkt na rynek, okazuje się, że właściwie nikt tego produktu nie chce kupić, no i pół roku tak naprawdę poszło… do piachu.

Kuba: I jak to teraz powiedziałeś, to mi się momentalnie przypomniały rozterki, które się działy w jednej z firm, w której kiedyś pracowałem, że, no Agile fajnie, ale jeszcze lepiej byłoby Agile robić, gdybyśmy mieli pełne środowisko Continuous Integration, Continuous Deployment, pokrycie testami w stu procentach, przebudowaną architekturę na nowe sposoby, przygotowane zespoły, superidealnie wszystko funkcjonujące – i tam był taki argument: „Odroczmy pracę w sposób zwinny, bo nasz proces jest jeszcze nieoptymalny”. No i to jest dokładnie hasło z tego odcinka – być może naprawdę nie trzeba mieć optymalnego procesu, bo o wiele więcej efektu uzyskamy, robiąc właściwe rzeczy, dostarczając je iteracyjnie przyrostowo, robiąc eksperymenty, skupiając się na wartości. Nawet jeśli nasz proces trąca myszką i przypomina rozwiązania z XX wieku.

Jacek: W dalszej części odcinka chcielibyśmy zaproponować Ci kilka pomysłów na to, jak przełożyć więcej ciężaru na tą stronę, jak robić właściwe rzeczy, jednocześnie pozostając w takim sposobie myślenia, że proces jest ważny, ale jednak żeby trochę więcej tego produktu było na pierwszym miejscu. I pierwszą naszą rekomendacją jest zapoznanie się, a oczywiście najlepiej w praktyce zastosowanie podejścia Product Discovery. O Product Discovery mówiliśmy w dosyć rozległy sposób w odcinku dziesiątym, gdzie wprowadziliśmy to pojęcie, pokazaliśmy, czym jest, natomiast ta myśl, żeby skierować swoje zainteresowanie w stronę Product Discovery była dla nas takim pierwszym intuicyjnym krokiem, z tego powodu, że Product Discovery główny nacisk kładzie oczywiście na produkt, ale przede wszystkim na to, że dajemy sobie bardzo dużą przestrzeń na zweryfikowanie, czy aby nasze pomysły, idee i jakieś nasze przewidywania rynkowe, czy one faktycznie mają sens. Tak więc, gdybym miał zarekomendować komuś, kto chce trochę wyjść z tego poziomu „polerowania” procesu i zastanowić się, czy aby na pewno robi właściwy produkt, no to Product Discovery wydaje mi się takim bardzo sensownym pierwszym krokiem, żeby wejść w ten bardzo rozległy świat produktowy.

Jacek: I dosyć powiązane z Product Discovery jest to, że jak rozmawiam z kimś o w ogóle czy konkretnie całym podejściu czy jakichś technikach z tego całego nurtu związanego z tym odkrywaniem produktu czy potrzeb użytkownika, klienta itd. itd., to jest taka myśl: „Nie no, to kosztuje, to zajmuje czas, to zajmuje czas zespołowi, to… my wiemy dobrze, co trzeba robić”, czyli taka perspektywa: „Szkoda marnować kasę na to, szkoda marnować czasu, szkoda marnować mocy przerobowej zespołu na takie czynności”. Zacznijmy po prostu dostarczać, zgodnie z pierwszym pomysłem. I tutaj jest bardzo mocno powiązane z taką moją… może autorską obserwacją, że o wiele łatwiej optymalizuje się stronę kosztową niż stronę przychodową. Jeśli mamy takiego klasycznego business case’a, no to on ma stronę kosztów – wszystkie koszty, które są potrzebne do tego, żeby wytworzyć produkt, przygotować jakieś rozwiązanie – oraz stronę przychodową – to są jakieś oszczędności, które to coś wygeneruje, to są jakieś nowe przychody, nowi klienci, jakieś inne wartości – może mniej mierzalne – związane z bezpieczeństwem, z jakimś komfortem użytkowania naszego produktu i te rzeczy przychodowe to jest często bardzo mocno zgadywanie, mamy bardzo słabą kontrolę nad tym, natomiast strona kosztowa wydaje się być o wiele bardziej w zasięgu ręki. To jest konkretny budżet, to jest konkretna kasa, to są jakieś faktury, to są jakieś dniówki pracy członków zespołu. No i duża uwaga idzie na to, co dokładnie dobrze widać niż na to, co jest tylko jakimś takim przypuszczeniem, że może jak byśmy zrobili trochę lepszy produkt, to będzie lepszy przychód i tu wszyscy, akurat po tej stronie, to wszyscy czują doskonale, że to jest totalne zgadywanie. A, powiedzmy, że… pomijając temat tego, że w wielu projektach te terminy i prognozy pracy są łatwe do zmiany, czy łatwo je przekraczać, no to wydaje się, że jest nad tym trochę większa kontrola. I, żeby tylko nie narzekać albo bawić się w osobę obserwującą rzeczywistość, to, co warto tutaj zrobić, no to właśnie zaatakować cały ten temat, jak my mierzymy wartość, jak my prognozujemy korzyści z naszej pracy. I coś, co jest często bardzo nieoczywiste z perspektywy poszczególnych zespołów projektowych, to jak tu wygląda np. temat przychodów z tej naszej pracy, czyli np. ile zarobimy na tym, co wytworzymy, ile nasza firma zarobi na tym, co wytwarzamy w ramach danego zespołu projektowego czy w ramach danego produktu. I jeśli w ramach naszych analiz pracy czy usprawniania procesu skupimy się na tym, jakie są KPI, miary, jak można je przyspieszyć, jak można je zintensyfikować, to może się okazać, że bardzo mocno otworzą nam się oczy i w ogóle zaczniemy rozmawiać językiem tych właśnie korzyści biznesowych i szukać optymalizacji, jak tu szybciej, wcześniej, jak lepiej, więcej dostarczyć tej wartości biznesowej. I jeśli będziemy umieć regularnie powoływać się na tą stronę, to często w ramach jakichś takich – czy wewnętrznych dyskusji w zespole czy w dyskusjach wewnątrz organizacji pomiędzy zespołami, no, stajemy w ogóle w awangardzie osób, które myślą o biznesie, a nie o tym, jak tu oszczędzić parę kosztów. Co wraca do np. Product Discovery, możemy poświęcić tydzień warsztatu na jakieś techniki z tego nurtu, później konsekwentnie, iteracyjnie rozwijać nasz produkt, korzystać z tych rozwiązań i nie przejmować się, że 90% czasu zajmujemy się czymś innym niż stricte realizacja z góry założonego zakresu, bo jak już przyjdzie czas, że realizujemy ten zakres, który już wymyśliliśmy czy odkryliśmy, to to jest po prostu wysoka wartość, najwyższa możliwa wartość, to jest ciągłe dostarczanie wartości.

Jacek: No to w sumie jedyny komentarz do tej twojej wypowiedzi jest z mojej strony taki, że – powiedziałeś na początku, że Discovery może być kosztem, natomiast warto spojrzeć na to z tej strony, jak dużym ryzykiem jest zawierzanie naszym odczuciom i spekulacjom i po prostu powiedzenie sobie: „Pół roku możemy spokojnie robić, zrobimy i wdrażamy produkt/rozwiązanie/usługę” – takie podejście jest ekstremalnie ryzykowane. Wyobrażam sobie sytuację, w której bardzo dobrze znamy rynek, mamy świetne czucie, no ale nadal jest to dosyć duże ryzyko, no bo de facto odpowiedź, czy wykonaliśmy dobrze robotę, będziemy mieli za pół roku na przykład. Z kolei w takim podejściu, gdzie dostarczamy iteracyjnie – i tak jak powiedziałeś, skupiamy się na biznesie, no to pierwsze sygnały będziemy mieć już bardzo wcześnie.

Kuba: I to, co mówisz, bardzo wiąże się z taką kolejną radą, czyli radą, żeby mierzyć rezultaty naszej pracy – cokolwiek robimy – czy to jest jakiś mały Przyrost, czy to są rezultaty jakichś wdrożeń, czy to są rezultaty jakichś uruchomień nowych rynków, cokolwiek jest w realiach naszego produktu czy projektu, to zdecydowane przerzucenie się na tę perspektywę mierzenia rezultatów, mierzenia rezultatów biznesowych i podejmowania wszystkich decyzji w naszym produkcie czy kolejnych kroków w rozwoju, na bazie danych, które już posiadamy – i to, co ważne, danych z rynku – nie skupianie się na opiniach, nie dyskutowanie o tym, co nam się wydaje, co przewidujemy, tylko posiadanie pewnych miar i posiadanie pewnych konkretów czy konkretów, na których można bazować.

Jacek: No, żeby móc mierzyć rezultaty i podejmować decyzje na podstawie danych, to wcześniej trzeba mieć też sensownie działający proces, na takiej zasadzie, że faktycznie te nasze Sprinty powinny produkować Przyrosty Produktu – mówiliśmy o tym w odcinku 20, jak to dobrze zrealizować, więc warto też z tym odcinkiem się zapoznać, natomiast, no, tutaj, absolutnie, w sensie, ja o każdym produkcie myślę sobie w ten sposób, że – tak metaforycznie – że zaczynamy trochę we mgle, robimy krok, no i ten krok może nam coś pokazać i możemy się coś z niego nauczyć – i tak stopniowo powinniśmy być w stanie tą mgłę produktową – czyli te wszystkie nasze niewiadome, hipotezy i wątpliwości – rozrzedzać. A możemy je rozrzedzać tylko w ten sposób, jeżeli zaczniemy testować, sprawdzać, mierzyć się z rzeczywistością, no bo w alternatywnym scenariuszu zamykamy się w pudełku, przez pół roku robimy development, no i pokazujemy światu nasz rezultat. Okej, możemy po pół roku zareagować, na zasadzie: dostaniemy jakieś dane z rynku i zobaczymy, czy to jest to, na co czekaliśmy, natomiast, no, tutaj moja rekomendacja jest taka, nie musimy czekać tak długo, warto skupić się na tym, jak stworzyć minimalną wersję produktu, superuproszczoną, ale już dającą wartość i pozwolić rynkowi trochę z tym produktem się pobawić i wtedy możemy zobaczyć, czy te parametry czy te wskaźniki KPI, których się spodziewaliśmy, no, czy one rosną, maleją czy w ogóle produkt rezonuje z użytkownikiem.

Kuba: I zamieniając to na taką bardzo konkretną poradę, jeśli czujesz, że w swoim zespole aktualnie tych miar nie masz albo nie macie jako cała organizacja, poszukaj chociaż jednej miary, takiej bardzo prostej, wprowadźcie to co Sprint Review. Warto patrzeć przede wszystkim właśnie na taką miarę, jak performuje nasz produkt, jak się sprzedaje, jak go widzą nasi klienci, a nie – wracając do przykładów z początku odcinka – jak nam się układa velocity. To jest wtórne, to jest superwewnętrzna miara, a to jak, nam się sprzedaje produkt, jaka jest wartość, jest ważną miarą biznesową i może być bardzo ważną inspiracją do dalszych działań.

Jacek: Tak, tylko jeden komentarz, pracując kiedyś z zespołem, stawiałem za każdym razem kreskę – uczestniczyłem w przeglądzie Sprintu – stawiałem za każdym razem kreskę, kiedy mówili o rzeczach absolutnie technicznych i pod spodem miałem przestrzeń na stawianie kresek, kiedy mówili o aspektach biznesowych. Na koniec spotkania miałem kilkanaście kresek technicznych i właściwie żadnej kreski biznesowej i bardzo podobny test możesz sobie zrobić na najbliższym Przeglądzie, jak często podczas Przeglądu Sprintu czy ogólnie Przeglądu Produktu, rozmowa toczy się o tym, że: „Ale zobaczcie, popatrzmy na wskaźniki, zobaczmy, jaki był rezultat. Zrobiliśmy ankietę, i co z niej wyniknęło”. Jak bardzo to jest rozmowa na bazie danych, a jak bardzo to jest dyskusja na zasadzie: „Taki jest plan, jak widzicie, idziemy w dobrą stronę, velocity skoczyło o 2%, a przewidywalność spadła o 4, ale mamy to pod kontrolą”. Zachęcam do szybkiego quizu przy najbliższej okazji.

Kuba: To idąc tym tropem konkretnych porad, co można zrobić, jeśli nasze dotychczasowe argumenty Cię przekonały, to kolejny punkt: Mocne skupienie się w swojej roli na pracy z Product Ownerem i pracy z klientem, jeśli jest to wykonalne w Twoim kontekście czy w Twoich realiach. To jest takie hasło zwłaszcza właściwe dla osób, które pełnią rolę Scrum Mastera czy też Agile Coacha. Czasem dużo uwagi idzie na zespół, na sposób pracy zespołu, a ten Product Owner tak po prostu sobie gdzieś tam jest, wykonuje rolę, wykonuje pracę właściciela produktu, jest sobie jakiś tam Backlog, ale, no, jest. W myśl tej koncepcji z tego odcinka dużo większe rezultaty da to, że poprawimy naszą relację z Product Ownerem, poprawimy sposób wykonywania pracy w tej roli tej osoby i nauczymy, czy zainspirujemy tą osobę do tej pracy zgodnie z tym, co w ramach tego odcinka nagrywamy.

Jacek: Bardzo mnie często zaskakuje reakcja zespołów, kiedy rozmawiając z nimi właśnie o takim przesunięciu się trochę bardziej w stronę rynku konkretnych danych czy klienta, pytam się, jak często mają szansę doświadczyć interakcji z prawdziwym użytkownikiem i często reakcja jest taka, że: „W życiu, to jest niemożliwe, my jesteśmy za daleko, a w ogóle kto by pomyślał, przecież my nie możemy takich rzeczy na takim wczesnym etapie pokazywać, bo co oni pomyślą”. Jakby… to nie musi być taki drastyczny skok na główkę z 15 metrów, to mogą być małe kroki, możemy pokazywać kawałki naszego produktu naszym najbardziej zaufanym klientom, osobom, które są z firmą bardzo długo. Można wydzielić jakąś taką mniejszą, zaufaną grupę osób, które już teraz być może dzielą się swoimi obserwacjami na temat produktu, wysyłając jakieś zgłoszenia na Cutomers Service czy pisząc maile. Bardzo łatwo, na bazie moich doświadczeń, jest taką osobę wciągnąć trochę bardziej, żeby zyskać jakiś wartościowy feedback i wcale to nie jest tak nierealne jak niektórym osobom się wydaje, że gdzie będzie ten klient jest taki trochę wyidealizowany i nie możemy chociaż przez chwilę mu pokazać, że jesteśmy nieperfekcyjni, bo on przestanie kupować nasze produkty. Absolutnie się nie zgadzam z taką hipotezą.

Kuba: Idąc dalej tropem podpowiedzi co do skupienia się na rzeczach zgodnych z ideą tego odcinka, no to warto zwrócić uwagę na Backlog Produktu – i tutaj podpowiedź nasza to to, żeby nie traktować Backlogu Produktu jako listy potocznie zwanych „feature’ów”, czyli jakichś konkretnych cech czy produktu, czy funkcjonalności, czy jakichś kolejnych elementów produktu, czyli naszym – to jakby tutaj to rozsupłując – konkretnych kawałków zakresu. I wiele Zespołów Scrumowych niestety sprowadzanych jest do wytworzenia konkretnych kawałków zakresu. Bardzo ciekawą alternatywą – zgodną z duchem tego odcinka – może być traktowanie Backlogu jako listy hipotez czy listy eksperymentów. To może oznaczać, że te elementy w Backlogu muszą być sformułowane trochę inaczej niż „zbuduj zakładkę”, bo to może oznaczać: „sprawdźmy nową metodę logowania przez konkretnego partnera, np. Facebooka, czy ona pozytywnie wpłynie na poziom rejestracji nowych użytkowników” – i to będzie eksperyment „zróbmy coś, żeby było więcej nowych użytkowników”, a nie: „podłączyć logowanie przez Facebooka”, bo to jest z góry zamknięty zakres, który kompletnie nie ustawia nas w tej roli eksperymentatorów. I na początku te eksperymenty pewnie nie będą przesadnie odważne, ale jeśli wejdzie nam w krew ciągłe zgłębianie, co tak naprawdę chcemy sprawdzić, jaką mamy hipotezę, co nam się wydaje, że trzeba zrobić albo jaki problem jest w ogóle do rozwiązania, to może się okazać, że co prawda ten Backlog będzie o wiele bardziej taki otwarty, ale jednocześnie zostawia mnóstwo przestrzeni na to, żeby właśnie mówić o tym, jakie wartości mamy dostarczać, a nie, który kawałek zakresu – zgodnie z wyceną – ma być zrealizowany w najbliższym Sprincie.

Jacek: No i tu znów ta porada, myślę, że u niektórych z Was mogła wywołać lekkie przerażenie, w sensie, na bazie doświadczeń częściej jednak widzę, że te Backlogi to jest zakres niż lista hipotez. Natomiast, znów, no takim bardzo konkretnym pierwszym krokiem może być umówienie się: „To zróbmy jeden mały eksperyment per iteracje” czy „Zróbmy jeden mały eksperyment per Sprint” i zobaczmy w ogóle, jak się z tym czujemy. Zobaczmy w ogóle jaka jest bariera wejścia, żeby taki eksperyment przeprowadzić. Być może kultura firmy jest na ten moment absolutnie niegotowa na coś takiego. A może się okazać, że to jest coś, co otoczenie managerskie podświadomie oczekuje od zespołów, że chcieliby, żeby byli tacy pro-aktywni, ale to się nigdy nie zadziało i to może być fajne zaskoczenie i być może znajdziecie partnerów, którzy zaczną Was wspierać w takim podejściu, więc pierwszy mały krok, sprawdzający w ogóle grunt, na ile to jest możliwe i jakie przeszkody są do pokonania, żeby ten sposób myślenia stał się takim podejściem domyślnym.

Kuba: I ostatnia rada związana z tym, co w praktyce można zrobić, żeby więcej uwagi skupić na właściwym produkcie, to perspektywa układania Backlogu nie po kolejności wykonywania zadań – idąc tropem tego tematu zakresu – że skoro jest jakaś aplikacja na przykład, to ona musi mieć stronę startową i później pierwszą zakładkę, drugą zakładkę, trzecią zakładkę, tylko w praktyce zastosujmy to, co już w „Przewodniku po Scrumie” jest przemycone, że właściciel produktu powinien maksymalizować wartość. I teraz jeśli w naszym Backlogu ta wartość w żaden sposób nie jest odzwierciedlona, no to mamy kłopot, bo nie możemy poukładać tej wartości, bo jej w żaden sposób nie formułujemy, nie definiujemy. Jak można zmierzyć wartość, jak ją można formułować, jak ją można przedstawiać – to jest akurat temat na zupełnie osobny odcinek, który nagramy w przyszłości, ale tutaj chcemy dać tutaj do myślenia tym, żeby gdzieś przemycić temat, że niektóre elementy Backlogu są mniej wartościowe, a inne bardziej i jak najbardziej forsować to, żeby w pierwszym kroku realizowane były te elementy czy te hipotezy czy te eksperymenty, które na ten moment przewidujemy, że będą bardziej wartościowe.

Jacek: No i ten sposób, który powiedziałeś, czyli że zaczynamy od strony logowania, pierwsza, druga, trzecia zakładka absolutnie blokuje możliwość podejmowania decyzji co do realease’u produktu w zależności od naszego, nazwijmy to, widzimisię. W sensie, jeżeli przyjdzie taki dzień, że Product Owner czy właściciel biznesowych będzie chciał powiedzieć: „Dobra, startujmy”, no to może się okazać, że mamy trzy kroki z pięciu w procesie zrobione, no i to powoduje, że proces po prostu cały nie działa. Gdyby podejść do tego myśląc o wartości, to byśmy być może zrobili – trzymając się twojej metafory – po najważniejszej funkcjonalności w każdej zakładce, co już by pozwoliło przejść przez cały proces użytkownikowi, no, czyli w założeniu rozwiązałoby to jakiś jego problem. I to takie podejście można zastosować niezależnie czy pracujemy w Scrumie czy po prostu pracujemy zwinnie nad jakimś produktem.

Kuba: I gdy coś takiego sugeruję w zespołach, to od razu słyszę pierwszą wymówkę – bo nie mogę tego traktować inaczej niż wymówkę – że: „No ale skąd my będziemy wiedzieć, co jest wartościowe, a co nie”. Oddzielny temat, oczywiście, są dziesiątki metod na to, żeby to spróbować zbadać, sprawdzić czy potestować, ale w ramach tutaj tej rozmowy ja bym chciał może o wiele bardziej podkreślić to, że oczywiście nie będziemy wiedzieć na 100%, to są tylko pewne założenia, przypuszczenia, ale te założenia są lepsze niż nic. Są lepsze – najwyżej w efekcie eksperymentu się dowiemy, że np. przypuszczaliśmy, że jakaś cecha produktu będzie wartościowa, a rynek uważa trochę inaczej, i mamy przynajmniej jakąś nową wiedzę. Okazuje się, że sortowanie po nagłówkach nasi klienci nie cenią tak wysoko i w przyszłości, gdy będziemy rozwijać nasz produkt, powinniśmy pamiętać o tej lekcji, że w żaden sposób sprzedaż naszego produktu nie wzrosła, mimo że na naszych listach nagłówki dają się sortować. I, podsumowując cały odcinek, takie hasło ostatnie jest takie, że zachęcamy do tego, żeby wyluzować – tak potocznie nazywając – z optymalnym procesem, a o wiele mocniej skupić się na tym, żeby – pomimo odrobiny chaosu lub nieefektywności w procesie – maksymalizować realizację właściwych rzeczy. A podsumowując konkretne rady, które chcieliśmy przekazać w tym odcinku, zachęcamy Ciebie do wrócenia do materiału z 10 odcinka na temat Product Discovery, zachęcamy do tego, żeby zwrócić uwagę na to, czy w ramach Twojego zespołu patrzycie na stronę przychodową Waszego produktu czy wartość biznesową Waszego produktu. Mierzcie rezultaty, skupiajcie się na rezultatach co iterację, co Przyrost i kolejne decyzje na tej bazie podejmujcie. Skup się, jako Scrum Master czy Agile Coach na tym, żeby popracować z Product Ownerem, żeby zdobyć kontakt do klienta i zaprosić tego klienta do pracy z zespołem. Zamieńcie swój Backlog na listę hipotez i eksperymentów i zacznijcie na tej bazie o wiele odważniej kontestować zlecany Wam zakres przez kogokolwiek, kto może Wam zlecać. I zwróćcie uwagę, czy Wasz Backlog realnie poukładany jest po wartości i maksymalizujcie tą wartość biznesową.

Jacek: Jeżeli tematy, które poruszamy w podcaście wydają Ci się interesujące i chciałbyś bądź chciałabyś pogłębić te zagadnienia w praktyce, to szykujemy bardzo ciekawą opcję, mianowicie 7 i 8 listopada spotkamy się w Poznaniu na szkoleniu, które nazwaliśmy „Porządny Agile”. Będzie to szkolenie, podczas którego chcemy bardzo głęboko zanurkować z Tobą w meandry zwinności, podyskutować na zaawansowanym poziomie o tematach, które poruszamy w podcaście i jeżeli ta krótka zajawka jest dla Ciebie interesująca, to zapraszam Cię na stronę porzadnyagile.pl/szkolenie.