Przyczyna źródłowa

Pisząc o koncepcji Jidoka napisałem tak “[pracownik ma obowiązek] znaleźć przyczynę takowego niepożądanego stanu rzeczy, wyeliminować ją i dopiero potem [podjąć z powrotem pracę]”. Po zastanowieniu dochodzę do wniosku, że to jest świetny materiał na rozważania o tym, co powinno być elementem sesji retrospekcji i co leży w obowiązku kierownika projektu, zwłaszcza realizowanego metodami agile. Chodzi o to znajdowanie i eliminowanie przyczyn źródłowych problemów.

Jak się popatrzy na obecne środowisko pracy w wielu organizacjach to jedyną reakcją na problemy stosowaną przez wyższe kierownictwo jest coraz większy nacisk na to, aby problemów nie było. Jeżeli projekt przekracza deadline’y to kierownictwo wyznacza większe bonusy za dotrzymanie deadline’ów. Jeżeli jest za dużo błędów to grozi się obcięciem pensji za ponowne wypuszczenie błędnej wersji oprogramowania. Problem w tym, że takie podejście tak naprawdę konserwuje to, co jest. Bo zakłada, że wszystko robiliśmy dobrze, tylko się nie staraliśmy wystarczająco dobrze. Więc jeżeli następnym razem się postaramy bardziej to będzie dużo lepiej. Hmm, bardzo odważne założenie. W rzeczywistości będzie zapewne tak, że jak teraz przy tych metodach które mamy trochę nam nie wyszło to jak je zastosujemy jeszcze bardziej dokładnie to jeszcze bardziej nam nie wyjdzie.

Tak naprawdę rzadko kto podejmuje się zadania proponowanego przez Japończyków (choć nie tylko ich) czyli znalezienia przyczyny źródłowej takiego a nie innego stanu rzeczy. Wysiłek ten podejmowany jest rzadko, bo nie jest to zadanie proste. Przyczyna źródłowa oznacza zadawanie pytania “dlaczego” tak długo aż dojdziemy do odpowiedzi, której już dalej nie da się podzielić. Co więcej bardzo często znajdowanie przyczyny źródłowej polega na odkrywaniu i kwestionowaniu podstawowych założeń, na których oparta jest nasza organizacja i jej sposób działania.

Jeżeli popatrzyć na metodyki agile to najodpowiedniejszym miejscem do znajdowania przyczyn źródłowych problemów wydaje się być retrospekcja. Wówczas poza zastanowieniem się co się stało warto by też zastanowić się nad przyczynami źródłowymi problemów. Ponieważ nie jest to łatwe ani proste nie można się zastanawiać nad wieloma przyczynami źródłowymi jednocześnie. Raczej spośród wielu problemów nękających projekt należałoby wybrać jeden, który najbardziej boli i skupić się na jego rozwiązaniu. Czyli najpierw znaleźć jego przyczynę źródłową a dopiero potem wdrożyć rozwiązanie.

Aha i tutaj jedna uwaga. Przyczyny źródłowe problemów w projektach mają to do siebie, że często są tzw. przyczynami systemowymi. Czyli wynikają wprost z tego jak skonstruowany jest system, w tym wypadku system zarządzania w danej organizacji. Jeżeli przyczyna jest przyczyną systemową to aby permanentnie ją wyeliminować należy zmienić system. A to niestety często jest poza zasięgiem kompetencyjnym osób pracujących w projektach. Jedyne logiczne rozwiązanie w takiej sytuacji to rzeczony przypadek udokumentować oraz przedstawić odpowiednio wysokim menedżerom w firmie. A następnie mieć nadzieję, że zależy im na tym, aby ich system zarządzania działał sprawnie.

Dwa narzędzia, które mogą pomóc w znajdywaniu przyczyn źródłowych to na przykład A3 Problem Solving Method (bazująca na rozwiązaniach Toyoty) oraz Current Reality Tree (bazująca na narzędziach myślowych teorii ograniczeń).

Budowanie dla utrzymania

W nawiązaniu do tego, co kiedyś napisałem o wyzwaniach związanych z tworzeniem dokumentacji wdrożeniowej i utrzymaniowej oprogramowania napiszę jeszcze o jednym pokrewnym rozwiązaniu. W znanym tekście “The New New Product Development Game”* autorzy jako jeden z głównych powodów znaczącej poprawy efektywności producentów stosujących opisywane nowe metody tworzenia produktów podali korzystanie z zespołów wielofunkcyjnych. W szczególności w skład zespołów opracowujących nowe produkty wchodziły osoby z produkcji, czyli te, które później będą odpowiedzialne na wytworzenie w setkach tysięcy sztuk pomysłów inżynierów. Idea, która za tym stała była prosta i oczywista - często to, co jest optymalne z punktu widzenia inżyniera projektującego nowy produkt, wcale nie jest optymalne z punktu widzenia osoby, która ten produkt będzie musiała wykonać w tysiącach sztuk. Celem tworzenia takich zespołów miało być projektowanie takich nowych produktów, które nie tylko będą spełniały marzenia inżynierów (i marketingowców), ale jednocześnie będą proste w produkcji. Stąd zaangażowanie osób za nią odpowiedzialnych w rozwój produktu od samego początku projektu.

Przekładając to co zostało napisane na temat produkcji na rozwój oprogramowania wydaje się, że odpowiednikiem produkcji (wytwarzania) jest tutaj (wbrew pozorom) wdrożenie/utrzymanie. Sytuacja wygląda bowiem tak, że zespół rozwoju projektuje nowy system, który później trafia do zespołów wdrożeniowych i utrzymaniowych, które muszą zadbać o to, aby produkt działał bezbłędnie u każdego z klientów firmy. Podobnie jak produkcja w fabryce, tak wdrożeniowcy wytwarzają gotowe, działające u klient produkty firmy software’owej, oczywiście na bazie produktu stworzonego przez inżynierów odpowiedzialnych za rozwój.

