IT is not rocket science
Leave a Comment

Scrum w ‘Spotlight’

http://www.independent.co.uk/ (‘Spotlight’,Tom McCarthy)

Co to jest: łatwe, ale trudne – zmienne, ale niezmienne?
Odpowiedź: wdrożenie kultury ciągłego doskonalenia w organizacji, w której zmiana stanowi status quo, ale która nie podejmuje się usprawnień.
W skrócie: Scrum w IT.

Metodyka, którą zaproponowano w latach 90. XX wieku jako odpowiedź na problemy i wyzwania związane z zarządzaniem branżą informatyczną ewoluowała w rytmie zmian samej branży, podpowiadając trendy i wpływając na kierunki jej rozwoju.

Każdy Scrum w IT ma dwa końce: ‘Scrum u nas nie działa’ oraz ‘to, co robimy nie nadaje się do pracy w Scrumie’. Przyzwyczaiło nas to do myślenia zarówno o metodyce, jak i o środowisku jej implementacji jako o synonimach – nierozłącznych i warunkujących się nawzajem. W dodatku otoczonych aurą braku zaufania, dezaprobaty i wątpliwości skazanych na negatywną odpowiedź. Niesłusznie – Scrum bowiem sprawdza się poza obszarem IT. Jakie ma wymagania?

Przede wszystkim lubi środowiska dynamiczne i zmienne, w których iluzja kontroli ryzyka i długoterminowego planowania posiada oficjalny status iluzji; dobrze czuje się również w centrum uwagi wielu interesariuszy; wreszcie służą mu ludzie otwarci, elastyczni i chętni uczyć się nowych rzeczy. Takie właśnie warunki panowały w zespole Spotlight, tytułowej głośnej fabule o opartej na faktach historii dziennikarzy z bostońskiej gazety zaangażowanych w pewien gorący temat.

W jaki sposób zasady Scruma sprawdziły się w Spotlight – zespole dziennikarzy śledczych ‘Boston Globe’?

Interdyscyplinarność i samoorganizacja

Zespół składał się z czterech specjalistów, z których każdy miał doświadczenie w różnych obszarach – pomimo tego wszyscy dzielili się wiedzą i wymieniali się zadaniami. W filmie zespół trzyma się sztywno swoich ról, jednak w rzeczywistości ‘(…) ten podział nie był taki sztywny. Wszyscy robiliśmy wszystko (…) Powód, dla którego akurat nasza czwórka znalazła się w zespole Spotlight był taki, że dobrze się uzupełnialiśmy’ (A. Jucewicz: Jeśli nie my, to kto? ,Wysokie Obcasy’, 2016, nr 12 (871), s.61.). Kiedy zespół usłyszał o nowym zadaniu – temacie śledczym – od razu przystąpili do ustalenia pierwszych kroków i podziału zadań.

Komunikacja i transparentność

Osoby z zespołu pracowały w jednym biurze i codziennie przekazywały sobie informacje o postępach swojej pracy, zagrożeniach i ryzykach śledztwa. Informacje były zwięzłe, ale regularne. Co więcej, filmowa Sacha Pfeiffer zapytana o to, ile czasu spędzi nad danym zadaniem była w stanie to określić.

Cel i Produkt

Spotlight to zespół redaktorów zobowiązanych pracować nad konkretnym tematem przez wiele miesięcy, bez konieczności zamieszczania w międzyczasie publikacji dopóki wszystkie materiały nie zostaną skompletowane i przygotowane. Zespół jednak cały czas miał gotową część produktu – tworzony na bieżąco zbiór historii śledztwa – i był przygotowany w każdej chwili do jego dostarczenia.
Osoby ze Spotlight pracowały w osobnym pokoju, do którego nie miał dostępu nikt oprócz nich samych, co pozwalało im skupić się na pracy, unikając rozproszenia przez ewentualne wymagania innych ludzi.

Product Owner i Interesariusze

Kiedy Marty Baron został naczelnym ‘Boston Globe’ od razu zwrócił uwagę na konkretny temat i polecił żeby zajął się tym Spotlight, porzucając zagadnienie, nad którym do tej pory pracowali. Co na to zespół? ‘To jest nasz nowy szef. Takie jest nasze nowe zadanie. Trzeba je wykonać'(A. Jucewicz: Jeśli nie my, to kto? ,Wysokie Obcasy’, 2016, nr 12 (871), s.61.). Marty Baron był Product Ownerem – jedyną osobą, która zlecała pracę zespołowi, znała się na przedmiocie pracy i decydowała o fazach dostarczenia produktu. Baron decydował o tym, nad czym zespół będzie pracował, nie ingerował jednak w to, jak Spotlight będzie pracował – zespół organizował się sam. Baron regularnie informował o kolejnych krokach pracy zespołu różnych Interesariuszy: wydawcę gazety, redaktora innego działu, dziennikarzy. Dbał o komunikację i zależności w całej redakcji oraz sprawdzał puls pracy.

Product Backlog i Continuous Improvement

Temat, nad którym pracował Spotlight, okazał się dziennikarską hydrą wymagająca ciągłych zmian oraz uwzględniania nowych interpretacji tematu. Miało to wpływ na ilość dodatkowych wymagań oraz na dynamikę pracy. Spotlight odpowiadał proaktywnie na wszystkie wyzwania, na bieżąco proponując rozwiązania – nawet jeżeli nowe kierunki działań destabilizowały wcześniejsze założenia. Product Backlog był więc aktywnym zbiorem wymagań, współtworzonym i regularnie weryfikowanym przez zespół. Co więcej, stanowił on część komunikacji wizualnej w formie kartek na tablicy w biurze zespołu.

Zmienne środowisko i sprawne dostosowywanie się do zmian

Spotlight funkcjonował w wyjątkowo dynamicznej i trudnej do przewidzenia rzeczywistości. Nie powodowało to jednak oporu przed zmianą – żadna z osób w zespole nie ulegała wpływom ego, brnąc uparcie w nieaktualnym kierunku, ale wszyscy byli skupieni na wspólnym celu. Często zmieniające się warunki nie były komfortowe, ale zespół akceptował ten stan jako część pracy.

Spotlight nie zrażał się koniecznością zmian, ale potrafił konstruktywnie na nie reagować, pozostając czujnym i otwartym na nowe perspektywy.

Scrum sprawdza się poza IT… i nie jest to żart!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s