Rozwój oparty na misji

Wraz z rozwojem firm skalowanie rozwoju produktów Agile staje się coraz trudniejsze. Według 52% respondentów w 13th State of the Agile Report, różnice między kulturą organizacyjną a wartościami Agile są głównym mankamentem ich pracy.

Liderzy organizacyjni są w stanie wykorzystać kulturę Agile do poprawy rozwoju produktu. Solidna kultura Agile obejmuje autonomię zespołu w podejściu do złożonych problemów, ścisłą pracę z klientami oraz długoterminową wizję i strategię.

Te abstrakcyjne wartości są trudne do oceny i zaangażowania. W organizacji wdrożenie skutecznej strategii ich wykorzystania staje się nietrywialną pracą. Podejście Mission Driven Development (MDD) wyrosło ze start-upów na średnim etapie rozwoju jako alternatywa dla rozwoju takiej kultury.

Skalowanie Wyzwania

Podczas skalowania może pojawić się kilka wzorców spowolnienia. Motywacja zespołu może spaść w przypadku projektów, które mają niejasny koniec. Menedżerowie produktu mogą czuć się zagubieni na spotkaniach operacyjnych, a tym samym tracić czas na projektowanie strategicznych ścieżek produktowych. Wdrażanie nowych funkcji i produktów może ulec spowolnieniu, ponieważ systemy stają się coraz bardziej złożone.

Do tych barier należy podejść z perspektywy kulturowej i praktycznej. Pokonanie ich obejmuje rezygnację z kontroli, zwiększenie autonomii zespołu, wdrożenie radykalnej przejrzystości i stworzenie skutecznych ram rozwoju produktu w celu uzyskania wyników.

Wyzwania związane ze skalowaniem tradycyjnych zwinnych frameworków

Podczas skalowania Agile należy zsynchronizować poziomy zarządzania i zespołu. Poziom zarządzania odpowiada za opracowanie strategii firmy, tworzenie i komunikowanie wizji produktu, realizację decyzji kadrowych oraz wspieranie rozwoju zespołu. Poziom zespołu wykonuje niezbędne zadania, aby skutecznie przełożyć tę wizję i strategię na wartościowe produkty i funkcje.

Tradycyjne frameworki Agile (XP, Scrum i Kanban) są zoptymalizowane do działania na poziomie zespołu, pozostawiając relacje zarządcze głównie nierozwiązane. Nowa fala skalowanych frameworków Agile ewoluowała, aby wypełnić tę lukę, tj. SAFe, LeSS, Scrum of Scrums, Nexus, DAD, itp. Jednak te podejścia wymagają dużo planowania do wdrożenia i wysiłku w zarządzaniu i utrzymaniu.

Lekkie podejście, framework Mission Driven Development zapewnia wystarczającą ilość wytycznych, aby wdrożyć solidną strukturę wokół skalowania rozwoju i wykorzystania wartości Agile.

Podstawowe elementy rozwoju ukierunkowanego na misję

Misje

Punktem wyjścia jest Mission Discovery. Misja biznesowa wymaga czasu i wysiłku i powinna identyfikować ukryty problem, przestrzeń rozwiązania oraz pożądany wynik biznesowy. Dokładnie zdefiniowana misja napędza motywację, wspiera współpracę i promuje badania nad szerszymi przestrzeniami projektowymi.

Oddziały

Odpowiedzialnymi podmiotami za powodzenie każdej misji są oddziały. We współpracy z menedżerami produktu małe zespoły składające się z 2-4 osób prowadzą niezbędne działania, aby dostarczyć rozwiązania, które odpowiadają celowi misji i ograniczeniom czasowym.

Cykl 6-tygodniowy

Sześciotygodniowy przedział czasowy pozwala wszystkim drużynom przestrzegać tego samego harmonogramu planowania bazowego, dając jednocześnie wystarczająco dużo czasu na osiągnięcie znaczącego wyniku.

Okres buforowania

Ramy MDD zwykle obejmują między innymi tygodniowy lub dwutygodniowy okres buforowy na ostateczne integracje i wdrożenia, szkolenia i rozwój umiejętności, działania innowacyjne oraz planowanie kolejnego cyklu.