Ciągnąc tą analogię dalej w niektórych projektach warte zainteresowania jest włączenie osób odpowiedzialnych za wdrożenia i utrzymanie (maintenance) do zespołów wytwarzających produkt, czyli zespołów rozwijających nowe oprogramowanie. Taka koncepcja wygląda na pierwszy rzut oka dość karkołomnie, ale im dłużej się nad tym zastanawiam tym większy ma sens. Wiadomo, że włączenie tych osób do zespołu spowoduje, że system będzie inaczej zaprojektowany. Zarówno te osoby, które muszą system zainstalować u klienta jak i te, które potem muszą odpowiadać na klienckie zapytania i/lub radzić sobie z błędami zgłaszanymi przez klienta będą miały mnóstwo pomysłów na usprawnia. Oczywiście jedną ze strategii jest je po prostu zbyć, ale... Ale tak naprawdę to one wystawiają swoją głowę klientowi na ścięcie i to od efektywności ich pracy zależy postrzeganie firmy przez organizację klienta. I nawet pomijając to jaki jest cel tej gry, to jak wiadomo każdemu z nas pensje tak naprawdę płaci... klient naszej firmy.

* Tekst znany jest głównie z tego, że w nim jako w pierwszym w literaturze pojawiło się określenie SCRUM na zespół pracujący zgodnie z metodami “lekkimi” - pojęcie agile jeszcze wtedy nie istniało. Sam artykuł ukazał się w Harvard Business Review, ale jak to kogoś interesuje to można go sobie wygooglać w formie PDFa. W tytule nie ma błędu.

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).

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.

User Acceptance Tests

Ostatnio prowadziłem szkolenie z agile, podczas którego padło bardzo logiczne pytanie: „a co z User Acceptance Tests (UAT – testy akceptacyjne)? kiedy je się wykonuje i jak zapewnia się, że podczas ich trwania ma się dostęp do grupy wykonawczej, aby ewentualnie naprawić zgłoszone przez użytkowników błędy?”. Pytanie jak najbardziej logiczne, dobre i odpowiedź powinna gdzieś być do znalezienia. Niestety po przeszukaniu dostępnej w mojej biblioteczce literatury okazało się, że odpowiedzi na to pytanie nie ma w posiadanej przeze mnie literaturze agile. Dlatego napiszę co ja na ten temat sądzę i jak ta sprawa była rozwiązywana w firmach, w których widziałem duże wdrożenia metod zwinnych. I przy okazji: jak ktoś gdzieś ma opis w literaturze takiego lub podobnego rozwiązania to bardzo proszę o podanie mi źródła.

„Problem” z User Acceptance Tests wynika z faktu, że według procesów agile grupa wykonawcza, pracująca nad projektem powinna cały czas w ramach iteracji dostarczać kolejne działające inkarnacje produktu. Tymczasem w tzw. świecie realnym, w którymś momencie przychodzi moment, kiedy taki działający produkt należy pokazać klientowi, który to klient powinien się zdecydować czy produkt spełnia jego wymagania czy nie. Ta właśnie procedura nazywa się testami akceptacyjnymi (UAT) i zwykle trwa jakiś czas- na pewno nie jeden czy nawet dwa dni. Co więcej z punktu widzenia firmy produkującej oprogramowanie jest to czas, który jest krytyczny. W trakcie testów akceptacyjnych musi być stały dostęp do zespołu, który wytworzył dany produkt aby bardzo szybko reagować na ewentualne błędy (pamiętajmy, że testuje to już klient – użytkownik ostateczny). Jak to więc zrobić, aby mieć dostęp do grupy wykonawczej w środowisku agile?

Ano bardzo prosto. Tylko trzeba się wznieść na „poziom wyżej”. Tak jak już kiedyś pisałem poziom iteracji i poziom wersji rządzi się trochę innymi prawami jeżeli chodzi o planowanie. Przypomnę tylko, że w ramach jednej wersji może być kilka iteracji. Wersja natomiast oznacza wersję produkcyjną, która zostaje zainstalowana u klienta ostatecznego w jego środowisku produkcyjnym. W ramach danej wersji następujące po sobie iteracje stanowią pewną całość i odbywają się jedna po drugiej, bez przerw. Nikt jednak nie powiedział, że tak samo musi być z wersjami. Często jest to w ten sposób rysowane w różnej literaturze (prace nad kolejną wersją rozpoczynają sie natychmiast po zakończeniu prac nad poprzednią), ale praktyka często weryfikuje takie podejście. W praktyce jest tak, że po zakończeniu pracy nad jedną wersja produkcyjną danego produktu następuje jej wypuszczenie i wdrożenie (deployment) w środowisku klienta. Natomiast prace nad kolejną wersją tego samego produktu zaczynają się zwykle z pewnym opóźnieniem (na przykład 2-4 tygodnie). W trakcie tego „opóźnienia” odbywają się dwie rzeczy. Po pierwsze klient przeprowadza UAT wersji, którą dostał. Jako, że w tym czasie nie ma prac rozwojowych nad wersją kolejną to w przypadku jakiejkolwiek awarii zespół wykonawczy jest w stanie bardzo szybko zareagować na ewentualne problemy. Jednak zespół wykonawczy nie przeznacza tego czasu tylko na bycie w gotowości. Oprócz tego, ten czas przeznaczany jest na przygotowanie do rozpoczęcia prac nad kolejną wersją. Zwykle oznacza to w praktyce przejrzenie z kierownikami produktu wszystkich funkcjonalności mających wejść w skład następnej wersji, nadanie im priorytetów oraz przeprowadzenie wstępnej estymacji. I nie jest to wbrew zasadom agile – wręcz przeciwnie, powtórzę po raz kolejny, że agile to nie chaos i kierownicy produktu powinni na początku prac nad wersją wiedzieć co chcą w jej ramach dostać. Zwłaszcza jeżeli chodzi o funkcjonalności o wysokich priorytetach, które wejdą do produkcji w pierwszych iteracjach pracy nad nową wersją.

Na koniec podsumowując w jednym zdaniu: praktyka wskazuje, że User Acceptance Tests w projektach agile przeprowadza się w „przerwie” pomiędzy pracą nad kolejnymi wersjami produktu.

Metoda Uwe K.

Jakiś czas temu pracowałem dla naszych sąsiadów zza Odry i Nysy Łużyckiej a moim szefem był niejaki Uwe K. Miał on bardzo ciekawą metodę zarządzania zadaniami. Otóż dzwonił codziennie o godzinie 16.15 do mnie, jako do swojego pracownika i przekazywał ustnie zadania do wykonania. Następnego dnia często dzwonił o godzinie 8.00 z pytaniem gdzie może obejrzeć rezultaty mojej pracy. Najwięcej zadań oczywiście było przekazywane w piątek o 16.15, tylko po to, aby oczekiwać, że będą zrealizowane do poniedziałku do 8.00. Bardzo ciekawa metoda zarządzania to była. Szczególnie w kontekście tego, że życie nie składa sie jedynie z pracy. Jak się zapewne domyślacie dość szybko zacząłem aktywnie działać w kierunku zwolnienia Uwe K. z funkcji mojego szefa...

