Lean i Agile nie tylko w IT…

Na koniec 2012 roku zostałem zaproszony na konferencję Agile w Biznesie. Na jej zakończenie odbyła się dyskusja, którą prowadzący zaczął stwierdzając, że przez dwa dni słuchaliśmy o przykładach wdrożeń Agile w IT, w organizacjach takich jak Grupa Allegro czy Gemius, czyli firm zbudowanych wokół oprogramowania, ,więc może w końcu porozmawiamy o

Agile w biznesie. Chwilę później jeden z uczestników zapytał czy są przykłady użycia tego całego adżajla w prawdziwych, porządnych organizacjach jak banki czy firmy motoryzacyjne. A co z Toyotą? A co z bankami inwestycyjnymi (na wielu konferencjach omawiane są projekty z tego obszaru)? I przede wszystkim – czym jako organizacja biznesowa różni się allegro.pl (zbudowane wokół systemu aukcyjnego) od dowolnego banku (zbudowanego wokół systemu centralnego)? W mojej ocenie większość organizacji “biznesowych” w XXI wieku jest budowana wokół kluczowego oprogramowania. Oczywiście software to nie wszystko, ale tak samo firmy takie jak Grupa Allegro, Gemius czy Onet to nie tylko software.

Agile Product Development

Pierwsze oblicze Agile, od którego należy zacząć, to Agile Product Development – zwinne wytwarzanie produktów. W tej kategorii mieszczą się mocno wyeksploatowane już zagadnienia takie jak Scrum czy Extreme Programming, czyli metody organizacji pracy zespołów tworzących nowe produkty. Metody te jakiś czas temu trafiły do mainstreamu, ale jednocześnie w mojej ocenie są bardzo mocno skoncentrowane na operacyjnej pracy zespołów, który to obszar nie jest aż tak istotny dla wyższej kadry zarządzającej.

Wikispeed

Przykładem przedsięwzięcia spoza IT wykorzystującego Scrum jest organizacja Wikispeed, której celem jest zbudowanie sportowego samochodu spalającego poniżej 1,5 l / 100 km (albo jak liczą Amerykanie – przejeżdżającego ponad 100 mil na galonie benzyny). Wikispeed wytwarza kolejne prototypy samochodu w tygodniowych iteracjach, z których każda dostarcza działający i poprawiony samochód.

Cykl pracy (czyli od pomysłu inżyniera do usprawnienia “na produkcji”) trwa tydzień, podczas gdy w przypadku tradycyjnych firm motoryzacyjnych zajmuje to do kilku lat(np. 3 lata w przypadku Porsche). Samochód Wikispeed jest dopuszczony do ruchu (w USA) oraz uzyskał pięciogwiazdkowe wyniki w testach zderzeniowych. Więcej informacji na temat Wikispeed można znaleźć w licznych prezentacjach Joe Justice’a (pomysłodawcy tej inicjatywy), np. tutaj: http://www.youtube.com/watch?v=pjempylJy1w.

Lean

Drugi obszar filozofii Agile (pewnie niektórzy się obruszą, w końcu Lean był pierwszy – ale nie chodzi tu o dyskusje nad nazwami, tylko o ideę) to usprawniane (albo odchudzanie) procesów w organizacji – szeroko rozumiany Lean. Historia zaczyna się od

Lean Manufacturing w Toyocie, następnie w latach siedemdziesiątych pomysł eliminowania marnotrastwa w projektach oprogramowania znalazł odzwierciedlenie w Lean Software Development, a obecnie metody wizualizacji procesów biznesowych (np. mapowania strumienia wartości) są wykorzystywane w wielu obszarach zarządzania organizacją. Lean poprawy procesów biznesowych upatruje w skracaniu czasu cyklu – przejścia pracy przez dowolny proces generujący wartość. Im krótszy czas, tym bardziej elastycznie jesteśmy w stanie reagować na zmieniający się rynek.

Maersk

