24. lutego 2013 · 2 komentarze · Categories: Better Way, Lean, Tesis · Tags: , ,

Miałem przyjemność brać udział w spotkaniu ITSMF w Poznaniu. Przyjemność spotęgowana tym, że spotkanie odbyło się w siedzibie Grupy Allegro oraz prelegenci to moi koledzy z GA. Nie będę pisał całej relacji. To zrobią inni.

Podczas prelekcji Przemka Wysoty na temat zarządzania zmianą padło pytanie czy istnieje w GA taka forma jak CAB (Change Advisory Board). W odpowiedzi usłyszeliśmy, że tak naprawdę to nie istnieje i wynika to ze zwinności (agile) organizacji. Otwartość na zmiany, szybkość, dostosowanie się do potrzeb firmy. Od słowa do słowa doszło do szybkiego skrótu myślowego, że agile tzn. brak kontroli. To mi przypomniało historie naszego biura zarządzania portfelem projektów, które też już nie istnieje. Czy to znaczy, że nie zarządzamy portfelem lub nie mamy change managementu w IT? Nic bardziej mylnego.

Na prawie wszystkich konferencjach poświęconych nowoczesnej organizacji, zwinności padają słowa: nie potrzebujemy managerów, ale potrzebujemy management. Nie potrzebujemy testerów, ale potrzebujemy testowanie itd.

W wielu przypadkach to sobie ciężko wyobrazić, jednak jest sens w tych słowach. Jest to bardzo ciężkie do osiągnięcia dla tradycyjnych firm. Transformacja jest bardzo ciężka, o ile w ogóle możliwa. Pocieszające jest to, że istnieją na świecie nowe organizacje, które opierają się na nowym DNA – przykładem jest Valve.

Brak CAB’u lub biura zarządzania portfelem jest łatwiejszym zastosowaniem powyższego. Nie potrzebujemy CAB’u, ale potrzebujemy kontroli zmian. Nie potrzebujemy biura zarządzania portfelem, ale potrzebujemy zarządzania portfelem.

To jest łatwiej sobie wyobrazić pod warunkiem zmian systemowych i bardziej wywodzi się z lean niż agile.

W krótkim zdaniu można powiedzieć, że biuro zarządzania portfelem jest odpowiedzialne za priorytetyzowanie projektów zgodnie z kierunkami strategicznymi firmy i za ich wprowadzenie do realizacji.  Jeszcze krócej, jest odpowiedzialne za to, aby zlecać do realizacji projekty, które są najbardziej wartościowe (najważniejsze) dla organizacji. Tu powstaje pytanie, czy rzeczywiście potrzebujemy do tego osobnego biura zarządzania portfelem? Przecież to jest odpowiedzialność każdej osoby w firmie, aby robić to co najważniejsze dla firmy, a już na pewno odpowiedzialność managerów. Zatem oddajmy managerom tą odpowiedzialność. Niech będzie to dokładnie nazwana odpowiedzialność za decyzje o tym co firma realizuje. Co jest najważniejsze, a co jest mniej ważne. Rozumiem, że nie każdy to potrafi. Nie jest to jednak powód, aby nie podejmować decyzji i się uczyć. Błędy są rzeczą ludzką i dzięki nim możemy wiele się nauczyć. Jak ktoś od początku nie jest do tego gotowy to dajmy czas na naukę i zdobycie kompetencji. Nie jest tutaj rozwiązaniem zatrudnianie kogoś innego, kto zrobi za nas robotę i podejmie decyzje.  Organizacje z nowym DNA idą dalej, oddają tę odpowiedzialność do pracowników. Każda osoba w firmie, znając strategię, znając swoich klientów i to co dla nich najważniejsze powinna umieć zweryfikować, czy to co robi ma rzeczywiście sens. Dokładając do tego system szybkiej informacji zwrotnej i weryfikacji tego co robimy możemy pozwolić sobie na eksperymenty bez obawy o błędy na dużą skalę. Właśnie ta szybka informacja zwrotna jest najlepszą kontrolą dla naszego działania. Dodatkowo uczymy siebie odpowiedzialności i przedsiębiorczości.