Historia powyższa przypomniała mi się gdy rozmawiałem w zeszłym tygodniu z pewną osobą, której nie udało się wdrożenie zwinnych metod zarządzania w średniej wielkości polskiej firmie informatycznej. Teoretycznie firma była idealna do wdrożenia. Produkty cechujące się dużą niepewnością funkcjonalności, bardzo duża możliwość testowania niepełnego produktu przez klientów ostatecznych, projekty na tyle małe, że można je robić jednym zespołem, więc odpadają wszelkie typowe problemy ze skalowaniem metod zwinnych. Niestety wdrożenie zostało wyłożone. Co się stało? Zacznijmy od tego, że wdrożenie agile project management zostało umotywowany tym, że "firma zbyt wolno reaguje na potrzeby klienta". Celem było więc stworzenie systemu, który pozwoli szybko reagować na zgłaszaną przez klienta informację zwrotną o produktach firmy. O ile osoby zajmujące się programowaniem dość szybko zrozumiały o co chodzi w nowym systemie pracy, to zrozumienie metod zwinnych po stronie osób zarządzających produktem (product managerów) było cokolwiek powierzchowne. Doprowadzono do sytuacji, w której dano product managerom pełną dowolność zmian funkcjonalności produktu bez liczenia się z opinią kierowników projektów realizacyjnych. Bardzo szybko spowodowało to pojawienie się syndromu opisanego powyżej. Objawiało się to wpisywaniem przez menedżerów produktu na listę funkcjonalności niezdefiniowanych rzeczy podczas spotkań planujących iterację. Realizatorzy prosili o uszczegółowienie takich wymagań, co następowało zwykle na trzy dni przed końcem iteracji. Na innym poziomie było wrzucanie do ostatniej iteracji przed wypuszczeniem wersji zmian fundamentalnych, wymagających zmian w architekturze - oczywiście tłumaczone nagłą potrzebą klienta. A także inne kwiatki, których nie mogę opublikować. Jak się domyślacie oczekiwanie było, że na koniec każdej iteracji będzie dostępny działający produkt. A już wersja to koniecznie musiała być, bo przecież obiecana klientowi. Jakiekolwiek tłumaczenie od strony realizatorów, że taka praca jest nieoptymalna menedżerowie produktów kwitowali krótko: "no jak to, czy to znaczy, że nie jesteście wystarczająco agile?". Dość szybko ludzie z zespołów realizacyjnych zaczęli myśleć dokładnie to, co ja myślałem o moim szefie.

Nauka z tego taka, że zwinność zwinnością, ale i tak zawsze trzeba pamiętać, że istnieje gdzieś niepisana cienka linia, której przekroczenie spowoduje zabicie metody. Najpierw na poziomie elementarnego poziomu i trzymania się zasad. Chwilę potem na poziomie ludzkich relacji i chęci dalszej współpracy. Napiszę jeszcze raz to, co już tu wielokrotnie wprowadzałem: agile to wprowadzanie porządku w chaos. Agile to nie jest zarządzanie bez reguł.

I na koniec taka refleksja. Nie wiem dlaczego, ale zaczyna u mnie dominować przekonanie, że wdrożenia metod agile są najbardziej zagrożone nie od strony realizacji, ale od strony zarządzania produktem. Właśnie ze względu na błędne zrozumienie, że agile oznacza "wszystko nam wolno". A co ciekawe firmy praktycznie nigdy nie chcą aby im szkolić menedżerów produktów...

Jak upowszechnić ideę, czyli dlaczego zostanie tylko SCRUM

Witam po dłuższej przerwie wakacyjnej. W każdym razie żyję i teraz już postaram się wrócić do zwykłej częstotliwości pisania.

Na początek temat tylko z pozoru odległy od głównej tematyki tego bloga. W trakcie wakacji kilkukrotnie powróciło do mnie zagadnie czynienia nowej idei popularną. Chodzi o sytuację, kiedy mamy nową (innowacyjną) ideę i chcemy ją upowszechnić. Niektórzy puryści powiedzą w tym momencie, że to nic trudnego, po prostu trzeba tą ideę sprzedać używając „zwykłych” metod marketingu i sprzedaży, postępując podobnie jak z każdym innym produktem. Być może mają rację. A nawet mają ja na pewno. Ale ja się zacząłem zastanawiać nad czymś innym. Jaka powinna być konstrukcja systemu, w którym krąży rzeczona idea, aby tenże system był w stanie w sposób najbardziej skuteczny upowszechnić tą właśnie ideę wśród firm (uwaga to ważne: mówimy o upowszechnieniu wśród organizacji komercyjnych).

Czyli sytuacja wyjściowa jest następująca: mamy nową, dobrą ideę, czyli na przykład agile project management i chcemy, żeby koncepcja ta przedostała się do świata firm i była tam używana. Jaki system zbudować, aby to było możliwe?

Jeden z modeli takowego systemu, który służy upowszechnianiu idei został mi zasugerowany przez Marka Kowalczyka. Po drobnych zmianach system ten, nazwany przeze mnie „modelem guru”, wygląda mniej więcej tak:

W centrum tego modelu stoi „guru” – osoba, która jest niekwestionowanym autorytetem jeżeli chodzi o daną koncepcję, czy też ideę, najczęściej jej twórca. Osoba ta najczęściej przekazuje swoje idee poprzez książkę swojego autorstwa, która zawiera jedynie właściwą wykładnię tego, co jest treścią idei. Książka najczęściej nie jest jedna, tylko robi się z tego cykl, każda następna prezentująca kolejną odsłonę idei. Książka jest głównym nośnikiem marketingowym, pozwalając dotrzeć do masowego odbiorcy za bardzo sensowne pieniądze (dla odbiorcy). Te osoby, które po przeczytaniu książki zainteresuje idea są następnie zachęcane do odbywania spotkań z „guru” lub osobami przez niego wskazanymi, na których to spotkaniach można zgłębić kolejne tajniki wiedzy. Całą tą machinę aktywnie wspiera sieć społeczna zbudowana wokół idei. Sieć taka zwykle opiera się o jakąś formę portalu webowego lub sieć stowarzyszeń/klubów w których spotykają się osoby zainteresowane tą właśnie ideą. Sieć ta ma zwykle jakiś sposób na wyróżnienie swoich członków spośród innych ludzi. Takim sposobem są na przykład wszystkiego typu gadżety reprezentujące idee: teczki, koszulki, kubki, zakładki do książek, etc. Zwykle sprzedawane po cenach absurdalnie wysokich.

