Dlaczego Scrum może zaszkodzić produktowi?

A teraz prędko

Scrum jako narzędzie optymalizację procesu wytwarzania oprogramowania jest świetne. Pozwala na lepszy podział pracy, zwiększa zaangażowanie osób tworzących rozwiązania, przyspiesza rozwiązywanie problemów w zespole developerskim, zwiększa przejrzystość realizowanych zadań, zmniejsza luki komunikacyjne pomiędzy developerami a biznesem. Scrum poświęca opasłą dokumentacje na rzecz optymalizacji komunikacji i umożliwia szybką adaptację do zróżnicowanych problemów oraz efektywniejsze reagowanie na zmiany niż podejście kaskadowe.

Scrum jest również bardzo pomocny z perspektywy tworzenia produktu, w szczególności w skostniałych strukturach dużych firm, które nie przywykły do bardzo dynamicznego i nieprzewidywalnego trybu pracy jakie wymusza praca nad rozwiązaniami technologicznymi. Z narzędziami takimi jak backlog (lista zadań do realizacji), wymaganiami w postaci user story, które zawierają informacje co użytkownik chcę wykonać, zmniejszeniu wielkości zadań i iteracyjnym ich wdrażaniem świetnie wspiera ewolucyjne podejście do tworzenia produktów i ich testowania

Niestety Scrum nie jest metodyką do tworzenia produktów i wraz z nim idą także bardzo ważne zagrożenia. Scrum umożliwia szybsze dostarczenie rozwiązania i daje złudne poczucie, że tworzy się wartość dla klientów. Scrum daje także dwa wskaźniki, które dla niedoświadczonych Product Owner’ów są łatwymi miernikami złudnego wzrostu: liczba wdrożonych funkcjonalności oraz prędkość realizacji zadań w sprincie (1 iteracja zespołu developerskiego) tzw. Velocity. Te dwa wskaźniki z perspektywy produktu nic nie wnoszą i można byłoby je dodać do innych miernych wskaźników (Vanity metric) rozwoju produktu jak choćby liczby odsłon.

Jeśli wykorzystujesz te dwa wskaźniki analizując jak się Twój produkt rozwija proszę przestań:) dla dobra Twojego i Twojego zespołu. Dla osób zainteresowanych na jakich wskaźnikach warto się skupić polecam: Lean Analytics: Use Data to Build a Better Startup Faster