To jak to jest z tym CAB’em? Na spotkaniu padło pytanie to kto na końcu jest odpowiedzialny za zmiany. I oczy padły na mojego serdecznego kolegę, który zarządza działem. Tak, to jest właściwa osoba na właściwym miejscu. Jest odpowiedzialny za zmiany wykonywane przez jego zespół. Nie ma tutaj dodatkowych osób, które podejmą decyzję za niego. On wie, kto jest jego klientem, jakie ma potrzeby i zgodnie z tym podejmuje decyzje. Można iść dalej, jak zespół dobrze będzie rozumiał klienta, swoją odpowiedzialność to sam będzie umiał podejmować odpowiednie decyzje. Trzeba ku temu stworzyć odpowiednie warunki i kulturę. Kulturę uczenia się, wyciągania wniosków, poprawiania całości.

Wyobraźmy sobie, gdy dany pracownik bierze na siebie zadanie i odpowiedzialność za te zadanie. Popełnia błąd i zostaje ukarany. Wtedy to będzie jego ostatni raz, gdy tak postąpił. Następnym razem będzie szukał decyzji i odpowiedzialności u kogoś innego. Będzie się bardzo długo przygotowywał do zadania, przygotowywał różne scenariusze na wypadek, gdy się nie uda. Na wypadek, kiedy będzie musiał się tłumaczyć z błędu. Jest to dość naturalne działanie, lecz prowadzi do straty (waste) w postaci dodatkowego czasu oraz zaangażowania dodatkowych osób. Wtedy, rzeczywiście musi być taki CAB, który weźmie na siebie pracę za kogoś.

Zmiana kulturowa zakłada, że ludzie znają się na swojej pracy i chcą ją zrobić porządnie. Czasem popełniają błędy, ale to ich uczy. Tylko wtedy stają się coraz lepsi.

Kultura to jeden składnik, drugim jest działanie i myślenie systemowe. Jeden składnik umożliwia drugi i odwrotnie. Co w przypadku gdy, wierzymy w dobrą pracę ludzi, jednak oni nie mają narzędzi i możliwości do jej wykonywania. Co w przypadku, gdy system nie pozwala wykonać danej zmiany w sposób bezpieczny? Wtedy to znów prowadzi do przygotowywania dodatkowych planów, scenariuszy, angażowania dodatkowych osób. Nie możemy zmieniać kultury, gdy system na to nie pozwala. Trzeba zmienić system, na taki, który np. pozwoli w prosty sposób przeprowadzić zmianę na bezpiecznym wycinku całości lub na środowisku testowym lub, lub, lub. Potrzebujemy system, który da szybką informację zwrotną, bez dużych konsekwencji błędnego działania i pozwoli na szybką reakcję i działanie naprawcze w przypadku pojawienia się problemów. Standardy, automatyzacja, oprogramowanie wspomagające zarządzanie przychodzą nam z pomocą. A błędy? Błędy i pomyłki się zdarzają i będą się zdarzać wszędzie tam, gdzie działamy na krawędzi naszych możliwości. Tam gdzie wyciskamy z siebie jak najwięcej możemy.

To tak jak działanie Andon Cord w fabrykach Toyoty. Jest to prosty mechanizm (linka), która służy do zatrzymania produkcji w momencie kiedy pracownik widzi problem lub możliwość usprawnienia. Przeciętnie w ciągu dnia następuje około 1000 zatrzymań linii produkcyjnej w celu wprowadzenia małych poprawek. Oczywiście system pozwala na zamknięcie produkcji w małym obszarze, więc nie jest to destruktywne dla całego procesu produkcyjnego. Każdy pracownik ma prawo i obowiązek zatrzymania linii, kiedy uzna to za stosowne. Pewnego razu liczba Andon Cord spadła do 700 dziennie. Czy był to powód do radości? Dla zarządu był to sygnał ostrzegawczy. Z jednej strony  mogło to znaczyć, że z jakiegoś powodu pracownicy boją się zatrzymywać linie produkcyjną i w tym przypadku zarząd jeszcze raz podkreślił, żeby nie bać się usprawniać i poprawiać. To jest wartość na podstawie której budujemy doskonałość. Z drugiej strony może to oznaczać, że nie działamy na maksymalnych możliwościach, że odpuszczamy i wtedy jest mniej błędów. Nie mamy czego usprawniać.