Znaczenie 6-tygodniowego cyklu

Chociaż sześciotygodniowy okres może wydawać się bardzo długi dla niektórych praktyków Agile, zawiera kilka ważnych korzyści.

Zespoły pracujące w krótkich cyklach zwykle tracą zaangażowanie w wizję produktu, ponieważ mają wrażenie, że sprawdzają „listę prania” poprawek, błędów i drobnych funkcji. Zagraża to autonomii zespołów w poszukiwaniu i wyborze najlepszego sposobu dostarczania rozwiązań.

W miarę wydłużania się cykli dokładność szacowania produktu maleje. W rezultacie wymaga to dużego wysiłku planistycznego ze strony zespołów produktowych.

Sześć tygodni zostało nazwanych Złotowłosą ramami czasowymi produktów, zapewniając wystarczająco dużo czasu, aby dostarczyć produkt o minimalnej opłacalności dzięki innowacyjnemu myśleniu, szybkiemu prototypowaniu i ciągłej dostawie.

Cykl 6-tygodniowy dodatkowo zwiększa zaangażowanie zespołu w wizję poprzez wykorzystanie autonomii. Mikrozarządzanie nie jest konieczne, o ile misje są jasno określone, a cykle są wystarczająco krótkie, aby zespoły mogły skoncentrować się tylko na pożądanych wynikach.

Wreszcie, menedżerowie produktu mogą angażować się w działania planistyczne co sześć tygodni, zachowując wystarczającą przewidywalność, aby zespoły mogły śledzić misję. Dzięki temu więcej czasu można skoncentrować na strategicznym i eksploracyjnym wymiarze rozwoju produktu.

Wdrażanie rozwoju opartego na misji

Weźmy na przykład startup ze średniej fazy, który posiada produkt B2B oferujący optymalizację cen sieci, co zwiększa przychody klientów dzięki wykorzystaniu aplikacji sztucznej inteligencji. Firma niedawno podpisała nową rundę finansowania, której celem jest konsolidacja jako ważny podmiot w branży i zwiększenie udziału w rynku o 300%.

W tym scenariuszu istnieje kilka wyzwań związanych z rozwojem produktu:

• W jaki sposób można uzyskać informacje zwrotne od obecnych i potencjalnych klientów, aby zweryfikować hipotezę wartości oczekującej?
• Jakie funkcje należy zbudować lub usunąć z platformy, aby uzyskać atrakcyjne wrażenia użytkownika?
• Jak można skonfigurować strukturę zarządzania do obsługi skalowania i wykorzystywania wartości kulturowych w celu przyspieszenia wzrostu?

Ostatecznie, aby uniknąć skomplikowanych frameworków, firma decyduje się na zastosowanie frameworka Mission Driven Development. W Mission Driven Development szczegóły „ostatniej mili” są definiowane przez każdą organizację. Główne elementy, które należy zdefiniować, to:

• Odkrycie misji
• Struktura misji
• Zespół oddziału
• Inspekcja i adaptacja
• Iteracja bufora
• Planowanie wydajności

Odkrycie misji

Punktem wyjścia jest Mission Discovery. Tim Herbig opisuje odkrycie jako iteracyjny proces zmniejszania niepewności wokół problemu lub pomysłu, aby zapewnić, że właściwy produkt zostanie stworzony dla właściwych odbiorców. Zanim jakakolwiek misja zostanie zrealizowana w cyklu iteracyjnym, powinna zostać jak najdokładniej zweryfikowana.

Proces Mission Discovery jest prowadzony przez specjalnie przydzielone zespoły. Zespół ds. odkrywania jest kierowany przez menedżera produktu i składa się z badaczy produktu, analityków biznesowych i projektantów. Gdy istnieje wielu menedżerów produktów, podlegają oni dyrektorowi ds. produktów (CPO), który zapewnia wspólną wizję produktów, dopasowanie produktów i globalną strategię firmy oraz terminową dostawę.

Zalecanym punktem wyjścia do odkrywania misji są wyzwania, problemy lub możliwości. Na przykład rozpoczęcie od wyzwania pomaga zespołowi eksplorować więcej przestrzeni projektowych, w końcu poszerzając możliwości rozwiązań.