Model powyższy został w praktyce zaimplementowany i sprawdza się znakomicie w pewnych przypadkach. Przykładami „guru” i stojących za nimi idei rozpowszechnianych w takim modelu są między innymi: Stephen Covey (7 nawyków skutecznego działania), Robert Kiyosaki (Bogaty Ojciec), Anthony Robbins (The Power Within) czy w końcu David Allen (GTD). Wymienione przykłady dowodzą, że model ten działa i w oparciu o niego można skonstruować sprawnie działający mechanizm szerzenia idei i (przy okazji) zarabiania pieniędzy.

Wymieniony model ma jednak dość znaczącą wadę. Otóż nigdzie nie ma dowodów na to, że pozwala on w sposób efektywny sprzedawać idee do firm. Wszystkie wymienione koncepcje są nakierowane na sprzedaż dla jednostek a nie dla organizacji. Mimo, że może nawet wystąpić sytuacja kiedy to firma płaci za seminarium GTD czy dowolne inne to nadal cały czas ta idea jest sprzedawana poszczególnym osobom w ramach organizacji. Czy ktoś kiedyś słyszał, żeby firma działała według 7 nawyków, aby według GTD albo czegoś podobnego? Nie. Firmy działają według Lean, CMMI, SixSigma, ISO, PMI czy Prince2 . W tym momencie mnie tknęło. Następnym logicznym pytaniem jest bowiem: czy te wszystkie koncepcje też mają wspólny model wokół którego się obracają? Analiza wykazała: mają.

„Model standardu” jest drugim modelem upowszechniania idei, który sporządziłem próbując dokonać reverse engineeringu na koncepcjach odnoszących największe sukcesy w firmach. Takich, które zostały już wielokrotnie wdrożone i które są znane większości osób zaangażowanych w daną działkę przemysłu. „Model standardu” prezentuje się w sposób następujący:

Zgodnie z nazwą w centrum modelu jest standard. Koniecznie spisany, dostępny albo za darmo, albo (częściej) w postaci płatnego wydawnictwa. Standard ten jest oficjalnie opracowany i utrzymywany przez pewną organizację, która jest zwykle pomysłodawcą idei. Ta sama organizacja zajmuje się certyfikacją, która jest kolejnym elementem modelu. Organizacja, która wymyśliła ideę rości sobie prawo do oceniania i certyfikowania z zakresu propagowanej idei. Odbywa się to zwykle dwutorowo. Po pierwsze organizacja może przetestować i certyfikować poszczególne osoby/organizacje pod kąte tego jak dobrze znają one dany standard. W ten sposób powstają wszystkie dyplomy, certyfikaty, stopnie dojrzałości itp. Drugi zakres działania organizacji certyfikującej jest jeszcze ciekawszy: dotyczy certyfikacji organizacji, które mogą propagować standard dalej. Czy organizacja, która wymyśliła pierwotną ideę, daje swoistą licencję innym organizacjom na propagowanie tej właśnie idei. Zauważyłem zresztą, że bardzo rzadko ta organizacja, która wymyśliła ideę sama dostarcza np. wiedzę z jej zakresu. Ona wynajmuje do tego „niezależnych”, certyfikowanych dostawców. Cudzysłów jest dlatego, że ci dostawcy są w 100% zależni od organizacji certyfikującej, gdyż brak ich uznania, cofnięcie certyfikatu w większości wypadków skutkowałby natychmiastowym wypadnięciem z rynku. Na koniec jako element propagowania idei jest jeszcze coś takiego jak sieć kontrahentów. Chodzi tu o to, że organizacje certyfikujące poprzez swoich „niezależnych” dostawców często wymuszają na przedsiębiorstwach, że w momencie implementacji standardu będą „namawiać” swoich partnerów do przyjęcia tego samego standardu. „Właśnie wdrożyliśmy ISO i aby utrzymać wymaganą jakość oczekujemy, że za 6 miesięcy wszyscy nasi dostawcy też wdrożą ISO”. Działa rewelacyjnie, zwłaszcza jak pierwszym podmiotem, który tak mówi jest organizacja rządowa udzielająca zleceń (przypadek PMI, Prince2 czy CMMI).

Jaki jest powód tego, że „model standard” jest znacznie skuteczniejszy w sprzedawaniu idei do firm niż „model guru”? Według mnie klucz leży w modelu potrzeb Maslowa a konkretnie w drugiej kluczowej potrzebie każdego człowieka, czyli potrzebie bezpieczeństwa. W tym wypadku bezpieczeństwa zawodowego menedżera, który podejmuje decyzje o wdrożeniu danej idei. W przypadku „modelu guru” idea taka nie jest dla niego bezpieczna, gdyż opiera się o konkretnego, jednego człowieka. Czy jakikolwiek wysoki szczeblem menedżer pozwoli, żeby jego firma opierała się o idee jednej jednostki, jednego człowieka? Nie. Zupełnie inaczej natomiast wygląda sytuacja, kiedy mamy wdrożyć znany na rynku standard wspierany przez „niezależną” instytucję certyfikującą i „niezależnych” dostawców wiedzy. Zresztą tych dostawców jest wielu w odróżnieniu od „modelu guru”, gdzie zwykle dostawca jest jeden (firma założona przez twórcę idei).

I tak na koniec. Dlaczego piszę o tym na tym właśnie blogu? Otóż próbowałem przeanalizować sobie w jaki sposób próbuje się upowszechniać koncepcje agile project management. Wydaje mi się, że do tej pory wszystkie koncepcje agile były upowszechniane w sposób przypominający „model guru”. Dwa najbardziej jaskrawe przypadki to Alistair Cockburn z jego metodami Crystal oraz Ken Schwaber i SCRUM. Upowszechnianie idei w ten sposób jakoś szło. Ken Schwaber, Mike Cohn oraz Esther Derby, jako jedyni spośród „guru” agilowych, zdecydowali się jednak powołać Scrum Alliance. „Niezależną” organizację trzymającą pieczę nad standardem oraz certyfikującą „niezależnych” dostawców. Jeżeli moje rozważania są poprawne oznacza to, że prędzej czy później, ale raczej prędzej SCRUM upowszechni się jako jedyna słuszna metoda zwinnego zarządzania projektami.

