Jak zostałem Mojżeszem Agile?

74

Jakiś czas temu rozpoczynałem współpracę z nowym zespołem. Cała ekipa już się w miarę dobrze znała – ostatnio przeszli przez wymagający projekt. Ja miałem być ich nowych Scrum Masterem i szczerze mówiąc nie mogłem się doczekać współpracy z nimi – mieli opinię świetnych specjalistów, a praca z takimi osobami jest zawsze ciekawa 🙂 (czytaj: niekoniecznie łatwa).

Zgodnie z naszym firmowym systemem ocen, powinienem był zdefiniować swoje oczekiwania w stosunku do całego zespołu i poszczególnych jego członków. Podchodząc do tematu „zwinnie”, chcąc zaangażować zespół w to ważne zadanie (w końcu oni też powinni zdefiniować swoje oczekiwania w stosunku do mnie i siebie nawzajem), zdecydowałem, że chcę zaproponować zespołowi jakiś inny sposób na definiowanie oczekiwań, coś czego jeszcze prawdopodobnie nikt nie robił.

Akurat w tym czasie wieczorami czytałem nową książkę Jurgena Appelo (#Workout) i natknąłem się na ciekawy rozdział „Work Profile and Project Credits”. Porusza on istotny temat tytułów w firmie, drabinek kariery, ról projektowych itp. Pojawia się z nim też pewna inspirująca myśl…

Job titles and project roles can have a significant impact on the clarity, branding, status, and behavior of employees.

Tak! Dokładnie tego szukałem! Chcąc zdefiniować swoje oczekiwania w stosunku do zespołu (oraz dać zespołowi narzędzie do zdefiniowania oczekiwań w stosunku do siebie) powinniśmy rozpocząć od rozmowy o tym w jakich rolach się widzimy. Tak więc mamy do czynienia z klasycznym przypadkiem „steal and tweak”, gdzie wykorzystując istniejące idee, konstruujemy coś nowego. Teraz wystarczyło tylko zbudować warsztaty dla zespołu oraz je przeprowadzić.

Forma warsztatów jest całkiem prosta:

  • Przedstawić uczestnikom teorię opisaną w książce Jurgena. Jedną z najważniejszych myśli jest to, że każdy z nas jest odpowiedzialny za budowanie własnej marki osobistej. Markę budujemy na różne sposoby, w pewnym stopniu również poprzez wpisywanie siebie w tytuły firmowe. Elementami najbardziej jednak wpływającymi na naszą markę osobistą są role, w które wcielamy się w projekcie. To one pokazują, czym się zajmowaliśmy, co było dla nas najważniejsze itp. To one też w kontekście naszego ćwiczenia posłużą za definicję naszych wzajemnych oczekiwań.
  • Każdy uczestnik wymyśla role dla innych (ale nie dla siebie!). Warto zaprezentować zespołowi kilka przykładów ról (poniżej).
  • Konfrontujemy role oraz wspólne oczekiwania podczas dyskusji oraz negocjacji. Jest to niezwykle istotny element całych warsztatów. Wszystkie wymyślone role muszą być jasne dla uczestników, każdy musi chcieć przyjąć daną rolę (Być może już w nią wchodzi? Być może chce się w tym kierunku rozwinąć?), możemy się wymieniać rolami, uzupełniać definicje itp. Istotna jest moderacja tej części warsztatu w kierunku:
    1. osiągnięcia konsensusu i dobrego zrozumienia ról oraz
    2. nie popadania w szczegółowe definiowane ról, które mogą ograniczyć zdolność zespołu do samoorganizacji.

Na zakończenie warsztatów powinniśmy otrzymać listę ról przypisanych do wszystkich członków zespołu. Lista ta pozwoli im budować swoją markę osobistą oraz pozwoli nam lepiej zarządzać wzajemnymi oczekiwaniami. Dodatkowo, lista może posłużyć jako tzw. „Project Credits” – poprojektowy artefakt wiszący w „hall of fame” na korytarzu w firmie. W naszym przypadku poszliśmy o krok dalej. Nasze role tak bardzo nam się spodobały, że nie mogłem się doczekać i powiesiłem je obok wejścia do naszego pokoju już teraz. Oto kilka przykładów ról (pogrubione role oznaczają te najważniejsze dla danego członka zespołu):

​​​Imię

Tytuł w firmie​

​Role

Kamil

(nieistotny)​​
  • Mojżesz Agile,
  • Strażnik Procesu oraz Doradca ds Procesu,
  • Pomocna Dłoń, oraz
  • Właściciel Spotkań, Mediator, Kapitan (kpt. Sowa), Specjalista do Spraw Niedeweloperskich, Organizator Pracy w Biurze

Natalia ​​

(nieistotny)​​
  • Nadzorca Jakości i Wymagań, oraz
  • Ewangelista Porządku, Strażnik Detali, Siewca Wiedzy Domenowej, Menadżer Testów Automatycznych, Tester Oprogramowania​

​Marcin ​

(nieistotny)​​
  • Obiektywny Obserwator,
  • Opiekun/Doradca Techniczny,
  • Całościowy Code Reviewer, oraz
  • Zarządca Chmury, Developer, Tester Oprogramowania, Build Master

I tak oto zostaFamily-Guy-4ACX30-Moses-Griffinłem Mojżeszem Agile 🙂 dodam, że zespół miał całkiem sensowne uzasadnienie tego dlaczego chcą żebym przyjął tą rolę. Spodobało mi się to, chcę to robić i chcę żeby w tym właśnie kierunku budowała się moja marka osobista.

PS Póki co za krótko pracujemy razem żeby ocenić jaki wpływ definiowanie ról miało na zespół. Podchodząc do ćwiczenia już na etapie warsztatów zauważyłem kilka istotnych korzyści, m.in. to, że całym zespołem omówiliśmy nasze doświadczenia z pewnymi rolami, zaś jako lider lepiej zrozumiałem, czego się obawiają, gdzie chcę się rozwijać a czego nie lubią. Już sama ta korzyść jest wg mnie wystarczającym argumentem za przeprowadzeniem tego ćwiczenia.

Może ci się spodobać również Więcej od autora

Komentarze

This site is using the Seo Wizard plugin created by http://seo.uk.net/