Po co nam ten Product Owner? (historia ilustrowana)

Zdarza się czasami, że rozmawiam z kimś, używamy tych samych wyrazów, wydaje się, że rozmawiamy o tym samym – i niespodziewanie w rozmowie pojawia się niezrozumienie lub zdumienie. Często wówczas odkrywamy, że co prawda używamy tych samych słów, ale zupełnie inaczej je rozumiemy…

Kiedy rozmawiam o wytwarzaniu oprogramowania, takie niezrozumienie często pojawia się przy terminie Właściciel Produkt. Zdarza się, że ktoś mówi „tak, mamy oczywiście właścicieli produktów” – a później okazuje się, że opisuje rolę menedżera albo kierownika projektu.

Po co nam Właściciel Produktu i czym ta osoba różni się od Kierownika Projektu? Spróbujmy to sobie narysować!

Czytaj więcej »Po co nam ten Product Owner? (historia ilustrowana)

Nie używamy metryk, bo…

Na portalu AgileBrains Przemek napisał bardzo dobry tekst „Metryki w Scrum – Jak mierzyć efektywność wdrożenia Scruma?”. Po przeczytaniu tego artykułu można odnieść wrażenie, że bardzo łatwo jest zacząć mierzyć i odkrywać nowe wymiary efektywności. Bułka z masłem. Albo kawałek ciastka, jak mawiają Amerykanie.

Tymczasem w organizacjach, z którymi pracowałem, bardzo rzadko spotykałem się z używaniem wartościowych metryk. Dlaczego tak jest? Dlaczego mamy dostępnych sporo ciekawych metryk – a tak rzadko ich używamy?

Czytaj więcej »Nie używamy metryk, bo…

Dlaczego trudno być dużym i zwinnym

W 2012 roku Henrik Kniberg opublikował krótki film, w którym wyjaśnia ideę „Agile Product Ownership in a Nutshell”. Filmik zdecydowanie warto obejrzeć – a ja dzisiaj chciałbym wykorzystać obrazek z tego filmu do zastanawienia się, dlaczego dużym organizacjom IT trudno jest zwinnie rozwijać produkty.

Naszkicowany przez Kniberga obraz zwinnego wytwarzania produktu wygląda tak:

Czytaj więcej »Dlaczego trudno być dużym i zwinnym

Dlaczego Scrum nie działa – część 2

Kiedy decydujemy się na pracę we framework’u Scrum, to oczekujemy z tego jakichś korzyści. Zresztą obiecuje nam to sam Scrum Guide mówiąc, iż dzięki Scrumowi możemy „wytwarzać produkty o najwyższej możliwej wartości”.

Czasami jednak wprowadzamy takie rzeczy jak „sprint”, „backlog” i „właściciel produktu” – a jednak nie dostrzegamy żadnych benefitów. Mamy poczucie, że tracimy czas na planowaniach, stand-upach i przeglądach, a nie dostajemy nic w zamian…

Przyczyny takiego stanu mogą być oczywiście różne – w tym tekście chciałbym omówić jedną z nich, którą jest brak barier chroniących zespół deweloperski.

Czytaj więcej »Dlaczego Scrum nie działa – część 2

Ilu Właścicieli Produktu potrzebujesz?

Zdarzyło mi się kiedyś usłyszeć takie słowa „No to mamy tego Scruma, ale mamy mały problem z Właścicielem Produktu…”. „Hm, a co to znaczy: mały problem?” – zapytałem. „W zasadzie to problem polega na tym, że go nie ma…”.

Scrum Guide mówi jasno: żeby nazywać swoją pracę Scrumem, musisz mieć wszystkie elementy opisane w tym przewodniku. Jednym z najważniejszych elementów Scruma jest rola Właściciela Produktu – jeżeli go nie ma (albo jeżeli z jakiegoś powodu nie pełni swojej roli, albo jest więcej niż jedna osoba zarządzająca backlogiem), to po prostu nasza metoda pracy nie jest Scrumem, tylko czymś innym.

I tutaj często pojawia się kolejne zastrzeżenie: „Ale nasz produkt jest tak skomplikowany, że nie ma żadnej osoby, która potrafiłaby go zrozumieć i pełnić taką rolę!”. Przyjrzyjmy się zatem, w jaki sposób różne metody i frameworki radzą sobie z problemem zarządzania złożonym backlogiem.

Czytaj więcej »Ilu Właścicieli Produktu potrzebujesz?

Umowy i zaufanie