Walidacja misji obejmuje kilka czynności, które pomagają firmie lepiej zrozumieć potrzeby klientów:

1. Przeprowadzanie badań rynku i analizy konkurencji
2. Zrozumienie przestrzeni problemowej, w której definiowana jest misja
3. Projektowanie szkiców i prototypów o niskiej wierności
4. Zdefiniowanie jasnego zakresu misji
5. Zbieranie opinii klientów i walidacja

Te działania sprawiają, że misja jest solidną wytyczną dla zespołu deweloperskiego i gwarancją tworzenia wartości dla użytkowników.

W rezultacie niektóre misje są zatwierdzane i wprowadzane do Rejestru Misji, który stale ewoluuje wraz z odkrywaniem i zbieraniem informacji zwrotnych.

W tym przykładzie podejmijmy następujące wyzwanie: jakie funkcje należy zbudować z platformy, aby zapewnić atrakcyjne wrażenia użytkownika? Tylko jeden zespół ds. odkrywania, kierowany przez menedżera produktu, byłby odpowiedni, aby sprostać temu wyzwaniu.

Załóżmy, że obecnie platforma przykładowej firmy pobiera surowe dane klienta i zwraca zoptymalizowaną sieć cenową na przetworzonych plikach danych. Jednak platforma UX nie została zoptymalizowana pod kątem urzekających wrażeń. Celem na tym etapie jest ustalenie, czy wartość dla klienta będzie pochodzić z poprawy UX, opracowania nowych funkcji lub ulepszenia usług platformy.

Po wstępnych badaniach rynku podjęto decyzję o opracowaniu nowych funkcji. Funkcje kandydujące dla platformy to:

• Ultraszybkie przeszacowanie
• Szybki i responsywny interfejs
• Inteligentne i zaawansowane zasady przeceny
• Historia przecen i sprzedaży

W celu odkrycia firma decyduje się na podejście sprintu projektowego: pięciodniowy proces udzielania odpowiedzi na krytyczne pytania biznesowe poprzez projektowanie, prototypowanie i testowanie pomysłów z użytkownikami. Proces odkrywania jest uruchamiany dla każdej cechy kandydującej, aby zobaczyć, która stworzy większą wartość dla obecnych i potencjalnych klientów. Najważniejszą funkcją wybraną do opracowania są inteligentne i zaawansowane reguły przeszacowania.

Struktura misji

Osiągnięcie solidnej definicji misji nie jest trywialnym zadaniem. Musi przedstawiać jasne wyzwanie biznesowe i wyznaczać granice jego wyników, a jednocześnie zapewniać wystarczająco dużo miejsca, aby zespoły mogły znaleźć innowacyjne i wydajne rozwiązanie. Jasna, precyzyjna misja:

• Wyraźnie określa wyzwanie biznesowe, po zidentyfikowaniu i nakreśleniu przestrzeni problemu.
• Syntetyzuje wszystkie informacje i spostrzeżenia odkryte w poprzednich fazach.
• Linki do pożądanego wyniku biznesowego.
• Jest zorientowany na wyniki, wyraźnie pokazując obraz sukcesu misji.
• Jest realistyczna i osiągalna w ramach 6-tygodniowego cyklu.
• Jest wystarczająco wąska, aby zapewnić ostrość i wystarczająco szeroka, aby nie dopuścić do szczegółów.

W tym przykładzie po tygodniu odkrycia zebrano i zsyntetyzowano informacje i opinie użytkowników.

Użytkownik docelowy: Analitycy cen klientów.

Przestrzeń problemów: użytkownicy chcą mieć możliwość ustawiania inteligentnych i zaawansowanych reguł ustalania cen oraz zarządzania nimi, aby mogli automatycznie dostosowywać ceny w określonych warunkach.

Najcenniejszymi warunkami reguł są cena konkurencji, pilność wysyłki, suma zamówienia, dostępne zapasy i rabat dla klientów premium.

Informacje: Reguły powinny być stosowane w niestandardowych priorytetach i w razie potrzeby można je modyfikować.

