Zapraszam do nietypowego tekstu, z którego dowiecie się jak robić dobre Sprint Review. A może nawet dowiecie się po co Wam ta cała zwinność i jak nie popaść w przesadę, próbując być agile.
Nadmierne komplikowanie wszystkiego
Jakiś czas temu złapała mnie ochota na powrót do podstaw i uproszczenie tego, co już wiemy. Z niewiadomego powodu wiele organizacji znacząco komplikuje życie sobie i innym, próbując dorabiać ideologię praktycznie do wszystkiego, zamiast zająć się najważniejszym – swoim celem.
Bardzo trudno rozmawia się z ludźmi z organizacji projektowych, którzy przesiąknęli tym specyficznym trybem myślenia i działania. „Potrzebujemy zrobić projekt, który będzie dotyczył konfigurowania i wysyłania powiadomień push na komórki i przez strony www!” No dobrze, ale co jest celem? „Wysyłanie powiadomień!” A po co wysyłamy te powiadomienia? „Żeby zachęcić ludzi do kupowania w promocjach.” Czyli nie chcemy projektu związanego z powiadomieniami, ale chcemy zwiększyć sprzedaż promocji. Tego typu myślenie zostało pokazane na niezliczonej ilości agile’owych memów i komiksów, nie będziemy się powtarzać.
Organizacje projektowe każdą pierdołę ubierają w wielkie projekty, które są rozliczane z ich „dowiezienia”, a nie z rezultatów. Nie zastanawiamy się po co coś robimy, tylko staramy się robić mocniej, lepiej, szybciej, silniej. A może rozwiązaniem wcale nie jest kolejny projekt, tylko zmniejszenie naszego zakresu prac i skupienie się na rozwoju tego, co działa?
Zamiast tworzyć nowe i nowsze, czasami warto odwołać się do zdrowego rozsądku i sprawdzić co już działa, co ma największy potencjał i co możemy zrobić w pierwszej kolejności. Tak, wiem. Empiryzm.
To może agile?
Podejście agile to przecież nic innego jak zdrowy rozsądek. A ten powinien walczyć z robieniem rzeczy w nieefektywny sposób, niezależnie od przyczyn. Powinniśmy ignorować okrzyki pod tytułem „Zawsze tak robiliśmy!” czy „Specyfika naszej pracy nie pozwala nam pracować tak, jak robi to cała nasza konkurencja i wszyscy, których znamy!”. Skoro coś nie działa, to czasami musimy się sami przed sobą przyznać, że nie działało to nigdy i całe lata robiliśmy coś po prostu źle.
Tu trzeba podkreślić, że nikt z #białko nigdy nie zaproponuje postawienia czegoś na głowie bez zrozumienia problemu i ryzyk, jakie wiążą się z rewolucją. Co też zawsze powtarzamy na naszych szkoleniach i warsztatach oraz w naszej pracy jako konsultanci wspierający zwinne firmy. Ale wróćmy do sedna problemu.
Na wstępie napisałem, że wiele organizacji próbuje dorabiać ideologię i/lub komplikuje sobie życie. Podałem przykład z „projektozą”, gdzie zamiast na robieniu biznesów skupiamy się na robieniu projektów. Niestety, podobnie często jest ze zwinnością. Zamiast robić biznes, zaczynamy „robić agile”. A to źle. Nie taki jest cel zwinności.
Q „Agile is not the goal, your goal is the goal.”
Pamiętajmy, że wszędzie i w każdym podejściu liczy się to, do czego nasza firma została powołana. Albo mówiąc inaczej – cel, który sobie postawiliśmy. Od czasu Scrum Guide 2020 jest łatwiej, bo mamy przynajmniej Cel Produktu, który zmusza nas do tego, żebyśmy się nad tym zastanowili. Ale to nie jedyna opcja.
Co zrobiliśmy i co zrobimy?
Nie dalej niż tydzień temu zastanawiałem się, od czego zacząć naprawiać Scrum. Spoiler alert: na pewno nie od Wydarzeń, ale od sensu naszej codziennej pracy. Co robimy i po co? Jaki cel mamy zamiar osiągnąć? Jak pracują i współpracują nasze zespoły? To wszystko jest o wiele ważniejsze, niż jakiekolwiek Wydarzenia i Artefakty Scrum.
I przy tej okazji chciałbym wszystkie dzisiejszej tematy zebrać w jedno i zaapelować: przestańmy udziwniać „ten cały Scrum” i „ten cały agile”. Pracujemy iteracyjnie i przyrostowo, bo nie da się z góry określić potrzeb, możliwości i procesu wytwórczego. Pracujemy po to, żeby osiągnąć jakiś cel i przynieść naszej organizacji (bądź nam samym) korzyści. Nie robimy „ceremonii Scrum„, bo nie interesuje nas sztuka dla sztuki.
Wróćmy więc do podstaw i upraszczajmy. Zacznijmy od znalezienia celu. Potem pracujmy w krótkich okresach, możemy nawet nazwać je iteracjami bądź Sprintami. W ramach tychże krótkich okresów najpierw się zaplanujmy, potem spróbujmy zrealizować nasz plan, a na koniec powiedzmy o tym, co z tego planu udało się zrobić, co nie i co w związku z tym mamy zamiar robić dalej. Dajmy sobie szansę na zmiany wymagań, zrobienie czegoś lepszego. I zapomnijmy o tym nieszczęsnym projekcie.
W tekście pod tytułem „Sprint Review to nie demo” poruszałem już ten temat, ale dziś chciałbym do niego wrócić w nieco innym ujęciu. Review to bardzo ważne spotkanie, które dotyczy esencji zwinności i tego, o czym jest dzisiejszy tekst. Zobaczmy co zrobiliśmy, jak nam poszło (oraz co nie poszło i dlaczego), a następnie zastanówmy się nad tym, co będziemy robić dalej. Nie, jeszcze tego nie planujemy, na razie tylko o tym rozmawiamy.
Robiąc „poprawne” Sprint Review możemy się przekonać, że warto rozmawiać. O tym co właśnie zrobiliśmy i o tym, co będziemy robić zaraz i dalej. I ta rozmowa da nam więcej niż jakieś frameworki, procesy czy wydarzenia. Po prostu przestańmy komplikować.
Bardzo fajnie napisane 🙂
Ja ostatnio odnoszę wrażenie, że jeśli nie jesteśmy zwinni, to już możemy pakować swoje rzeczy i szukać innego zajęcia. A w koło wszyscy celebrują swoją zwinność, tylko nikt nie mówi, co dalej.
Zaprezentowaną powyżej 'zwinność’, czyli chociażby krótkie iteracje stosowaliśmy kilka lat temu, bo doszliśmy do wniosku, ze tak jest efektywniej. I nikt wtedy nie wywyższał się, że jest 'zwinny’ a inni nie 🙂