Ostatnio spotkałem się z ciekawym problemem (zasłyszanym). Otóż PO sprecyzował wymagania do dosyć prostego mechanizmu po czym dołożył stopień komplikacji zmieniający proste krzesło w krzesło elektryczne. Przy czym nie chodzi tutaj o morderczą naturę tego drugiego tylko o stopień komplikacji rozwiązania. I teraz pytanie jak to ugryźć bo oczywiście na spotkaniu natychmiast pojawił się tajemniczy pomruk (i nie był to pomruk podziwu dla sprytu PO bynajmniej).

Właściwie temat jest prosty – nie ma co tutaj kombinować – zespół powinien przedstawić realną estymację zakresu prac a pojawiające się cyferki powinny spowodować refleksję u PO. Lub jeśli są zgrani wystarczająco to po prostu powiedzieć jakiego rodzaju to jest problem. No i wywołać dyskusję w stylu czy jednak zwykłe krzesło nie byłoby wystarczające. W praktyce jednak często się spotykamy z problemem odporności PO na wiedzę przekazywaną z zespołu jak również zdrowy rozsądek. Bywa, że PO jest tak dumny z pomysłu, że racjonalne argumenty nie trafiają. Oczywiście jest to tylko wierzchołek góry lodowej która w całości nazywa się brak współpracy.

I tu pojawia się u mnie ciekawa obserwacja z praktyki. Jak „przepychanie” takich wymagań niszczy relację pomiędzy PO a zespołem. Bo o ile oczywiście sporadycznie mogłoby to przejść, o tyle notoryczne wpychanie kolanem wymagań, których większość nie rozumie (w sensie nie widzi ROTI) powoduje negatywne konsekwencje. Zespół prędzej czy później przestanie dyskutować z takimi wymaganiami a nawet zgłaszać obiekcje (po co dyskutować skoro i tak to przeforsuje). Rolą Scrum Mastera jest oczywiście takie rzeczy wyłapywać i przedyskutować z Product Ownerem. I jego rolą jest również spowodowanie co najmniej refleksji u PO jak ważna jest współpraca. Bo jedynym sposobem ochrony są wartości Scrum. PO który będzie wiedział lepiej ma wszelkie atrybuty władzy potrzebne do przepchnięcia czegokolwiek. W końcu jest wyłącznym dysponentem backlog-u. I niestety PO który zawsze wie lepiej jest chyba najprostszym przepisem na wykolejenie współpracy. Nie od razu – stopniowo lecz bardzo skutecznie.

No i jeszcze konkluzja – jeśli PO jest tak mocno umocowany w biznesie, że faktycznie przepchnie cokolwiek, biznes się na to zgadza i uważa, że jest świetnie to moim skromnym zdaniem uczciwiej byłoby powiedzieć Kanban. Bo urządzanie retrospektyw – wydmuszek, naginanie wartości Scrum  jest troszkę oszukiwaniem samych siebie. Pytanie – po co? A jakie jest wasze zdanie?