When projects fail in a company, management tries to understand what went wrong. Often, first impressions are that we don’t have skilled enough people or our methodology is not well implemented. When we ask a consulting company, they, in most cases, conduct ASIS analysis then sell a new methodology implementation or trainings. Nothing or little will change. The challenge is in the system of work. System of work consists of such things as structure, hierarchy, goals, multitasking, team dysfunctions, planning horizons, etc.. All of this and more influence our projects every day. Although systems of work are around us, it is not visible. That is the challenge.

„Leaders are missing the solution because they are not looking at the systemsstructuresprocesses and polices that affect day-to-day behaviorsThey arefocused on the symptoms instead of the principles that promote trust.”                       

Covey „Speed of trust”

 

Don’t Change the Methodology. Change the System! (part 1)

Don’t Change the Methodology. Change the System!

21. maja 2015 · 1 comment · Categories: Agile · Tags: , , ,

And another post – short and easy:)

Many of my friends start a journey to agility. They all have different challenges with it. All want to learn more. They ask me for recommendations of books/trainings, which are good for people who want to start own way towards agility.

Some of good books are on the list here: http://www.orgtesis.pl/readings/     (and now I need to update this list with another one)

Being Agile in an Waterfall World

Being Agile in an Waterfall World

Why I write „now”?

Recently I did another change in my life. And as always – Change is good!

I changed a company.

 

I miss my old great team, but it is time to move on. New challenges. New people.

There is no surprise, AllegroGroup is The Agile Company. By all means. It is nimble and works by heart according to The Agile Movement. Teams are able to use agility enabling practices. I had an opportunity there to experience a change/transformation from a waterfall mindset to an agile mindset. Was it easy? – For sure not. Long story. A huge achievement for all teams. A few times I had a chance to give a speech about a transformation on conferences either in Poland or abroad (PMI EMEA Congress, PMI Global Congress North America).

Now I joined another company. It is my first week. I am focused on getting a feeling of organizational culture etc. You can imagine… all around is new and exciting for me.

During meetings we talk a lot about agility. About understanding the differences between waterfall and Agile. Lots of questions, answers and inspiring discussions.

For sure it is very complex organization.

Many of us are in similar environment. So what to do? Where to start? There are many ways. For sure, good start is to read good books, and there are many of them on market 🙂

I remind myself one, which I bought half a year ago. My friend Joseph Flahiff is an author. Very experienced professional. You can find his profile on LinkedIn.

 

Title?

BEING AGILE IN A WATERFALL WORLD – a practical guide for complex organizations”   (LINK)

 

If I would have to write one sentence about this book, I would write “100% of common sense about Agile”.

The book is easy to read. All is explained in an easy to understand way. There are many examples from companies around world. Joseph got very pragmatic approach and you can feel it.

Remember Agile is NOT a NOUN!  (you will read more about it in Joseph’s book)

I stop here. Book is recommended to all who starts way towards agility. No doubts about it! Want to know more? Read it or ask me :).

Do you have some good books to be recommended? Share them with me and others. Thank You!

 

Being Agile in an Waterfall World

Being Agile in an Waterfall World

 

Czas na następny certyfikat – AgilePM Foundation & Practitioner. Stoi za tą certyfikacją APMG, ta sama organizacja, która ma w swojej ofercie certyfikacje na Prince2, ITIL, MSP i inne. W związku z tym, struktura certyfikatów jest podobna na początku poziom Foundation, a następnie Practitioner. Trzeba zrobić jeden po drugim.

Więcej na temat tej certyfikacji można oczywiście przeczytać na stronie APMG: APMG Strona

