Trzy role. Trzy cechy. Transparentność, zaufanie i prawdomówność. Mówiliśmy już zarówno o scrumowych rolach, jak i wielokrotnie o poszczególnych cechach. Nadszedł czas na nieco głębsze przemyślenia. Dziś #białko w wariancie filozoficznym.

Czytaj dalej
Prawdomówność i jej nieodłączni towarzysze

Temat wymagań przewija się w zasadzie od samego początku naszego istnienia jako #białko. Jednym z naszych naszym ulubionych tematów jest dzielenie wymagań, a w naszych rozważaniach filozoficznych często poruszamy też tematykę MVP. Ale nigdy tak naprawdę nie powiedzieliśmy jak mówić o wymaganiach, żeby nie sugerować sposobu realizacji?

Czytaj dalej
Wymagania, a nie zadania!

Temat rekrutacji zawsze jest tematem drażliwym. W końcu wybierając kandydata wielu osobom trzeba podziękować, a jednej – zaufać. Ale czy na pewno? I czy rekrutacja do zespołów zwinnych wyróżnia się czymś szczególnym?

Czytaj dalej
Jak rekrutować do zespołów zwinnych?

Duży nacisk w metodykach zwinnych kładzie się na prognozowanie, czyli „przewidywanie przyszłości”. Zespoły mają prognozować po to, żeby wiedzieć ile i co zostanie dowiezione na koniec każdej iteracji. Czym jest prognozowanie i jaki ma wpływ na podejmowane przez nas decyzje?

Czytaj dalej
Forecasting czyli prognozowanie

Każdy, kto trafia do środowiska agile’owego z zewnątrz spotyka się z barierą językową. Dla jednych nie będzie ona przeszkodą i szybko odnajdą się w „stand-upach” i „Sprintach„. Inni długo będą zgadywali, czym jest ta „eskalacja” podobno wykonywana przez Scrum Mastera.

Czytaj dalej
Eskalacja

„Oni mieli szczęście, dlatego im się udało. Umiejętności, ciężka praca i doświadczenie nie miały znaczenia. To tylko łut szczęścia sprawił, że im wyszło, a nam nie.” Brzmi uspokajająco, prawda?

Czytaj dalej
Rola szczęścia w sukcesie

Nasza rola w projekcie scrumowym nie ma znaczenia! Wszyscy tak mówią, ale czy faktycznie tak jest? Czy stanowisko, które zajmujemy nie predysponuje nas do czucia się ważniejszymi od innych? Dziś spróbujemy odpowiedzieć na pytanie, czy istnieje coś takiego jak hierarchia w Scrum.

Czytaj dalej
Hierarchia w Scrum

Dość często można usłyszeć takie krzyki. Zwykle, im gorzej zorganizowany projekt, tym więcej osób chce, aby „zostawić programistów w spokoju i pozwolić im pracować”. Tak, jakby cała otoczka projektowa była zbędna i do pełnego sukcesu wystarczyłby sam kod. Nic bardziej mylnego.

 

Rys historyczny

Wiele lat zajmowałem się programowaniem. Brzmi to trochę jak wyznanie, ale mile wspominam tamte lata. To jednak umiejętność spojrzenia na problemy zarówno z punktu widzenia kodu jak i potrzeb biznesowych okazała się być bardziej pożądana na rynku. Równolegle z byciem Scrum Masterem i trenerem Scrum przez lata byłem więc analitykiem.

Przez ten czas miałem do czynienia z wieloma organizacjami, projektami i rozwiązaniami. Zawsze gdzieś też następował moment, w którym ktoś w końcu rzucił „Zostawcie programistów w spokoju!” lub „Pozwólcie nam po prostu pracować!”.

Czasami chodziło o Sprint Retrospective i o „ciąganie programistów na spotkania biznesowe”, ale najczęściej po prostu o jakąkolwiek metodykę prowadzenia projektów. Przecież wystarczy tylko „klepać kod”, bo „my już wiemy co mamy zrobić”.

Ale czy na pewno?

 

