Wygląda na to że im wyższa temperatura, tym poważniejsze przemyślenia. Podobnie jak to miało miejsce w ostatnich kilku tekstach i filmach, dzisiejsze pytanie „Komu robimy dobrze?” jest co najmniej dwupoziomowe.
Dla kogo ten cały agile?
Zacznijmy od początku, czyli od naszego ulubionego Agile Manifesto i ogólnie agile mindsetu, które mówią, że nasze prace wykonujemy po to, żeby zadowolić naszych klientów. Nawet Scrum Guide mówi, że celem samego Scruma jest „wytwarzanie produktów o wysokiej jakości”. Co prawda jeszcze kilka lat temu powiedzielibyśmy, że celem jest wytwarzanie produktów o „najwyższej możliwej wartości”, ale twórcy metodyki doszli do wniosku, że nie jest to coś za co powinniśmy umierać.
Niemniej, cała idea podejścia zwinnego zbudowana jest wokół tego, że jeżeli będziemy tworzyć lepsze rozwiązania, dostarczać je albo ich części szybciej, to nasi odbiorcy będą bardziej zadowoleni. To z kolei spowoduje, że łatwiej będzie nam rozwijać nasze rozwiązania w kierunku, który przynosi najwięcej korzyści – bo dostaniemy jakże cenną informację zwrotną. Dzięki temu będziemy też więcej zarabiać i łatwiej nam będzie współpracować z odbiorcą/odbiorcami naszych prac.
Tyle o teorii. W praktyce, wiele firm i organizacji w dalszym ciągu używa podejścia agile jako jakiegoś wytrychu, który ma za zadanie zwiększyć efektywność zespołu. Pojawiają się takie hasła jak „robić więcej za mniej”, że już nie wspomnę nawet o naszym ulubionym „robić dwa razy więcej dwa razy szybciej”. Nie tędy droga.
W transformacji agile chodzi między innymi o to, żeby przestać marnować czas i pieniądze na rzeczy zbędne i niesprawdzone. Nie chodzi o to żeby „dostarczyć biznesowi wszystko to, co sobie wymarzy w czasie o połowę krótszym”. Tu w ogóle nie chodzi o to, żeby komukolwiek dostarczyć wszystko, co sobie wymarzył. Skąd niby mamy wiedzieć, czy „to” jest wartościowe?
Prawdziwa zwinność, czyli co?
Zwinności w „prawdziwym” wydaniu mówi nam, że nie ma „ich” i „nas”. Jest jedna grupa osób, która chciałaby wytwarzać coś o wysokiej wartości i czerpać z tego korzyści. To oznacza, że nieuniknione będą trudne rozmowy pod tytułem „czy na pewno chcemy zrobić to, co nam się tak bardzo podoba?”. Bo może lepiej jednak zrobić coś, co jest mniej sexy, ale za to będzie bardziej dochodowe? Albo na przykład – bardziej potrzebne naszym użytkownikom? Tylko tych założeń nie możemy brać z sufitu. „Bardziej dochodowe”, ” bardziej potrzebne”, „bardziej wartościowe” – to wszystko trzeba empirycznie sprawdzić.
W podejściu zwinnym jesteśmy partnerami, którzy zmierzają w jakimś określonym kierunku. Ustępstwa będą pochodziły z obu stron… Tylko właśnie – jakich znowu stron? I tak naprawdę trudno nazwać to „ustępstwami”. Jeżeli jakieś rozwiązanie jest obiektywnie lepsze, bliższe naszej wizji i celowi, to po prostu je wybierzemy. Niezależnie od tego, kto jest zaproponował i co tak naprawdę w głębi serca chcielibyśmy zrobić. Nie jesteśmy tu po to, żeby spełniać swoje zachcianki, ani nawet zachcianki „biznesu”. Jesteśmy od wspólnego wybierania i robienia tych najbardziej wartościowych rzeczy.
Powiedzmy sobie to wprost: podejście zwinne nie służy do tego żeby brać wszystko jak leci i realizować po kolei. Chodzi o to żebyśmy wzajemnie się challenge’owali i żebyśmy znaleźli to, co faktycznie warto zrobić. Dobrze by były, gdybyśmy zrobili to w obiektywny sposób albo na podstawie danych które już posiadamy. Na przykład możemy zrobić MVP, wypuścić je na rynek i zweryfikować nasze założenia.
No to komu w końcu chcemy zrobić dobrze? Naszym interesariuszom – zadowolić ich i zrealizować wszystko, co sobie życzą? Czy może faktycznie chcemy zrobić dobrze odbiorcom naszych prac, co z kolei powinno przełożyć się na wyniki naszej organizacji? Tylko wtedy działamy na rzecz całej organizacji, a nie tylko i wyłącznie naszego zespołu bądź działu biznesowego, który zleca nam prace.
Komu jest dobrze?
Pamiętajmy o tym, po co robimy to wszystko na każdym szczeblu. Idąc piętro niżej, jeżeli zdecydujemy się na wprowadzenie jakiejś techniki czy narzędzia, to zawsze zadajmy pytanie „Komu to ma służyć i tak naprawdę komu będzie z tym lepiej?”.
Typowy przykład, to zdecydowanie się na User Stories, jako na format zapisu wymagań. Jeżeli robimy to po to, żeby łatwiej nam było zarządzać backlogiem, szybciej się dogadywać z innymi i wyłuskiwać te wymagania, które faktycznie służą jakimś konkretnym celom (a odrzucać te które ktoś zgłosił na zasadzie „chcę bo chcę”) – to dobrze.
User Story na pewno nie wprowadzamy po to, żeby „biznes w końcu mówił nam konkretnie co chce i po co”! Wtedy wygląda to tak, że zmuszamy ludzi do korzystania z czegoś, czego nie rozumieją. Wymagamy zgłaszania potrzeb w określonej formie, bo dzięki temu połowa rzeczy nie zostanie w ogóle nawet zgłoszona, bo nikt nie będzie potrafił napisać US-a. Za to drugą połowę odrzucimy, bo nie będzie zgodna z wymyślonym przez nas formatem albo Definition of Ready. Pytanie „Komu właściwe robimy dobrze?” aż ciśnie się na usta!
Komu ma być dobrze?
Pytanie „Komu robimy dobrze?” powinno wisieć nad nami przy okazji każdej jednej zmiany. Niezależnie czy to jest drobna rzecz, którą wymyśliliśmy sobie jako akcja z naszego retro, czy jest to coś dużego, co wynika wprost z transformacji która dzieje się w całej naszej firmie.
W przypadku drobnych usprawnień zgłaszanych na retro, bardzo często zespoły chcą zmienić coś po to, żeby im było wygodniej. Nie zawsze jest to tożsame z tym, bardziej skuteczną i efektywną pracą czy z wyższą jakością produktu. Nasza akcje mają na celu uniknięcie trudnego tematu albo zabezpieczenie się przed jakimś działaniem osób trzecich, bo to jest po prostu wygodniejsze niż próba rozwiązania faktycznego problemu.
W skali makro bardzo często dokonywane są zmiany, które mają na celu podtrzymanie status quo albo legitymizację patologicznych sytuacji. Wydaje nam się, że jeżeli ubierzemy je w proces, to staną się mniej patologiczne. Albo próbujemy pokazać, że „działamy zgodnie z zasadami”. Co z tego, że kiepskimi.
Komu robimy dobrze zgadzając się na miesięczny Sprint? Po co wymagamy od biznesu trzy-stronicowego opisu zgłaszanej zmiany? Komu robimy dobrze, jeżeli na Review pokazujemy rozwiązania, które nie są zgodne z Definicją Ukończenia? Dlaczego zgadzamy się na to żeby jeden zespół pseudo-scrumowy realizował zmiany dla 15 różnych klientów zewnętrznych? Komu robimy dobrze naciskając na to żeby Scrum był konieczne zgodny z podręcznikiem albo odwrotnie – rozluźniając jego ramy i pozwalając na tak zwane ScrumButy?