Zanim przejdę dalej to muszę poruszyć jedną ważną kwestię – DSDM (Dynamic Systems Development Method).  Certyfikacja AgilePM wprowadzona przez APMG wzoruje się praktycznie w 100% na DSDM. Różnica podstawowa dla użytkownika jest taka, że AgilePM jest płatny, a DSDM jest darmowy. Dla mnie historia wygląda dość prosto. APMG obserwując trendy na rynku zarządzania projektami widzi, że Agile jest na fali wzrostowej. Patrząc na wzmocnione działania PMI w tym obszarze oraz już rozwinięte stowarzyszenia jak Scrum Alliance czy Scrum.org pozazdrościło produktu jakim jest certyfikacja Agile. A to przecież duże pieniądze można zarobić. Nie mając kompetencji w tym obszarze (do tego jeszcze wrócę) postanowili zastosować to co już było na rynku. Zastosowali DSDM, który jest jedną z najstarszych metodyk Agile. Tak, dokładnie – metodyka. DSDM/AgilePM jest metodyką opisującą zwinne zarządzanie projektami. Nie jest to framework (rama działania), nie jest to zbiór najlepszych praktyk. Jest to metodyka, która opisuje krok po kroku działania na projekcie zwinnym. DSDM jest też najstarszą metodyką Agile – powstał w 1995 roku. Jednym z głównych jej autorów jest Arie van Bennenkum, jeden z sygnatariuszy Agile Manifesto. O samej metodyce należy napisać całkowicie osobny post. Jak będzie zainteresowanie to napiszę o tym. W krótkich słowach jest to najbardziej sztywne podejście do Agile jakie znam (pewnie istnieją sztywniejsze…, ale szczerze, to ja już bym ich poznawać nie chciał). Jest to taki PRINCE2 w zarządzaniu projektami.

Osobiście cieszę się, że poznałem dość dokładnie tą metodykę. Jest w niej kilka elementów, które warto wykorzystywać na co dzień.

Czytając książkę lub przygotowując się do egzaminu bardzo szybko odnosi się wrażenie jak bardzo można skomplikować prostą sprawę. Np. scrum rozpoznaje 3 role: Zespół Deweloperski, Scrum Mastera, Product Ownera, a w DSDM/AgilePM mamy ich 13. I do certyfikacji trzeba je znać wszystkie wraz z odpowiedzialnością. Dodatkowo mamy opisane całą masę różnych dokumentów (nazwane są one produktami), które powstają na każdym kroku – podobnie jak to ma miejsce w Prince2. I na nic się nie zda tłumaczenie praktyków, że nie chodzi o formalne dokumenty (produkty), że dokumentem może być zdjęcie tablicy, lub sam fakt spotkania i rozmowy. Ci co przeczytają książkę nie mając bardzo dużego doświadczenia praktycznego odniosą wrażenie skomplikowania i formalizmu. Już widzę w oczach jak powstaje zbiór wzorów (templates) dokumentów (produktów) do Agile.

Są też pozytywne strony. DSDM/AgilePM opisuje projekt całościowo. Od powstania idei, poprzez napisanie business case, realizację i zakończenie. Porusza aspekty zgodności ze standardami jakości. Daje wiele gotowych rozwiązań. To może spowodować szybsze przekonanie się do Agile. Często mówię, że jak mam sobie wyobrazić Agile w projektach rządowych to właśnie wyobrażam sobie taki jak DSDM/AgilePM.

Największym minusem jest to, że olbrzymia część skupienia idzie w stronę mechaniki Agile, a najważniejsze czyli zachowanie i natura ludzi jest potraktowana bardzo powierzchownie.

Wracam do certyfikacji. Na wcześniej podanej stronie można też kupić książkę Agile Project Management Handbook. Książka kosztuje 35 Funtów. To jest mniej niż książka do PMI-ACP, ale z drugiej strony jej siostrzana wersja opisująca DSDM jest dostępna za darmo w postaci elektronicznej: DSDM Książka

Czy się różni? Minimalnie i nie ma to większego znaczenia dla egzaminu. Książka AgilePM posiada np. dopisane na końcu każdego rozdziału tzw. Agile Project Manager Top Tips. Kilka wskazówek dla Kierowników Projektu.

 