Analitycy chcieliby łatwo sprawdzić, jakie zasady obowiązują w określonych momentach dla danego produktu.

Pożądany wynik biznesowy: Zwiększ zaangażowanie użytkowników na platformie o 25%, mierzone na podstawie czasu spędzonego na platformie.

Zgromadzenie drużyny

Proces tworzenia zespołu odbywa się ad hoc dla każdego cyklu rozwojowego. Kluczowe znaczenie mają zasady autonomii zespołu i samoorganizacji. Zespół składa się z różnych czynników, począwszy od złożoności misji, umiejętności programistów i projektantów, zainteresowań i chemii w drużynie.

Proces tworzenia składu ułatwiają trenerzy Agile. Przed podjęciem jakiejkolwiek decyzji, każda osoba jest pytana, jaką pracę chciałaby wykonywać w ciągu najbliższych sześciu tygodni. Następnie, w oparciu o doświadczenie, wiedzę i umiejętności, budowane są drużyny, które zapewniają im niezbędną wiedzę i umiejętności, aby pomyślnie wykonać misję.

Trenerzy Agile pracują z kilkoma drużynami w całym cyklu rozwoju, pomagając im w podnoszeniu przeszkód i zależności. Gdy istnieje kilku trenerów Agile, podlegają oni szefowi Agile, który jest odpowiedzialny za tworzenie składu, ciągłe doskonalenie i dostarczanie produktów Agile.

Zalecana wielkość oddziału to 2-4 osoby: zwykle jeden projektant i jeden lub dwóch programistów, w zależności od złożoności misji. Uważa się, że inżynier QA pomaga jednej lub kilku drużynom w osiągnięciu pożądanych standardów jakości.

Zespoły są często mieszane po każdym cyklu, więc każdy może współpracować z różnymi ludźmi, szerzyć wiedzę i pracować nad różnymi wymiarami produktu, chociaż wysokowydajny zespół może współpracować przez kilka cykli.

Konkretny oddział w przykładzie powinien wziąć pod uwagę osoby z możliwościami projektowania interfejsu użytkownika, przetwarzania danych i wizualizacji danych.

Kontrola i adaptacja w ramach cyklu

Trenerzy Agile powinni stale zachęcać do przejrzystości, inspekcji i adaptacji poprzez standardowe praktyki Agile.

Odbywają się krótkie cotygodniowe spotkania w celu organizacji pracy i ułatwienia podnoszenia przeszkód i zależności. W razie potrzeby przeprowadza się pielęgnację, aby zapewnić, że drużyny w pełni rozumieją misję i historie użytkowników. Krótkie retrospektywy przeprowadzane są pod koniec każdego tygodnia w celu identyfikacji i wdrożenia zmian i usprawnień.

Ciągłe praktyki dostarczania powinny być utrzymane przez cały cykl. Cel misji można osiągnąć wcześniej, ponieważ 6-tygodniowy okres cyklu jest podejściem opartym na rytmie i ustalaniu podstawowych zasad, jednocześnie pomagając osiągnąć przewidywalność drużyny.

Dobrą praktyką zwiększania przejrzystości jest prezentacja pod koniec czwartego tygodnia, oparta na uzgodnionym przez zespoły i menedżerach produktu kamieniu milowym. Celem tych demonstracji jest dostosowanie, zmniejszenie lub zwiększenie zakresu zgodnie z wymaganiami.

W przypadku przykładowej misji plan wydania został uzgodniony między oddziałem a menedżerem produktu w czterech różnych wydaniach:

1. Wydanie 1:
   • Nowy interfejs funkcji reguł
   • Zasady cen konkurencji
2. Wydanie 2:
   • Zasada pilności wysyłki
   • Zamów całkowitą regułę
   • Priorytety zasad
3. Wydanie 3:
   • Dostępna reguła inwentaryzacji
   • Reguła aplikacji wizualizacji
4. Wydanie 4:
   • Rabat dla klientów premium

Wydanie 3 zostało uzgodnione jako demo na czwarty tydzień. Ponieważ wydania były przeprowadzane przez cały cykl rozwojowy, pożądany wynik biznesowy (w tym przypadku zaangażowanie użytkowników) powinien być śledzony od momentu rozpoczęcia cyklu rozwojowego. Graficznie można oczekiwać postępu w następujący sposób:

