“Zet” na Daily Scrum

Daily Scrum to wbrew pozorom – obok retrospektywy – chyba najtrudniejsze ze spotkań Scrumowych. Źle przeprowadzane jest podłożem wszelkich problemów trapiących zespół – od braku realizacji planowanych wymagań, poprzez typowo indywidualne podejście deweloperów do pracy, aż do poczucia bezsensu pracowania w Scrumie.

• • •

Tworzenie oprogramowania w 30 dni

Po tę książkę  sięgałem z wielkim zaciekawieniem. Co też panowie Schwaber i Sutherland – twórcy Scruma – mają do powiedzenia o swoim opus magnum, w jaki sposób zachęcają do jego używania, jak rozwijają myśli zawarte w Przewodniku po Scrumie… I chyba równie wielkie jak to zaciekawienie, było moje rozczarowanie po lekturze całości.

• • •

Wierchuszka na przeglądach

Przegląd Sprintu (często błędnie nazywany: podsumowaniem lub demem) to spotkanie, które zrewolucjonizowało komunikację wykonawców (IT) z końcowym klientem oraz wymusiło po stronie IT sporą zmianę podejścia do swoich działań. Oto w stałym cyklu i już od samego początku pracy zespół deweloperski nie dość, że musi dostarczyć coś w pełni funkcjonalnego i wartościowego biznesowo, to jeszcze, wspólnie z Product Ownerem, ma za zadanie to zaprezentować. W efekcie klient ma okazję na bieżąco, w stałym cyklu, oglądać efekty prac i zgłaszać swoje uwagi czy propozycje co do dalszych kroków.

• • •

Scrum, czyli jak robić dwa razy więcej, dwa razy szybciej

Pamiętam gdy zobaczyłem po raz pierwszy ten tytuł, uznałem go za przewrotny, ciekawy sposób na dotarcie do różnych grup ludzi, którzy wcześniej z różnych względów nie chcieli mieć do czynienia ze zwinnymi sposobami prowadzenia projektów. Wszak hasła: więcej i szybciej są motorami napędowymi niektórych menedżerów, czyż nie? Ba, kto nie chce mieć więcej i szybciej?

• • •

Scrum i nie tylko. Teoria i praktyka w metodach agile.

Książkę tę nabyłem jako początkujący Scrum Master, niejako przez przypadek, w jednej z popularnych sieciówek. Była jedną z bardzo niewielu polskich pozycji traktujących o agile, co w zasadzie było dla mnie jedynym wabikiem do jej zakupu. Nieoczekiwanie  stała się jedną z moich ulubionych pozycji, którą często wertuję w prawo i w lewo żeby sobie przypomnieć pewne rzeczy.

• • •

Istota retrospektywy

Na jednej z ostatnich konferencji agile’owych natrafiłem na grupkę (jak się okazało – w większości Scrum Masterów) żywo dyskutującą o retrospektywach. Jako, że konwersacja była prowadzona publicznie, w trybie otwartym, przyłączyłem się w roli słuchacza. Rzecz była o pomysłach na ciekawe retrospektywy w formie, jak to określono, “psychozabawy” (a słysząc to słowo moje myśli skierowały się ku “Uśmiechowi Numeru” czy innym kultowym nastoletnim gazetkom z lat 90.)

• • •

Succeeding with Agile: Software Development Using Scrum – Mike Cohn

Ta książka to bez dwóch zdań jedno z najważniejszych wydawnictw jakie do tej pory ukazało się w tematyce Scruma. Autor skomasował tu wiele lat swojego imponującego doświadczenia tworząc dzieło, które jest lekturą obowiązkową dla każdego, kto planuje wprowadzić w swojej firmie tę metodykę pracy.

• • •

Niepokorny deweloper

Scrum to gra zespołowa, działa dobrze, jeżeli wszyscy przykładają się na równym poziomie, bo oczywistym jest, że na efekt pracy zespołu składają się ludzie go tworzący. Co jeśli jeden z członków zespołu deweloperskiego zaczyna przysparzać problemów, psując atmosferę? Nie chciałbym się w tym momencie rozpisywać nad przyczynami takiej sytuacji, może być ich bardzo wiele –  od znużenia projektem, wypalenie zawodowe, po kwestie relacji panujących między członkami zespołu czy też kwestie ich charakterów. Skupmy się na samej sytuacji, gdzie problemem staje się komunikacja oraz egzekwowanie zobowiązań od takiej osoby.

• • •