Kosmiczne agilowe innowacje

W pierwszy dzień Świąt na TVN24 wyemitowano bardzo ciekawy reportaż dotyczący oryginalnego konceptu i historii przyznania X Prize. Dla niezorientowanych: nagrodę XPrize w wysokości USD 10 mln ufundował wówczas nieznany biznesmen a miała ona być przyznana pierwszej drużynie, której uda się skonstruować komercyjny statek kosmiczny, który w ciągu 2 tygodni dwukrotnie wyniesie na niską orbitę (100 km) dwie osoby. Miało to otworzyć drogę do kosmicznej turystyki. Nagrodę zdobył w 2004 roku zespół pod kierownictwem konstruktora Burta Rutana. Reportaż cały był arcyciekway, ja zwrócę uwagę na dwie rzeczy.

Jednym z zespołów startujących do XPrize, któremu nie udało się wtedy wygrać, był Armadillo Aerospace. Jego kierownik opowiadał o tym jak przygotowywali się do stworzenia pojazdu. Po pierwsze zespół składał się z ludzi o różnych zainteresowaniach i umiejętnościach, ale wspólnie stanowili całość, która była w stanie zaprojektować i zbudować pojazd. Po drugie pracowali i pracują głównie społecznie, bez znaczącego wsparcia finansowego, więc musieli wymyśleć jak najbardziej efektywny sposób pracy. Sposób ten polegał na tym, że co tydzień budowali prototyp, przeprowadzali próbę oraz następnie zbierali dane i wyciągali wnioski. W następnym tygodniu od nowa. Coś Wam to przypomina? I neich mi ktoś jeszcze raz powie, że agile to tylko software a i to nie każdy. Pewnym wytłumaczeniem skąd metody agile w projektowaniu pojazdów kosmicznych niech będzie fakt, że szefem firmy jest niejaki John Carmack- współtwórca Id Software (Wolfenstein, Doom, Quake, ...). Co ciekawe metody się sprawdzają. Zespół co prawda nie wygrał oryginalnej XPrize, ale za to dwa miesiące temu skasował nagrodę za tzw. poziom pierwszy Northrop Grumman Lunar Lander Challenge. I jako jedyny podszedł to poziomu drugiego, na razie niestety bez rezultatu (szczegóły w wideo na podanej stronie).