Certyfikacja ma dwa poziomy Foundation i Practitioner. O ile Foundation jest rzeczywiście tym na co nazwa wskazuje, to drugi egzamin nie ma nic wspólnego z byciem „Practitioner”. Jest to advance theoretical. Trzeba oczywiście mieć dokładniejszą wiedzę i o wiele bardziej rozumieć zastosowanie Agile, jednak inteligentna osoba po przeczytaniu książki jest w stanie zdać Practionera, nawet bez jednej godziny przepracowanej praktycznie w Agile. Doświadczenie praktyczne nie jest wymagane, jak to ma miejsce przy certyfikacji PMI-ACP. Jedynym wymaganiem jest wcześniejsze posiadanie certyfikatu Foundation.

 

To jak podejść do egzaminu? Gdzie go zdać?

APMG ma swoją dziwną politykę związaną ze zdawaniem egzaminu. Maksymalnie jest utrudnione zdawanie egzaminu bez wcześniejszego wykupienia szkolenia. Oczywiście chodzi tutaj o pieniądze. Można to zrobić przez 4 otwarte centra egzaminacyjne w Niemczech, Holandii, Anglii i Australii lub przez British Council (też w Polsce). Ja bardzo dawno temu uparłem się, aby zdawać Prince2 bez szkolenia. Wtedy jakimś cudem udało się przebrnąć przez British Council –powiedziano mi, że jestem jednym z pierwszych w Polsce. Mam nadzieję, że teraz jest to o wiele łatwiejsze.

Najłatwiejszym sposobem jest jednak wykupienie szkolenia gdzie egzaminy są wliczone w cenę. Szkolenia i egzaminy mogą być prowadzone przez ATO (Accredited Training Organization). Na ile się orientuje, w Polsce znajdziesz na ten moment dwie firmy, które prowadzą szkolenia z AgilePM. W związku z tym, że temat jest świeży w APMG, a szczególnie w Polsce, to nie zaufałem polskim firmom i postawiłem na polecanego trenera z Anglii. I tutaj jest moment kiedy muszę wrócić do braku kompetencji APMG w obszarze Agile. Większość trenerów akredytowanych do prowadzenia szkoleń i egzaminów do AgilePM to trenerzy, którzy przez lata szkolili z Prince2, MSP, M_o_R i innych. To bardzo dobrzy trenerzy (pod względem umiejętności trenerskich), ale nie są to praktycy Agile. Nawet jak kiedyś byli praktykami zarządzania projektami co daje im predyspozycje do szkolenia z Prince2, to w Agile słabo to wygląda. To jest cały czas bolączka APMG. Z tego co wiem, trwają prace nad polepszeniem tego stanu. Cały czas zalecam ostrożność.

Trenera, którego ja miałem – NIE POLECAM. Ale, żeby była jasność – to bardzo dobry trener i zrobił swoją robotę dobrze. Nauczył do egzaminów i cała grupa zdała tak Foundation jak i Practitioner. Nie można mu pod tym względem nic zarzucić. Tylko bardzo mocno było czuć, że zna temat w teorii, a nie z praktyki.

W Polsce posiadaczy certyfikatów jest około 30-40 osób. To znacznie więcej niż PMI-ACP.

AgilePM Practitioner - Certyfikat Michał Rączka

AgilePM Practitioner – Certyfikat Michał Rączka

 

Egzamin AgilePM Foundation

Jak ktoś zdawał egzamin Prince2 Foundation lub ITIL Foundation to wie, jak proste jest zdanie tego poziomu egzaminu. Tak też jest przy AgilePM. Mamy 60 pytań i 60 minut. Aby zdać egzamin potrzebujemy minimum 50% poprawnych odpowiedzi. Mamy cztery odpowiedzi do wyboru, z czego tylko jedna prawidłowa. Egzaminy odbywają się przy wykorzystaniu kartek i ołówka.