Kiedy nie stosować metod zwinnych

Na Controlling Chaos pojawił się przydługi wywiad z Jerrym Manasem. Trwa półtorej godziny i gdzieś w środku pojawił się jeden wątek, który z oczywistych względów mnie zainteresował. Otóż rozważane było czy stosować podejście procesowe czy elastyczne (org. flexible). Zeszło na Agile Project Management i po chwili padły tam trzy kryteria/sytuacje, których zaistnienie wyklucza użycie metod zwinnych (agile) do zarządzania projektem:

1. Bezpieczeństwo
2. Wymaganie dokładności
3. Standardy prawne

Moje komentarze do tych sytuacji:

Ad.1. Chodzi o sytuację kiedy mamy projekt od którego będzie zależało życie ludzkie: oprogramowanie nawigacyjne samolotu, projekty wojskowe czy np. oprogramowanie tomografu komputerowego. Sytuacja wyjątkowa. Takimi projektami zarządza się zupełnie inaczej niż czymkolwiek innym.
Ad. 2. Ta sytuacja zachodzi wtedy, kiedy z góry wiemy, że są ściśle zdefiniowane parametry produktu końcowego, które chcemy uzyskać. W wywiadzie był podany przykład budownictwa: tam jest wszystko opisane jak co powinno wyglądać (w projekcie) i nie ma miejsce na zwinność. Po prostu trzeba zrobić. To jest bardzo logiczne. Jeżeli parametry wyrobu są podane wcześniej i wymagane jest dokładne spełnienie tychże kryteriów to logiczniejszym wyjściem jest zaplanowanie całości w celu uzyskania tychże kryteriów niż dochodzenie do nich w sposób iteracyjny. Z drugiej strony problem może się pojawić jak nie mamy pojęcia w jaki sposób osiągnąć wymagane parametry. Wtedy rozważyłbym, czy jednak metody zwinne nie byłyby przydatne.
Ad. 3. Projekt dotyczy wdrożenia standardów prawnych (org. regulatory standards). Sytuacja jest prosta: standard istnieje i mamy go wdrożyć. Standard ze swojej definicji jest dokładnie określony i nie ma tam miejsca na zwinność. I jedna tylko drobna uwaga. Chodzi tylko i wyłącznie o standardy prawne. Jeżeli projekt dotyczy standardów innego typu, np. wewnątrzfirmowych to już rozważenie metod zwinnych jest jak najbardziej wskazane. Jak to było wspomniane w wywiadzie należy pamiętać, że standardy wewnątrzfirmowe są narzędziem a nie celem samym w sobie. Ich interpretacja jest jak najbardziej uzasadniona jeżeli gwarantuje osiągnięcie celów, dla których zostały stworzone.

Moja opinia:
Zgadzam się w całości z tym, co usłyszałem w wywiadzie. Oznacza to, że dla bardzo znaczącej większości projektów użycie metod zwinnych nie jest wykluczone.

Zwinne zarządzanie zmianą w organizacji

Parę tygodni temu obyłem inspirującą rozmowę z pewnym ciekawym człowiekiem. Rozmawialiśmy na temat projektu wprowadzenia zmian organizacyjnych w bardzo dużej firmie. Zmiany miały być na wielką skalę. Na tyle wielką, że projekt musiał być realizowany w etapach. Na sam koniec rozmowy poprzez tematykę etapów zeszło na metody skutecznego zarządzania takim projektem. Jedną z rozważanych hipotez stało się użycie metod zwinnych do zarządzania tymże projektem.

Na pierwszy rzut oka pomysł wydaje się być totalnie pozbawiony sensu. Podstawowym założeniem wszystkich metod zwinnych (wszystkiego co nazywa się agile) jest iteracyjne dostarczanie działającego produktu. Działającego produktu. A my mówimy o projekcie wprowadzenia zmian organizacyjnych. Więc nie spełniamy podstawowego założenia. Drugim założeniem bardzo ważnym dla metod zwinnych jest koncentracja na przepływie wartości dodanej dla klienta, której emanacją są definicje funkcjonalności. Dlatego w projektach zwinnych nie definiuje się struktury podziału pracy tylko strukturę podziału funkcjonalności produktu końcowego. Bo to ukończona funkcjonalność niesie wartość dodaną a nie praca wykonana. Znowu więc na pierwszy rzut oka nijak ma się to do wprowadzania zmian organizacyjnych w firmach. A na drugi rzut oka?

Załóżmy przez chwilę, że organizację jako całość traktujemy jako produkt. Klientem na ten produkt jest właściciel organizacji lub jego przedstawiciel (zarząd). Tenże produkt przynosi właścicielowi korzyści biznesowe (zwykle wyrażone dość konkretnie w pieniądzach). Aby te korzyści przynosić tenże produkt posiada zestaw funkcjonalności, pewnych działań realizowanych przez organizację, które to działania, każde z nich, ma pewną wartość dla klienta. Jeżeli by tej wartości nie miało to klient (właściciel) już dawno wyrzuciłby to działanie ze swojego produktu (organizacji).

Przy takim spojrzeniu nie ma przeszkód, aby zarządzać projektem zmian organizacyjnych przy użyciu metod zwinnych. Klient (właściciel) definiuje jakie nowe funkcjonalności powinien mieć produkt (organizacja). Na przykład organizacja powinna mieć dedykowany dział wsparcia klienta albo organizacja powinna zarządzać projektami według metod zwinnych. To jest funkcjonalność, której brakuje a która z punktu widzenia właściciela przyniosłaby realny wzrost wartości całej organizacji. Teraz taką funkcjonalność można potraktować tak jak w projektach zwinnych: rozbić na mniejsze, nadać priorytety i wspólnie z klientem zastanowić się co wdrażamy najpierw. A następnie powołany zespół projektowy ds. zmian organizacyjnych zacząłby takie zmiany wdrażać. Produktem dostawy po każdej iteracji byłaby cała organizacja, która wykazywałaby działające kolejne elementy zdefiniowanej funkcjonalności.

