Definicja wrzuty
Niemiłe stwierdzenie na daną osobę:
– Twoje zęby są jak gwiazdy: żółte i porozrzucane.
– Ale ci sypnął wrzutę*
albo:
Malunek graffiti.
– Znowu zamalowali nam wrzutę na budzie…*
* źródło: https://www.miejski.pl/ 😉
Tak czy inaczej, określenie ma raczej wydźwięk pejoratywny i odnosi się do czegoś niemiłego, a z naszej perspektywy najczęściej do zadań, które różni interesariusze próbują podrzucać do zespołów, aby zrealizować swoje (często nagłe) potrzeby, przy okazji burząc ustalony już wcześniej plan.
Jak sobie z tym radzić i czy faktycznie jest to takie złe? Kto i kiedy może zmienić zakres trwającego Sprintu?
Czasem może pojawić się konieczność rezygnacji z wymagania lub wymiany zadania na inne. Zmiana zakresu Sprintu może nastąpić z inicjatywy Product Ownera lub Zespołu Deweloperskiego. Taka propozycja jest omawiana i wszyscy muszą być świadomi, jakie mogą być jej konsekwencje, a ostateczną decyzję o zmianie podejmuje cały Zespół Scrumowy.
W trakcie Sprintu Product Owner może dowiedzieć się, że konkurencja kończy działalność lub wypuściła nową ofertę, na którą trzeba zareagować. Może się również zdarzyć, że Zespół przy okazji pracy nad wymaganiami odkrywa nowe zależności i ich realizacja jest niezbędna, by osiągnąć Cel Sprintu. Czasami mamy awarię, która wymaga szybkiej reakcji i ugaszenia pożaru, może też pojawić się interesariusz z zewnątrz np. architekt innego zespołu potrzebujący wsparcia, Security Officer ze znalezioną groźną podatnością w aplikacji, Product Owner innego zespołu potrzebujący jakiejś zmiany w kodzie związanej z wymaganiami w swoim obszarze, kolega z innego zespołu z problemem technicznym lub członek Zarządu z nowym pomysłem na funkcjonalność… itp.
Przy zmianie zakresu Sprintu kosztem “wrzuty” warto pamiętać, żeby – jeśli nie ma już innej możliwości – usuwać z niego zadania, w których nie została wykonana jeszcze praca i które mają możliwie podobny (do wrzuty) stopień złożoności lub/oraz podobną wartość biznesową. Pamiętajmy, że najważniejsze tutaj zawsze będzie zakomunikowanie swoich planów (i to na wszystkich możliwych płaszczyznach, tj.: wśród zainteresowanych Product Ownerów, deweloperów itd.).
W każdym z tych przypadków, pod żadnym pozorem, nie należy od razu wyciągać Przewodnika po Scrumie, Dekalogu Programisty, Kodeksu drogowego, regulaminu Facebooka czy innej “tarczy”, po użyciu której osoba potrzebująca pomocy zostałaby w pierwszym momencie odesłana z kwitkiem, bo proces na to nie pozwala. To nie jest prawda! Nie jest niczym złym dorzucenie czegoś w trakcie Sprintu, nawet zmiana priorytetów, jeśli stoi za tym jakiś istotny interes firmy.
Podobna sytuacja dotyczy konsultacji. Poświęcenie kilku minut na wysłuchanie interesariusza: czego potrzebuje, na kiedy i dlaczego może często rozwiązać np. problem klienta który czeka na coś bardzo długo – albo przynajmniej pozwoli ustalić plan na później, co w efekcie nie musi od razu oznaczać przerwania sobie pracy, Sprintu czy tytułowej wrzuty. Pamiętajmy: Ludzie i interakcje ponad procesy i narzędzia.
Wielokrotnie byliśmy świadkami zmian w trakcie zaplanowanej pracy i kluczowy jest tutaj – tak jak wspomniane zostało to wcześniej – sposób komunikacji, a w przypadku, gdy zmiany próbuje wprowadzać ktoś inny niż Product Owner zespołu, upewnienie się, czy taka osoba omawiała z nim ten temat. Jeśli nie, to inicjujemy spotkanie między nimi, aby wyjaśnić wszelkie wątpliwości.
W naszej organizacji zadbaliśmy o dystrybucję roadmap, których jednym z zadań jest przejrzyste pokazanie firmowych priorytetów, dzięki czemu podczas dyskusji na temat potencjalnej wrzuty do zespołu można się do nich odnieść.
Dlatego tak ważne jest też, aby każdy zespół miał aktualną (w perspektywie kwartału) swoją roadmapę. To interes całego zespołu, nie tylko Product Ownera. Bez posiadania planu, wszystko będzie można nazwać wrzutą, a takiego chaosu nie chcemy 😉
Podsumowując, wszystko zależy od perspektywy, nastawienia, czy nawet postawy różnych osób w danym momencie.
Pamiętajmy, żeby zawsze myśleć globalnie, z perspektywy całej firmy, a nie tylko swojego zespołu, szczególnie gdy kusi nas odesłać każdego, kto zawraca nam głowę, gdzie pieprz rośnie…
Jak napisano w manuskrypcie:
Bądźcie gotowi na zmiany wymagań
nawet na późnym etapie jego rozwoju.
Procesy zwinne wykorzystują zmiany
dla zapewnienia klientowi konkurencyjności.
Celem nie jest przecież sama praca dla pracy, ale dla ciagłego rozwoju i konkurencyjności produktu.
A Wy – jakie macie problemy z wrzutami i jak je rozwiązujecie? Nie zapomnijcie podzielić się doświadczeniami w komentarzach.