Manifestu Agile już za nami! Potrzebujemy manifestu produktu

Budowanie działającego oprogramowania było dla wielu firm koszmarem, dlatego w lutym 2001 roku narodził się właśnie manifest Agile. Coś musiało się zmienić, a manifest wydawał się być bardzo dobrym rozwiązaniem. Chociaż jest on wciąż aktualny w budowaniu działającego oprogramowania, obecne wyzwania są już inne. Wiele firm potrafi tworzyć działające oprogramowanie, ale nie potrafi dostarczyć wartości. Dlatego moja filozofia brzmi:

Budowanie funkcji nie zapewnia wartości, a bycie Agile nie wystarczy, aby dostarczyć wartość. Dopóki zespoły nie będą mogły skupić się na tworzeniu wartości, rezultatem będzie bezużyteczne oprogramowanie.

Wierzę, że nadszedł już czas, by w naszej rzeczywistości na stałe zagościł manifest produktu! Nie możemy ciągle budować funkcji, których nikt nie potrzebuje. Musimy przestać marnować nasz czas. Potrzebna jest nam pilna zmiana punktu widzenia.

Sensowny manifest produktu mógłby prowadzić zespoły produktowe do dostarczania wartości bez względu na to, z jakimi frameworkami pracują. Na końcu tego wpisu podzielę się szkicem mojego manifestu produktu. Mam nadzieję, że z niego skorzystasz.

Uwaga: Treść tego artykułu oparta jest na moich doświadczeniach i obserwacjach z ostatnich dziesięciu lat. Dlatego zapraszam Cię do podzielenia się również Twoją perspektywą.

Manifest Agile już dawno się postarzał

Wyzwania, przed którymi stoimy obecnie, są zupełnie inne niż te, przed którymi stawiano nas w czasach, gdy powstawał manifest Agile. Manifest koncentruje się przede wszystkim na wynikach, nie wspominając o rezultatach. Dlatego ślepe podążanie za nim nie zapewni Ci dostarczenia wartości dla użytkowników i firm.

Myślę, że manifest Agile dobrze spełnił swoje zadanie, ale teraz potrzebujemy czegoś więcej, aby sprostać naszym nowym wyzwaniom. Pozwolę sobie rozwinąć tę kwestię.

Strona Manifest Agile ma następujące cztery wartości:

• Ludzie oraz interakcje ponad procesami i narzędziami.
• Działające oprogramowanie ponad złożoną dokumentacją
• Współpraca z klientem ponad negocjacją kontraktu.
• Reagowanie na zmianę ponad trzymanie się planu.

Żadna z tych wartości nie jest zorientowana na rezultat. Np. zespół Scrum może mieć lepszą współpracę i interakcję z ludźmi biznesu i klientami, a mimo to nie dostarczać żadnej realnej wartości. Ani Działające oprogramowanie ani Reagowanie na zmianę nie dają pewności, że wartość zostanie zmaksymalizowana.

Co gorsza, kiedy patrzę na zasady manifestu Agile, postrzegam niektóre z nich jako zorientowane na fabryki funkcji:

• Ludzie biznesu i programiści muszą współpracować ze sobą codziennie przez cały czas trwania projektu. Spotkałem się z tym wiele razy, a rezultatem jest zbudowanie czegoś, co zadowoli interesariuszy biznesowych. Jednocześnie nie spełnia to potrzeb użytkowników.
• Działające oprogramowanie jest podstawowym miernikiem postępu. Otóż zupełnie się z tym nie zgadzam. Wszystkie funkcje są nieistotne, dopóki użytkownicy końcowi nie będą mogli z nich skorzystać. Moim zdaniem, działające oprogramowanie nie może być miernikiem postępu.

Manifest Agile nigdy nie został zaktualizowany, ale nasze wyzwania już tak. W dzisiejszych czasach tworzenie działającego oprogramowania jest łatwiejsze niż dwadzieścia lat temu, ale dostarczanie wartości użytkownikom końcowym jest już znacznie trudniejszym zadaniem.

Jeff Patton podzielił się ciekawą perspektywą w podcaście z Melissą Perri. Przypomniał sobie, że ludzie zajmujący się oprogramowaniem stworzyli manifest Agile, a jego celem była pomoc firmom w tworzeniu lepszego oprogramowania. Mimo to perspektywy produktu tutaj nie ma. O tej części nie powinni zapominać ci, którzy wierzą w manifest Agile.

Przejście od oprogramowania użytkowego do dostarczania wartości

Jestem zmęczony rozmowami o funkcjach, rozwiązaniach, wymaganiach i planach działania. Z mojego doświadczenia wiem, że łatwo jest skupić się na tym, co możemy zaplanować i zrealizować, a trudno jest skupić się na tym, co nieznane. Dlatego uwielbiamy planować rozwiązania do wdrożenia, a nie problemy do rozwiązania.

Podejmowanie nieznanego jest wyczerpujące, a jednak konieczne, aby dostarczyć prawdziwą wartość.

Żaden plan nie gwarantuje stworzenia wartości. Większość z tych planów postrzegam jako stratę czasu. Planujemy, analizujemy, zastanawiamy się, zmieniamy, dostosowujemy, a w międzyczasie nic nie dostarczamy. Wyzwanie polega na nauczeniu się, co działa, a co nie. Kontrolowanie i dostosowywanie planu jest tutaj bezcelowe.

Kwestionuję to, czy organizacje są gotowe na radykalną zmianę sposobu pracy. Do tej pory zaobserwowałem wiele transformacji Agile, które dotykają tylko realizacji, co oznacza, że zespoły robią Agile, ale zarząd nadal prowadzi działalność tak, jak robił to kilkadziesiąt lat temu. Kierownictwo określa, co należy zrobić w określonym czasie i oczekuje, że zespoły Agile sprostają ich oczekiwaniom. Mimo to, mają czelność twierdzić, że są organizacją Agile.

