Zdrowa, detektywistyczna ciekawość to bardzo dobra cecha lidera.

W szkoleniu PAL-EBM znajdziesz:

• Wprowadzenie do Evidence-Based Management: Poznanie podstaw koncepcji Evidence-Based Management (EBM).
• 
  

Genezę koncepcji Evidence-Based Management: Historia i rozwój idei EBM.

Omówienie jak jasne wyznaczanie celów dla siebie, zespołu i organizacji wspiera zaufanie: Analiza wpływu celów na budowanie zaufania w zespole i organizacji.

Zrozumienie jak nasze zachowania wpływają na transparencję, inspekcję i adaptację przy tworzeniu celów i jak się to ma do Evidence-Based Management: Badanie wpływu zachowań na kluczowe elementy EBM.

Cele

Zmiana podejścia do określania celów na przestrzeni lat: Ewolucja metod ustalania celów.

Przedstawienie rodzajów i zależności pomiędzy celami wg. EBM: Różne typy celów i ich wzajemne relacje w kontekście EBM.

Burza mózgów: Po czym rozpoznać dobry cel? Jak podchodzić do dysfunkcyjnych celów?: Warsztaty na temat identyfikacji efektywnych i problematycznych celów.

Rezultaty celów: Jaką zmianę chcemy zaobserwować po osiągnięciu naszego celu?: Definiowanie oczekiwanych rezultatów celów.

Miary

Pryncypia projektowania mierników spójnych z podejściem zwinnym: Zasady tworzenia miar zgodnych z Agile.

Kategorie i właściwy dobór miar do obranego kierunku dla osiągnięcia celu: Wybór odpowiednich miar dla konkretnych celów.

Zrozumienie Kluczowych Obszarów Wartości dla usprawniania wartości rynkowej oraz możliwości operacyjnych: Kluczowe wskaźniki wartości (KVA) w kontekście rynkowym i operacyjnym.

Ćwiczenie: Projektowanie systemu miar w ujęciu różnych rodzajów celów: Praktyczne warsztaty projektowania miar.

Empiryzm

Empiryzm - czym jest i jakie ma znaczenie przy budowaniu celów: Rola empiryzmu w ustalaniu celów.

Zwinność przy stawianiu hipotez, eksperymentowaniu i pobieraniu zweryfikowanej nauki: Zastosowanie Agile w formułowaniu i testowaniu hipotez.

Omówienie inspekcji i adaptacji w Evidence-Based Management: Znaczenie inspekcji i adaptacji w EBM.

Ćwiczenie: Plan zmian w ramach studium przypadku, dyskusja i weryfikacja hipotez: Praktyczne ćwiczenia i analiza przypadków.

Proces wprowadzania EBM w organizacji

Indywidualna refleksja: Gdzie możemy zacząć wprowadzać zmiany?: Osobista analiza potencjalnych obszarów zmian.

Jak EBM może pomóc wprowadzać zmiany w życie: Wykorzystanie EBM do wdrażania zmian.

Formowanie agentów zmiany i budowanie społeczności w zmianie: Kreowanie liderów zmian i wspólnoty wspierającej.

Ślepe uliczki, pułapki i zagrożenia przy wprowadzaniu EBM: Identyfikacja i unikanie potencjalnych problemów.

Moja historia

 
Posłuchaj - jest więcej niż prawdopodobne, że byłem tam gdzie ty. Moje początki w IT to cała seria potknięć i porażek. Nie wiedziałem, co robię, czemu to robię i czemu to, co robię nie działa.

Rozdział 1 - Project Manager
Pamiętam jak jako Project Manager regularnie zastanawiałem się, czy to ja nie potrafię dopilnować wątków w projekcie, czy to okoliczności sprzymierzyły się przeciwko mnie.



Niby człowiek kończył odpowiednie studia (Zarządzanie Projektami IT, Technologie Internetu, Analiza Biznesowa), certyfikował się (Prince 2, zarządzanie ryzykiem, G-Force: Project Management, etc.), ale cały czas w moich projektach działy się nieprzewidziane rzeczy, które prowadziły do wypuszczania na rynek tzw. kadłubków (jeśli znasz termin Minimum Viable Product, to wyrzuć z tego terminu Viable i będziesz wiedział, co mam na myśli).



Teraz, po latach, wiem, że wszystko sprowadza się do stosowania właściwego narzędzia do właściwego problemu. Młotkiem śruby nie wkręcimy, prawda?



No cóż, te kilkanaście lat temu tego nie wiedziałem 🙂

Rozdział 2 - Firma przechodzi transformację
Organizacja, w której pracowałem uznała w końcu, że nie możemy strzelać z XVIII wiecznej armaty do nuklearnych łodzi podwodnych. Czas na zmianę podejścia.



Na co? Na podejście zwinne. Mieliśmy dzięki temu zacząć dostarczać jakościowe produkty, w sensownym czasie i budżecie. Zostałem Agile Project Managerem z misją - "Paweł idź i odkryj, o co w tym chodzi, a potem wróć z tą wiedzą do firmy i pomóż nam się zmienić".



No więc zacząłem się dokształcać. Kolejne certyfikaty (m.in. Agile PM, książki, kursy, warsztaty, meetupy). Setki godzin spędzonych na edukacji. I klasyczna sytuacja - im dalej w las, tym więcej drzew.