Okres buforowania

Przyjmowanie jednego lub dwóch tygodni jako okresu buforowego jest praktyką powtarzaną przez wdrożenia Mission Driven Development, a także przez inne podejścia do skalowania, takie jak SAFe.

W SAFe innowacja i iteracja planowania odbywa się w każdym cyklu rozwoju. Służy jako przełącznik kontekstu, umożliwiając procesy i działania związane z eksploracją i innowacjami, zwykle pomijane w innych ramach skoncentrowanych na dostarczaniu. Przykładowe działania realizowane w tym tygodniu buforowym:

• Końcowa integracja rozwiązania . Podczas wdrażania pod koniec 6-tygodniowego cyklu prawdopodobnie oczekuje się na integrację, weryfikację, dokumentację i walidację. Poświęcony czas pomaga zapewnić efektywną i płynną integrację nowych rozwiązań w istniejących produktach.
• Planowanie misji i ustalanie priorytetów . Misje są dopracowywane, klasyfikowane w małych lub dużych partiach i traktowane priorytetowo w następnym cyklu rozwoju. Podczas ustalania priorytetów misji, niektóre firmy wdrażają dni prezentacji, podczas których najważniejsze misje są przedstawiane firmie, a następnie — we współpracy — są zaangażowane w następny cykl rozwojowy.
• Hackathony . Hackathony zyskały coraz większą popularność wśród startupów i firm dzięki ich zdolności do wspierania innowacji, tworzenia społeczności oraz budowania nowej wiedzy i umiejętności w zabawny sposób. Wyniki są prezentowane innym i stają się kandydatami do Backlogu Misji.
• Rozwój eksperymentalnych prototypów lub projektów pobocznych . Powszechną praktyką jest danie inżynierom i projektantom czasu na pracę nad tym, co zdecydują, o ile pokażą pracę wykonaną pod koniec czasu buforowego.
• Prace inżynierskie . Zazwyczaj wykonywane są prace czysto inżynierskie, takie jak rozwój infrastruktury, automatyzacja testów, redukcja zadłużenia technicznego i migracje systemów.
• Rozwój nowych umiejętności i wiedzy . Szybkie tempo ewolucji wiedzy zmusza programistów do bycia na bieżąco z globalnymi trendami. Czas buforowy jest odpowiedni do przeprowadzenia między innymi szkoleń na miejscu, społeczności praktyków i warsztatów technologicznych.

Okresy buforowe powinny opierać się na zidentyfikowanych lukach w wiedzy, celach w zakresie innowacji i potrzebach na następny cykl. Na przykład tygodniowy okres buforowy może wyglądać tak:

Planowanie wydajności

Według współzałożyciela Basecamp, Jasona Frieda, przy podejmowaniu decyzji o zaangażowaniu w misję w kolejnym cyklu rozwoju, powszechną praktyką jest najpierw identyfikacja małych lub dużych partii. Duże partie odnoszą się do cech lub funkcjonalności dużych produktów, podczas gdy małe partie odnoszą się do mniejszych iteracji lub zadań. W podanym przykładzie wybraną misję dla nowej funkcji można uznać za dużą partię.

Zalecenie tutaj jest proste: zawsze mieszaj małe i duże partie. Małe partie to misje, które szacuje się na 3-4 tygodnie, a duże partie mogą potrwać sześć tygodni lub dłużej.

Jeśli zespół wykonujący małą partię zakończy swoją misję do 3 lub 4 tygodnia, uzgodnione demo jest okazją do oceny, czy drużyna powinna dalej pracować nad ulepszaniem wdrożonego rozwiązania, pomóc innej drużynie, podjąć nową misję w małej partii lub rozpocząć nieplanowana praca.

Dobra mieszanka dużych i małych partii uniemożliwia ludziom pracę przy 100% wydajności, umożliwiając tym samym manewrowanie i dostosowywanie się w przypadku nieplanowanych prac. Zespoły zajmujące się dużą partią skupiają się tak bardzo, jak to możliwe podczas cyklu, podczas gdy zespoły zajmujące się małą partią mogą zajmować się zadaniami ad hoc, które wynikają z nieoczekiwanej pracy.