Przez programistów, dla programistów

Przez lata używałem wielu rozwiązań open source’owych. Niektóre z tych projektów są zarządzane tak sam, jak rozwiązania komercyjne, ale inne są robione „przez programistów dla programistów”. Można by rzec, że jest to raj dla ludzi, którzy chcą w spokoju programować. I to niestety widać.

Rozwiązanie stworzone przez programistów dla programistów zwykle jest nie do zaakceptowania dla szarych użytkowników. Klient nie powinien doktoryzować się z informatyki, żeby móc wygodnie korzystać z aplikacji. Nie powinien słyszeć „to oczywiste”, „domyśl się”, „przecież to jest tu i tu”, bo to sugeruje że rozwiązanie nie powstało dla niego.

Problem usability i UX jest o wiele szerszy niż tylko zapędy programistyczne, bo ten aspekt kuleje często też u analityków. Niemniej, samym programistom bardzo trudno jest wczuć się w typowego użytkownika, który o komputerach wie o wiele mniej niż ktokolwiek związany z IT.

Branża IT żyje w bańce i nietrudno jest założyć, że wszyscy na świecie mają tak samo jak my. Tymczasem dla wielu osób instalacja aplikacji na telefonie jest skomplikowana. Synchronizacja danych pomiędzy kilkoma komputerami to ogromne wyzwanie. Udostępnienie filmów z wakacji dla kilku znajomych jest praktycznie niemożliwe. Trudno jest to sobie wyobrazić, jeżeli wszyscy nasi koledzy są „z branży”.

Dlatego też nie uważam, żeby „zostawienie programistów w spokoju” to było dobre rozwiązanie, jeżeli chcemy tworzyć rozwiązania dla szerszego grona odbiorców.

 

Kto zadba o spójność?

Nawet jeśli doskonale wiemy co mamy do zrobienia i zadbaliśmy wewnątrz naszych zespołów o wsparcie dla UX, to nie możemy mieć pewności, że nasz klient wie czego chce.

Nie jest to też jego wina. Bardzo często po prostu wyobrażamy sobie, co nam może się przydać, ale dopiero gdy to faktycznie dostaniemy do rąk własnych okazuje się, jak to jest dla nas użyteczne (i czy w ogóle).

Pomóc w tym aspekcie może doświadczony Product Owner, który pracując z klientem poznaje jego potrzeby i, jak to się ładnie mówi, „optymalizuje wartość wytwarzanego rozwiązania” czyli sugeruje bardziej perspektywiczne drogi rozwoju. Także sam Zespół Deweloperski, w myśl Agile Manifesto, powinien ściśle współpracować z użytkownikami końcowymi, aby realizować ich najskrytsze potrzeby.

Chcemy też, żeby tworzone rozwiązania wpisywały się w ogólną wizję produktu. I tu znów odnajdziemy wartość płynącą z roli Product Ownera. Bo jeśli wszyscy jesteśmy zajęci „tylko programowaniem”, to nikt nie ustala hierarchii potrzeb, ani nie przygląda się potencjalnym szansom na zmiany zakresu.

To jest kolejna zaleta tworzenia Minimum Viable Product czyli MVP. Z jednej strony mamy klienta, który nie zawsze wie, czego potrzebuje. Z drugiej zaś programistów, którzy nie są nawet zainteresowani pomocą klientowi w uświadomieniu swoich potrzeb. Jak to pogodzić? Zróbmy działający fragment aplikacji, który oddamy do użytku klientowi.

Bardzo ważne jest, żeby nie traktować MVP jako proof-of-concept, bo wtedy nie podejdziemy do tego na poważnie. Unikajmy jak ognia prezentowania klientowi rozwiązania podczas demo czy szkolenia. On musi zacząć tego używać, żeby przekonać się czy jest to dla niego wystarczające i odpowiednie. Dopiero gdy będzie miał skin in the game i będzie używał naszego rozwiązania na co dzień, dowie się jak bardzo mu ono (nie)odpowiada.

 

Kto się zajmie organizacją?