Koszt egzaminu otwartego to: 175 Funtów

 

Przykładowe pytania jakich można się spodziewać:

  1. Which individual role is responsible for all aspects of the delivery of the solution?
    • Team Leader
    • Project Manager
    • Solution Developer
    • Business Visionary
  2. Which is NOT one of Atern’s lifecycle phases?
    • Pre-project
    • Project start up
    • Foundations
    • Deployment

 

Egzamin AgilePM Practitioner

Ten egzamin już jest o wiele bardziej skomplikowany w swojej strukturze. Na samym początku jest scenariusz (case study) przykładowej firmy – jest to opis na kilka stron. W praktyce bardzo mała część pytań odnosi się do tego scenariusza. Pytania są pogrupowane w obszary np. Techniques, People and Roles, Control etc…

Każdy obszar ma kilka pytań. W każdym obszarze możemy zdobyć 15 punktów. Różne pytania są warte rożną ilość punktów, w zależności od trudności. Są pytania, które mają dwie poprawne odpowiedzi, ale dla ułatwienia jest to napisane, aby zaznaczyć dwie odpowiedzi – patrz przukład.

Maksymalna ilość punktów jaką można zdobyć to 60. Aby zdać potrzebujemy podobnie jak przy Foundation 30 punktów (50%). Na egzamin mamy 2 godziny.

Egzamin jest przeprowadzany na zasadzie Open Book – czyli można mieć przy sobie i korzystać z książki Agile Project Management Handbook. Jest to pewnie po to, aby spowodować potrzebę zakupu książki i uzasadnić wydane pieniądze. Czy książka rzeczywiście się przydaje? Pewnie tak, aczkolwiek ja nie korzystałem.

Egzamin odbywa się przy pomocy kartek i ołówka.

Koszt egzaminy otwartego to: 270 Funtów

 

Przykładowe pytania jakich można się spodziewać:

  1. Mamy dwie kolumny. W jednej twierdzenie lub definicja, a w drugiej znaczenie. Trzeba połączyć ze sobą te dwie kolumny:
Column 1 Column 2
1.

 

 

2.

 

 

3.

Develop and test the Timebox products in line with agreed priorities.

 

Work Together to understand the full detail of all the work intended for completion in the Timebox.

 

Agree high-level acceptance critieria for each product to be delivered in the Timebox.

 

  • Refinement
  • Kick off
  • Investigation

 2. Pytanie, które polega na znalezieniu dwóch poprawnych odpowiedzi:

Which 2 actions represent an appropriate application of the MoSCoW prioritisation technique by the Solution Development Team?

  • Re-prioritise some Must Have requirements to Should Haves
  • Replace the display stand with two roll-up banners
  • Escalate a concern that there is NOT enough contingency of Could Have Requirements
  • Change the priority of the requirement for internal wall posters from a Must Have into a Could Have requirement.
  • Confirm with the Business Visionary that the Must Have requirements represents the minimum usable subset

3.  Pytanie, które polega na oznaczeniu czy twierdzenie i uzasadnienie są prawdziwe (True) czy fałszywe (False) oraz czy uzasadnienie tłumaczy twierdzenie czy nie tłumaczy. Do każdej pary mamy możliwość wyboru jednej odpowiedzi z sześciu kombinacji.

Assertion Reason
1 The high-quality output needed in this project means that there is NO opportunity for iterative development BECAUSE An iterative proces can stifle the autonomy and creativity of the Solution Development Team.

 

Przyznam, że nie zrobił na mnie większego wrażenie ani Foundation, ani Practitioner. Mógłbym spokojnie nauczyć kogoś do tych egzaminów jakbym zrobił akredytacje.

Podobnie jak przy poprzednim opisie, jeżeli istnieje potrzeba, abym coś dodatkowo opisał o powyższej certyfikacji lub masz pytania i/lub uwagi, to proszę o komentarz.

