Badanie KPMG przeprowadzone w ponad 17 krajach pokazuje, że 81% organizacji przeprowadzało co najmniej 1 transformację Agile na przestrzeni ostatnich 3 lat, a 63% deklaruje, że wdrożenie Agile jest ich strategicznym priorytetem1. Jednocześnie rośnie rozczarowanie Agile i Scrum, tam gdzie transformacje nie przyniosły pożądanych rezultatów. Dlaczego? Ponieważ same transformacje Agile nie są przeprowadzane w duchu Lean.
Agile pełnymi garściami czerpie z Lean. Nie może obejść się bez Kanbana czy Scruma, które pozwalają na jego realną implementację w organizacji, a które wywodzą się z tej metodyki. Warto jednak wrócić do fundamentów Lean, by zrozumieć, dlaczego zdarza się, że transformacje Agile nie przynoszą pożądanych efektów biznesowych.
Zacznijmy od uproszczonej definicji celu wdrażania metod leanowych, którym jest eliminacja marnotrawstwa. Zarówno w zakresie nadmiernej produkcji, poprzez nierówne obciążenie elementów linii produkcyjnej, a kończąc na niskojakościowych produktach, które nie dostarczają wartości klientowi (np. stanowią element reklamacji, zwrotu lub braku satysfakcji klienta).
Geneza Lean i podstawowe zasady
Lean historycznie odnosi się do sprawnie działającej linii produkcyjnej. Wyobraźmy sobie zatem, że projekty, którymi zarządzamy mają za zadanie ciągłe dostarczanie wartości bez marnotrawstwa zasobów (m.in. czasu, finansów, przestojów sprzętu), ale też eliminując produkcję wadliwych lub niekompletnych produktów.
U podstaw Lean leży 6 podstawowych zasad:
- Dostarczaj wartość dla odbiorcy.
- Zidentyfikuj strumień dostarczania wartości do odbiorcy.
- Skup się na flow – optymalizuj przepływ dostarczania produktu/usługi.
- Zaprojektuj proces tak, by każdy kolejny krok pociągał za sobą kolejny.
- Ciągle optymalizuj proces.
- Wizualizuj proces.
Tak przedstawiony fundament transformacji Agile’owych może rzucać na nie nowe światło. Agile rozumiany jako iteracyjna praca w krótkich pętlach nastawionych na dostarczanie wartości działa świetnie jako pierwszy krok w procesie zmiany organizacyjnej. Żeby jednak dostarczanie produktu np. w postaci oprogramowania, budynku, produktu finansowego, przebiegało efektywnie, sprawnie i na czas, konieczne jest wdrożenie sprawnie działającej linii produkcyjnej, czyli dodanie do tej mieszanki metod Lean.
3 kroki do budowy projektowej liniii produkcyjnej
Krok 1: Produkty i subprodukty
Wracając do metafory linii produkcyjnej. Nikt nie tworzy linii produkcyjnej, na której w całości budowany jest samochód. Konstrukcja każdego produktu to od kilku do kilku tysięcy subproduktów, które składają się na produkt finalny. W przypadku samochodu będą to np. uszczelki czy składowe silnika.
Producent samochodów w celach optymalizacji produkcji najczęściej podzleca produkcję produktów składowych do firm specjalizujących się w konkretnych subproduktach. Dzięki specjalizacji producenci nie marnotrawią czasu na przełączanie się pomiędzy produkcją różnych części, są bardzo dokładni w ich wytwarzaniu, więc subprodukt jest wysoko jakościowy, a koszty i czas wytworzenia jest zoptymalizowany.
Rozdzielanie produktu głównego na mniejsze iteracje, na które składają się np. user stories dowożone w sprintach, to nic innego niż właśnie podzielenie produktu głównego na subprodukty. Aby podział produktu na subprodukty był efektywny, warto jednak pamiętać o:
- powtarzalności produkcji poszczególnych elementów,
- dedykowanej linii produkcyjnej dopasowanej do specyfiki subproduktu,
- możliwości wyspecjalizowania podmiotów (osób, działów, organizacji) w poszczególnych produktach,
- granularności subproduktów w procesie.
Organizacje przeprowadzające transformację Agile często tutaj popełniają błąd i utrzymują tradycyjny schemat organizacyjny zbudowany na bazie domeny biznesowej lub wykorzystywanej technologii, a nie podział na zespoły, których celem jest dostarczenie konkretnych subproduktów w powtarzalnym procesie. Jest to źródło ogromnego marnotrawstwa na poziomie organizacji. Doskonałym przykładem jest transformacja Agile w IT:
- podział ze względu na domeny biznesowe to np. podział na produkty IT dla branży travel dla linii lotniczych, agentów turystycznych czy dla turystów,
- podział ze względu na wykorzystywaną technologię to często podział kompetencyjny np.: back-end, front-end, testerzy, etc.
O ile więcej sensu miałby podział na zespoły, w których proces dostarczania konkretnych subproduktów jest powtarzalny. Przykładem takich powtarzalnych procesów jest np.:
- proces tworzenia strony www w oparciu o WordPress,
- proces tworzenia aplikacji mobilnej na Androida,
- proces integracji platformy webowej z serwerami pocztowymi do wysyłki komunikacji mailowej, etc.
W każdym takim procesie znaczna część kroków jest powtarzalnych. Da się je zamknąć na skończonej checkliście zadań, a dzięki temu opomiarować pod względem ilościowym i jakościowym. Pozwala to również zwizualizować flow, zadbać o powiązanie poszczególnych kroków procesu między sobą, a także zapewnić strumień stałego dostarczania wartości dla klienta. Dzięki powtarzalności procesu lepiej jesteśmy w stanie również zrozumieć potrzeby odbiorców.
Czyli podsumowując pozwala to realizować sprawnie pryncypia Lean.
Krok 2: Opomiarowanie ilościowe
Kolejną trudnością związaną z biznesową walidacją sukcesu transformacji Agile jest często brak opomiarowania jej realnych biznesowych rezultatów. Nic dziwnego – w przypadku braku powtarzalnych procesów jest to niezwykle trudne, czasochłonne i kosztowne. Jak jednak stwierdzić, czy coś jest sukcesem bez zmierzenia skali tego sukcesu?
W powtarzalnym procesie opomiarowanie jest proste. Lean podpowiada od czego zacząć.
Wyznacz strumień dostarczania wartości w procesie – to on powinien być opomiarowany jako pierwszy. Miary dostarczania strumienia wartości w procesie mogą być różne. Podstawowe to czas, koszt i zysk.
Doskonałym przykładem będzie tutaj branża budowlana. Powiedzmy, że projekt dotyczy budowy osiedla domków jednorodzinnych. Będziemy mieć tutaj serię powtarzalnych procesów np.:
- proces wylewania fundamentów,
- proces kładzenia dachu,
- proces wylewek,
- proces ułożenia kostek brukowych wokół domu,
- proces montażu piorunochronów, etc.
Widać jak na dłoni, że część procesów dostarcza kluczową wartość dla odbiorcy, a część to procesy poboczne. Kluczową miarą do opomiarowania będzie czas przestojów w pracy pomiędzy ekipami budowlanymi. Jego minimalizacja jest sposobem na zmniejszenie kosztów, a jednocześnie maksymalizację zysków (skraca się czas time-to-market i zwiększa liczba dostarczonych produktów w jednostce czasu, a co za tym idzie zysk firmy jest większy).
Oczywiście, żeby zmierzyć realny związek pomiędzy optymalizacją przestojów a kosztem i zyskiem, należy mierzyć również:
- koszt produkcji 1 produktu,
- koszt jednego procesu,
- zysk na 1 produkcie.
Punktem wyjścia jest opomiarowanie realnego czasu procesów i ich składowych.
Krok 3: Opomiarowanie jakościowe
Skupienie na optymalizacji czasu może prowadzić do zaniedbania kryteriów jakościowych. Dlatego kolejnym krokiem jest zdefiniowanie czynników jakościowych dotyczących odbioru produktu i każdego z subproduktów.
Wracając do przykładu linii produkcyjnej: kontroler jakości to kluczowa rola na produkcji. Tak samo jak jasne kryteria odbioru. Firmy produkcyjne doskonale rozumieją, że nawet jeden wadliwy składnik może zaważyć na sprzedaży produktu, a także na liczbie zwrotów.
Brak kryteriów jakościowych w procesie jest jednak często problemem nękającym firmy działające w duchu projektowym. Dlatego podczas transformacji Agile kluczowa jest walidacja jakości w procesie.
Kluczowe miary jakościowe zależą od branży, mogą to być m.in.:
- liczba reklamacji/poprawek,
- liczba wyłapanych błędów w kontroli jakości,
- koszty reklamacji/poprawek,
- zysk/oszczędność wynikająca ze zmniejszenia liczby reklamacji,
- wskaźniki związane z zadowoleniem klienta, np. NPS, % powrotów klientów, LTV.
Agile bez Lean to nie Agile
Agile powstał jako idea zwinnego wytwarzania oprogramowania. Przeniknął do innych dziedzin życia m.in. do zarządzania projektami – nie tylko w IT. Jednak źródła Agile sięgają metod Lean, przejmując ich miękką stronę (ludzie ponad procesy i narzędzia, współpracę z klientem ponad formalności, działający produkt ponad dokumentację, reagowanie na zmiany ponad podążanie za planem).
Zapomina się jednak przy tym, że słowo „ponad” zawarte w Agile Manifesto nie oznacza rezygnacji z procesów, narzędzi, formalności, dokumentacji czy planu. Wszystkie te elementy są również istotne dla sukcesu projektów i produktów, które są ich rezultatami.
Warto również zwrócić uwagę, że Agile formułowany był w czasach, kiedy ciężko było o powtarzalność procesów w projektach IT. Firmy IT działały wówczas w sytuacji ciągłej zmiany i dynamicznego rozwoju. Po 30 latach digitalowej transformacji można jednak zaobserwować potrzebę budowy powtarzalnych procesów, a także ich standaryzacji i opomiarowania. Powrót Agile do korzeni Lean nie tylko pozwoliłby na urealnienie jego wartości biznesowej, ale też na jego dalszy rozwój.
1 https://www.consultancy.eu/news/3451/agile-working-is-becoming-a-strategic-transformation-priority
Beata jest serial entrepreneurką, współzałożycielką i managing partnerką w Project: People i Project: Values, jednocześnie jest prezesem 2 spółdzielni Hermes & Partner. Dodatkowo jest współautorką książki The LiGHT Book (z m.in. Robertem Cialdini czy Phillipem Zimbardo) oraz autorką różnorodnych narzędzi biznesowych (m.in. Values Poker czy Lean Marketing Sprint). Beata jest strategiem, marketingowcem i konsultantem lean z ponad 14 letnim doświadczeniem na międzynarodowym rynku. Współpracowała m.in. z takimi firmami jak Sabre, T-Mobile czy Google. Dzieli się wiedzą i doświadczeniem jako mentor w programach akceleracyjnych (np. Google LaunchPad Warsaw, EIT Digital) oraz jako wykładowca na Wyższej Szkole Europejskiej oraz Wyższej Szkole Bankowej w Gdańsku. Więcej na: www.mosor.pl