W tym przypadku i system i kultura pozwalają na to, aby stawać się coraz lepszym, aby dążyć do doskonałości. Uczymy się brać odpowiedzialność i próbować pracować na krawędzi naszych możliwości, tak aby ciągle się poprawiać.

Na spotkaniu padło pytanie czy mamy błędy. Odpowiedź była tak mamy i pewnie zbyt dużo. Jednak całość działa. Robimy błędy i uczymy się usprawniać system.

Wartości Lean mówią o eliminacji strat (Eliminate Waste) i o spojrzeniu na całość (Optimize the Whole).  Te podstawowe wartości prowadzą do takiego działania, kiedy nie ma formalnego biura zarządzania portfelem i CAB’u. Nie znaczy to, że ta praca nie jest wykonywana. Proces jest maksymalnie uproszczony, tak aby dostosować się do kontekstu i potrzeb organizacji. Biorąc pod uwagę kulturę organizacyjną oraz dostosowany system jest to możliwe. Daleko jeszcze do doskonałości, wiele usprawnień jeszcze musi być wprowadzone. To byłby najgorszy moment, gdy byśmy stwierdzili, że już jest doskonale i że nie ma co poprawiać.

16. lutego 2013 · Write a comment · Categories: Agile, Lean, Tesis · Tags: , , , ,

W ostatni poniedziałek 11.02.2013 miałem przyjemność zaprezentować podejście Agile dla IPMA Polska w Poznaniu– opis jest TUTAJ, a prezentacja znajduje się w zakładce Presentations.

To było ciekawe spotkanie dla mnie. Połączenie teoretycznie rozłącznych organizacji PMI, IPMA, WSB oraz tematyki Agile. Ja jestem wolontariuszem i członkiem zarządu w PMI, prezentacje robiłem dla IPMA. Jestem też wykładowcą na WSB na kierunku pod patronatem PMI. A WSB jest członkiem instytucjonalnym w IPMA. Tak czy inaczej wszystkie te organizacje łączy jeden cel podnoszenia profesjonalizmu i wiedzy.

Jak wiele osób wie – wywodzę się z tradycyjnego podejścia do zarządzania projektami. Na takim zdobywałem przez wiele lat wiedzę i doświadczenie. Od dłuższego czasu dużo też energii poświęcam na poznanie podejścia Lean-Agile. Pasjonuje mnie ten temat. Na nowo mogę zdobywać dużą porcję wiedzy i doświadczenia. Podczas prezentacji pokazywałem różnicę między tradycyjnym podejściem, a zwinnym. Łatwo mi o tym mówić bo znam oba. Prezentacja dotyczyła tematu Agile Project Management, więc główny nacisk oraz większość poruszanych aspektów dotyczyła podejścia zwinnego. Sądząc po komentarzach, pytaniach oraz po spotkaniu networkingowym mogę stwierdzić, że większość osób była bardzo zadowolona z prezentacji. Miałem wiele ciekawych rozmów.

