Blog

Kilka dni temu miałam przyjemność uczestniczyć w szkoleniu PAL-E, czyli Professional Agile Leadership (PAL) – Essentials, które poprowadził Andy Brandt. Ciekawa byłam co ma do zaproponowania Scrum.org w kontekście zwinnego menedżera. Zaskoczenie było bardzo pozytywne.

Przede wszystkim uczestnicy

To, czego nie doceniałam idąc na PAL-E to wglądy, którymi podzielili się uczestnicy. W kameralnej grupie znaleźli się przedstawiciele różnych organizacji: małych i dużych. Zwinnych i zainteresowanych zwinnością. Grupa zachwyciła mnie już podczas rundy zapoznawczej, w której opowiadaliśmy sobie w jakim celu właściwie tutaj jesteśmy. Ta początkowa dyskusja, kontynuowana potem podczas przerw kawowych i nie tylko, czyli w trakcie i po szkoleniu, zainspirowała mnie do podzielenia się tym na blogu. Fakty i przemyślenia tego wpisu są zebrane nie tylko z tego szkolenia, ale również (a może przede wszystkim) z ostatnich kilku lat mojej pracy z menedżerami.

Jestem kierownikiem projektu, który właśnie się kończy

Całkiem normalna sytuacja biorąc pod uwagę, że projekt to zbiór aktywności które posiadają zaplanowany z góry początek i koniec. Sytuacja staje się nieco trudniejsza w momencie, gdy organizacja w której ten projekt jest umiejscowiony zaczyna sympatyzować ze zwinnością. Tutaj możliwości mamy kilka:

• zwinność jest wdrażana poza moim projektem i nie mam z zespołami zwinnymi zidentyfikowanych w projekcie zależności
• zwinność jest wdrażana poza moim projektem, ale mam zidentyfikowane zależności (technologiczne, osobowe, zakresowe) między moimi zespołami i zespołami zwinnymi
• jeden z moich zespołów projektowych zdecydował się pracować zwinnie i jesteśmy zagubieni w tej zmianie
• …

W tej sytuacji pojawia się naturalne dla profesjonalisty pytanie: “po co mojej organizacji ta cała zwinność?” i na to właśnie pytanie odpowiada pierwsza część szkolenia.

Nie wiem, czy wzięliście już udział w szkoleniu PAL-E, więc żeby nie psuć ewentualnej niespodzianki, ale zasygnalizować zagadnienia, polecam na początek nagranie z TEDs Simon Sinek: “Start with why”. a potem zapoznanie się z modelem Cynefin, który prezentuje sam autor – Dave Snowden.

Zachęcam Cię abyś w kontekście swojej organizacji odpowiedział(a) sobie na pytanie – “dlaczego wybieramy zwinność” lub “dlaczego jej nie wybieramy”. Jeśli obejrzysz zaproponowane powyżej filmy, odpowiedź na to pytanie może być nieco łatwiejsza. Samo poszukiwanie tej odpowiedzi jest wartościowe dla menedżera. Jeśli wydaje Ci się, że odpowiedź masz już w głowie – podziel się nią w swoim zespole. Zaproś do refleksji – wnioski mogą Cię zaskoczyć. Jeśli masz ochotę, podziel się swoimi przemyśleniami również z nami, w komentarzu pod artykułem.

Podsumowując ten punkt: PAL-E dla kierownika projektu w organizacji, która coś robi zwinnie – zdecydowanie tak.

Pracuję w Project Management Office – czy coś się zmieni?

Zespoły pracujące w “agile”, czyli zwinne często posiadają “backlog produktu”. Backlog produktu to uporządkowana lista rzeczy, które w danym momencie uznajemy za warte zrealizowania w obrębie konkretnego produktu. Wszystkiego, co w danym momencie rozwoju produktu wiadomo. Miałam fascynującą rozmowę z przedstawicielami PMO, na temat transparentności tego rejestru. Właściwie to mówimy tutaj o transparentności “tych rejestrów”, w sytuacji gdy produktów jest więcej. Jesteście w stanie sobie zapewne wyobrazić co się dzieje, jeśli te produkty są realizowane zarówno przez tradycyjne, kaskadowe projekty jak i przez nowe zespoły zwinne. Poniżej wypisałam typowe wyzwania, z którymi zmagają się zespoły zwinne i ich menedżerowie:

• powielanie wymagań (gdy coś jest robione w kaskadzie i zwinnie)
• kłopoty z dekompozycją wymagań pomiędzy zespoły wewnętrzne i zewnętrzne
• podwykonawca ma inny system do rejestracji wymagań niż my – jak żyć?
• brak kryteriów akceptacji na poziomie wymagań
• backlog produktu nie jest aktualizowany
• backlog jest trzymany w kilku miejscach jednocześnie (prezentacja, excel i JIRA) i nie wiemy gdzie jest źródło prawdy
• audyt twierdzi, że nasz backlog musi być wersjonowany
• ten backlog ma być spójny z wizją produktu – ale gdzie ta wizja?
• …przykłady można długo mnożyć.

O takim i wielu innych wyzwaniach rozmawiają menedżerowie, którzy zdecydowali się realizować właściwe rzeczy we właściwy sposób. Tym razem zadajemy sobie trzy kolejne pytania:

• kto?
• co?
• jak?

W odniesieniu do zagadnienia backlogu produktu, po głębszej analizie problemu może pojawić się taki zestaw pytań:

• kto jest odpowiedzialny za przygotowanie backlogu produktu?
• kto jest odpowiedzialny za jego pielęgnację/skomunikowanie/przejrzystość/aktualizację?
• czy ta osoba ma wystarczającą wiedzę merytoryczną i wsparcie narzędziowe?
• kto ją wspiera w tym zadaniu?
• kto korzysta z tego artefaktu?
• czy wszystkie osoby korzystającego z tego artefaktu są świadome jego istnienia?
• …

Klasyczna pułapka zamyka się, gdy schodzimy w głąb tego drzewa z pytaniami i próbujemy zająć się nimi mniej więcej bezpośrednio. W jakiejś tam kolejności wynikającej z mniej lub bardziej przemyślanych priorytetów. Przepraszam za spłycenie zagadnienia priorytetyzacji Twoich zadań. Wierzę że wybierasz to czym się zajmujesz i robisz to dobrze. Jednak w tym punkcie, chcę napisać o czymś innym.

W zwinności, a w szczególności w popularnym Scrumie występują trzy role, z których istnienia menedżer powinien czerpać sporo satysfakcji w swojej codziennej pracy.

• Właściciel Produktu (Product Owner) – jest odpowiedzialny za zagadnienia związane z pytaniem “CO?”
• Zespół Deweloperski (Development Team) – jest odpowiedzialny za zagadnienia związane z pytaniem “JAK?”
• Scrum Master – jest odpowiedzialny za zagadnienia związane z procesem, czyli “KTO?” i “JAK”
• Ty jako zwinny menedżer jesteś odpowiedzialny za to, żeby ich w realizacji tych zadań wspierać.

Podsumowując ten punkt: PAL-E dla menedżera PMO w organizacji, która jest w trakcie transformacji zwinnej – oczywiście, że tak.

Dla kogo jeszcze to szkolenie?

Napotkałam w swojej pracy wiele historii, które zawierają się w kategorii “problemy zwinnego menedżera” oraz “problemy menedżera ze zwinnością”. Z braku miejsca zasygnalizuję tylko kilka:

• jestem dyrektorem pionu, w którym pojawili się Product Ownerzy – jak mam nimi zarządzać?
• jestem HRBP, która ma wspierać transformację zwinną, co się zmieni w mojej pracy?
• jestem szefem transformacji, jak zmierzyć czy dobrze nam idzie?
• jestem menedżerem IT, deweloperzy w moich zespołach narzekają na Scrum – co robić?
• jestem menedżerem IT, biznes sam sobie zbudował system i co ja mam teraz z nimi począć?
• jestem menedżerem w obszarze biznesowym, IT nie realizuje moich potrzeb w sposób satysfakcjonujący, jak to zmienić?

Zaraz, zaraz – a Trener?

Trenera pochwalę raz a dobrze – mimo że Andy Brandt “razadobrzyzmu” nie lubi i nie poleca.

Oprócz profesjonalnie przeprowadzonego szkolenia uczestnicy dostali w gratisie liczne i wartościowe dygresje. Właściwie nie dygresje, tylko “mini wykłady” – ilustrowane rysunkami opowieści o tym, co ważne. Kilka moich ulubionych przykładów:

• jak ze źle zaprojektowanych systemów i niemocy organizacyjnej mogą powstać całkiem dobrze prosperujące produkty (patrz http://pragmaticleader.net/2017/05/01/the-ultimate-patch/)
• dlaczego nie powinniśmy mówić “zasoby”, tylko ludzie (prawdziwi ludzie wraz z ich wszystkimi talentami a nie elementy maszyny)
• Kim jest profesjonalista i co to jest “minimalny profesjonalizm” (patrz “Andy jedzie”)

Zatem – cytując Trenera – “tutaj się zatrzymamy”.

Jeśli chcesz, abym rozwinęła któryś z powyższych wątków w kolejnym wpisie, wspomnij proszę o tym w komentarzu pod artykułem.