Wczoraj wieczorem byłem na wydarzeniu PMI Poznań – PMI@Night. Gościem specjalnym był znajomy trener z USA: Joseph Flahiff. Więcej informacji o nim znajdziecie na jego stronie: http://whitewaterprojects.com/
Prelekcja Josepha była na temat powodów porażek implementacji Agile w zarządzaniu projektami. Znów przyszedł nam z pomocą Pareto i jego podział 80/20. Kiedy chcemy wdrożyć Agile w zarządzaniu projektami to 20% trudności jest po stronie narzędzi, technik – tych uczymy się bardzo szybko. Jednak 80% to kultura w organizacji, która jest prawdziwym wyzwaniem. Kultury tak szybko nie zmienimy, a do samej zmiany potrzebujemy wsparcia na wszystkich poziomach organizacji. O tym jaka kultura jest wymagana, jakie wartości i zasady w organizacji napiszę następnym razem.
Być może mało odkrywcze, ale mi dało do myślenia jedno zdanie, które padło podczas prelekcji. Agile jest zastosowaniem Lean w rozwoju oprogramowania. Całkowicie się z tym zgadzam. W moim otoczeniu jest bardzo dużo projektów, które polegają na rozwoju oprogramowania. Tam Agile sprawdza się w 100%. Został do tego stworzony, został stworzony przez programistów i przez nich jest stosowany. Tak powinno być.
Będąc coraz większym zwolennikiem Agile próbuje go stosować w każdym projekcie jaki prowadzę i tu zaczynają się trudności. Bo te projekty mają inny kontekst niż rozwój oprogramowania. Przywołam tu znane powiedzenie z zarządzania projektami „Context is a King”. Projekty przeze mnie prowadzone polegają na wdrożeniach systemów klasy ERP/CRM. Są to też projekty które wprowadzają zmianę organizacyjną. Są to projekty, w których udział bierze kilku dostawców. Przy tego typu projektach wyzwania są inne niż przy rozwoju oprogramowania.
Pytanie jakie się nasuwa to czy powinniśmy stosować Agile w tego typu projektach? Skoro Agile jest stworzony dla rozwoju oprogramowania, dla innego kontekstu to pewnie powinniśmy szukać innych sposobów.
Zatem wróćmy do źródeł. Skoro Agile jest zastosowaniem Lean w rozwoju oprogramowania to działając przy innych projektach powinniśmy stosować Lean w kontekście tych projektów. Mary Poppendieck przytacza takie wartości Lean dla projektów rozwoju oprogramowania:
- Eliminacja strat (ang. Eliminate Waste)
- Tworzenie jakości i spójności (ang. Build Quality In)
- Wzmocnienie pozyskiwania wiedzy (ang. Create Knowledge)
- Podejmowanie decyzji najpóźniej, jak to możliwe (ang. Defer Commitment)
- Wdrażanie najwcześniej, jak to możliwe (ang. Deliver Fast)
- Respektowanie zespołu (ang. Respect People)
- Spojrzenie na całość (ang. Optimize the Whole)
Mimo, że są one napisane z myślą o rozwoju oprogramowania, cały czas są prawdziwe dla wszystkich projektów technicznych. Trzymając się tych zasad, należy spojrzeć na kontekst projektu i dostosować proces projektowy do tego kontekstu. Tak często słyszę, że nie da się wybudować domu korzystając z podejścia Agile. A korzystając z Lean da się? Skoro Toyota jest w stanie budować samochody od kilkudziesięciu lat korzystając z Lean, to i domy można budować. Można też inaczej podejść do projektów wdrożeniowych. Zastosować Lean w kontekście tych projektów. Idąc dalej, jeżeli nas interesuje nowa lepsza organizacja to zasady Lean powinny być zastosowane w całej organizacji. To jest ta zmiana paradygmatu, o której piszę Steve Denning.