Przykładem firmy, która wdrożyła Kanbana (najpopularniejszą obecnie metodę Lean) w dziale produkcji oprogramowania, jest Maersk Line – największy na świecie spedytor kontenerów. Maersk jest przykładem organizacji, której kluczowa usługa nie ma nic wspólnego z oprogramowaniem, a jednak – tak jak w przypadku większości organizacji w XXI wieku – oprogramowanie stanowi serce całej organizacji. Maersk poprawił czas cyklu (od pomysłu do wdrożenia produkcyjnego) dla dwóch pilotażowych projektów o przynajmniej 50% (208 dni skrócono do 104 dni, a w przypadku drugiego projektu – 168 dni skrócono do 60 dni). Średnia dla całej organizacji przed wdrożeniem Kanbana wynosiła 150 dni, a po wdrożeniu spadła do 90 dni. Poprawie uległy inne kluczowe mierniki – jakość (liczba defektów) spadła o 88%, a opóźnień – o 80%. Drastycznemu zwiększeniu uległo ROI – wzrosło z ok. 4$ do ponad 26$ (w przypadku kluczowego systemu) na każdy zainwestowany dolar. Jednocześnie zwiększyła się efektywność zespołu (nieoczekiwany efekt uboczny odchudzania procesów) – koszt realizacji funkcjonalności spadł o 9%. Więcej o implementacji Lean i Agile w Maersk Line można znaleźć w prezentacji Ozlem Yuce – odpowiedzialnej za wdrożenie Agile w tej organizacji:

http://www.slideshare.net/OzlemYuce/ozlem-yuce-less-131112.

Stoos

Network Trzecią częścią agile’owego świata jest obszar, który dotyka zarządzania organizacją jako całością. Płaszczyzną do wymiany doświadczeń w tym obszarze jest Stoos Network, grupa zrzeszająca wiele osób uważających, że zarządzanie organizacjami nie przystaje do realiów i wyzwań XXI wieku i potrzebuje rewolucji. Trzeba zauważyć, że zarządzanie jako dziedzina działalności człowieka jest wynalazkiem takim jak wiele innych. Podwaliny pod współczesne zarządzanie położył Taylor na przełomie XIX i XX wieku. Innym wynalazkiem z tego okresu jest telefon. I chyba dla wszystkich jest oczywiste, że telekomunikacja i telefony przeszły od tego czasu kilka wielkich rewolucji. A jednak jeśli chodzi o zarządzanie –

