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?
Błahostka
Sprawa wygląda na błahą. Czepiają się, że w jednym Backlogu Produktu znajduje się więcej niż jeden Produkt. Czy komuś to przeszkadza? Tak, na przykład nam. A pisząc całkowicie poważnie – nie tylko przeszkadza, ale niesie za sobą całkiem poważne konsekwencje.
Wielokrotnie się przekonałem, że nie można oceniać książki po jej okładce. Tak samo nie można jednoznacznie ocenić, czy ujęcie wielu Produktów w jednym Backlogu jest dobre czy złe. Gdybyśmy byli purystami odpowiedzielibyśmy „Tak być nie może!”. Taka sytuacja to zawsze konsekwencja pewnych decyzji i warunków, które spowodowały konieczność ujęcia naszych prac w taki a nie w inny sposób.
Jedna rzecz, którą na pewno możemy napisać to, że będzie miało to swoje konsekwencje. Kilka pozytywnych i wiele negatywnych, niestety.
Pozytywne konsekwencje
Tą pozytywną konsekwencją wrzucania prac dotyczących kilku Produktów do jednego Backlogu jest fakt, że cała praca Deweloperów przechodzi przez jedno miejsce. Czyli dzieje się dokładnie tak, jak mówi nam Przewodnik Scrum. Ten aspekt akurat zawsze będziemy wspierać zero-jedynkowo, bo wydaje się, że to jedyny dobry sposób na organizację pracy. Jako zespół mamy jedno źródło prac i zawsze mamy tylko jedno najważniejsze wymaganie, które aktualnie czeka na realizację. Nie musimy się zastanawiać!
Posiadając wszystkie wymagania w jednym miejscu łatwiej jest nam je również priorytetyzować. W jednym miejscu, bez potrzeby tworzenia Backlogu Backlogów widzimy, jakie są priorytety prac wszystkich Produktów rozwijanych przez te konkretne zespoły. Czy ta informacja jest pożyteczna dla Deweloperów?
Cześć z nich może też stwierdzić, że i tak są „wypożyczani” z Zespołu do Zespołu i ze Sprintu na Sprint. Nie będą musieli być więc wypożyczani, jeśli wszystkie prace będą znajdować się w jednym Backlogu. Temat ten poruszymy w jeden z kolejnych poniedziałków kiedy to wrzucimy nowy odcinek na naszego #białkowego vloga pod tytułem „Stabilność zespołu”!
Na podstawie swojego doświadczenia mogę stwierdzić, że z tych pozytywnych konsekwencji to by było na tyle. Skoro wiemy już, co nam to może dać na plus, spróbujmy sprawdzić, jakie czekają na nas problemy.
Konsekwencje negatywne
Do negatywnych konsekwencji umieszczania kilku Produktów w jednym Backlogu na pewno zaliczymy fakt, że ludzie, którzy tworzą Zespół wcale tym Zespołem nie są. Mamy oto zbiór ludzi, których łączy to, że pracują nad jednym Backlogiem Produktu lub co gorsza, pracują w jednym departamencie lub dla jednego Product Managera. Gdy zapyta się ich, czy są zespołem potwierdzą, ale na Daily zobaczymy dobrze znaną sytuację, w której jedna osoba mówi, a reszta jej po prostu nie słucha. Nie jest to przejaw braku szacunku. Po prostu te osoby nie mają ze sobą nic wspólnego. Praca jednej osoby nie wpływa w żaden sposób na pracę innych.
Drugą kwestią, związaną z takim ujęciem pracy jest fakt, że nie zawsze jest praca dla wszystkich Deweloperów. Ujęcie więcej niż jednego produktu przy mocno specjalizowanych Deweloperach może doprowadzić do sytuacji, w której część Sprintów będzie dla niektórych Deweloperów okazją do samokształcenia (czytaj: bardzo często do nieefektywnego przepalania godzin). Zamiast pracować nad nowym Przyrostem siedzą i czekają, aż przyjdzie pora na ich elementy Backlogu. Jest on przecież ułożony w kolejności, począwszy od tych najważniejszych.
Trzecią konsekwencją, która trochę próbuje mitygować poprzednią, jest konieczność rozszerzanie kompetencji w Zespole. Potrzeba poszerzania wiedzy jest naturalną konsekwencją sytuacji, w której z jednej strony mamy mocno wyspecjalizowane jednostki, a z drugiej dobrze zarządzany Backlog. Jest z tym jednak problem: nie każdy chce się uczyć i nie każdy jest skory oddać swoją wiedzę innemu. Prowadzi to do niesnasek, pogorszenia atmosfery w zespole i wzajemnych podejrzeń. Stać nas na to?
Jeden Backlog i wiele Produktów
Jak napisałem na początku, świat nie jest czarno biały i nie można oceniać go wyłącznie w tych barwach. Zastanawiając się nad przyczyną ujęcia wielu Produktów w jednym Backlogu należy zwrócić uwagę na szereg aspektów organizacyjnych i ludzkich.
Może być tak, że w ramach naszej organizacji posiadamy jednego Product Ownera (Prezes?), który zna się doskonale na wszystkim. Albo takiego, przez którego muszą przechodzić wszystkie decyzje co do rozwijanego Produktu. Taki PO nie będzie miał czasu, aby biegać za trzema czy czterema Backlogami, a jego punktu widzenia jeden jest wystarczający.
Może być też tak, że na rynku nie ma bądź nie stać nas na doświadczonych deweloperów. Wtedy, chociaż chcielibyśmy, nie mamy kim zrobić zespołu zajmującego się wyłącznie jednym produktem. Zamiast sześciu zespołów produktowych, warunki pozwalają nam mieć jeden bądź dwa. I wtedy każdy z nich będzie zajmował się kilkoma produktami. Z definicji będzie miał tez jeden Backlog.
Kolejną z przyczyn może być ta, o której wspomniałem już powyżej – brak domenowych ekspertów w roli Product Ownerów. Mamy ich mało, ich praca jest limitowana, więc chcąc im ułatwić pracę grupujemy ją w jeden Backlog. Tylko pytanie, czy te wszystkie przeciwności to jest dobry powód, żeby brnąć w ten model razem z jego wszystkimi konsekwencjami.
Idę o zakład, że każdy z Was widział inne powody, dla których istniał twór o nazwie „jeden Backlog i wiele Produktów”. Podzielicie się?
Developer here.
Sam jestem w takiej sytuacji, ale to wcale nie jest takie proste. Ciągle się zastanawiam czym jest produkt i nadal nie wiem. Bardzo wiele zależy od tego jak to zdefiniujemy.
W moim przypadku, mój zespół zajmuje się aplikacjami wewnętrznymi, robimy różne aplikacje dla ludzi z firmy, żeby mogli wykonywać swoją pracę (a dokładniej back office dla e-commerce). Aplikacji wewnątrznych w firmie mamy od groma, samych zespołów też kilkadziesiąt.
W moim zespole mamy swój wiodący projekt na którego poświęcamy pewnie ze 70-80% czasu, ale czasami priorytety biznesowe układają się tak, że musimy zrobić coś z jednej z kilku innych aplikacji, którymi się opiekujemy. A co więcej, niektóre aplikacje są wspólne, bo są zbyt duże, żeby jeden zespół był w stanie je ogarnąć (pracujemy nad ich rozbiciem, ale to osobny temat).
Więc jak to jest z produktami? Teoretycznie mój zespoł zajmuje się 4 aplikacjami (produktami?) z czego 3 współdzielimy z dwoma innymi zespołami. Nasz PO jest też ownerem w 2 innych zespołach, więc mamy 3 niezależne backlogi. Nie byliśmy w stanie ogarnąć jednego backlogu, trzech zespołów i 7 aplikacji na jednej liście. Próbowaliśmy. Próbowaliśmy też dzielić go na aplikacje i wcale nie było lepiej. Rozwiązanie z backlogiem na zespół się sprawdza na razie najlepiej.
Z drugiej strony, gdy uznamy, że procesy biznesowe lub konteksty ograniczone (te z DDD), są produktami, to lekko naciągając rzeczywistość, możemy powiedzieć, że wtedy wygląda to lepiej. Jeden zespół zajmuje się obszarami A, inny obszarami B i nie wchodzimy sobie za bardzo w drogę mimo, że często commitujemy do tego samego repozytorium kodu i nasze release’y są wspólne.