9 pytań, które powinni zadawać Scrum Master i Product Owner
Zanim zostałem Scrum Masterem, pracowałem jako lider techniczny w wielu zespołach. Częścią tej pracy było podejmowanie decyzji – i myślę, że robiłem to całkiem dobrze. Zdecydowanie i asertywność to cechy mojego charakteru.
Jednak te cechy nie bardzo mi pomogły, gdy zostałem Scrum Masterem. Zdałem sobie sprawę, że aby odnieść sukces jako Scrum Master, muszę mniej stwierdzać, a zamiast tego więcej pytać. Ponieważ nie był to mój naturalny styl (i nie były to cechy, które przyniosły mi sukces do tego momentu w karierze), na początku było mi z tym trudno.
Ale z pewną cierpliwością coraz lepiej wychodziło mi zadawanie pytań. Chciałbym podzielić się z wami kilkoma moimi ulubionymi pytaniami. Większość pytań dotyczy zarówno Scrum Masterów, jak i Product Ownerów.
2 pytania o szacunki
Często potrzebuję przybliżonego szacunku od zespołu. Nie będę ich do niego przywiązywał. (Nie pytam tutaj o zobowiązanie. Szacunki i zobowiązania to nie to samo.) Naprawdę chcę jedynie przybliżonego szacunku. W takim przypadku jest to dobre pytanie:
„Nie potrzebuję szacunku. Ale gdybym miał o szacunek poprosić, jaka jednostka przyszłaby wam do głowy? Godziny, dni, tygodnie, miesiące czy lata?"
Tak, wiem, te jednostki mogą się pokrywać – kilka tygodni może być dłużej niż miesiąc. Ale szacunek taki jak „O, tygodnie, kilka tygodni." jest często wystarczający, żeby podjąć decyzję, co może też oznaczać decyzję, by poprosić zespół o nieco dokładniejszy szacunek.
W sytuacjach, gdy mam oficjalny szacunek od zespołu, często zadaję kolejne pytanie:
„Jak bardzo jesteście pewni swojego szacunku?"
Tutaj chodzi o sprawdzenie, jak pewny jest szacunek i czy członkowie zespołu są co do niego zgodni. Szacunek, co do którego zespół jest w 90% pewny, będzie dokładniejszy niż szacunek, co do którego zespół ogólnie nie jest bardzo pewny i gdzie opinie bardziej się rozchodzą.
Rozbieżności w zespole co do szacunku mogą być też wskaźnikiem tego, że zespół zbyt pochopnie ten szacunek podał. Niekoniecznie musi to być coś złego, ale powinno być jasne, że szacunek jest wtedy mniej pewny.
3 pytania o decyzje zespołu
Jako Scrum Master lub Product Owner, czasem chcesz poczuć, jak gruntownie zespół przemyślał jakąś decyzję. Oto trzy pytania, które często zadaję:
- „Jakie trzy inne opcje rozważyliście przed podjęciem tej decyzji?"
- „Co najgorszego mogłoby się stać, gdybyśmy kontynuowali w tym kierunku?"
- „Co musi pójść dobrze, żeby była to naprawdę najlepsza decyzja?"
Nie powinieneś może zadawać wszystkich trzech pytań naraz, ani też tych samych pytań przy każdej pojedynczej decyzji zespołu.
Ponadto jako Scrum Master lub Product Owner nie zadajesz tych pytań dlatego, że możesz unieważnić decyzję zespołu. Masz jednak prawo rozumieć, jak pewny jest zespół co do decyzji i czy byli co do niej zgodni.
Te pytania mają ujawniać tego rodzaju rozbieżności. Jeśli zapytasz „Co musi pójść dobrze, żeby była to naprawdę najlepsza decyzja?" i ktoś powie „Wszystko!", zazwyczaj oznacza to, że jest problem.
2 pytania o spotkania
Nie przepadam za spotkaniami. Gdybym stał na korytarzu, na którego jednym końcu byłaby gromada węży, a na drugim spotkanie, nie wiedziałbym, w którą stronę iść.
Dlatego staram się w miarę możliwości zminimalizować liczbę spotkań oraz liczbę uczestników. Na początku spotkania często zadaję następujące pytania:
- „Czy potrzebujemy każdego, kto tu jest?"
- „Kto jeszcze powinien być obecny?"
Pierwsze pytanie zadaje się, żeby sprawdzić, czy można obejść się bez kogoś. Często widzę zwinne zespoły, które nieco za bardzo przesadzają z pracą zespołową i współpracą. Członkowie zespołu mają wtedy wrażenie, że muszą uczestniczyć w każdym spotkaniu, nawet jeśli jest dla nich zupełnie nieistotne. Może to być na przykład deweloper JavaScript uczestniczący w spotkaniu dotyczącym tego, czy warto przejść na nową aktualizację dostawcy bazy danych.
Jeśli Twoi członkowie zespołu są nieco zbyt gorliwi w kwestii spotkań, podziękuj im za zaangażowanie we współpracę, ale jednocześnie daj im do zrozumienia, że nie muszą być na każdym spotkaniu. Ustal zasadę, że żaden członek zespołu nie powinien uczestniczyć w spotkaniu, jeśli nie może wystarczająco przyczynić się do spotkania lub czerpać z niego wystarczającej wartości.
(Tak, może to być nadużywane. W razie potrzeby może trzeba będzie wyjaśnić niektórym osobom, że nie oznacza to, że nie muszą już uczestniczyć w żadnym spotkaniu. Ostatecznie zespół jako całość powinien mieć prawo do przegłosowania decyzji jednej osoby o nieprzybyciu na spotkanie.)
Drugim pytaniem chce się ustalić, czy ktoś powinien być obecny, kto jeszcze nie jest. Choć nienawidzę spotkań (pewnie wolałbym węże), czasem musimy mieć więcej osób na spotkaniach.
W razie wątpliwości decyduj się na mniej spotkań i mniej osób, ale niektóre spotkania po prostu trzeba przeprowadzić – a te spotkania są jeszcze wartościowsze, gdy są na nich właściwe osoby.
1 pytanie do chodzenia po biurze
Szczególnie gdy pracuję jako Scrum Master, spędzam dużo czasu włączając się do rozmów w biurze. Jest to znane jako Management by Wandering Around (zarządzanie przez chodzenie). Na przykład gdy zauważam, że programista i tester prowadzą pozornie ważną rozmowę, czasem podchodzę do nich i sprawdzam, czy mogę im w czymś pomóc.
(Oczywiście nie należy tego robić za każdym razem, ani gdy wygląda to na prywatną rozmowę!)
Czasem rozmowy, które przypadkowo słyszę, są też wartościowe dla innych. Być może redaktor techniczny powinien wiedzieć o tym, co tester i programista zdecydowali. Dlatego pytam:
- „Czy ktoś jeszcze powinien o tym wiedzieć?"
Jeśli tak, oferuję podzielenie się tą informacją, jeśli jest to w mojej mocy. Jeśli nie, oferuję bezpośrednie dołączenie tej osoby.
1 pytanie na Daily Standupy
Na Daily Standupie patrzę na wykres Burndown zespołu i często zastanawiam się, jak zespół zamierza ukończyć wszystkie prace do końca Sprintu. Kiedy jednak pytam ten zespół, czy uda im się wszystko skończyć, są zazwyczaj bardzo optymistyczni.
Gdy uważam to za nierealistyczne, patrzę ponownie na wykres Burndown i pytam:
- „Czy wiecie coś, czego ja nie wiem?"
Być może w odpowiedzi usłyszę, że jeden z członków zespołu nie zaktualizował jeszcze swoich godzin w narzędziu zespołu. Albo ktoś wyjaśni, że co prawda są teraz trochę w tyle, ale czegoś się nauczyli i teraz wszystko znowu przyspiesza. (Rzadko uważam coś takiego za realistyczne, ale często to słyszę.)
Pytanie zespołu, co wiedzą, a ja nie, daje doskonałą okazję do synchronizacji założeń. Być może zakładają, że teraz wszystko znowu przyspieszy, a ja tak nie sądzę. Dlatego jest to świetne pytanie do ujawniania różnych założeń.
Podsumowanie: Pytania są lepsze niż stwierdzenia
Kiedy po raz pierwszy przyjąłem rolę Scrum Mastera, nic nie wiedziałem o sile pytań i przegapiłem wiele okazji, by dowiedzieć się więcej o moim zespole i jego pracy. Dopiero po dłuższym czasie odkryłem, że mogę się najwięcej nauczyć, zadając pytania i naprawdę słuchając odpowiedzi.
Mam nadzieję, że uznasz te pytania za tak samo pomocne jak ja.
Ten wpis pochodzi z bloga Mike'a Cohna i został przez nas przetłumaczony na język polski.
