Przemyślenia

Nie mów JAK robić, powiedz CO chcesz i DLACZEGO to jest ważne

Klocki Lego świetnie nadają się do symulowania pracy zespołów scrumowych. Gdy korzystam z nich podczas szkoleń oraz warsztatów, zapraszam uczestników do zbudowania miasta. Zazwyczaj jestem hostem tego ćwiczenia, a osoba współprowadząca przyjmuje rolę Product Ownera.

Na początku sprzedaje ona uczestnikom wizję. Opowiada, dlaczego chciałaby wybudować miasto, jak je sobie wyobraża oraz podaje kilka wstępnych ograniczeń, np. „przez środek miasta przepływa rzeka„. Następnie przedstawia zarys Product Backlogu, który składa się m.in. z domów, biurowców czy obiektów użyteczności publicznej. Uczestnicy w kilku sprintach budują miasto, samodzielnie decydując, jak zrealizować za pomocą LEGO wizję Product Ownera.

Czasem zdarza się, że uda się im zbudować wszystko, co zaplanował Product Owner w swoim Product Backlogu. W takiej sytuacji mówi im: „OK, wszystko co miałem w planach już wykonaliście, ale mam budżet na dalszą pracę – budujcie więc to, co uważacie za słuszne„. W tym momencie dzieje się ciekawa rzecz – w bardzo krótkim czasie powstają najciekawsze, najbardziej innowacyjne oraz imponujące budowle, które świetnie wpisują się w pierwotną wizję miasta.

Ci sami ludzie, ten sam produkt. Zupełnie nowa jakość, zupełnie inna energia w zespole.

Jest to dla mnie jeden z dowodów na to, że najlepsze produkty powstają w środowisku, w którym zespół:

  • zna wizję produktu, rozumie po co i dla kogo tworzony jest produkt,
  • wie co ma zrobić i samodzielnie podejmuje decyzję jak to wykonać,
  • otrzymuje przestrzeń do samoorozwoju oraz doskonalenia się.

Co istotne, podejście polegające na mówieniu „co” zamiast „jak”, można stosować na różnych poziomach. 

Product Owner nie mówi zespołowi jak coś ma działać. Mówi, co chciałby uzyskać i dlaczego ma to dla niego znaczenie. Operuje na poziomie efektów, które chciałby osiągnąć (np. „zwiększenie konwersji z kont testowych do kont płatnych”), a nie na konkretnych rozwiązaniach (np. „wysyłajmy dodatkowy e-mail zachęcający do zakupu naszego produktu”).

Gdy skalujemy produkt na kilka zespołów, Chief Product Owner nie mówi Product Ownerom jak ma coś działać. Nie mówi też, w jaki sposób mają podzielić się pracą (np. „Janek zrób wyszukiwarkę, a Ty Krzysiek zrób listę przedmiotów”). Mówi, co chciałby uzyskać („użytkownicy mają mieć możliwość szybkiego dotarcia do naszych produktów”) i dlaczego to dla niego ważne.

CEO/zarząd/boss nie mówi, jakie konkretnie funkcjonalności ma dostarczyć dla niego Chief Product Owner wraz z zespołem Product Ownerów (np. „przygotuj możliwość integracji z Facebookiem„). Nie mówi też, jak mają się zoorganizować (np. „Jeden zespół integruje się z Facebookiem, a pozostałe modyfikują naszą aplikację„). Mówi jaki cel chce zrealizować („podwojenie liczby użytkowników do końca roku„) i dlaczego jest to istotne.

Nie prośmy zespołu, aby zbudował nam łódkę. Poprośmy, aby pomogli nam przedstać się na drugą stronę rzeki.

Photo by James Pond on Unsplash

 

Jacek Wieczorek
Jestem konsultantem zwinności i praktykiem podejścia agile. Napisałem książkę "Labirynty Scruma" o sprawdzonych sposobach na najczęstsze pułapki w Scrumie. Pomagam przekształcać organizacje w miejsca, w których efektywnie tworzone są wartościowe produkty. Prowadzę bloga jacekwieczorek.pl, współtworzę podcast Porządny Agile oraz portal Agile247. Na co dzień pomagam klientom działając jako konsultant w firmie 202 Procent, którą współtworzę z pasjonatami zwinności.
Mogą Cię zainteresować poniższe wpisy
Premiera podcastu „Porządny Agile”
Twoi ludzie to misjonarze czy najemnicy?
5 komentarzy
  • […] widzę elementy w Backlogu Produktu, które nie dostarczają wystarczającej informacji na temat kontekstu biznesowego. Jest wprawdzie napisane, co należy zrobić, ale nie jest napisane dlaczego. Zwykle wystarczą […]

  • Jacek Wieczorek Sty 19,2014 at 21:21

    @ZDN – powodzenia z nowym produktem. Daj znać po czasie jak poszło.

  • ZDN Sty 19,2014 at 14:04

    Nie znałem tematu, wydaje się bardzo sensowny, mam nadzieję, że będzie równie skuteczny. Zabieramy się za wprowadzeniem całkiem nowego produktu, który na każdej płaszczyźnie znacznie odbiega od usług, z którymi do tej pory miał do czynienia mój zespół. Temat świeży, myślę, że ten model zarządzania może się tu sprawdzić. Dzięki za inspiracje.

  • Jacek Wieczorek Lis 19,2013 at 09:47

    @DawidL – dzięki za link, jest interesujący. Dobrze to podsumowałeś.

  • DawidL Lis 19,2013 at 09:03

    Przejście z modelu zarządzania „jak” (detailed command) na model „co” (mission command) zaczęła praktykować (już) armia amerykańska. Więcej- http://blogs.hbr.org/2013/06/making-management-as-simple-as/.
    Skomplikowane otoczenie powoduje, że nie da się ludziom powiedzieć ze szczegółami jak coś maja zrobić, ponieważ to oni będą TO robić i to oni będą widzieli wszystkie szczegóły jak się za TO zabiorą.

Zostaw swój komentarz

Twój komentarz*

Twoje imię*
Twoja strona*

This site uses Akismet to reduce spam. Learn how your comment data is processed.