Dziwne to stanowisko - agile coach. W przypadku Scruma to scrum master ma uczyć organizację zwinności. Lecz gdy organizacja nie ma doświadczonych scrumasterów, to zatrudnia sobie konsultanta z zewnątrz, który dla niepoznaki nazywa się agile coach.
Pech chciał, że organizacje podłapały to proste rynkowe rozwiązanie i zrobiły z tego ścieżkę kariery. Jedna, którą widziałem, zaczynała się od team member, potem można było zostać scrum master, następnie agile coach. Za kołczem było już ciekawiej, gdyż można było się "rozwijać" jako agile evnagelist bądź też change agent. Patrząc na te nibyścieżki nibykariery wymyśliłem kolejne dwa poziomy: the awakener oraz budda. Co tu się wyrabia? Nie pojmuję.
Zatem nie lubię nazwy agile coach. Bo po pierwsze to nie agile a raczej agility, a po drugie nie to coach a raczej to instruct. Gdy trzeba powiedzieć coś o adżajlu mówię, że jestem agility (technical) consultant - sam to wymyśliłem :)
Zapytaj inżynierów
Jesteś zatem agile coach i czym się zajmujesz tak na co dzień. Jakie czynności wykonujesz? Z palca powiem, że: prowadzisz szkolenia, warsztaty, startujesz zespoły, rozmawiasz to z tym to z tamtym, projektujesz metryki. Może też kołczujesz :)
Mam dla Ciebie kiler-test: zapytaj developerów co sądzą o Twojej pracy, czy jest dla nich pożyteczna? Jeśli nazywają cię kolorowym pisakiem albo gościem od karteczek, to wiedz, że odleciałeś. Straciłeś kontakt z ziemią i krążysz już na takiej orbicie, że zupełnie nie dostrzegasz przyziemnych problemów inżynierów.
Żebyśmy się dobrze zrozumieli, prowadzenie szkoleń czy startowanie zespołów to bardzo pożyteczne rzeczy, ale ustawianie i startowanie zespołów nie zmienia organizacji.
Procesy w zespołach nie są aż tak ważne
To, jakie procesy pracy są w zespołach, nie jest aż tak ważne. Jeśli w zespołach są kompetentni ludzie, to sobie poradzą i ogarną swój proces. Kompetencje są ważne. Na ludziach nie posiadających odpowiednich umiejętności nie zbuduje się samoogarniajacego się zespołu.
Ważna jest technologia dlatego, że zwinność to uzyskiwanie przewagi biznesowej dzięki technologii. Zespoły pracujące w monolicie, z ręcznym procesem deploymentu i całą masą legacy nigdy nie będą zwinne. Będą stale wykładać się o podstawowe rzeczy takie jak koszt wprowadzania zmian, kosztowne testowanie, liczba błędów na produkcji.
Najważniejsze jest to, co się dzieje między zespołami. To właśnie między zespołami dzieją się: walki o zasoby, niedogadanie, polityka, ciągnięcie w swoją stronę, itp.
Podstawowe zadanie kadry zarządzającej
Podstawowym zadaniem kadry zarządzającej jest deklaracja stałości celu odnośnie do poprawy jakości i uzyskiwania przewagi na rynku. Tego oczekują pracownicy oraz klienci. Jeśli cele są nie jasne, jeśli co chwila zmieniają się priorytety, to świadczy to o jednej z trzech rzeczy:
- nie znasz zasad, na podstawie których podejmowane są decyzje o priorytetach,
- jakość zarządzania jest bardzo słaba i skupia się na mikrozarządzaniu ludźmi,
- wspólny cel nie został nazwany i różne części organizacji ciągną we własne strony.
Ewentualnie dzieją się się wszystkie trzy rzeczy na raz.
Agile, Scrum, Kanban, LeSSy, esy, Impact Mapping, Event Storming i inne bazują na deklaracji stałości celu.
Trzy kluczowe obszary działania agile coacha
Z powyższej refleksji mamy zatem trzy kluczowe obszary działania dla agile coacha w organizacji:
- Deklaracja stałości celu odnośnie do poprawy jakości i uzyskiwania przewagi na rynku
- Sprawność technologiczna, która umożliwia zwinność
- Kompetencja pracowników
Te trzy wymienione rzeczy są warunkiem koniecznym zwinnej transformacji. Jeśli zostaną zapewnione, wszystkie inne sprawy się udadzą. Zatem jeśli agile coach zajmuje się czym innym niż te trzy, to jego pracę należy uznać za stratę. Nie oznacza to, że jest ona zła, lecz to, że nie prowadzi do celu - transformacji organizacji - i należy ją minimalizować. Maksymalizować zaś należy działania na rzecz: stałości celu co do jakości, sprawności technologicznej oraz kompetencji pracowników.