Ostatnio miałem przyjemność prowadzić szkolenie na temat zwinnego wytwarzania oprogramowania dla pracowników jednej z dużych firm informatycznych. W trakcie gdy mówiłem, widziałem w twarzach uczestników narastającą konfuzję i zwątpienie. Aż wreszcie jeden z nich wypowiedział to, co nurtowało zapewne ich wszystkich: „Ale czy w ogóle można tak pracować? A gdzie umowa z klientem? A gdzie wpisujemy zakres prac? A ustawa o zamówieniach publicznych? A jaki klient na to pójdzie?”.

Czytaj więcej »Umowy i zaufanie

Kto znowu zmienił moje dane?!

Godzina 16.30, już wychodziłeś z pracy, w planie było kino i kolacja – i stało się… Zgłoszenie produkcyjne z wysokim priorytetem zostaje przypisane do ciebie. Już po godzinie wiesz, że przyczyną jest pewien wpis w bazie danych w tabelce z transakcjami, ale skąd się ten wpis tam wziął? Godzina 18:00, na szybko korygujesz wpis i aktualizujesz dane ręcznie, żeby zamknąć zgłoszenie. Jest 18:15 i masz nadzieję, że już więcej się to nie zdarzy – bo gdybyś chciał dojść do tego, jak ten wpis powstał, to pewnie byłby godziny analizy i pracy z debuggerem. Wychodzisz o 18:30, jeszcze wyrobisz się do kina, ale co będzie jeżeli zadzwonią znowu z tym samym problemem za pół godziny?

Czytaj więcej »Kto znowu zmienił moje dane?!

Warsztaty BSS/OSS w Warszawie dla rynku telekomunikacyjnego, 2016

8 czerwca 2016 miałem okazję brać udział w warsztatach BSS/OSS w Warszawie organizowanych przez Comarch dla rynku telekomunikacyjnego.
Warsztaty miały charakter mocno sprzedażowy, ale nie zabrakło momentów wskazujących bieżące kierunki rozwoju tej dynamicznej branży.
Nie zabrakło w wystąpieniach również wielu popularnych obecnie buzzword-ów takich jak IoT, M2M, customer expirience, czy już trochę przebrzmiałe big data.
Poniżej znajdziecie podsumowanie tematyki prezentacji i mam nadzieję, że wyczytacie coś ciekawego dla siebie :)

bssoss1

Czytaj więcej »Warsztaty BSS/OSS w Warszawie dla rynku telekomunikacyjnego, 2016

O zwinnym remontowaniu

remont1Przez kilka wakacyjnych dni razem z dwójką przyjaciół remontowaliśmy niewielkie mieszkanie. I nieoczekiwanie sposób naszej współpracy zaczął mi bardzo mocno przypominać słowo „agile”…

Rozpocznijmy od przedstawienia projektu: naszym celem było wyremontowanie mieszkania, ponieważ zmieniała się nieco jego funkcja. Zespół do wykonania prac składał się z trzech osób. Mieliśmy inwestora (vel właściciela produktu…), 6-dniowy termin na wykonanie zadania oraz dość ściśle określony budżet projektowy.

Czytaj więcej »O zwinnym remontowaniu

Co tak naprawdę robi Scrum Master?

Na piętnastu stronach Scrum Guide’a – podstawowego dokumentu opisującego ten framework – roli Scrum Mastera poświęcona jest jedynie jedna strona. Na tej stronie znajdziemy kilkanaście punktów opisujących, w jaki sposób Scrum Master (albo pisząc krócej: SM) wspiera Właściciela Produktu, Zespół Deweloperski i całą organizację oraz przeczytamy definicję, iż SM to „servant-leader” zespołu. Tylko tyle.

Osobiście mam poczucie, że wyobrażenie o sposobie działania SM wśród znanych mi deweloperów jest bardzo różne. Niektórzy wyobrażają sobie SM jako osobę, która organizuje spotkania, inni jako osobę która usuwa przeszkody z drogi zespołu, inni jako kierownika-bez-prawa-do-podpisywania-urlopów, jeszcze inni jako osobę, która chodzi i sprawdza czy wszystkie zadania są wpisane w odpowiednie miejsca. Te wyobrażenia często mocno bazują na tym, co usłyszeliśmy o roli SM albo na tym, jakich SM w swoim życiu spotkaliśmy. A bazowanie na wyobrażeniach może łatwo doprowadzić do nieporozumień…

Może więc warto poświęcić kilka akapitów na przybliżenie tej roli?Czytaj więcej »Co tak naprawdę robi Scrum Master?