Jedna z nich dotyczyła tego, że w agile nie ma nic nowego i że to wszystko już było. Biorąc pod uwagę mój poprzedni post trochę się z tym zgadzam. Jeżeli Agile jest zastosowaniem Lean to oczywiście nie może być to nowość bo Lean jak i podłoże Lean (TPS) powstał już bardzo dawno temu. Dodatkowo na prezentacji pokazywałem historie Agile. Po raz pierwszy Scrum był wspomniany w dokumencie The new new product development game. Dokument ten pochodzi z 1986. Można jeszcze kilka przykładów podać z historii. Jeden z kolegów stwierdził, że np. TQM i teoria ograniczeń (TOC) już dawno o takim podejściu mówiły. Technicznie zgadzam się. Agile nawet jawnie korzysta z TQM i TOC. To jest wartościowa wiedza. Podczas konferencji StoosConnect na jednej z prezentacji pokazane były skróty około dwustu metod, technik zarządzania, które na dzień dzisiejszy biznes ma do wykorzystania. Większość jest bardzo skomplikowana, nawet dla bardzo zaawansowanych osób, które ukończyły szkoły biznesowe.  Ile osób umie rozwinąć skróty takie jak TQM czy TOC? A ile osób wie czego one dotyczą i jak je zastosować? Dokładając do ich skomplikowania to, że większość osób ich nie rozumie sprowadza się do tego, że bardzo mało jest firm, które je w pełni stosuje i czerpie korzyści. Oczywiście podkreślam to, że większość z tych metod ma bardzo dużą wartość. Są opracowane na podstawie wieloletnich badań i obserwacji. Sam Ken Schwaber jeden z sygnatariuszy Agile Manifesto oraz współtwórca Scrum’a spędził wiele lat na obserwacjach systemów produkcyjnych poznając tak techniki wytwórcze jak i zarządcze. Robił to, aby z nich czerpać i zaproponować coś lepszego.  Wszyscy sygnatariusze Agile Manifesto to inżynierowie, którzy mieli możliwość poznać większość technik zarządczych. Więc co odróżnia Agile, że staje się popularny, że ludzie rozumieją i chcą z tego podejścia korzystać, że przynosi konkretne i mierzalne efekty? Po pierwsze to nowe zwinne podejście korzysta z dotychczasowej wiedzy ludzi, bierze elementy z metod i standardów zarządczych. Czerpie z nich to co najlepsze. Po drugie procesy zwinne są bardzo proste i zrozumiałe. Po trzecie i chyba najważniejsze – agile stawia człowieka na pierwszym miejscu. To nie procesy i narzędzia robią z nas lepszych tylko my sami możemy siebie poprawić. Agile jest bardzo bliski działaniu mózgu człowieka i w tym można upatrywać sukcesu.

Produkujemy coraz bardziej skomplikowane produkty, coraz więcej w tych produktach jest myśli i wiedzy ludzkiej (np. programy komputerowe). Coraz więcej kreatywności. Aby osiągać wysoki poziom innowacji nasze produkty będą jeszcze bardziej złożone. Więc nie utrudniajmy sobie życia poprzez wytwarzanie skomplikowanych i złożonych produktów przy wykorzystaniu skomplikowanych i złożonych procesów wytwórczych. Na procesy wytwórcze mamy wpływ i możemy je uprościć. To właśnie odróżnia agile od tego co już było. To jest to nowe myślenie. Agile jako proces jest prosty, jednak jest trudny do wdrożenia. Jest go trudno wdrożyć bo nadal ciężko nam uwierzyć w człowieka i zmienić nasze podejście (mindset).

Pewnie na tym nie koniec. Pewnie jeszcze będzie wiele okazji, aby o tych różnicach porozmawiać i wymienić się spostrzeżeniami. Jestem przekonany, że to może być ciekawy temat i przy konstruktywnym podejściu możemy znaleźć coś nowego.

Na koniec cały czas musimy pamiętać, że najważniejszy jest kontekst naszych projektów i agile na poziomie procesu nie zawsze jest idealny. Jednak sprawdza się w wielu projektach opartych na wiedzy, innowacyjności, kreatywności.  Wartości, które idą za agile powinny być stosowane w każdym projekcie. Szczególnie na poziomie pracy zespołów.

06. lutego 2013 · Write a comment · Categories: Lean, Tesis · Tags: , ,

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.