Porównamy się?

Każdy ma tendencję do porównywania się. Nie ma nic złego w zdrowej rywalizacji, ale jeśli ktoś “na górze” zaczyna nas porównywać, to może zrobić się… dziwnie. To jak, porównamy się?

 

Kto jest lepszy?

Często rozmawiając o szacowaniu elementów Backlogu Produktu mówimy, że każdą, absolutnie każdą rzecz można porównać do drugiej. Dlaczego więc nie porównać miedzy sobą dwóch zwinnych zespołów deweloperskich pracujących w tej samej organizacji?

Jeszcze lepszym porównaniem będzie to pomiędzy zespołem z wewnątrz organizacji i zespołem spoza. Często szukając możliwości zaoszczędzania środków (nie tylko pieniędzy) szukamy sposobów na realizację projektu lub produktu poza organizacją. Nie muszę mówić, co może być skutkiem takiego podejścia. Dumpingowe ceny, obiecywanie wszystkiego czego chce klient – to wszystko już było. Jak się kończy, wszyscy doskonale wiemy.

Mimo wszystko, mimo tych doświadczeń, Project Managerowie, CEO i ludzie zarządzający projektami wciąż mają tendencję do porównywania. Z jednej strony ich rozumiem, potrzeba zaoszczędzenia w niejednym projekcie jest większa niż zapewnienie dotychczasowej jakości produktu. Czasem jednak możemy nadziać się na przysłowiową minę.

Czy wiedząc o tym, mając doświadczenie nadal wierzymy, że jest zasadne się porównywać? Oczywiście, że tak. Taka jest nasza natura. Sprawdźmy więc, co może z tego wyniknąć.

 

Porównamy się?

Porównując między sobą dwa zespoły, niezależnie czy z tej samej organizacji, czy z dwóch rożnych, zawsze doświadczymy tego samego zjawiska. Zespoły są nieporównywalne. Nie chodzi mi o tak trywialną rzecz jak ich liczebność. Są rzeczy, których porównać się nie da: doświadczenie ludzi, ich motywacja do realizacji powierzonych ich zadań czy tak prosta rzecz jak ich dostępność w danym okresie. To wszystko powoduje, że porównywanie jest nie tyle niemiarodajne co wręcz niemożliwe! I to pomimo mocnych starań podpartych skomplikowanymi wyliczeniami w Excelu.

Najczęstszą przyczyną “konieczności” porównania między sobą zespołów jest próba podjęcia decyzji, komu powierzyć realizację ważnego przedsięwzięcia. Zespołowi, który posiadamy, który zna naszą organizację, ale który poprzednie 2 projekty skończył po czasie czy temu nieznanemu Software House’owi, dobrze ocenionemu przez znajomego managera, który gwarantuje nam, że zrobi wszystko, co znajdzie się w Backlogu Produktu. Komu uwierzycie?

Inną przyczyną, tą zdecydowanie groźniejszą, jest chęć nagradzania tych zespołów, które więcej dostarczają. Przepis na katastrofę gotowy! Zespoły HR, które chcą podążać tą drogą zapraszamy serdecznie do #białko. Na spokojnie wytłumaczymy, co może pójść nie tak.

 

Spróbujmy to zmierzyć!

Nie chcę napisać, że wszystkie Software House’y działają w ten sam sposób. Sam znam kilka, które spokojnie mógłbym nazwać zaufanymi i szczerze polecić jako wykonawców prac. Jeśli tylko potrzebujecie namiar, dajcie znać. Na tym przykładzie jednak chcę pokazać, że nie można wiarygodnie porównać wyników takich zespołów. I wcale nie lepiej jest z dwoma zespołami z tej samej organizacji. Tutaj sprawa jest ciekawsza, bo wszystko najczęściej rozbija się o wycenę.

Prowadząc warsztat z szacowania elementów Backlogu (Sprintu czy Produktu) często zadaję pytanie:

“Co powinien zrobić doświadczony Product Owner, jeśli jeden z zespołów oszacuje jakieś wymaganie na 5, a inny oszacuje wykonanie tego samego wymagania na 13 story points?”

Zadając to pytanie zdaję sobie sprawę, że wystawiam uczestników warsztatu na próbę. Pozwalam im poddać się potrzebie zarządzenia tą sytuacją, próbie szukania oszczędności i pokazania, że są skutecznymi managerami. Wybór oczywiście pada na zespół, który wycenił wymaganie na 5. Jak możecie się już domyśleć, wybór ten jest błędny.

Raz, nie wiemy jakie doświadczenie reprezentują członkowie zespołu. Dwa, nie wiemy co było przyczyną różnicy w oszacowaniach. Może jeden z nich widzi zagrożenie w realizacji wymagania? Nie da się ocenić wskazanego przez zespoły oszacowania bez analizy tego, co za nią stało. Nie oszukujmy się, często nie zadajemy sobie tego trudu.

 

#białko radzi – nie porównuj!

Po pierwsze, nie porównuj. Nie ma to sensu. Pozwólmy szacować zespołom wymagania w sposób, który uznają za stosowny. Jeśli chcesz sprawdzić co jest przyczyną różnicy w oszacowaniach – dowiedz się tego. Ale nie narzucaj sposobu wyceny. Jeśli różnica nie wynika z kwestii merytorycznych sprawdź, jaki punkt odniesienia określiły zespoły i do czego porównywane jest wymaganie. Często właśnie ten punkt decyduje o różnicy w wycenach.

A co, jeśli jednak zachcemy spróbować jakoś się porównać? Są metodyki, które próbują odpowiedzieć na tę potrzebę. Przykładem może być SAFe. Ten zakłada, że szacowania są znormalizowane, a zespoły odnoszą się do wymagania, które zajmie im “pół dnia dewelopmentu i pół dnia testów”. To wymaganie oszacowywane jest na 1.

Zastosowanie powyższego podejścia powoduje, że normalizujemy nasze wyceny na przestrzeni zespołów. Przede wszystkim, mamy jeden punkt odniesienia. Nie pozwala nam jednak w dalszym ciągu na porównanie się pomiędzy zespołami. Dla jednego z nich, tego bardziej doświadczonego, wymaganie na pół dnia dewelopmentu i pół dnia testów będzie 3 razy większe niż dla tego, który doświadczenia ma mniej. Nic to nie zmienia, wciąż jesteśmy w punkcie wyjścia. Po co tracić więc na to wszystko czas?

Ciekaw jestem, jakie Wy macie doświadczenia w tym temacie? Czy często zdarza się, że musicie porównywać między sobą dwa zespoły?

Łukasz Bręk

14 lat doświadczenia w IT, 7 lat doświadczenia w Scrum, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: