30 kwietnia 2016
Maciej Wilmiński
Wierchuszka na przeglądach
Przegląd Sprintu (często błędnie nazywany: podsumowaniem lub demem) to spotkanie, które zrewolucjonizowało komunikację wykonawców (IT) z końcowym klientem oraz wymusiło po stronie IT sporą zmianę podejścia do swoich działań. Oto w stałym cyklu i już od samego początku pracy zespół deweloperski nie dość, że musi dostarczyć coś w pełni funkcjonalnego i wartościowego biznesowo, to jeszcze, wspólnie z Product Ownerem, ma za zadanie to zaprezentować. W efekcie klient ma okazję na bieżąco, w stałym cyklu, oglądać efekty prac i zgłaszać swoje uwagi czy propozycje co do dalszych kroków.
Z jednej strony spotkanie to stanowi dla zespołu świetną mobilizację – będąc swoistym Mieczem Damoklesa. Na koniec sprintu nie ma zmiłuj, coś trzeba opowiedzieć, coś pokazać, a zatem coś musi powstać i to coś musi działać i być zrealizowane w należytej jakości. Jeśli się nie uda, zespół sam będzie musiał stanąć oko w oko ze swoimi zleceniodawcami i mocodawcami, aby wyjaśnić, co się wydarzyło.
Z drugiej, stanowi bezcenną szansę na uzyskanie informacji zwrotnej na temat aktualnych efektów pracy zespołu, ujrzenie zadowolonego klienta, może nawet jakieś pochwały? Choć może być oczywiście i tak, że klient nie będzie specjalnie ukontentowany, wówczas powinien on zakomunikować co mu się nie podoba i dlaczego, a zespół powinien wychwycić z tego wskazówki do dalszej pracy, zmniejszając ryzyko stworzenia czegoś, czego klient nie chce. W obu przypadkach zespół zyskuje ocenę swojej pracy. Ma szansę ujrzeć, że komuś zależy na jego pracy, że ktoś na nią czeka, a czasem i nawet docenia.
W tym tekście chciałbym poruszyć temat obecności na Przeglądzie Sprintu tak zwanych “interesariuszy”. To dla nich wszak przegląd jest organizowany. Właśnie. Często popełnianym błędem jest organizowanie spotkania dla Product Ownera, na którym tenże “odbiera” kolejne wymagania, nierzadko będąc zaskoczonym końcowymi efektami. A przecież powinno się to odbywać w trakcie sprintu, na bieżąco. Nie tędy droga, pamiętajmy, że Product Owner tak naprawdę jest jednym z organizatorów i prezenterów tego spotkania.
Przeglądy sprintu powinny być otwarte, szeroko komunikowane, a wiedzieć o nich i przyjść na nie powinien móc każdy pracownik firmy. Powinniśmy jednak zadbać o to, co jest szczególnym zadaniem Product Ownera, aby na spotkanie zaproszeni zostali i pojawili się Ci, którym szczególnie bliskie jest to, nad czym zespół pracuje.
Właściwie, to kim są Ci interesariusze?
Jeżeli pracujemy bezpośrednio z klientem zewnętrznym – sytuacja jest prosta – musi on być obecny na każdym Przeglądzie i powinniśmy go organizować w takim czasie, aby klient znalazł na nie czas. Bez jego obecności spotkanie traci swoją podstawową wartość.
Inaczej jest jeśli pracujemy z klientem “wewnętrznym”, czyli dla innego działu organizacji, popularnego “biznesu”. Wówczas interesariusze to często tak zwana “wierchuszka” organizacji. Ludzie, których kalendarze wypełnione są po brzegi, którzy niespecjalnie mają wolny czas i nie lubią go marnować. Najczęściej są to: zarząd, dyrektorzy, kierownicy, przełożeni (vulgo: menedżerowie) czy wszyscy którym zespół i Product Owner pośrednio lub bezpośrednio powinni zdawać na bieżąco relację z tego, co się dzieje. Od samego początku powinniśmy zachęcać ich do udziału w spotkaniach, pokazując jakie są jego profity. O ile jednak bezpośredni przełożeni czy menedżerowie “średniego szczebla” powinni regularnie się na tych spotkaniach pojawiać, o tyle szczególnie ważne osoby zapraszajmy wówczas, kiedy ich obecność jest istotna, coś wniesie. Nie ma bowiem nic gorszego niż Gruba Ryba na spotkaniu, które w jego mniemaniu będzie stratą czasu. Która jest wyraźnie znudzona, zniecierpliwiona, będąca myślami gdzie indziej czy wręcz pracuje w trakcie spotkania nad czymś innym, stukając głośno w klawiaturę podczas, gdy ktoś prezentuje zrealizowane wymaganie. Będzie to bolesne i niełatwe doświadczenie dla zespołu, któremu uwadze na pewno to nie umknie, a w efekcie mocno odbije się na jego motywacji.
Zapraszajmy więc “poziom C”, Zarząd, Dyrektorów wtedy, kiedy zamykamy jakiś ważny etap, dodaliśmy kluczową funkcjonalność, produkt jest gotowy do wdrożenia albo stoimy przed jakąś ważną decyzją. Nie zawracajmy im głowy spotkaniem po każdym sprincie, kiedy często gotowy jest wyłącznie fragment funkcjonalności, będący tylko etapem ku oczekiwanemu efektowi. I zadbajmy o to, aby zaproszenie na spotkanie dostali oni z odpowiednim wyprzedzeniem, żeby nie stawać przed niepożądaną sytuacją, kiedy godzina czy wręcz data przeglądu jest dostosowana do wolnego okienka Ważnego Uczestnika.
Jeżeli już Ci interesariusze się pojawią, rolą Scrum Mastera jest dopilnować, aby spotkanie nie przebiegało w sztywnej, napiętej atmosferze i nie przerodziło się w spowiedź czy raport, a zachowało luźny, nieformalny charakter. Scrum Master musi też starać się, aby na spotkaniu nie było ważnych i ważniejszych. To bardzo trudne, szczególnie w firmach z dość formalnymi relacjami, niemniej jednak konieczne.
Dlatego szczególnie przed tymi pierwszymi spotkaniami, na początku Scrumowej drogi konieczne są indywidualne rozmowy z interesariuszami, aby wyjaśnić im po co jest to spotkanie i dlaczego są oni na nie zaproszeni. Różnie z tym bywa. Obserwowałem sytuację, kiedy Ważna Persona weszła na spotkanie w momencie ostatniego zdania wygłaszanego przez Product Ownera. Ważna Persona poprosiła Zespół Scrumowy o pozostanie w sali i powtórzenie przeglądu specjalnie dla niego…
Przy okazji Scrum Master powinien zadbać o to, aby Przegląd Sprintu zastąpił, na tyle, na ile to możliwe, “pisemne raportowanie” podsumowujące to, co się dzieje w zespole, nad czym trwają prace i na jakim są etapie. Precz z marnotrawstwem!
Nie ma nic lepszego dla Zespołu Scrumowego niż Przegląd Sprintu, kiedy efekty pracy są bardzo dobre, a w spotkaniu uczestniczą ważne persony z firmy lub klient, którzy potrafią odpowiednio docenić pracę, jaka została włożona. Ludziom rosną skrzydła, a ich motywacja rośnie niesamowicie. Takich właśnie Przeglądów życzę wszystkim naszym czytelnikom!