Czy kadra kierownicza jest gotowa zrzec się swojej władzy? Dopóki nie będą w stanie upełnomocnić zespołów Agile, o dostarczeniu wartości będzie można tylko pomarzyć.

Kierowanie się wartościami wymaga czegoś więcej, niż tylko pracy z jakimkolwiek frameworkiem agile. Bez względu na to, który framework Agile wybierzesz, żaden zespół nie może dostarczyć prawdziwej wartości bez posiadania uprawnień do podejmowania decyzji.

Frameworki Agile są z założenia niekompletne. Np. Scrum nie obejmuje zarządzania produktem, ale jest najczęściej używanym na świecie frameworkiem agile. I tu pojawia się wiele problemów. Firmy często błędnie rozumieją Scrum i próbują używać go wyłącznie jako framework wykonawczy. Niestety, bez solidnych umiejętności zarządzania produktem, żaden zespół Scrum nie jest w stanie uwolnić swojego maksymalnego potencjału.

Maarten Dalmijn rzuca wyzwanie i sprawdza czy perfekcyjnie wdrożony Scrum zapewnia wartość. I ja się z nim zgadzam, ponieważ Scrum nie obejmuje krytycznych aspektów dostarczania wartości. Oto, co powiedział Maarten:

Czy Scrum dostarcza odpowiedzi na któreś z poniższych pytań:

- Jak stworzyć przekonującą Wizję Produktu?
- Jak stworzyć skuteczną Strategię Produktu?
- Jaki jest Twój produkt?
- Kim jest Twój klient?
- Co oznacza wartość dla Twoich klientów i firmy?
- Jak uporządkować backlog produktu, aby dostarczyć największą wartość?
- Jak być pewnym, że to, nad czym pracujesz, będzie wartościowe?
- Jak sprawdzić, czy to, co dostarczyłeś, rzeczywiście jest wartościowe?

Pozwól, że Ci to zaspoileruję: nie. Scrum nie daje żadnych odpowiedzi na żadne z tych pytań.

Dlatego z utęsknieniem czekam na manifest produktu. Organizacje będą ponosić porażkę, dopóki nie zrozumieją, w jaki sposób dostarczać wartość. Nadszedł już czas, by skupić się na tym, co ważne.

Na końcu tego wpisu podzielę się draftem mojego manifestu produktu.

Wartości manifestu produktu

• Rozwiązywanie problemów ponad wdrażaniem rozwiązań
• Orientacja na rezultaty ponad definiowaniem funkcji
• Walidacja hipotez zamiast kierowania się opiniami
• Empatia dla użytkowników końcowychzamiast zakładania ich potrzeb

Zasady manifestu produktu

1. Generowanie wartości jest ostateczną miarą sukcesu.
2. Kluczem do sukcesu jest jasne określenie, czym jest wartość, a czym nie jest.
3. Nigdy nie zaczynaj oceny rozwiązań, dopóki nie zrozumiesz problemu.
4. Przyjmij jeden priorytet na raz i powiedz "nie" temu, co Cię od niego odciąga.
5. Korzystaj z nauki poprzez znajdowanie szybkich sposobów potwierdzania założeń.
6. Kierownictwo ufa zespołom produktowym, że postępują właściwie. Dlatego są one upoważnione do podejmowania decyzji.
7. Nie trzymaj się kurczowo bezużytecznych funkcji w produkcie; pozbądź się tego, co nie daje wartości.
8. Wyznacz termin realizacji dla zaległych pozycji, stale dostosowując się do tego, czego się nauczyłeś. Usuń pozycje, gdy upłynie termin płatności.
9. Dążenie do dostosowania się do interesariuszy zamiast prób zadowolenia ich.
10. Dowiedz się, jak odróżnić to, czego potrzebujesz od tego, co chcesz.
11. Opinie użytkowników końcowych mają większe znaczenie niż opinie interesariuszy.
12. Zdefiniuj, co prowadzi do sukcesu i opracuj sposób, w jaki można go codziennie mierzyć.

Potrzebuję Twojej pomocy, aby uczynić ten manifest jeszcze wyraźniejszym. Co byś tu zaadaptował i dlaczego? Podziel się ze mną swoimi przemyśleniami w komentarzach i razem przekształćmy świat produktów cyfrowych.

Podsumowanie

Od wielu lat staram się znaleźć lepsze sposoby na wdrażanie frameworków Agile w organizacjach. Miałem już dość, kiedy widziałem jak zespoły Scrum stają się fabrykami funkcji. Na razie uważam, że wyzwanie jest o wiele większe niż wdrożenie frameworków agile. Chodzi o zmianę sposobu myślenia organizacji. Oto zmiany, które moim zdaniem należy wdrożyć, aby dobrze prosperować dzięki zwinności Agile:

• Przestań kłaść nacisk na plany. Skup się na znalezieniu alternatywnych rozwiązań, aby uczyć się szybciej.
• Traktuj porażki jako konieczny krok w kierunku sukcesu. Brak porażek oznacza, że firma gra bezpiecznie i traci szansę na innowacje. Koniec końców konkurencja potraktuje taką firmę jako łatwy kąsek.
• Nie traktuj tworzenia funkcji jako celu
• Ważne jest rozumienie  różnicy między wynikiem a rezultatem.
• Pokora, by zaakceptować, że nie mamy wszystkich odpowiedzi.

"Klienci nigdy nie pokochają firmy, dopóki pracownicy nie pokochają jej jako pierwsi." - Simon Sinek