Często ludzie pytają nas, czy praca Product Ownera to praca na 100%? Przecież PO odpowiedzialny jest „tylko” za Backlog, jak może to zajmować więcej niż jedną godzinę dziennie? Wy pytacie, ja mówię – sprawdzam!

Gdybyśmy mieli zdefiniować składniki niezbędne do tego, aby nasze scrumowe przedsięwzięcie się powiodło, byłby to zupełnie inny zestaw niż ten opisywany w Scrum Guide. Ale czy na pewno?

Jak długo Scrum będzie pozostawał aktualny? Kiedy zastąpią go inne frameworki albo kiedy firmy w ogóle zrezygnują z Agile? I co wtedy będą robili Scrum Masterzy? Te wszystkie pytania mogą być  bardzo martwiące, szczególnie dla tych osób, których kariera oraz zarobki są związane ze Scrumem. Spróbujmy więc na te pytania odpowiedzieć i zobaczyć, czy musimy Czytaj dalej…

Mieliśmy taki okres na naszym blogu, kiedy publikowaliśmy dużo tekstów opisujących najczęstsze pomyłki, największe błędy i innego rodzaju listy. Dziś wracamy do tego z listą trzech największych błędów popełnianych przy tworzeniu Zespołów Scrumowych.

Są problemy mniejsze i większe. Istnieją też problemy ogromne, które sprawiają ludziom, zespołom oraz firmom tyle kłopotów, że żyć się odechciewa. Opowiemy Wam dziś o najogromniejszym problemie ze Scrumem, czy też raczej – z jego wprowadzaniem.

Zastanawiam się, skąd się bierze mylna i błędna „własna” interpretacja Scruma, która jest tak powszechna. I chociaż na pewno nie znajdę jednej przyczyny, to mam pewien pomysł, skąd się to wszystko bierze.

Bardzo mało zespołów posiada Cel Produktu. Jeszcze mniej ma Cel Sprintu. Moim zdaniem obie te rzeczy są ze sobą powiązane. Stawiam nawet śmiałą tezę, że nie masz Celu Sprintu, bo brakuje Ci Celu Produktu.

Mówi się że wszystko co nowe, to zapomniane stare. Jeżeli uznamy to powiedzenie za prawdę, to musi ono dotyczyć również i Scruma, którego oficjalna historia liczy 20 lat. Czy może być tak, że ten framework istniał dużo wcześniej? I, co ważniejsze, jak odpowiedź na to pytanie pomoże nam budować lepsze zespoły dzisiaj?

Założeniem Scrum jest stwierdzenie, że jeden Produkt to jeden Product Backlog. Nawet patrząc z punktu widzenia nazwy – lista wymagań dotyczy produktu (Product) a nie produktów (Products). Dlaczego więc można spotkać konstrukcję zawierającą jeden Backlog i wiele różnych Produktów?

Testy w Scrum? To jak wkładanie kija w mrowisko. Przecież zespoły tylko robią robotę, a testuje klient, zewnętrzni testerzy albo w ogóle ktoś jeszcze inny. Tylko czy tak naprawdę powinno być i czy to jest dobry pomysł?