Takie podejście do tematu zmian organizacyjnych po krótkim zastanowieniu wydaje się być obiecujące. Nie dość, że wydaje się być możliwe do wdrożenia to ma jeszcze dwie ważne cechy. Po pierwsze traktując organizację jako produkt z określonymi funkcjonalnościami spowodujemy, że definiując co trzeba zmienić będziemy się patrzeć na funkcjonalności właśnie a nie działania, które mamy przeprowadzić. Podobnie jak w przypadku zwinnych projektów przestajemy rozmawiać o działaniach a zaczynamy się skupiać na efektach, które te działania mają przynieść. Dzieje się tak, gdyż właściciel podobnie jak klient chce efektów a nie działań. Druga ważna sprawa wynika wprost z poprzedniej. Skupienie się na efektach oznacza, że będziemy musieli rozważać wartość biznesową każdego z nich. (każdej nowej funkcjonalności, którą będzie miała mieć organizacja). A analiza wartości biznesowej wprowadzanych zmian jest czymś, co w przypadku tradycyjnie zarządzanych projektów zmian organizacyjnych rzadko się zdarza. Potencjalnie uzyskujemy bardzo dużo.

Powyższe to czysta spekulacja, ale czy to zadziała? Zgodnie z duchem zasad projektów zwinnych teoretyczna negacja jest zabroniona. Trzeba by przeprowadzić eksperyment. Szukam chętnych. Adres email w informacji o mnie po prawej stronie.

Kontrakty na projekty zwinne

Ostatnie kilka tygodni spędziłem bardzo pracowicie spotykając się z wieloma bardzo interesującymi ludźmi. Stąd dłuższy brak postów na blogu. Z drugiej strony spotkania te były niezwykle interesujące i dostarczyły bardzo ciekawych spostrzeżeń.

Przykład, który mnie najbardziej zadziwił to omawiany już tu kiedyś (tutaj) „problem” kontraktów na projekty zwinne. Generalnie podczas każdej prezentacji, szkolenia czy nawet rozmowy na temat zwinnych metod zarządzania projektami prędzej czy później któryś z obecnych kierowników projektów podnosi „problem” kontraktów. Najczęściej przybiera to formę pytania „a co ja mam powiedzieć mojemu klientowi jak on zapyta ile będzie kosztował cały system”. Zwykle w takich przypadkach tłumaczę, że kontrakty na projekty realizowane zwinnie powinny być płacone inkrementalnie za wykonaną pracę, tak jak jest dostarczana funkcjonalność. Odpowiedź kierowników jest zwykle jedna: „moi klienci się na to nigdy nie zgodzą, oni chcą wiedzieć ile będzie kosztowała całość”. Dyskusja trwa długo.

Otóż tak się składa, że rozmawiałem ostatnio z kilkoma osobami, na co dzień kupującymi oprogramowanie, w tym oprogramowanie tworzone na zamówienie. Jako, że metody zwinne moim konikiem są, prędzej czy później schodziło na tą tematykę. Z wielkim zdziwieniem stwierdzałem, że idea zwinnego rozwoju oprogramowania, w tym płacenia inkrementalnego... bardzo im się (wszystkim) podobała. Jako, że byli to ludzie odpowiedzialni za pieniądze natychmiast (wszyscy) reagowali tak samo: to jest idealny sposób ograniczania ryzyka. Jeden z nich wprost od razu zapytał gdzie może znaleźć firmę, która zgodzi się na rozwój oprogramowania w taki właśnie sposób: płacenia za krótkie, ściśle zdefiniowane iteracje. Czy przeszkadza im to, że nie wiedzą ile będzie kosztowała całość? W zasadzie nie. Ewentualne kontrowersje natychmiast znikały gdy dowiadywali się, że będą mogli zmieniać definicję „całości” w dowolnym momencie, ze skutkiem z końcem kolejnej iteracji. To jest racjonalne, bo przecież zwykle oprogramowanie kupuje się nie po to, aby było „całością”, tylko po to, aby realizowało potrzeby biznesowe. Co ciekawe ludzie, którzy zlecają tworzenie oprogramowania rewelacyjnie to rozumieją. Dla nich rachunek jest prosty: kwota jaką zapłaciłem za oprogramowanie musi być (zdecydowanie) mniejsza niż korzyść wyrażona finansowo, którą ono (szybko) wygeneruje. Dlatego możliwość dynamicznego dostosowywania się do zmieniających się potrzeb i w ten sposób możliwość szybszego generowania większej korzyści jest bardzo, ale to bardzo dużą realną wartością. Więc ja się pytam o jakim „problemie” kontraktów na projekty zwinne mówią kierownicy projektów? Zadanie domowe dla nich: przy następnej rozmowie z klientem zapytajcie się czy nie zgodziliby się na kontrakt oparty o metody zwinne zarządzania projektami.

Na koniec jedna uwaga: klienci z którymi rozmawiałem są osobami wydającymi pieniądze, że które ponoszą pełną odpowiedzialność (w części są to ich własne pieniądze). Podkreślam to, bo w korporacjach, gdzie wydaje się pieniądze „budżetowe” sprawa może wyglądać zdecydowanie inaczej.

Metody zwinne w organizacji "stabilnej" cz. 4

Dzisiaj po raz ostatni napiszę o tym dlaczego stabilne organizacje przechodzą na zwinne zarządzanie projektami. Powód, który zostawiłem na koniec jest dość kontrowersyjny, choć jednocześnie jest dość często wymieniany przez managerów z firm, które wdrożyły zarządzanie zwinne projektami.

Powodem, dla którego przechodzi się na zarządzanie zwinne jest często chęć przestawienia organizacji z nastawienia czysto technicznego na nastawienie biznesowe. Tradycyjny paradygmat zarządzania przyłożony do organizacji produkujących bardzo zaawansowane technicznie produkty takie jak na przykład oprogramowanie powoduje bowiem, że wewnątrz organizacja zaczyna skupiać się na technice podczas gdy na zewnątrz powinna skupiać się na zaspokajaniu biznesowych potrzeb klienta. Inżynierowie pracujący w organizacjach zarządzanych tradycyjnie przez większość swojego czasu zastanawiają się jak rozwiązać problem techniczny a nie problem biznesowy klienta. Wbrew pozorom to nie to samo. W niektórych firmach powstają wręcz specjalne działy analityków, których jedynym zajęciem jest przekładanie wymagań biznesowych na wymagania techniczne. Założenia za tym stojące są takie, że inżynierowie nie mogą zrozumieć wymagań biznesowych a z drugiej strony, że klient nie jest w stanie pojąć techniki. O ile to drugie być może jest prawdziwe to zarządzanie zwinne projektami całkowicie odrzuca założenie pierwsze.