ciągle próbujemy kierować organizacjami tak, jakby były one osadzone w realiach rewolucji przemysłowej… Istotnym obszarem rewolucji w zarządzaniu, o której mówię, jest kwestia kultury organizacji i relacji z pracownikami. W XIX wieku pracownicy, którymi trzeba było zarządzać stanowili w większości niewykwalifikowaną siłę roboczą… Znacząco od tego czasu się to zmieniło. Już w latach 60tych Douglas McGregor przedstawił Teorię X i Teorię Y (http://en.wikipedia.org/wiki/Theory_X_and_Theory_Y). Organizacje zbudowane z myślą o kontroli i sterowaniu pracownikami motywowanymi zgodnie z Teorią X obrastają w procedury i biurokrację, które jakże często odstraszają utalentowanych pracowników. Jestem przekonany, że jednym z największych zagrożeń stojąccych przed wszystkimi przedsiębiorstwami obecnie jest ryzyko utraty kluczowych pracowników i problem ze ściąganiem nowych talentów. Bardzo dobrą (i już klasycznie cytowaną) prezentację na temat potrzeby rewolucji w zarządzaniu dał Gary Hamel (http://www.youtube.com/watch?v=K3-_IY66tpI).

Statoil, Handelsbanken

Nowoczesne podejście do zarządzania kwestionuje wiele utartych praktyk zarządzania, które po głębszym zastanowieniu okazują się być bardziej szkodliwe niż korzystne. Jedną z takich praktyk są budżety roczne. Myślę, że każdy kto miał w swojej karierze do czynienia z budżetowaniem albo przesuwaniem środków pomiędzy budżetami nie potrzebuje wyjaśnienia

do jakich dysfunkcji mogą budżety prowadzić. I w przekonaniu wielu osób koszt tych dysfunkcji jest zbyt duży, żeby uzasadniać korzyści z budżetów płynące. Organizacjami, które budżetowanie odrzuciły są np. Statoil czy szwedzki Handelsbanken. Idea odejścia od budżetów została opisana w koncepcji Beyond Budgeting, o której często opowiada Bjarte Bogsnes (członek zarządu Statoil). Beyond Budgeting nie sprowadza się jedynie do porzucenia budżetów, ale jest to jeden z jej istotnych elementów. Więcej szczegółów można znaleźć w wykładzie Bjarte tutaj: http://www.youtube.com/watch?v=Ed1g_Crw6v8.

World Bank

Inną wielką organizacją, której przedstawiciel jest aktywnym uczestnikiem ruchu Stoos jest Bank Światowy. Steve Denning, przez dziesięć lat dyrektor departamentu w Banku Światowym, opisał swoje przemyślenia w książce

Radical Management, gdzie zauważa, że zarządzanie organizacjami potrzebuje radykalnej zmiany i wprost pisze o inspiracjach płynących ze zwinnych metodyk rozwoju oprogramowania takich jak Scrum. O Radical Management rozmawialiśmy ostatnio na spotkaniu Agile Warsaw. Nagranie z tego spotkania już wkrótce będzie dostępne na kanale http://youtube.com/agilewarsaw.

Thogus Products

Wiele (jeśli nie większość) organizacji stoi obecnie przed

groźbą utraty rynku. Przez utratę mam tu na myśli “utowarowienie” (czy ktoś zna dobre tłumaczenie zwrotu “commoditization”?) ich kluczowych produktów czy usług. Najbliższy nam w TouK rynek telekomunikacyjny jest idealnym tego przykładem – operatorzy komórkowi byli przez lata kurami znoszącymi złote jajka – usługa była świeża, produkt innowacyjny. Obecnie jest jednak dla wszystkich oczywiste (i to bynajmniej nie tylko w Polsce), że rola telekomów powoli sprowadza się do roli przesyłania danych. I wszystkie telekomy szukają jakiegoś pomysłu na dostarczanie wartości dodanej klientom – jak na razie chyba bez skutku… Taką samą sytuację miała firma Thogus Product, założona pod koniec lat 50 rodzinna firma zajmująca się odlewami z plastiku. Po 40 latach, w obliczu kryzysu przełomu tysiącleci, właściciel stwierdził, że mimo stabilnej sytuacji finansowej, to obecny rynek stał się tak ciasny, że dla Thogus koniecznością jest zmiana profilu działalności i z firmy przemysłowej przeistoczenie się w firmę technologiczną. W efekcie tego procesu zwolnionych zostało 50% załogi – na pokładzie zostali tylko Ci, którym pasowała wizja budowania organizacji na miarę nowej epoki. Firmie mimo zmniejszenia obsady udało się podwoić obroty. Więcej o historii można usłyszeć w wywiadzie z prezesem i właścicielem: http://www.youtube.com/watch?v=-XxlAn7N2Ts.

Zappos

Wreszcie Zappos, internetowy sklep z butami i firma, o której innowacyjnym podejściu do zarządzania można opowiadać długo. Ja jednak chciałem wykorzystać ich przykład do pokazania jak często i jak bardzo organizacje postawiły swoje działanie na głowie… Chodzi mi tu o działanie call center i generalnie obsługę klienta. Firmy wydają obecnie miliony na tworzenie produktów, ich marketing i sprzedaż. I często nie mają żadnej bezpośredniej relacji z końcowymi użytkownikami czy klientami. Kontakt ten pojawia się w momencie kiedy niezadowolony klient dzwoni ze swoim problemem do call center. Jakże często w organizacjach “słuchawki” są centrum kosztowym, którego działanie należy optymalizować pod kątem redukcji kosztów. Jakże często obsługa klienta jest outsource’owana (często w przypadku firm amerykańskich i niektórych zachodnioeuropejskich – outsource’owana do Azji). Jakże często metryki efektywności call center to utylizacja czasu na telefonie i szybkość zamknięcia sprawy. Jakże często pracę call center opisują skrypty rozmów albo wręcz automaty. Nie oszukujmy się, wszyscy to znamy, do każdego dzwonią “oskryptowani” telemarketerzy… Zappos do obsługi klienta podeszło zupełnie inaczej. Po dwutygodniowym szkoleniu (w którym swoją drogą muszą wziąć udział wszyscy pracownicy firmy, niezależnie od stanowiska i roli) operatorzy call center dostają swoje biurko, swój telefon, żadnego skryptu i jedno zadanie –

rozwiązać problem dzwoniącego klienta. I jedną metrykę – liczba zadowolonych klientów **po zakończeniu obsługi zgłoszenia. Nic dziwnego, że Zappos zapracował sobię na renomę firmy “powered by service”… O call center, albo jak sami o tym mówią, o **customer experience w Zappos posłuchać można np. na prezentacji http://www.youtube.com/watch?v=UOQb1WyvG5A.

Lean Startup

Ostatnim kluczowym obszarem Agile jest jej najmłodszy przedstawiciel – Lean Startup (chociaż jest on tak naprawdę mocno zakorzeniony w metodyce

Customer Development z lat dziewięćdziesiątych). W mojej ocenie kluczowym elementem, o którym mówią Eric Ries i Steve Blank, jest sama definicja startupu. Powszechnie rozumiemy startup jako małą, startującą firmę, dwóch nastolatków w garażu, przymierających głodem i budujących nowy rewolucjny produkt albo portal internetowy. Autorzy Lean Startup odchodzą od tej intuicyjnej definicji. Stwierdzają oni, że startup to każda organizacja, albo jej fragment, która działa w warunkach wysokiej niepewności (technologicznej, biznesowej, albo innej), której zadaniem jest odkrycie działającego i powtarzalnego modelu biznesowego (czyli najczęściej klientów gotowych płacić za dany produkt albo usługę). Ustatkowane przedsiębiorstwa uruchamiając “projekty” tworzące nowe produkty jak najbardziej można traktować jako startupy, tyle że mające mniej lub bardziej komfortowe zaplecze finansowe. Ja podejście to rozciągam jeszcze bardziej. Jestem gotowy postawić tezę, że olbrzymia większość organizacji działających dziś na rynku potrzebuje przełomowych, innowacyjnych produktów. W tym momencie w swoich centralnych obszarach biznesowych są one nieodróżnialne od konkurencji. Jako klient różnych banków nie widzę istotnych różnic pomiędzy ich produktami. Oferty telekomów nie różnią się w żaden dostrzegalny sposób. Producenci energii, których od kilku lat możemy zmieniać tak jak operatorów komórkowych – tak samo. Przykłady można mnożyć. Jednocześnie łatwość tworzenia nowych produktów powoduje, że jesteśmy zasypywani innowacyjnymi alternatywami. PayPal odebrał istotną część rynku bankom. Nie będę bardzo zaskoczony, jeżeli za kilka lat kolejny kęs rynku finansowego “łyknie” BitCoin, telewizje będą marginelizowane przez YouTube i Netflix, albo (i?) powszechnie będziemy używać w domu drukarek 3D do tworzenia przedmiotów codziennego użytku (których wzory będziemy pobierać z ikea.com, choć pewnie częściej z jakiegoś nowego You3Design :D). Korporacje, chcąc tego uniknąć, muszą same zacząć działać w duchu startupowym i zacząć tworzyć innowacyjne produkty…

IMVO

Firmą, której historia pokazuje o co chodzi w Lean Startup i dlaczego zwyczajowe podejście do robienia startupu (wymyślmy produkt, zbudujmy go, sprawdźmy czy ktoś go kupi) tak często się nie udaje (prawdopodobieństwo dużego sukcesu w okolicach 1%), jest IMVO, fimra założona na początku lat 2000 przez Erica Riesa. Nie chcąc opisywać całej historii napiszę tylko, że firma ta przez pół roku tworzyła pierwszą wersję swojego produktu, po czym, w trakcie pierwszego kontaktu z klientami, okazało się, że nikt nie chce go w tej postaci używać. Dużą część pracy zespołu trzeba było wyrzucić do kosza. Jedyne co pozostało po tym pół roku była zgromadzona wiedza o tym, że w tej formie użytkownicy produktu nie będą używać. Ries zaczął się zastanawiać czy tej samej wiedzy nie dało się zgromadzić szybciej i taniej. I doszedł do wniosku, że wystarczyłby

** jeden dzień pracy**, w trakcie którego powstałaby strona www opisująca wszystkie zalety produktu z jednym przyciskiem – pobierz wersję testową. Przycisk mógłby nie działać, bo jak się okazało – użytkownicy nie byli zainteresowani takim produktem! Wiedza zdobyta – taka sama. Nakład pracy – przynajmniej stukrotnie niższy. I dokładnie taka filozofia leży u podstaw Lean Startup. Początek istnienia każdego produktu czy nowej usługi (tak w startupie jak i w ustabilizowanej korporacji) sprowadza się do znalezienia działającego modelu biznesowego, czyli – w pewnym uproszczeniu – klientów. Jednocześnie budżet takiego projektu nie powinien być przeliczany na liczbę funcjonalności w produkcie czy jego jakość (zakres), tylko raczej na liczbę eksperymentów i modyfikacji tego modelu (w Lean Startup taka modyfikacja nazywana jest Pivotem). Więcej o Lean Startup można usłyszeć w jednym z licznych wykładów Erica Riesa, np. tu: http://www.youtube.com/watch?v=fEvKo90qBns. Z kolei jeśli chodzi o jego mentora, Steve’a Blanka, polecam obejrzenie rozmowy z nim przeprowadzonej w ramach Commonwealth Club tutaj: http://www.youtube.com/watch?v=1RTcXwJuCaU.

Podsumowanie

Wiele dużych organizacji (przynajmniej w Polsce) do Agile podchodzi z dużym dystansem. Wyższa kadra zarządzająca nie do końca dostrzega problem, który Lean czy Agile próbuje adresować. Często próby wykorzystania takiej metodyki, np. Scruma, odbierane są jako chęć zepchnięcia odpowiedzialności przez IT na biznes, albo co gorsza, przez dostawcę na zamawiającego.

Paradoks leży w tym, że w Agile zupełnie nie o to chodzi. Ryzyko tylko teoretycznie w klasycznym podejściu jest przenoszone na dostawcę. Ostatecznie za produkty wykonane nawet najlepiej jak jest to możliwe, ale takie, których rynek nie przyjął, płaci biznes. Za odpływających utalentowanych pracowników i problemy z przyciąganiem nowych liderów płaci biznes. Za przerośnięte i nieefektywne procesy biznesowe i marnotrastwo czasu i energii również płaci biznes. Osobiście uważam, że elementem wspólym dla wszystkich metodyk, praktyk czy podejść mieszczących się w jakże pojemnym w 2013 roku pojęciem Agile, jest zdrowy rozsądek i brak zgody na absurdy, w które korporacje obfitują. Absurdem (przynajmniej wg. mnie) jest kontynuowanie projektu, o którym wszyscy w połowie jego trwania już wiedzą, że nie zrealizuje swoich celów, a na zakończenie i tak fetują “wielki” sukces. Absurdem (przynajmniej wg. mnie) jest akceptowanie (i w ogóle dopuszczanie do) konfliktów pomiędzy działami w organizacji, w efekcie czego efektywna komunikacja jest nierealna, a wszystkie inicjatywy przede wszystkim walczą z oporem materii zamiast koncentrować się na generowaniu wartości. Szeroko rozumiany Agile to jasno wyrażony sprzeciw wobec prognoz i raportów tworzonych w Excelu (w raportach możemy udowodnić każdą tezę), to wybór często trudnej, ale rzeczywistej rzeczywistości :), to akceptacja faktu, że wiemy, że niewiele o rynku wiemy i nie okłamywanie się, że nasze plany na początku są trafione. Wiemy, że się zmienią, nie wiemy tylko kiedy i jak bardzo… Także przyjęcie (przynajmniej w jakimś stopniu) podejścia agile’owego przez ustabilizowane korporacje nie uważam osobiście za ekstrawagancję czy eksperyment, a raczej jako nieuniknioną konieczność, jeśli organizacje te chcą (w dłuższej perspektywie) przetrwać.