Jako następny w tej serii artykuł będzie dotykał certyfikacji Scrum.org – PSM (Professional Scrum Master) i PSPO (Professional Scrum Product Owner). Cdn…

03. marca 2013 · 2 komentarze · Categories: Agile · Tags: , , , , , ,

Uwaga: tym wpisem odchodzę od sedna blogu, jednak wiele osób pyta o wiedzę i certyfikaty Agile. Z tego powodu warto kilka słów na ten temat napisać i ewentualnie rozszerzać jak będą dodatkowe pytania i komentarze.

Napiszę o różnych certyfikatach, które mają za zadanie potwierdzić wiedzę i „doświadczenie” w Agile osoby, która je posiada. Czemu akurat wybrałem tytułowe certyfikaty? Z bardzo prostej przyczyny. Nie lubię teoretyzować, a z takich czy innych powodów i okazji posiadłem wymienione certyfikaty co może kwalifikować moją osobę do napisania o nich z poziomu doświadczeń. Czy istnieją jeszcze inne dostępne certyfikaty? Tak istnieją, tylko ja z nimi nie miałem do czynienia, więc tylko je wymienię i podam linki, gdzie można przeczytać więcej.

Czy certyfikaty są coś warte? Odpowiedź na to pytanie pozostawiam Tobie. Wg mnie wiedza i doświadczenie są wiele warte. Certyfikaty nie mogą być celem samym w sobie. Ja je pozyskałem z głodu wiedzy i aby siebie sprawdzić. To było i jest dla mnie warte spędzenia kilku godzin.

Wszystkie tytułowe certyfikaty dotyczą szeroko pojętego Agile. Tak szeroko, że każdy z nich jest bardzo, bardzo różny. Nie da się znając Scrum tak po prostu zdać PMI-ACP lub AgilePM. Nie da się znając AgilePM zdać PMI-ACP. Różnice są bardzo duże. Można powiedzieć, że Scrum i AgilePM stoją na maksymalnych przeciwległych granicach podejścia do agile i dotykają materii wąsko i głęboko, a certyfikacja PMI-ACP dotyka bardzo dużo różnych podejść (też Scrum i AgilePM), lecz dość płytko.

Zacznijmy od najtrudniejszego, czyli od PMI-ACP.

Za tym certyfikatem stoi PMI (Project Management Institute). Dla wielu PMI cały czas kojarzy się z tradycyjnym zarządzaniem projektami, z PMBOK’iem oraz certyfikatami PMP i CAPM. Skojarzenie dość prawidłowe, jednak podlega dużej zmianie. PMI już od jakiegoś czasu wiele swojej energii poświęca dla agile i certyfikacja jest jednym z produktów tej energii.

PMI-ACP – Agile Certified Practitioner. Spójrz na nazwę i przeczytaj jeszcze raz. Jest to certyfikacja roli, a nie stanowiska. Nazwa wskazuje na praktyka Agile.

Celem PMI jest stworzenie certyfikacji, która dotyczy wykorzystania Agile w różnych dziedzinach. Jednak na ten moment dość mocno widać wpływ dziedziny rozwoju oprogramowania.

Oficjalny dokument opisujący certyfikat PMI-ACP znajdziesz tutaj: PMI-ACP HANDBOOK

Na dzień dzisiejszy ok 2000 osób posiadło ten certyfikat na całym świecie, ok 6-10 osób w Polsce. Jest to początek, jednak liczba nowych certyfikacji wzrasta bardzo szybko.