Całe proces zarządzania zwinnego został tak stworzony by na każdym etapie dbać o klienta. Inżynier pracujący nad projektem głównie rozwiązuje problemy klienta i spełnia jego wymagania. Każde działanie zespołu projektowego jest podporządkowane wypełnieniu wymagania funkcjonalnego klienta. Wymagania funkcjonalne zaś są reprezentacją wartości dodanej dla klienta, czyli tego, za co firma realizująca projekt dostaje pieniądze. Takie podejście pomaga inżynierom skupić się na rozwiązywaniu realnych problemów klientów a nie problemów technicznych, które często są ciekawe i interesujące ale w żadnym razie nie przyczyniają się do znacznej poprawy funkcjonalności produktu.

Kolejną cechą pomagającą zespołowi projektowemu nastawić się na rozwiązywanie potrzeb klienta jest sposób zapisywania wymagań i idący za tym stały kontakt z klientem. W projektach zwinnych zakłada się, że wymagania pierwotnie spisywane są na dość dużym poziomie ogólności. Następnie są one uszczegółowiane podczas bieżących kontaktów z przedstawicielami klienta. Jak już kiedyś wspominałem rozwiązuje to problem kodowania i dekodowania informacji – osoby implementujące wymagania na bieżąco i bezpośrednio od klienta dostają informację o tym jak będzie wykorzystywana zlecona funkcjonalność. Otrzymywanie tych informacji bezpośrednio od klienta z pominięciem zespołu analityków oznacza lepszy kontakt z rzeczywistym światem klienta i zdecydowanie lepszą komunikację. Doświadczenie projektów prowadzonych metodami zwinnymi wskazuje, że ilość niepoprawnie (z punktu widzenia klienta) działających funkcji produktu jest nieistotnie mała. Oczywiście wszystko to pod warunkiem, że klient zgodzi się poświęcić swój czas na intensywną komunikację z zespołem projektowym – zwykle nie ma z tym jednak problemu, gdyż w zamian uzyskuje zdecydowaną korzyść w postaci lepiej przemyślanego produktu.

Dużą rolę w skupieniu na kliencie odgrywają przeprowadzane po każdej iteracji prezentacje działającego produktu. Podczas tych prezentacji klient może i powinien sam używać produktu wytworzonego do tej pory w projekcie. Najłatwiej jest to zrobić w przypadku oprogramowania komputerowego, gdzie po prostu klient dostaje do ręki klawiaturę i myszkę. Może w pełni korzystać ze wszystkich funkcji, które miały być wyprodukowane we właśnie zakończonej iteracji. NA tym samym spotkaniu obecni są także członkowie zespołu projektowego, którzy na żywo widzą, w jaki sposób klient używa ich produktu. Takie spotkania bardo pomagają ustawić właściwą perspektywę biznesową wśród zespołu. Szczególnie, że odbywają się relatywnie często. Zdarzało się wielokrotnie, że zespół widząc jak ich klient używa produktu proponował rewolucyjne zmiany w produkcie wielokrotnie upraszczające sposób użycia i w efekcie pozwalające klientowi pracować dużo bardziej efektywnie.

Na koniec mała uwaga: w żaden sposób nie chcę tutaj dowieść, że tradycyjnie zarządzane projekty nie są nastawione pro-kliencko. Twierdzę jedynie, że metody zwinne wydatnie pomagają skupić się na rozwiązywaniu faktycznych problemów klienta, komunikacji z klientem oraz na sposobie, w jaki faktycznie będzie wykorzystywany produkt końcowy.

Przejrzystość – przykład

W nawiązaniu do posta o przejrzystości.

Znany mi jest przypadek projektu, w którym kierownik wyższego szczebla miał zwyczaj idąc po kawę wchodzić do pokoju projektowego, patrzyć się na ścianę na której były te wszystkie informacje po czym bez słowa wychodzić z pokoju. Takie „nawiedzenia” zdarzały się mniej więcej co dwa dni. Co z tego? Otóż jednocześnie ten sam kierownik (który był jednocześnie sponsorem – płacił za projekt) nigdy nie pytał kierownika projektu o status. Nauczył się sam go odczytywać i te dwie minuty raz na dwa dni mu starczały. Z kierownikiem projektu spotykali się tylko podczas demonstracji na koniec iteracji. Obaj: kierownik projektu i sponsor byli z tego bardzo zadowoleni. Pierwszy miał święty spokój a drugi czuł się najlepiej poinformowanym sponsorem w firmie. Wniosek: radiatory informacji się sprawdzają.

Wdrażanie metod zwinnych

Metody zwinne jak wielokrotnie wskazywałem na tym blogu i w każdych innych źródłach są niezwykle proste. Pełen proces zarządzania projektem zwinnym przy odrobinie szczęścia można zapisać na kilku kartkach A4. To prowadzi do przekonania, że wdrożenie metod zwinnych w firmie jest równie proste. Ostrzegam. Wcale tak nie jest.

Główny problem polega na tym, że aby poprawnie zarządzać projektami nie zmienić i wystarczy wdrożyć samych procesów zarządczych. W większości wypadków natomiast zmiana sposobu realizacji projektów polega mniej więcej na tym, że pewnego pięknego dnia szef daje pracownikom książkę lub zbiór instrukcji i mówi „od dziś tak będziemy pracować”. Niestety tak się nie da. Być może w ten sposób można zmienić metodę zarządzania projektami z PMI na Prince2 lub odwrotnie. Natomiast jest to zdecydowanie za mało, aby przestawić firmę na zarządzanie zwinne.

Wdrożenie zarządzania zwinnego musi być skupione nie na zmianie samych procesów, ale na zmianie przynajmniej trzech elementów w firmie:

1. Procesu – tak, to jest ważne, aby wszyscy zainteresowani wiedzieli, według jakiego procesu pracują i co jest od nich wymagane. Ten element jest najprostszy – jest to czysta wiedza, którą trzeba sobie po prostu przyswoić. Są do tego książki, są szkolenia, nie ma problemu.
2. Umiejętności ludzi – zarządzanie zwinne niesie za sobą konieczność używania zupełnie innego zestawu umiejętności, zwłaszcza w obszarze międzyludzkim, niż tradycyjne zarządzanie projektami. Ze względu na bardzo duże znaczenie komunikacji międzyludzkiej i odstąpienie od dokumentowania najmniejszych szczegółów uzyskuje się z jednej strony dramatyczny wzrost wydajności, z drugiej zaś duże pole do psucia stosunków między ludźmi. Tylko osoby posiadające odpowiednie umiejętności będą mogły z sukcesem prowadzić projekty zwinne. Nabycie tych umiejętności nie jest już takie proste jak zmiana procesu. Umiejętności z definicji oznaczają, że coś się umie zrobić – to już jest praktyka a nie teoria.
3. Kultura pracy (tzw. kultura organizacyjna) – rzecz ostania, ale bardzo ważna, aby zarządzanie zwinne pokazało wszystkie swoje zalety i zapewniło oczekiwany wzrost efektywności. Kultura pracy, czyli zestaw postaw prezentowanych przez wszystkich pracowników organizacji. Tutaj musi nastąpić wielka zmiana. Choćby dlatego, aby "szefostwo" nie wymagało na początku dokładnego planu całego przedsięwzięcia a z drugiej strony sprzedaż nie próbowała usilnie sprzedać klientowi efektu końcowego drugiej iteracji (w momencie kiedy wersja produktu miała pojawić się po iteracji ósmej). Kulturę pracy zmienić najtrudniej. Nie można tego zrobić oddolnie, zawsze musi to przyjść od strony wyższej kadry kierowniczej. Podkreślam to, gdyż jest to jasna wskazówka, że bez zaangażowania i przekonania wyższego kierownictwa wdrożenie metod zwinnych nigdy nie zakończy się pełnym sukcesem a metody te nie pokażą swojego pełnego potencjału.

Podsumowując wypada mi tylko powtórzyć, że jeżeli ktoś twierdzi, że można „wdrożyć agile” poprzez danie do przeczytania książki programistom i kierownikom projektów to się bardzo grubo myli. Przeprowadzenie wdrożenia metod zwinnych tylko na jednej płaszczyźnie zamiast na wszystkich w pesymistycznym przypadku może spowodować w organizacji więcej szkody niż pożytku.

Metody zwinne w organizacji "stabilnej" cz. 1

Ostatnimi czasy metody zwinne zarządzania projektami stają się coraz bardziej popularne. Metody te najlepiej sprawdzają się w środowiskach bardzo dynamicznych, w projektach, w których występuje duża doza niepewności. Okazuje się jednak, że duża część firm działających w bardziej stabilnych środowiskach również wdraża zarządzanie zwinne. Jakie są powody tego? Na pewno swoista „moda”, ale czy tylko? Ze względu gwałtownie narastający charakter zjawiska napiszę w kilku postach, jakie mogą być powody, dla których organizacje pracujące w środowisku stabilnym wdrażają zwinne zarządzanie projektami.

Uzasadnienia nie będą w żadnej logicznej kolejności, dlatego na pierwszy ogień pójdzie powód bardzo ważny dla większości osób zaangażowanych we wdrożenia zwinnego zarządzania projektami, choć z drugiej strony być może mniej interesujący dla kierownictwa. Otóż skutkiem wprowadzenia zwinnych metod zarządzania projektami, jest to, że zespołom realizującym projekty pracuje się... przyjemniej.

Przyjemność ta wynika z kilku czynników. O jednym pisałem już kiedyś, przy okazji omawiania tematyki zmian w projekcie – w projektach zarządzanych metodami zwinnymi zespół pracuje nad zestawem funkcjonalności, które nie mają prawa się zmienić (w danej iteracji). To powoduje duży spokój psychiczny zespołu, jako że jasno określone są reguły, na podstawie których dokonywane są zmiany i nikt nie zaskakuje członków zespołu. Wbrew pozorom stabilność (choćby w ramach jednej iteracji) jest jednym z podstawowych wymogów zachowania przyjemności z wykonywania pracy.

Kolejnym bardzo dobrze wpływającym na pracę czynnikiem jest fakt, że ze swojej natury zespoły pracujące zgodnie z metodami zwinnymi są zespołami relatywnie małymi położonymi w jednej fizycznej lokacji. Bardzo częsta komunikacja między członkami zespołu powoduje dobrą atmosferę pracy choćby dlatego, że wszelkie niezrozumienia są błyskawicznie usuwane a problemy są komunikowane przynajmniej raz dziennie podczas spotkań. Poza tym w takim zespole ze względu na charakter spotkań (zarówno codziennych jak i podsumowujących iterację) każda z osób czuje się dowartościowana, bo jej zdanie jest brane pod uwagę.

Uwaga. Powyższe jest prawdą tylko o ile osoby zajmujące się koordynacją zespołów posiadają odpowiednie umiejętności komunikacyjne!!!

Praca w projektach zwinnych jest przyjemna również dlatego, że każdy z członków zespołu ma poczucie odpowiedzialności i szybką nagrodę w postaci osiągnięcia sukcesu – działający produkt na koniec iteracji. Mała wielkość zespołu w połączeniu z krótkimi iteracjami oraz tym, że na koniec każdej iteracji trzeba dostarczyć produkt wzbogacony o konkretną wartość dodaną dla klienta powoduje, że każdy z członków zespołu jest zaangażowany w dostarczanie tej wartości. Krótki czas realizacji sprawia, że każdy widzie efekty swojej pracy podczas prezentacji dla klienta. Człowiek natomiast skonstruowany jest tak, że lubi jak mu coś wychodzi.

Jak to się ma do zarządzania firmą jako całością? Ma się, gdyż jeżeli pracownikom pracuje się przyjemniej to pomaga im to pracować efektywnie. Poza tym pracownicy, którzy mają przyjemną atmosferę w pracy zwykle rzadziej myślą o zmianie pracodawcy. Jeżeli idzie to w parze z efektywnością (a idzie) to oczywistym jest, że lepiej mieć pracownika zadowolonego niż zdegustowanego.