Scrum: Co jeśli właściciel produktu ma zadania?

Właśnie zacząłem współpracować z zespołem, który wychwycił niektóre aspekty Scrum (dwutygodniowe timeboxing), ale nie inne (zespół nie zgadza się obecnie na wszystkie prognozy lub liczbę punktów w sprincie, ale zmienię to wkrótce.) Właściciel produktu jest również zasobem technicznym (naukowcem) z pewnym doświadczeniem rozwojowym.

Czy właściwe jest, aby zadania właściciela produktu (obejmujące głównie badania) były połączone z zadaniami zespołu (niektóre z nich to badania i niektóre prace rozwojowe).

Eksperci w Scrumie bardzo stanowczo twierdzą, że Właściciel produktu i Scrum Master powinny być dwiema różnymi osobami. Jednak nie ma takiej zasady wykluczającej z Zespołu programistów. Uwaga w przewodniku Scrum :

Wielkość zespołu programistów

Optymalny rozmiar zespołu programistów jest wystarczająco mały, aby pozostać zwinny i wystarczająco duży, aby wykonać znaczącą pracę. Mniej niż trzech członków zespołu programistów zmniejsza interakcję i powoduje mniejszy wzrost wydajności. Mniejsze zespoły programistyczne mogą napotykać ograniczenia umiejętności podczas Sprintu, przez co zespół programistów nie jest w stanie zapewnić potencjalnie możliwego do uwolnienia Przyrostu. Posiadanie więcej niż dziewięciu członków wymaga zbyt dużej koordynacji. Duże zespoły programistyczne generują zbyt dużą złożoność, aby zarządzać procesem empirycznym. Role właściciela produktu i Scrum Master nie są uwzględniane w tej liczbie, chyba że wykonują one również pracę Backlogu Sprintu.

Następstwem tej ostatniej linii byłoby to, że jeśli Właściciel Produktu wykonuje pracę Backlogu Sprintu, jest on liczony jako członek Zespołu Programistycznego.

To powiedziawszy, rób wszystko, aby dobrze wykonać swoją pracę.

Właściciel produktu jest odpowiedzialny za maksymalizację wartości produktu i zwrot z inwestycji. Może się to wydawać proste, ale zazwyczaj jest to pełnoetatowa i bardzo wymagająca rola - prawdopodobnie najtrudniejsza w Scrumie. Wymaga to dużej ilości strategicznej pracy na wysokim szczeblu, a także zadań na niższym poziomie, od analizy możliwości rynkowych i konsultacji z zainteresowanymi stronami i użytkownikami produktu w celu podjęcia właściwych decyzji, po zawsze dopracowanie mapy produktu i zaległości, uczestnictwo w planowaniu i przeglądać działania, udostępniając się zespołowi, aby odpowiedzieć na ich pytania itp.

Jeśli OP jest odpowiedzialny za inne zadania poza tym, w większości przypadków postrzegam je jako marginalne. Moja odpowiedź brzmi: tak, stwórz zadania dla PO, jeśli naprawdę musisz i jeśli przyczyniają się one bezpośrednio do wytworzenia przyrostu oprogramowania sprintu, ale nie widzę tego często w twoim przeciętnym projekcie Scrum.

Scrum zajmuje się przede wszystkim komunikacją i wykonywaniem prac, które są istotne i terminowe. Wszystko, co pozwala osiągnąć ten cel, jest w porządku, jeśli dzięki temu Twój zespół może być najbardziej produktywny.

Trudno jednak dobrze sobie radzić. Jestem teraz na tej pozycji i trudno mi poświęcić odpowiednią ilość czasu jako właściciel produktu, jednocześnie pozostawiając czas na rozwój. Jednak w tym momencie układ działa dobrze dla tego konkretnego zespołu. Powrócimy do decyzji, by wycofać się z podwójnego obciążenia, gdy spadnie nasza wydajność, ale do tego czasu będziemy dalej pracować w ten sposób.

Więc spróbuj. Rób retrospektywy, aby stale ulepszać swój proces. Nie pozwól, aby trzymanie się wcześniej niektórych metod utrudniało wydajność Twojego zespołu.