Aby mieć możliwość podejścia do egzaminu trzeba wypełnić formularz na stronie pmi.org. Jest to uproszczone w porównaniu do formularza PMP. Trzeba spełniać następujące warunki:

  • posiadanie 2000 godzin udokumentowanego doświadczenia w zarządzaniu projektami lub wcześniej zdany egzamin PMP lub PgMP,
  • posiadanie 1500 godzin udokumentowanego doświadczenia z zarządzania projektami wykorzystując Agile,
  • posiadanie 21 godzin kontaktowych z wiedzą na temat praktyk agile (szkolenia).  Nie musi być to szkolenie przygotowujące do PMI-ACP. Może być szkolenie np.  scrum.org na Professional Scrum Master lub inne.

Doświadczenie opisuje się poprzez pokazanie projektów przy których się pracowało. Projekty te nie mogą się nachodzić, gdyż tylko z jednego projektu w jednym czasie można udokumentować godziny. Trzeba podać daty projektu, tytuł oraz opis do 2000 znaków. Dodatkowo należy wpisać dane kontaktowe do osoby, która może poświadczyć te doświadczenie na wypadek audytu. Ja tym razem nie przechodziłem audytu, ale przy innym certyfikacie kilka lat temu mnie sprawdzano. Jak formularz jest wypełniony zgodnie z faktycznymi dokonaniami to audyt nie jest problemem, tylko trzeba liczyć co najmniej 2-3 tygodnie czasu na przesyłkę oraz sprawdzenie dokumentów przez PMI.

Po wypełnieniu formularza jest on sprawdzany merytorycznie co trwa maksymalnie 10 dni. U mnie ten etap trwał 3 dni i dostałem maila, że moja aplikacja jest dobra merytorycznie i kwalifikuje się do przejścia do następnych kroków.

Następnym krokiem jest płatność. Niestety nie ma nic za darmo. Dla członków PMI opłata wynosi 435USD, a dla pozostałych 495USD. Gdy dokonamy opłaty to albo skierują nas na audyt, albo od razu dostaniemy Eligibility ID, numer który uprawnia nas do rejestracji na egzamin poprzez portal prometric.com. Przy rejestracji na portalu trzeba spojrzeć dokładnie na co klikamy. Są dwie drogi wyboru PMP/PgMP i osobna CAPM / PMI-ACP. To jest ważne, bo gdy wybierzemy PMP, to system informuje nas, że podany numer już jest wykorzystany. Ku mojemu zaskoczeniu (pozytywnemu oczywiście) PMI-ACP można zdawać w kilkudziesięciu ośrodkach w Polsce, w Poznaniu w trzech. Ci co zdawali PMP wiedzą, że akredytowany jest tylko jeden w Warszawie. Wybieramy ośrodek, godzinę, idziemy i zdajemy. Na egzaminie jest 120 pytań, z czego 100 jest ocenianych i mamy na to wszystko 3 godziny czasu.  Nie podawany jest procentowy próg poprawnych odpowiedzi potrzebnych do zdania. Wynik otrzymujemy w dwóch kategoriach narzędzia i techniki oraz wiedza i umiejętności. Skala oceny jest trzystopniowa: Proficient, Moderate Proficient, Below Proficient. Ja zdobyłem w obu kategoriach ocenę Proficient. Nie wiem, czy inne oceny też kwalifikują do zdania egzaminu.

Certyfikat PMI-ACP

Certyfikat PMI-ACP

Tylko jak się przygotować do egzaminu? Czy jest trudny? Czego można się spodziewać?

Jak ktoś się interesuje tematem, posiada mocne co najmniej 1500 godzin doświadczenia Agile i jeszcze przebył szkolenia, to bez większego problemu powinien zdać egzamin. Łatwo powiedzieć komuś kto już zdał J. Mi też tak powiedzieli, jednak dodatkowe przygotowanie nie zaszkodzi i jak coś robić to raz a dobrze. PMI rekomenduje do przygotowania do egzaminu PMI-ACP przeczytać kilka pozycji książkowych: PMI-ACP Literatura.