Link do zdjęcia: http://memy.pl/mem_620814_teraz_predko

  • http://scrum-master.pl Bogdan

    Velocity może być wykorzystywane do dwóch rzeczy: a) do prognozowania terminu zakończenia pewnego zakresu prac, np. najbliższego wydania; b) jako dana historyczna pomocna przy prognozowaniu ilości pracy, jaką zespół może wybrać na najbliższy sprint.

    Najcięższy grzech, z jakim się zetknąłem, a który dotyczy wypaczonego spojrzenia na velocity, to pokusa, żeby wykorzystywać to do mierzenia produktywności zespołu. Ale nikt przy zdrowych zmysłach (nawet początkujący Product Owner) nie używa velocity jako KPI do mierzenia dostarczanej wartości. Podobnie z liczbą zaimplementowanych funkcjonalności.

    Stwierdzenie, że Scrum może zaszkodzić produktowi, to tak, jakby powiedzieć, że jazda samochodem może zaszkodzić twojej podróży, bo jadąc nie w tym kierunku, co trzeba, możesz oddalić się od celu.

    Piszesz jeszcze, że Scrum nie jest metodyką do tworzenia produktów. Zgoda, bo rzeczywiście Scrum metodyką nie jest. Scrum tworzy jedynie ramy (framework) do rozwijania i utrzymywania złożonych produktów. Celem Scruma nie jest szybsze wykonywanie jakiejś pracy, a umożliwienie szybszego uczenia się dzięki skróceniu pętli informacji zwrotnej i podejmowaniu decyzji na podstawie empirycznych danych.

    • Adam Michalski

      Niestety ja się spotkałem z tym, że głównymi wskaźnikiami na jakie zwracał uwagę Produkt Manager były wskaźniki związane z tempem realizacji zadań w projekcie i liczbą dodanych funkcjonalności. Wiem, że takie zachowanie może być nie tylko związane z postradaniem zmysłów, ale jest pewną konsekwencją braku wiedzy i wpływu kultury firmy w jakiej dana osoba pracuję.

      Jeśli potraktujesz SCRUM jako narzędzie do zarządzania produktem i potraktujesz samo tworzenie funkcjonalności jako budowanie wartości produktu to SCRUM może zaszkodzić produktowi. Oczywiście jako samo narzędzie jest niewinne ponieważ ktoś popełnił błąd i wykorzystuje to narzędzie nie do tego do czego zostało stworzone (o czym pisze w tekście). Co nie zmienia faktu, że warto przypominać o tym, że choć SCRUM jest super to nie rozwiąże wszystkich problemów.

      Twój przykład z samochodem nie odnosi się do treści mojego wpisu. Piszę, że SCRUM nie zastąpi zarządzania produktem i to, że potrafimy szybciej jechać samochodem nie znaczy, że nie musimy patrzeć na mapę i sprawdzać czy jedziemy w dobrym kierunku.

  • http://scrum-master.pl Bogdan

    Domyślam się, że Twój przekaz miał być taki, że na podstawie szybkości pracy zespołu nie można wnioskować, czy produkt rozwija się w dobrym kierunku, czy nie. Z tym się zgadzam.

    Jeżeli miałeś do czynienia z taką sytuacją, to jest to wypaczone spojrzenie na Scruma i rzeczywistej przyczyny takiej sytuacji szukałbym we wspomnianych przez Ciebie braku wiedzy i kulturze organizacyjnej.

    Natomiast wydźwięk Twojego wpisu obecnie jest taki, że przyczyną jest Scrum sam w sobie, że stanowi on zagrożenie dla produktu i lepiej go nie używać.

    W przykładzie z samochodem miałem na myśli dokładnie to, o czym piszesz. Nie wystarczy jechać, trzeba wiedzieć, gdzie się jedzie. Nie można jednak winić samochodu za to, że kierowca nie patrzy na ani na mapę, ani na drogę, a tylko na prędkościomierz. A taki jest niestety wydźwięk Twojego wpisu.

    (Przykład z autem może nie do końca udany, bo Scrum nawet każe przystawać co chwila i weryfikować kierunek jazdy. Jednak jeśli ta zasada jest ignorowana, to znowu przyczyny trzeba szukać w braku wiedzy albo w ignorancji kierowcy, a nie winić samą zasadę za to, że nie jest przestrzegana.)

    Scrum nie zastąpi zarządzania produktem. Nic nie zastąpi. Ale można użyć Scruma do zarządzania rozwojem produktu, bo do tego służy. Każe określić, czym jest wartość, jak ją mierzyć, założyć, jak ją można dostarczać, zacząć to robić, a w krótkich odstępach czasu weryfikować, czy rzeczywiście wartość jest dostarczana i odpowiednio dostosowywać działania w celu optymalizacji dostarczanej wartości. Czym jest wartość i jak ją mierzyć oraz jak wykorzystać Scrum w zarządzaniu produktem to najważniejsze elementy szkolenia dla Product Ownerów.

  • http://scrum-master.pl Bogdan

    Po przemyśleniu doszedłem do wniosku, że użycie innego przykładu może Ci unaoczni problem, jaki mam z Twoimi stwierdzeniami. Pozwól, że sparafrazuję fragment Twojej wypowiedzi:

    „Dlaczego podróżowanie samochodem może zaszkodzić Twojej podróży?

    Niestety podróżowanie samochodem nie jest sposobem na podróże i wraz z tym idą także bardzo ważne zagrożenia. Podróżowanie samochodem umożliwia szybsze poruszanie się i daje złudne poczucie, że zbliżamy się do celu podróży. Podróżowanie samochodem daje także dwa wskaźniki, które dla niedoświadczonych podróżników są łatwymi miernikami złudnego zbliżania się do celu: liczba przejechanych kilometrów oraz prędkość.”