Znaleźć odpowiedniego Agile Coacha

W latach 2004 i 2005 coraz więcej zespołów przechodziło na metody zwinne i często na początku potrzebowały one oczywiście doradztwa i szkoleń. W wielu przypadkach musiałem jednak przyjeżdżać do firm po szkoleniach i porządkować bałagan pozostawiony przez trenerów. Błędnie zakładałem wtedy, że będzie to problem tylko tak długo, jak nowe zwinne zespoły – szczególnie w firmach tworzących oprogramowanie standardowe – będą jeszcze zdobywać doświadczenie. Niestety problem złych trenerów i coachów nie zniknął. Chociaż wiele firm zdecydowało się już na dobrych trenerów, moim zdaniem wciąż są oni raczej wyjątkiem.

Jak w przypadku wielu innych rzeczy, oczywiście to od klienta zależy, żeby znalazł najlepszego dla siebie trenera. Kiedy jednak zespół potrzebuje szkolenia, jest bardzo prawdopodobne, że ci, którzy muszą podjąć tę decyzję, nie mają jeszcze doświadczenia w tej dziedzinie. Celem tego artykułu jest pomoc firmom tworzącym oprogramowanie standardowe w znalezieniu odpowiednich trenerów i coachów metod zwinnych.

Różne czynniki przy poszukiwaniu odpowiedniego Agile Coacha

1. W większości przypadków oprogramowanie jest nadal tworzone na potrzeby wewnętrzne (IT) lub specjalnie dla konkretnego klienta. Dlatego wielu trenerów zwinnych nadal nie radzi sobie dobrze z firmami tworzącymi rozwiązania dla masowego rynku. Oczywiście nie chcesz być firmą, na której taki trener ćwiczy. Dlatego ważne jest, by wcześniej wiedzieć, czy potencjalny trener rozumie różnicę między IT (wewnętrznym), tworzeniem oprogramowania na zamówienie a tworzeniem oprogramowania standardowego.

2. W firmach tworzących oprogramowanie standardowe istnieją zupełnie inne role niż w przypadku innych rodzajów oprogramowania. Potencjalny trener musi rozumieć rolę product managera, marketingu produktu, zespołu User Experience, Interaction Designerów, Visual Designerów i badaczy użytkowników.

3. Trener musi wiedzieć, jak wygląda współpraca product managerów i projektantów UX z zwinnym zespołem deweloperskim. Trener powinien mieć osobiste doświadczenie z Dual-Track Agile (dwutorowym wytwarzaniem) – czyli z Product Discovery i Product Delivery.

4. W firmie programistycznej w pewnych przypadkach konieczne jest podejmowanie konkretnych zobowiązań i udzielanie wiarygodnych informacji o terminach zakończenia. Musi to odbywać się z integralnością, ze świadomością, że konwencjonalne roadmapy są często wypełnione pozycjami, które nie przynoszą klientowi realnej wartości. Trener musi więc rozumieć, jak podejmować takie zobowiązania i jak zarządzać nimi w zespole produktowym.

5. W zespołach deweloperskich tworzących oprogramowanie standardowe wizja produktu jest niezwykle ważna, by zapewnić kontekst i motywować zespół. Trener metod zwinnych musi zatem rozumieć kluczową rolę wizji produktu i strategii, a także to, jak łączy się to z Product Discovery i Delivery.

6. Przy oprogramowaniu wewnętrznym wielu trenerów metod zwinnych uważa, że jest całkiem szybko, gdy co dwa tygodnie Sprintu wypróbowują kilka pomysłów. Przy oprogramowaniu standardowym byłoby to jednak postrzegane jako niezwykle wolne. Upewnij się, że Twój trener zrozumiał, że szybkość jest niezwykle ważna dla innowacji i jak Dual-Track Agile pomaga nam walidować jak najwięcej pomysłów bez konieczności pisania kodu.

7. W organizacjach tworzących oprogramowanie standardowe istnieje ciągły cykl, w którym coś buduje się (prototypy i produkcja), mierzy wyniki, uczy się z nich i powtarza ten proces. Bardzo ważne jest, by trener rozumiał znaczenie tego cyklu oraz prototypów, analiz i testów A/B dla podejmowania decyzji, testowania i ciągłego uczenia się.

8. Pod względem kulturowym istnieje duża różnica między programistami w organizacji IT a tymi w organizacji tworzących oprogramowanie standardowe. Trener zwinny musi wiedzieć, że poziom doświadczenia i umiejętności programistów bardzo się różni i podejście musi być odpowiednio dostosowane. Wielu programistów ma znacznie więcej doświadczenia w tworzeniu prawdziwych produktów niż większość trenerów. Dlatego trenerzy z niewłaściwym nastawieniem mogą szybko zawieść, jeśli chodzi o zdobycie szacunku zespołu.

9. Kolejna duża różnica polega na tym, że zespół w organizacji IT musi spełniać potrzeby firmy. Zespół produktowy w organizacji tworzących oprogramowanie standardowe istnieje po to, by rozwijać rozwiązania dla klientów w sposób, który jest wykonalny i opłacalny dla firmy. To nie jest bez znaczenia. Trener musi rozumieć, że nie jest to organizacja usługowa nastawiona na zaspokajanie potrzeb firmy.

10. Ostatecznie kluczowe jest, że trener nie tylko rozumie firmy tworzące oprogramowanie standardowe, ale także wymagania i metody krytycznych dla biznesu usług SaaS (Software as a Service). Takie kwestie jak skalowanie, niezawodność, tolerancja na błędy, wydajność, monitorowanie i kontrola, automatyzacja testów oraz dług techniczny nie są już opcjonalne, lecz absolutnie konieczne. Ponadto przy tworzeniu oprogramowania standardowego nie ma miejsca na dogmatyczne i ślepe przestrzeganie procesów. Niektórzy ludzie lubią mylić w metodach zwinnych środki do osiągnięcia celu z samym celem. Jedynym celem, który naprawdę ma znaczenie, jest sukces produktu.

Podsumowanie

Wybierając trenera lub coacha metod zwinnych, pamiętaj, że firma, dla której pracuje, często nie jest tak ważna jak sama konkretna osoba. Sprawdź więc potencjalnego kandydata i dowiedz się, czy posiada on doświadczenie z firmami tworzącymi oprogramowanie standardowe, którego potrzebujesz.

Ogólnie rzecz biorąc, trener przyjeżdża do Ciebie, tłumaczy teorię i wyjeżdża. Coach natomiast faktycznie stosuje metody z Twoim zespołem w Twoim unikalnym środowisku.

Tekst pochodzi z bloga Marty'ego Cagana i został przez nas przetłumaczony na język polski.