Jak to wszystko ogarnąć? Z czego korzystać?

Sprinty? Ale jakiej długości? Raz 2 tygodnie, raz 3 tygodnie, w zależności od potrzeb. Można tak?
Zakres? Ale czego? Sprintu? Projektu? Produktu? Czym te terminy się w ogóle od siebie różnią?
Story Pointy? A może manday'e? A tu kolega mi podpowiada, że jeszcze jakiś Kanban jest - tam w ogóle nie szacują wymagań...
Czy ten Scrum Master to taki Project Manager tylko z nową nazwą? A może coś jednak stoi na zapleczu tej nowej roli?
Po co nam Product Owner? Przecież to Scrum Master koordynuje pracę Zespołu, nie?
Zaraz zaraz... czy oni nie mieli sami zarządzać swoją pracą?


I tak w kółko. Starałem się łączyć dwa światy, które są ze sobą sprzeczne - podejście projektowe i zwinne. Wtedy nie wiedziałem, że to zadanie niemożliwe.




Rozdział 3 - Światełko w tunelu
"Wystarczy, że odpowiesz sobie na jedno bardzo, ale to bardzo ważne pytanie. Co lubię w życiu robić?" - Chłopaki Nie Płaczą



Ten film to klasyk mojego pokolenia, a to pytanie to pytanie, które na pewnym etapie życia uderzyło mnie z całą swoją mocą.



Pamiętam to jak wczoraj - z dnia na dzień dowiaduję się, że Product Manager, z którym pracowałem odchodzi. Szybkie spotkanie z wiceprezesem - "Paweł wchodzisz w to? Chcesz spróbować?". Równolegle pojawia się okazja, żeby przejść do innej organizacji i pracować stricte procesowo, jako Scrum Master.



Co zrobić?

Wiceprezes podpowiada: "Paweł, wyobraź sobie siebie 6 tygodni od teraz. Są dwa scenariusze. Budzisz się rano i wiesz, że jesteś Product Managerem naszego głównego produktu, albo jesteś Scrum Masterem i wspierasz organizacje w transformacji procesu wytwórczego. Co daje Ci więcej satysfakcji?"



Weekend na przemyślenia. Mam okazję poświęcić się w pełni jednemu zagadnieniu. Taka okazja może się nie powtórzyć. Nie będę już musiał żonglować między rolami Project Managera, Scrum Mastera, Product Ownera, etc.


Rozdział 4 - From Good To Great Servant Leadership
Początki w roli Scrum Mastera były trudne. Niby człowiek się określił, mgła się rozproszyła, jest jasność, ale rzeczywistość okazała się bardziej złożona niż zakładałem.



OK, Zespół ma sam organizować swoją pracę. Tyle teorii, ale jak do tego doprowadzić?
Zespół ma mieć komplet kompetencji, żeby co Sprint wytwarzać wartość, ale co to konkretnie znaczy? Czy jak wysyłamy rezultaty naszej pracy do zewnętrznego działu Quality Assurance to nie jesteśmy zwinni?
Czym w ogóle jest wartość? Jak ją zwymiarować? Czy chodzi o wytwarzanie jak najszybciej jak najwięcej rzeczy, czy jednak jest tam jakieś drugie dno?
Czy Scrum to po prostu kolejna metodyka organizacji pracy? Czemu wszyscy tak podkreślają ten empiryzm, który stoi u jego podstaw?


Na własnej skórze przerobiłem wszystkie dysfunkcyjne postawy Scrum Mastera. Byłem zespołowym asystentem ("Przynieś, podaj, zanotuj”), administratorem JIRY ("Weź nam to przesuń do odpowiedniej kolumny”, koordynatorem („Mariusz, czym będziesz się dzisiaj zajmował?”), superbohaterem („Kochani, załatwiłem Wam tę kanapę, o którą prosiliście!”) oraz policjantem („Moi drodzy, minęło 15 minut, wychodzimy z Daily!”).


Wiem, wiem, nie są to powody do dumy. Ale jak to mawiali moi rodzice - „jak się nie przewrócisz, to się nie nauczysz”.



A nauczyłem się całkiem sporo. Z biegiem czasu zacząłem rozumieć swoją rolę, działać jak prawdziwy lider, który służy swojemu Zespołowi oraz organizacji, usuwa przeszkody, edukuje innych w zakresie zwinności.


Rozdział 5 - Trener
Droga Scrum Mastera, to droga permanentnej edukacji, rozwoju, wychodzenia ze strefy komfortu, kwestionowania status quo i, przede wszystkim, nauki na błędach.



Mnie ta droga na pewnym etapie zaprowadziła do szkolenia innych. Co ciekawe - to nie był mój pomysł. Jeden z kolegów zasugerował, że skoro idzie mi tak dobrze jako Scrum Masterowi, to szkoda byłoby nie podzielić się tą wiedzą i doświadczeniami z innymi.



Dwa lata trudnego procesu akredytacji. Setki godzin spędzonych na uzupełnianiu wiedzy, kolejne szkolenia, certyfikacje, wspólne przygotowania z innymi kandydatami i wreszcie sukces. W czerwcu 2021 roku przeszedłem przez tzw. peer review (moment, w którym pozostali trenerzy z organizacji Scrum.org weryfikują, czy mogę dołączyć do ich grona i uczyć innych) za pierwszym razem!