„Agile Product Management With Scrum” – Roman Pichler

Agile Product Management With Scrum, Roman Pichler

Agile Product Management With Scrum, Roman Pichler

Na rynku książek dostępne jest bardzo dużo pozycji, które opisują agile od strony procesu. Równie dużo informacji można znaleźć na temat poszczególnych metod pracy, takich jak XP czy Scrum. To, czego zawsze mi brakowało, to porządna książka na temat zarządzania produktem w środowisku agile.

Kiedy w trakcie podróży w góry czytałem książkę Romana Pichlera pomyślałem, że to jest coś, czego szukam – powinienem wręczać ją do przeczytania każdemu Product Ownerowi, z którym rozpoczynam pracę.

Autor przystępnym językiem wprowadza w świat zarządzania produktem, tłumacząc po kolei: kto to jest Product Owner, jak pracować z produktem oraz Product Backlogiem oraz jak planować wydania. Każdy rozdział zakończony jest sekcją opisującą najczęstsze przeszkody oraz antywzorce, które możemy zaobserwować, jak choćby proxy Product Onwer, brak wizji produktu czy brak planu wydań (brzmi znajomo?)

Książka jest krótka (ok. 130 stron), można ją przeczytać w jeden dzień. Jest to jej zarówno zaleta jak i wada. Z jednej strony świetnie, że tyle ciekawej wiedzy udało się upakować w skondensowanej formie, z drugiej strony rośnie apetyt na więcej. Pozycję należy traktować jako punkt startowy do dalszej eksploracji tematu zarządzania produktem.

Pozycja absolutnie obowiązkowa dla każdego Product Ownera. Nie zaszkodziłoby, gdyby przeczytał ją również każdy Scrum Master, który pracuje na co dzień z Product Ownerem – wiedza zawarta w książce może okazać się przydatna.

Plusy:

+ kompendium wiedzy o zarządzaniu produktem
+ zestaw startowy dla nowych Product Ownerów
+ można przeczytać w jeden dzień

Minusy:

– krótka, można przeczytać w jeden dzień ;)

Moja ocena: 5 / 5

Zmiany vs. eksperymenty

Zróbmy mały eksperyment

Zróbmy mały eksperyment

Prowadziłem ostatnio retrospektywę w zaprzyjaźnionym zespole. Spotkanie zmierzało powoli do końca – mieliśmy już bowiem zidentyfikowane problemy wraz z potencjalnymi rozwiązaniami. Wystarczyło tylko podjąć decyzję, które rozwiązania wybrać.

10-osobowy zespół, ze względu na specyfikę produktu złożony głównie z programistów, rozpoczął dyskusję nad wyborem rozwiązania do jednego z problemów. Z puli potencjalnych rozwiązań pozostały dwa najciekawsze, które podzieliły zespół na dwa obozy.

Rozpoczęła się dyskusja. Wymiana zdań była długa, pełna nieoczekiwanych zwrotów akcji i pomimo moderacji – trudna do opanowania, ze względu na emocje panujące w zespole.

Jednak z mojej perspektywy najciekawsze w tym wszystkim było to, że zespół przez cały czas operował na poziomie teorii. Dyskutowali o tym, co się wydarzy na skutek podjęcia takiej, a nie innej decyzji. Trochę tak, jakby wybór był wiążący na całe życie.

Dlaczego moim zdaniem nie warto było poświęcać więcej czasu na dyskusję nad zmianą, a zamiast tego zdecydować się na eksperyment?

  • to tylko teoria – rzeczywistość może okazać okaże się zapewne nieco inna, aniżeli została opisana przez zwolenników oraz przeciwników rozwiązania,
  • złożoność środowiska – na poziomie ludzi, zespołu, produktu oraz firmy. Gotowe rozwiązania czy najlepsze praktyki nie działają w złożonym otoczeniu, być może rozwiązanie wyłoni się dopiero na skutek pracy zespołu,
  • łatwość zmiany decyzji – nie trzeba czekać do kolejnej retrospektywy, żeby zmienić raz wybrane podejście. Jeżeli coś nie działa, możemy to zmienić od razu,
  • zdobywanie wiedzy – traktowanie rozwiązania jako mały eksperyment z wartościowym rezultatem (jakikolwiek by nie był), nauczy zespół więcej, aniżeli najciekawsza wymiana zdań.

A Ty jak traktujesz zmiany? Zapraszam do komentowania.

Fotografia użyta na licencji Creative Commons od użytkownika snre.