Temat wymagań przewija się w zasadzie od samego początku naszego istnienia jako #białko. Jednym z naszych naszym ulubionych tematów jest dzielenie wymagań, a w naszych rozważaniach filozoficznych często poruszamy też tematykę MVP. Ale nigdy tak naprawdę nie powiedzieliśmy jak mówić o wymaganiach, żeby nie sugerować sposobu realizacji?
Siła sugestii
W tekstach na temat Planning Poker i innych metod szacowania wspominaliśmy o efekcie zakotwiczenia (ang. anchoring), który pokazuje niesamowitą i groźną siłę sugestii. Wystarczy dowolna liczba, która zostanie nam przedstawiona, aby nasz sprytny umysł uczepił się jej i nadał jej znaczenie.
Pokazywaliśmy ten efekt w praktyce na Agile Warsaw, gdy poprosiliśmy zgromadzonych o oszacowanie pewnych proporcji, uprzednio wyświetlając na ścianie pewną liczbę. Była ona wysoka, więc prawie wszystkie szacunki okazały się zbyt wysokie.
Dlaczego tak się stało? Próbując odgadnąć rozwiązanie, nasz umysł łapie się wszystkiego, co mu może pomóc. Skoro pojawiło się pytanie, a wraz z nim skojarzona była jakaś liczba, to spokojnie można założyć, ze mają one ze sobą jakiś związek. Rację będziemy mieli na tyle często, że utwierdzimy się w zasadności tego podejścia.
Skoro tak działają niewinne liczby, to aż strach pomyśleć co się stanie, gdy przyjdzie do nas Product Owner i zakomunikuje, że dodał do Product Backlogu „nowe, łatwe wymaganie”. Kto będzie odważny i powie, że wcale nie jest ono takie łatwe? Jeżeli mamy w zespole pełną i „bezpieczną” transparentność to możemy liczyć, że ktoś taki się znajdzie. Ale co, gdy zespół się dopiero zgrywa?
Wymagania czy zadania?
Pół biedy, gdy mamy do czynienia tylko i wyłącznie z anchoringiem przy szacowaniu. O wiele częstszym i bardziej poważnym problemem jest narzucanie sposobu realizacji rozwiązania przez Product Ownera albo – o zgrozo – interesariuszy.
W tym drugim przypadku czym prędzej powinniśmy powiedzieć o tym naszemu Scrum Masterowi, bowiem to on powinien dbać o zrozumienie Scruma także poza naszym zespołem. W ramach tego powinien też cierpliwie wyjaśniać ścieżkę, którą spływają wymagania. Może przypomnieć także, że Scrum Team jest zespołem samoorganizującym się. Nikt nie powinien wymuszać na nas sposobu realizacji poszczególnych wymagań.
Niestety, zarówno Product Owner jak i sam Development Team często chcą wpisywać w HLAC (czyli kryteria akceptacji User Story) konkretny sposób realizacji danej funkcjonalności. Sprawia to, że zamiast z wymaganiami, zaczynamy mieć do czynienia z zadaniami. A to już duży kłopot.
Zadania się po prostu wykonuje. Jeżeli trzeba w tym miejscu w ścianie wkręcić haczyk, to trzeba wkręcić haczyk. Możemy ewentualnie dopytać o jego grubość i wykonamy te zadanie dokładnie tak, jak zostało ono zdefiniowane. Ale nie o to chodzi w metodykach agile!
Zamiast konkretnego i ściśle zdefiniowanego „wkręć tutaj ten kołek” zadania, powinno do nas trafić wymaganie „chcę powiesić w tym miejscu obraz”. A to zupełnie zmienia postać rzeczy.
Wykonujemy zlecenia czy dostarczamy wartość?
Jeśli wiemy, że ktoś potrzebuje powiesić obraz, to od razu cisną nam się na usta dodatkowe pytania. Jaki to jest obraz? W jaki sposób został oprawiony? Ile waży? Czy na pewno chcemy go mocować na stałe? Czy na pewno umieszczenie go tuż pod wylotem powietrza z klimatyzatora to dobry pomysł?
„Maksymalizowanie wartości dostarczanej klientowi” to nie jest pusty slogan. Nie wykonujemy zadań czy zleceń, ale staramy się maksymalnie zwiększyć zadowolenie naszego klienta przy jednoczesnym poświęceniu na to minimum nakładów (patrz: MVP).
Wymaganie w postaci „ściany w tym pokoju są zbyt puste, chcę tu wprowadzić trochę więcej klimatu” daje jeszcze większe możliwości. Bo wtedy dopiero możemy zaszaleć i zamiast wieszać obraz, namalować coś bezpośrednio na ścianie albo powiesić szablę.
„Ale w ogóle nie o to mi chodzi! Ja chcę po prostu powiesić obraz!”
Dobry Product Owner doskonale wie, na jakim poziomie szczegółowości wymagania powinny trafiać do Backlogu Produktu. Zawrze on w nim minimum, które zapewni właściwy tok rozumowania. Jednocześnie unikał będzie stwierdzeń, które zasugerują coś Zespołowi Deweloperskiemu.
Systemy ponad cele!
Jeżeli cały Scrum Team, dąży do zadowolenia klienta, aby wrócił on po więcej, to absolutnie wszyscy muszą się w to zaangażować. Product Owner – dbając o formę wymagań i dobre zrozumienie potrzeb, nawet tych niewypowiedzianych. Development Team – wykazując się kreatywnością w rozwiązywaniu problemów i skupiając się na rzeczywistych potrzebach klienta, a nie na „zadaniach do wykonania”. Scrum Master – wspierając wszystkich w takim formułowaniu i priorytetyzowaniu zadań, aby najważniejszy był zawsze klient.
Scrum Master jest też odpowiedzialny za to, aby maszynka o nazwie „Scrum” dawała odpowiednie rezultaty. Jeżeli mamy wskazać „winnego”, który pozwolił na to, że Product Owner przychodzi do Development Teamu z „zadaniami do wykonania”, a Development Team „planuje je na Sprint”, to będzie nim właśnie SM.
To nie tak, że PO czy Zespół Deweloperski są bez winy, ale to Scrum Master ma za zadanie pilnować tego, aby Scrum był Scrumem.
„Produktem ubocznym dobrego systemu jest spełnianie celów.”
Wracamy tutaj do pytania czy ważniejszy jest cel, czy wizja. Zakładając sobie cele do osiągnięcia, ograniczmy sposoby, w jaki możemy do nich dążyć. Opisując docelową wizję i budując system, które ją wpiera, pozwalamy na więcej elastyczności i odkładamy decyzje tak późno, jak to możliwe.
Jeśli chcemy stać się bardziej zwinni, zaufajmy zespołom w kwestii ich umiejętności i pozwólmy im uwolnić swoją kreatywność. Nie zabijajmy jej sugestiami co do sposobu realizacji pracy. Jeżeli to oni ją regularnie wykonują, to na pewno wybiorą najlepszą ich zdaniem formę.
Wymagania w projektach agile to temat-rzeka, dlatego zapraszamy na szkolenie trwające cały dzień, poświęcone właśnie tematyce wartości i zarządzania wymaganiami w projektach zwinnych.