Trzecim, wcale nie najmniejszym, aspektem dla którego „po prostu tworzenie oprogramowania” się nie sprawdza jest optymalizacja machiny projektowej.

Im mniejszy projekt, tym bardziej jesteśmy w stanie sami poradzić sobie z całą biurokracją, harmonogramowaniem, terminami, itp. Trzyosobowy start-up spotykający się co jakiś czas w kawiarni może nawet być zespołem rozproszonym bez związanego z tym spadku efektywność. Szczególnie, jeśli mają niezależne zadania.

Nie wyobrażam sobie natomiast żadnego większego projektu składającego się tylko i wyłącznie z „zostawionych w spokoju” programistów. Już nawet nie mówię tutaj o kwestiach formalnych i niezbędnej biurokracji, ale o samej synchronizacji pracy, zależności pomiędzy wymaganiami i wyznaczania spójnego kierunku rozwoju.

Poziom skomplikowania projektu rośnie wraz z liczbą osób i wymagań, a dzisiaj raczej nikt nie tworzy prostych aplikacji. Stąd potrzeba takiej organizacji projektu, żeby pomagała w stworzeniu i realizowaniu wspólnej wizji, a jednocześnie żeby „zostawiła programistów w spokoju”.

Do takich celów idealnie sprawdza się Scrum. Jak wspominaliśmy w tekście Artefakty, Wydarzenia, Role, narzut na spotkania scrumowe to jedynie 12%. Czas poświęcony na planowania, synchronizacje i retrospektywy zwróci się z nawiązką. I chociaż pewnie nadal będą osoby, które będą narzekały na „te wszystkie spotkania”, to musimy mieć świadomość, że bez nich tracilibyśmy o wiele więcej czasu na rozwiązywanie całej masy problemów.

 

Bądźmy praktyczni!

Czy są developerzy, którzy potrafią czuwać nad UX, potrzebami biznesowymi, spójnością rozwiązania i wybiegają w przyszłość, przewidując dalszy rozwój oprogramowania? Oczywiście.

Ale czy ktoś nie zna przynajmniej kilku programistów, których nawet siłą nie zaciągnie się na spotkanie z biznesem? Którzy non-stop powtarzają „powiedz mi co mam zrobić i ja to zrobię, ale nie zawracaj mi głowy tymi bzdurami”?

Jak zawsze mając do czynienia z ludźmi, napotkamy się na całe spektrum zachowań i osobowości, zgodne z rozkładem normalnym. Z mojego doświadczenia wynika, że ludzie pracujący w IT, a programiści w szczególności, częściej niż inni uwielbiają pracę zadaniową i rozwiązywanie skomplikowanych problemów. O wiele mniej radości sprawia im praca koncepcyjna nad rozwiązaniem biznesowym, a jeszcze mniej – odkrywanie prawdziwych potrzeb klienta.

Zawsze zdarzają się wyjątki, ale nie ma co budować na nich swojej strategii. Promowany przez nas empiryzm mówi jasno: sprawdź jak to wygląda w Twojej organizacji i dostosuj swoje podejście do realiów. Bo realia na pewno nie dostosują się do Ciebie.

Jeśli po przeczytaniu tego tekstu zainteresowałeś się wykorzystaniem metodyki Scrum na dużych projektach, zapraszamy na szkolenia Skalowanie Scrum.

Czytaj dalej
Zostawcie programistów w spokoju!

Zespoły rozproszone to chyba największa porażka dzisiejszego środowiska pracy. Nie dość, że daliśmy sobie wmówić, że to coś dobrego, to jeszcze wiele osób świadomie brnie w tym kierunku, pomimo rzeczywistości mówiącej jasno i wyraźnie, że to nie jest dobry pomysł.

Czytaj dalej
Zespoły rozproszone to porażka

Nie ma róży bez kolców. Nie ma też znienawidzonego „technical debt„, bez popełnionych błędów. Nawet, jeśli wydawało nam się, że są one nieistotne.

Czytaj dalej
Przyczyny zjawiska technical debt