Moja druga obserwacja z całego tego reportażu jest natomiast zupełnie inna. Reportaż otworzył mi oczy na to jakie gospodarcze znaczenie miała X Prize. Powstało kilkadziesiąt firm, setki ludzi podjeło wyzwanie i stanęło do walki o nagrodę. Ilość wytworzonej w ten sposób wiedzy, innowacji i produktów naprawdę wysokiej technologii jest nie do przecenienia. Oczywiście były i sukcesy jak i porażki - parę firm zbankrutowało, parę innych bardzo słabo sobie radzi. Jednak patrząc się na całość nie mogę odeprzeć wrażenia, że skutki były więcej niż pozytywne. To wszystko zostało spowodowane przez sumę 10 mln dolarów amerykańskich, czyli mniej więcej 30 mln PLN. To tyle, ile mniej więcej kosztuje wyremontowanie 1 km ulicy w mieście. I znowu pojawia się u mnie to pytanie: dlaczego u nas tak nie można??? Czy nas naprawdę nie stać na te 30 mln, czy też chodzi o co innego? Za wskazówkę niech świadczy fakt, że w Google Lunar X Prize starują obok drużyn z USA taże Włosi, Niemcy, Duńczycy, Szwajcarowie, ale także... Malezyjczycy i ..... Rumuni. Polacy nie :-(

Wdrożenia nowych metod - zadanie domowe

W środowisku osób zajmujących się wdrożeniami systemów zarządzania projektami (chodzi tu o systemy rozumiane jako zestawy procesów a nie oprogramowanie) do rangi anegdoty kultowej urosło podobno prawdziwe zdanie, wypowiedziane przez jednego z konsultantów pod koniec długiego i kosztownego projektu wdrażania nowej metody zarządzania projektami w pewnej firmie (XXX - nazwa metody zarządzania projektami):

“Jak na dziś to wszyscy już rzygają tym naszym XXX, w związku z czym wdrożenie uważam za w pełni zakończone sukcesem!!!”

Hmm. Przypadek wręcz kliniczny, który przypomniał mi się w ramach kolejnej rundy rozważań nad pewnym nieudanym wdrożeniem metod agile. Pytanie brzmi następująco. Jeżeli wdrażamy coś (cokolwiek) nowego w organizacji i jako efekt dostajemy aktywne niezaangażowanie osób do których adresowane było wdrożenie tego czegoś, to o czym to świadczy? Hipoteza jest taka, że po prostu nie odrobiliśmy pracy domowej i wdrożyliśmy rzecz, która jest absolutnie niepotrzebna z punktu widzenia osób zaangażowanych lub mimo, że rzecz jest potrzebna, to sposób jej wdrożenia jest nieadekwatny. Przez rzecz niepotrzebna rozumiem nie pozwalająca jednostkom na osiąganie lepszych rezultatów. Rezultatów mierzonych w sposób taki w jaki się je mierzy dla każdego konkretnego człowieka w tej konkretnej organizacji. Innymi słowy, mówiąc kolokwialnie z wprowadzonej przez nas zmiany człowiek “nic nie będzie miał”.

Oczywiste pytanie to czy każdy musi z tego wdrażanego rozwiązania coś mieć. Jasne, że tak! Bo skoro organizacja jako całość ma na danej nowości zyskać, to dlaczego nie mieliby zyskać poszczególni uczestnicy tej organizacji? Wszyscy uczestnicy. Z jakiego powodu tak często zakładamy, że wdrożenie czegoś nowego musi być robione przeciw ludziom a nie z ludźmi? Czy naprawdę jeżeli wdrażamy coś nowego to musi być tak, że ktoś będzie "rzygał" tym rozwiązaniem? Moja hipoteza jest taka, że absolutnie nie. Jeżeli rozwiązanie jest dobre dla całości organizacji, to musi być sposób, aby skonstruować je tak, aby było dobre dla wszystkich osób w nią zaangażowanych (odwrotnie nie działa). Powtarzam wszystkich. Tylko trzeba ten sposób znaleźć, dokładnie analizując sytuację.

Przed wdrożeniem trzeba odrobić pracę domową i zobaczyć jak zmiany proponowane przez agile mogą pomóc wszystkim innym interesariuszom projektów w organizacji. Ta pomoc musi zwłaszcza być sprawdzona w odniesieniu do miar, którymi mierzona jest efektywność pracy poszczególnych kierowników. Chodzi o to, aby tak skonstruować system zarządzania, że wprowadzenie nowych reguł spowoduje z punktu widzenia poszczególnych jednostek zmiany pozytywne. Bo na przykład będzie łatwiej osiągać właściwe cele lub choćby prezentować wyniki. Jeżeli nie zadbamy o to, aby wszystkim ważnym interesariuszom było łatwiej to osiągniemy efekt podobny do wyrażonego w przytoczonym cytacie. I osoby aktywnie niezaangażowane we wdrożenie, powodujące realne zagrożenie jego powodzenia.

Stąd, jak już kiedyś pisałem, jednym z większych błędów jakie można zrobić przy wdrażaniu agile jest wdrożenie samych tylko procedur. Trzeba zmienić jeszcze także inne elementy organizacji. A to jak je zmienić i na jakie, tak aby spowodować z jednej strony akceptację, a z drugiej zakładany efekt biznesowy to już jest zadanie domowe dla tych, którzy agile wdrażać będą. I gwarantuję dwie rzeczy:

1. nie jest to proste
2. nie ma gotowych rozwiązań (porównaj).

Innowacyjność po polsku...

Niestety tym razem chodzi tylko o to, że przetłumaczona na język polski. Jakiś czas temu napisałem tu wpis "Dlaczego nie u nas?" na temat tworzenia w USA wysoce innowacyjnych projektów z budżetem ~50 USD.

Ostatnio dostałem od Radka informację (dziękuję), że opisana tam sesja z TED jest już dostępna z polskim tłumaczeniem. Razem z informacjami o innych ciekawych projektach umieszczona jest na mindblowing.pl: http://mindblowing.pl/?p=81

Innowacje organizacyjne

Na początek trochę teorii i rozważań "podstawowych".

Świat jest przez nas opisywany za pomocą pewnych reguł. Stałych i niezmiennych. Te reguły określają to w jaki sposób działa świat (np. masy się przyciągają). Na podstawie reguł, które naszym zdaniem opisują świat, tworzymy pewnego typu metody i procedury, które są niczym innym jak zastosowaniem tychże reguł do konkretnego środowiska (np. szklankę stawiamy na stole a nie obok stołu - bo spadnie, co wynika wprost ze wspomnianej wcześniej reguły).

Przy takim spojrzeniu na organizacje działające w świecie rzeczywistym możemy założyć, że są dwie metody wprowadzania innowacji w organizacji. Pierwszy to zmiana metod i procedur. Po prostu jak chcemy wprowadzić coś nowego to zaczynamy od tego, że zmieniamy sposób działania ze starego na nowy. Następnie sprawdzamy czy nowy sposób działa lepiej czy gorzej, oczywiście względem pewnego konkretnego wskaźnika, który powinniśmy wyznaczyć zanim cokolwiek zaczniemy zmieniać. Ten sposób nazywa się często z angielska learning-by-doing.

Jest też drugi sposób wprowadzania innowacji, który o ile dobrze kojarzę nazywa się learning-by-understanding. Ten sposób zakłada, że zanim zaczniemy zmieniać cokolwiek w metodach i procedurach powinniśmy przeanalizować reguły, które rządzą danym kawałkiem rzeczywistości. W tym zwłaszcza upewnić się, czy to co wydaje się nam regułą opisującą daną rzeczywistość na pewno nią jest. Można tu zastosować metodę naukową. Dopiero jak mamy wystarczająco dobre reguły, to na ich podstawie konstruujemy metody i procedury. Tak aby wypełniały te zidentyfikowane reguły w konkretnym środowisku.

Powyższe uwagi są uwagami ogólnymi, ale jak najbardziej stosują się do agile a tak konkretnie do wdrażania metod zwinnych w organizacjach. Wielkim błędem jest wdrażanie metod "bo tak wszyscy robią", czy z innych tego typu powodów. A tak niestety często się dzieje. Niestety. To jest typowe podejście zmiany procedur i metod oraz później modlenia się o rezultaty. Stosując nielubiane przez mnie porównania wojskowe jest to podobne do radzieckiego "rozpoznania bojem". Ze względu na historycznie przetestowany poziom strat własnych podejście jest bardzo niezalecane. Zalecane jest za to sprawdzenie jakie reguły obowiązują w danym wycinku rzeczywistości, w którym porusza się dana organizacja. Dopiero na tej podstawie można skonstruować zestaw metod i procedur, które wdrożone przyniosą dokładnie taki efekt jak spodziewany.

To, co opisałem powyżej jest jedną z przyczyn dla której nie słyszałem o udanym wdrożeniu metod zwinnych, które było przeprowadzone ściśle według książki. Po prostu książki opisują pewną wiedzę ogólną a każda z organizacji działa w trochę innym otoczeniu, więc zestaw praktyk i metod musi być inny (choć reguły mogą, ale nie muszą, być takie same). I stąd właśnie do wdrożenia metod zwinnych często firmy potrzebują pomocy z zewnątrz - aby ktoś bezstronny "obejrzał" daną organizację i pomógł zdefiniować właściwe działania.