Łączenie małych i dużych partii również zmniejsza ryzyko. Posiadanie tylko dużych partii może zwiększyć prawdopodobieństwo negatywnego wpływu na wrażenia użytkownika. Jeśli kilka nowych funkcji zostanie wydanych blisko siebie, powinno im towarzyszyć dobre zarządzanie zmianami. Ponadto w przypadku nieplanowanych prac dostępna będzie mniejsza pojemność. Wreszcie, jeśli kilka dużych zespołów upadnie, iteracja może zostać odebrana jako bezproduktywna, a tym samym zdemoralizować drużyny.

Zagrożenia związane z rozwojem opartym na misji

Istnieje wiele korzyści z wdrożenia Mission Driven Development, ale jak każda nakazowa struktura, wiąże się z kilkoma nieodłącznymi zagrożeniami, które należy wziąć pod uwagę.

Zakres misji

Misje powinny być realistyczne, dążąc do dobrego dopasowania między złożonością wyzwania a umiejętnościami drużyny; w przeciwnym razie wpływ na wyniki rozwoju może być znaczący.

Zbyt ambitna misja może wywołać frustrację i niepokój, negatywnie wpływając na wyniki drużyny. Z drugiej strony niezbyt entuzjastyczna misja może spowodować demotywację drużyny i nudę. W związku z tym mentalność Minimum Viable Product powinna pozostać stała w ramach.

Dlaczego misja

Solidne misje biznesowe powinny mieć kompleksową definicję przestrzeni problemowej i jej relacji z wizją firmy. Jeśli ta relacja nie jest jasna, cenne spostrzeżenia mogą zostać utracone z powodu braku zrozumienia, jak rozwiązywanie problemów wpływa na cele firmy.

Pułapka wodospadu

Wpadnięcie w model kaskadowy w ciągu sześciu tygodni jest naturalną tendencją dla drużyn. Są na to dwa główne czynniki. Po pierwsze, presja na rozmieszczenie jest silniejsza pod koniec cyklu. Po drugie, drużyny chcą wycisnąć jak najwięcej w ramach misji, co skutkuje pilną potrzebą wdrożenia pod koniec cyklu rozwoju. Dlatego należy zachęcać do ciągłych praktyk dostarczania, aby osiągnąć wydania Agile w całym cyklu i uniknąć ryzyka związanego z wodospadem.

Działanie produktu

Zadania związane z eksploatacją produktu, takie jak zarządzanie infrastrukturą, usługami lub komponentami monitorowania, należy trzymać poza zasięgiem oddziałów, ponieważ mogą one wpływać na prędkość. Poleganie na standardach i praktykach programistycznych, takich jak projektowanie atomowe, zmniejsza wysiłki programistyczne i w konsekwencji przyspiesza skalowanie. Inną powszechną praktyką w tych ramach jest centralny zespół operacyjny, który poza zarządzaniem operacjami produktów i monitorowaniem zajmuje się infrastrukturą.

6-tygodniowy cykl jako schemat krótkowzroczny

Niektóre scenariusze nie będą odpowiednie dla frameworka. Staje się to szczególnie prawdziwe w przypadku dużych i złożonych systemów, które mogą mieć ogromny wpływ na doświadczenie klienta, takich jak projekty badawczo-rozwojowe lub migracja krytycznych systemów.

Lekka opcja do skalowania Agile

Skalowanie Agile w celu utrzymania tempa rozwoju produktu i wzrostu firmy jest ukrytym wyzwaniem dla praktyków Agile. Jako niedawno opracowane podejście Agile, framework Mission Driven Development zyskał popularność wśród firm ze względu na łatwość użycia i wdrożenia. Ramy MDD uruchamiają kompleksowy, przekrojowy proces innowacji produktu, od odkrycia do dostarczenia, który wypełnia luki obecne w tradycyjnych strukturach Agile. Mission Driven Development ma potencjał, by stać się nowym Scrumem dla rozwijających się firm.