W dniach 6-7 grudnia 2012 odbyła się II Konferencja „Agile w Biznesie”, organizowana przez Computerworld. Szereg prezentacji wyszło poza tradycyjne zastosowania metod zwinnych (ang. agile) w wytwarzaniu oprogramowania na poziomie zespołu SCRUM-owego w małych firmach, więc było bardzo interesująco.

Prezentacje te dotyczyły takich zagadnień, jak nowe podejścia do zarządzania firmą (a nie tylko wytwarzania oprogramowania) z wykorzystaniem filozofii Agile, budowania zwinnej organizacji, czy też łączenia podejścia Agile z podejściem tradycyjnym.

O prezentacjach mówiących o zwinnych organizacjach i zarządzaniu firmą wg podejścia Agile opowiem w kolejnym tekście bloga. Najpierw jednak chciałbym przedstawić – zwłaszcza tym, którzy nie mieli okazji uczestniczyć w konferencji – naszą prezentację dotyczącą łączenia metod zwinnych z tradycyjnymi w zarządzaniu projektami i portfelem projektów. „Naszą” czyli Arkadiusza Biernata z Banku Handlowego oraz Jerzego Stawickiego (JS PROJECT), autora tego bloga.

Punktem startowym prezentacji  była nasza teza (i przekonanie), że metody agilowe nie wyprą całkowicie tradycyjnych metod zarządzania projektami. Uważamy, że konieczne jest współistnienie i harmonia tych metod, czy to w ramach jednego złożonego projektu, czy w ramach organizacji. Tak jak napisane jest w chińskiej księdze „Tao Te Ching”: „siły, przedmioty, myśli są niekompletne i wręcz bezsensowne, gdy nie są powiązane z własnym przeciwieństwem”. A to współistnienie musi wynikać z rzeczywistych problemów i potrzeb zarządzania w świecie projektów: z  tego, że projekty trwają za długo i tego, że w czasach nam współczesnych oraz w przyszłości kluczowe znaczenie ma i mieć będzie – jak pisze Steve Denning – kwestia „zachwycenie klienta”.

I chociaż niektóre z przedstawianych przez nas przykładów obejmowały wytwarzanie oprogramowania, to jednak były one elementem większej całości: dostarczania projektów (ang. project delivery). To dostarczanie produktów wg nas to umiejętności zarządzania projektami i programami w celu wdrożenia zmiany w różnych aspektach takich jak: oprogramowanie (aplikacja/funkcjonalność), proces operacyjny, infrastruktura oraz produkt biznesowy. Wykorzystaliśmy i rozwinęliśmy ideę modeli cyklu życia Charlesa G.Cobba (zob. rysunek), którego podejście obejmuje całe spektrum modeli cyklu życia projektu: od tradycyjnego, sterowanego planem (typowy „waterfall”), poprzez przyrostowy, iteracyjny sterowany planem, iteracyjno-adaptacyjny, aż do modelu adaptacyjnego (czysty agile). Rozwinęliśmy, gdyż naszym zdaniem coraz częściej stosowane będą (a tak naprawdę  już są) podejścia łączące w jednym projekcie lub organizacji elementy i podejścia tradycyjnego (plan i etapy projektu plus „tradycyjny” kierownik projektu),  agilowego (iteracje, cross-funkcjonalne, samodzielne zespoły, Scrum Master i Product Owner), jak i innych podejść, jak Lean, czy Theory of Constraints (zarządzanie Ograniczeniami i wywodząca się z niego metoda łańcucha krytycznego).

Główną częścią naszej prezentacji były praktyczne przykłady takiego łączenia różnych podejść. Oto one:

1. Water-Scrum-Fall: połączenie tradycyjnego planu projektu i analizy wymagań (element „Water”) z agilowym wytwarzaniem oprogramowania przez zespół SCRUM-owy i tradycyjnego przekazania do operacji (element „Fall”).  
Na razie to połączenie skutkuje szeregiem problemów; dla ich rozwiązania konieczne jest i „rozmycie” granic między tymi fazami i większa współpraca IT i biznesu, a także ograniczenie analizy wymagań do tych naprawdę najważniejszych. Nawet w tym udoskonalonym podejściu pozostanie klient oczekujący w miarę precyzyjnej daty końcowej, a więc i całościowy plan przedsięwzięcia, jak i pion operacji powiązany wspólnymi celami w projekcie z IT, choć oba działające wg odrębnych zasad. Ostatecznie więc powstanie coś w rodzaju „rozmytego” podejścia Water-Scrum-Fall, czyli Fuzzy-Water-Scrum-Fall.

2. Zwinne zarządzanie projektem tradycyjnym, jako odpowiedź na potrzebę skrócenia czasu trwania projektów.
Polega na zastosowaniu hybrydy najlepszych praktyk, pochodzących i z łańcucha krytycznego (eliminacja wielozadaniowości, planowanie iteracyjne na bazie sztafety z buforem na końcu określającym kondycję projektu), z metod agile (wielofunkcyjny, samoorganizujący się zespół), uzupełnionych o najlepsze praktyki tradycyjnego zarządzania, takie, jak: wspólna ocena zespołu projektowego, czy stworzenia miejsca na popełnianie błędów. Taka hybryda prowadzi w rezultacie do dynamicznego zarządzania adaptacyjnego za pomocą prób i błędów.

3. Lean + TOC + SCRUM + CCPM dla sytuacji, gdy kierownictwo dąży do usprawnienia firmy i wyeliminowania różnych form marnotrawstwa, przy utrzymaniu zwinnych metod (SCRUM) na poziomie zespołów programistycznych.
Wtedy z jednej strony stosowane są praktyki Lean do eliminacji strat, przestojów i ograniczenia robót w toku i procedura 5-ciu kroków doskonalenia z TOC do identyfikacji i eliminacji wąskich gardeł, ograniczających przepustowość firmy. A dodatkowo – dla uzyskania odpowiedzi o termin dostarczenia produktu - agilowe iteracje uzupełniane są buforem (pochodzącym z metody łańcucha krytycznego - CCPM) stanowiącym dodatkową iterację i gwarantującym termin dostarczenia produktu.

4. Bardziej zwinne zarządzanie portfelem projektów.
W tym podejściu Komitet Priorytetyzacyjny zastępowany jest przez multifunkcjonalny, samoorganizujący się zespół ekspertów (z subtelną kontrolą); menedżer portfela projektów przez lidera portfela, a bramki (ang. gates) tradycyjne przez bramki iteracyjne.

5. Agilowe wdrożenie rozwiązania klasy ERP, proponowane przez SAP w ramach metodyki ASAP 7 i ASAP 8.
Taka metoda wdrożenia obejmuje m.in. Lean Business Blueprint (czyli „odchudzoną” koncepcją biznesową), priorytety wymagań biznesowych w backlogu, sprinty podczas fazy realizacji i przyrostowe (poprzez kolejne releas-y) uruchamianie funkcjonalności. A jeszcze rok temu powiedziałbym, że takie agilowe wdrożenie SAP-a to szaleństwo!

Jaka była nasza recepta dla uczestników konferencji w agilowej retrospektywie naszej prezentacji? Bardzo prosta: spróbujcie zastosować konwergencje różnych metod zarządzania projektami w swoim świecie biznesowym: „Try stuff, see what works and what doesn't , (…) and iterate”.