You May Also Like

Agile BI

Sztampowe podejście do tematu Business Intelligence to zbudowanie hurtowni danych, stworzenie procesów ETL i wdrożenie narzędzia (interfejsu użytkownika) do raportów i analiz. Jednakże oparta na relacyjnym modelu hurtownia danych nie radzi sobie ze wszystkimi klasami problemów, z którymi powinien poradzić sobie system wspierający podejmowanie decyzji biznesowych. Przykładem mogą tu być (na prawdę) bardzo duże ilości danych Tradycyjne rozwiązanie wymaga uprzedniego ustalenia jakiego rodzaju fakty będą podlegać późniejszej analizie. A przecież pomysł na wykorzystanie do budowania przewagi konkurencyjnej posiadanych (w pewnym momencie) informacji może przyjść nam do głowy później. Czy gromadząc dane musimy jakąś część informacji tracić? Czy możemy zbierać i szybko analizować dane, które nie mieszczą się w naszej hurtowni?Sztampowe podejście do tematu Business Intelligence to zbudowanie hurtowni danych, stworzenie procesów ETL i wdrożenie narzędzia (interfejsu użytkownika) do raportów i analiz. Jednakże oparta na relacyjnym modelu hurtownia danych nie radzi sobie ze wszystkimi klasami problemów, z którymi powinien poradzić sobie system wspierający podejmowanie decyzji biznesowych. Przykładem mogą tu być (na prawdę) bardzo duże ilości danych Tradycyjne rozwiązanie wymaga uprzedniego ustalenia jakiego rodzaju fakty będą podlegać późniejszej analizie. A przecież pomysł na wykorzystanie do budowania przewagi konkurencyjnej posiadanych (w pewnym momencie) informacji może przyjść nam do głowy później. Czy gromadząc dane musimy jakąś część informacji tracić? Czy możemy zbierać i szybko analizować dane, które nie mieszczą się w naszej hurtowni?