Dużo czytania. To co polecam znajdziesz w zakładce Readings (w kategorii Agile – specjalnie oznaczyłem to co jest warte dla PMI-ACP). Jeżeli chcesz zdobyć wiedzę to polecam przeczytać wszystkie. To jest skarbnica. Jeżeli chcesz zdać egzamin to te książki pokrywają dużo większy zakres niż jest potrzebny.  Trzymając się Lean i Agile trzeba robić to co jest wystarczająco dobre do wykonania celu. Jeżeli celem jest certyfikat to przeczytanie ich wszystkich będzie nadmiarowe i zbyt drogie.

Wyjściem jest zatem przeczytanie książki przygotowanej czysto pod egzamin lub odbycie szkolenia dedykowanego PMI-ACP.

Co do książki to praktycznie jest jedna godna polecenia pozycja PMI-ACP Exam Prep – Mike Griffiths. Książka jest ściśle przygotowana pod egzamin i zawiera 120 przykładowych pytań. Warto przeczytać – mi zajęło to cztery wieczory, lecz większość materiału znałem wcześniej.

Po przerobieniu pytań z książki można odnieść mylne wrażenie na temat samego egzaminu. Książka sugeruje wiele pytań, które polegają na dokładnym zapamiętaniu materiału. Na sprawdzeniu czy np. dokładnie się pamięta (co do wyrazu) wartości i zasady z Agile Manifesto, lub czy dokładnie się pamięta narzędzia wykorzystywane przy retrospekcji. Jako uzupełnienie książki polecam poczytać dużo więcej na temat XP i Scrum np. Scrum Guide.

Trudność egzaminu jest oczywiście względna. Jest to najtrudniejszy egzamin ze wszystkich wymienionych w tytule, jednak jest o wiele prostszy niż PMP. Mi sprawił rzeczywiście kłopot przy 4-5 pytaniach, ale ogólnie nie było wielkich niespodzianek.

Na egzaminie większość pytań wymaga rozumienia agile, wartości i czucia tematu. Książka Mike’a bardziej sugeruje pytania sprawdzające dokładne zapamiętanie treści. Jednak egzamin sprawdza czy się rozumie koncepcje i czy ma się doświadczenie w  zastosowaniu wiedzy, narzędzi, technik, umiejętności w tym kontekście. Pytań z serii sprawdzenia naszej pamięci jest ok 15%.

Na egzaminie trzeba rozumieć i znać:

  • Wartości i zasady z Agile Manifesto – kilka pytań.
  • XP (role, zasady )  – ok 15 pytań.
  • Scrum (role, artefakty, ceremonie) – kilka pytań, szczególnie o rolach.
  • Zarządzanie ryzykiem w agile – kilka pytań.
  • Estymowanie i planowanie – kilka pytań, co najmniej jedno na zasadzie case.
  • Servant Leadership i rola i zasady działania zespołu (np. komunikacja) – dużo pytań o zachowania i odpowiedzialności poszczególnych ról.

W związku z tym, że Alistair Cockburn (jeden z sygnatariuszy Agile Manifesto) brał udział w przygotowywaniu PMI-ACP to bardzo dobrze jest przejrzeć jego stronę i poczytać o walking skeleton, osmosys communication, radiators.

Nie trafiłem pytań które dotyczą DSDM, Crystal, Kodeksu Etycznego PMI.

Certyfikat jest przyznawany na 3 lata i aby przedłużyć jego ważność to podobnie jak przy PMP trzeba kolekcjonować punkty PDU związane z Agile. Wymagane jest zebranie 30 punktów, co nie jest problemem dla kogoś kto jest związany z tematem.

Być może coś jeszcze powinienem napisać o tym egzaminie. Jak będzie taka potrzeba z Waszej strony to oczywiście napiszę. Gdybyście poszukiwali szkolenia przygotowującego do certyfikatu PMI-ACP to proszę o maila.

W najbliższym czasie opiszę pozostałe certyfikaty, na czym polegają i co trzeba zrobić, aby je zdać.  Cdn…

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.