Większość scrumowych horrorów zaczyna się dokładnie w ten sam sposób – „używamy Scruma, ale”. Nazwa takiej „zmodyfikowanej” metodyki – ScrumBut – pochodzi właśnie od angielskiego „we use Scrum, but”. Zwrot ten zwykle poprzedza listę rzeczy, których podobno „nie da się” zastosować w tym konkretnym przypadku.
#białko agile blog
Oto wszystkie teksty na naszym zwinnym blogu:
Temat pragmatyzmu idealnie łączy się z podejściem zwinnym oraz takimi koncepcjami jak empiryzm. Z drugiej strony, walczy troszeczkę z perfekcjonizmem, który jest problemem dla wielu. Sprawdźmy więc jak wygląda pragmatyzm i kim właściwie jest pragmatyk?
O agile mindset do tej pory mówiliśmy tylko na naszym kanale na YouTube. Najwyższy czas zmienić te niedopatrzenie i rozprawić się z podwalinami zarówno zwinnego myślenia, jak i metodyk agile.
Zwinni w życiu i w pracy
To, że ktoś jest „agile”, to nie znaczy, że na pewno będzie idealnym członkiem Zespołu Scrumowego. Odwrotna zależność niestety jest prawdziwa – bez agile mindsetu niezwykle ciężko będzie komuś odnaleźć się w jakiejkolwiek metodyce ocierającej się o zwinność. Na szczęście to nastawienie każdy może wypracować, o ile tylko zechce.
Agile mindset zwykle definiuje się jako zestaw przekonań, wierzeń i działań, na który składają się: pozytywne podejście, pragnienie wiedzy, dążenie do sukcesu całego zespołu, pragmatyzm i gotowość na porażkę.
Nasza ulubiona para to pozytywne podejście i gotowość na porażkę. Te cechy posiada absolutnie każdy, kto bierze udział w zawodach czy konkursach dowolnego typu. Każdy sportowiec przejawia zarówno pozytywne podejście („pobiegnę szybciej”, „podniosę większy ciężar”), jak i gotowość na porażkę („to nic, że na tym treningu się nie udało ustanowić nowych rekordów, będą następne”). Te osoby tak samo działają w swoim życiu zawodowym, jak i prywatnym. „Będą kolejne okazje” to świetne przekonanie.
Podobnie myślą osoby pracujące zwinnie. Będą kolejne wymagania, będą kolejne iteracje i kolejne próby. To nie tak, że cieszymy się z porażek. Nie są one tragedią, ale okazją do wyciągnięcia wniosków i poprawienia swojego podejścia.
Ma to wiele wspólnego z pragmatyzmem, czyli działaniem w taki sposób, żeby przy minimalnych nakładach osiągnąć pożądane efekty. Róbmy to, co faktycznie potrzebne w takim stopniu, żeby zadowolić odbiorców i osoby, które daną rzecz będą później utrzymywały. Liczą się rzeczywiste, praktyczne skutki naszych działań. Nie ma znaczenia czy poświęcimy na coś jedną godzinę czy dziesięć, jeśli nie ma żadnych praktycznych różnic.
Sklejenie czegoś na gumę do żucia to nie pragmatyzm. To lenistwo.
Pamiętajmy, że pracujemy w zwinnych zespołach. Nie ma w nich miejsca na myślenie tylko o sobie. Oczywiście, każdy chce zrealizować zadania, których się podjął, ale nie może odbywać się to kosztem zespołu. „Ja swoje zrobiłem, to wy się nie wyrobiliście” jest dokładnym przeciwieństwem agile mindset. Powinniśmy traktować zespół jak jeden organizm – to my wszyscy odniesiemy sukces albo porażkę.
Na koniec zostawiłem pragnienie wiedzy, które dla wszystkich czytających te słowa powinno być oczywiste. Jeśli coś jest dla nas ciekawe lub przydatne, to chcemy wiedzieć o tym jak najwięcej. Chcemy być lepsi, bardziej efektywni, mądrzejsi.
Nie tylko agile mindset
Zwinne nastawienie objawia się także w zwinnych praktykach. Owszem, można takie „agile’owe” działania zaobserwować u osób nie będących do końca agile, ale prędzej czy później wpłyną one także na sposób myślenia. Nie da się działać w zwinny sposób i trzymać się skostniałego mindsetu, szczególnie gdy się widzi jak agile sprawdza się w praktyce.
Chodzi tu przede wszystkim o aktywne podejście do życia, pracy i problemów. To nie jest bierne narzekanie na to, że „coś mi się przytrafiło”, tylko czynne sprawianie, że rzeczy się dzieją. Wymaga to oczywiście wzięcia odpowiedzialności za wszystko, co nas dotyka i przyznanie przed samym sobą, że „wszystko co się mi przydarza, to moja zasługa”.
Gdy wyjdziemy od takiego nastawienia, to nie ma innego wyjścia niż granie w taki sposób, żeby wygrać, a nie jedynie unikanie porażek. Jeśli będziemy tylko unikać błędów to w najlepszym wypadku staniemy w miejscu. Progres możliwy jest tylko przez eksperymenty i próby, które czasami kończą się źle. To nie może nas powstrzymać, oczy powinny być skierowane na przyszłości, nie na aktualnych problemach.
Co nie znaczy, że mamy stawiać sobie twarde cele. O wiele lepiej w cały agile mindset wpisuje się podejście „systemy ponad cele„. Zamiast skupiać się na osiągnięciu jakiegoś rezultatu, tworzymy wizję przyszłości i dbamy o to, aby wszystkie nasze działania wspierały jej osiągnięcie. Po drodze oczywiście zaliczymy kolejne kamienie milowe, ale działając systemowo będziemy o wiele bardziej efektywni.
A skoro już wspominane zostały kamienie milowe, to warto dodać, że agile mindset przejawia się także w iteracyjnym podejściu do rozwiązywania problemów. I nie ma tu znaczenia czy mówimy o tworzeniu oprogramowania, czy remoncie mieszkania.
Wszystko to należy polać sosem z wspomnianego już pragmatyzmu i umiejętności budowania MVP. Nie próbujmy zbawiać świata, nie budujmy idealnego produktu, nie dopracowujmy miliona niepotrzebnych szczegółów i nie dodawajmy setek wodotrysków. Nasz produkt przede wszystkim ma działać i być użyteczny. Minimum Viable Product to coś, co już powoduje uśmiech na twarzy odbiorcy.
Filozofia agile
Możemy spojrzeć na agile mindset jako na manifestację filozofii agile. Bo przecież całe te rozważania na temat sposobu myślenia i nastawienia to nic innego jak dyskusja filzoficzna. I to próbująca odpowiedzieć na pytanie „jak żyć?”.
Wszystkim agile’owcom na pewno bliska jest metoda naukowa. Na podstawie obserwacji formułujemy hipotezę, którą następnie testujemy. Wyniki naszych eksperymentów analizujemy i aktualizujemy nasze przewidywania. Czy to metoda naukowa, czy cykl Deminga (PDCA), czy pętla OODA – wszystko opiera się o „inspekcję i adaptację”, a nie o przekonanie o naszej nieomylności. To rzeczywistość dostarcza nam danych.
Być może cały agile mindset można zawrzeć w kilku prostych słowach. Może wystarczy, że podkreślimy empiryzm, samoorganizację i skłonności do ciągłej analizy (retrospekcji) i dostosowywania naszego podejścia. Do tego odrzucimy puste teorie, a zajmiemy się tym, co działa w praktyce. Przyznamy, że obracamy się w domenie złożonej Cynefin frameworku i nie możemy nawet marzyć o „dobrych praktykach”. Jedyne, co nam pozostaje to próbowanie.
Nawet jeśli wzorujemy się na innych, to nasza sytuacja jest unikatowa i nasze rezultaty zapewne będą inne. Musimy być gotowi na wszystko i pilnie zwracać uwagę na to, jakie są rezultaty naszych działań. Podzielmy duże rzeczy na małe kawałki i podejdźmy do nich z optymizmem. Wyciągajmy wnioski z porażek, bądźmy pragmatyczni i mierząc wysoko, stąpajmy twardo po ziemi.
Aż w końcu wykształcimy nasz agile mindset.
3 filary Scruma – transparentność, inspekcja, adaptacja. Łatwo powiedzieć, trudniej zrealizować. Szczególnie, gdy słyszymy „bądźmy transparentni, nie ukrywajmy niczego o czym mamy wiedzę, a co może wpłynąć znacząco na efekt tego, co aktualnie robimy”. Do tego niezbędne okaże się zaufanie. Tylko jak tu komuś zaufać?
W dzisiejszym świecie biznesu, szybkość wprowadzenia produktu na rynek jest kluczowym czynnikiem sukcesu. Dlatego też, w podejściu Agile często stosujemy metrykę zwana „Time To Market” (TTM). Czym jest TTM, jak go używać i przede wszystkim, jak go skrócić?
Przychodzi taki dzień w życiu wielu organizacji, że dochodzi się do granicy – stare metody po prostu przestają działać. Czasami pojawiają się nowe wyzwania, i ciężko jest nadążyć za rynkiem. To jest dzień, w którym podejmowana jest decyzja: transformacja agile.
Dziś (nieco) żartobliwie o managemencie, kierownictwie i – a jakże – pułapkach czyhających w dużych organizacjach. Ciekawostki obejmują: Dilbert principle, Peter principle, a także Prawo Putta.
Jak wszyscy wiemy, życie Product Ownera nie zawsze jest usłane różami. Realizacja Backlogu Produktu zgodnie z założeniami to utopia, Właściciel Produktu często napotyka na swojej drodze wyzwania. Jak wyglądają najczęstsze problemy PO?
Zanim zacząłem filozofować na temat zwinnego podejścia do życia i pracy, czułem, że stawianie sobie twardych celów nie jest skuteczne. O wiele lepiej mieć wizję przyszłości i system, który nas do niej doprowadzi.
Skazywanie się na porażkę
Stawianie sobie twardych, ściśle określonych celów jest proszeniem się o kłopoty, o porażki i o zniechęcenie. Jeśli obiecasz sobie, że każdego dnia wykonasz przynajmniej 15000 kroków, to jeden ulewny dzień, choroba albo nadgodziny sprawią, że odnosisz porażkę. A w takiej sytuacji łatwo o zrezygnowanie z całego pomysłu.
„Schudnę 10 kg przez 3 miesiące”, „dostanę w tym roku awans”, „będę ćwiczył codziennie” – ostre cele bez żadnego marginesu, ściśle określone miary i bliskie terminy to prosta droga do klęski.
Jeśli podejdziesz do celów elastycznie i obiecasz sobie, że przejdziesz sto tysięcy kroków każdego tygodnia, to zostawiasz sobie dość duże pole manewru. Możesz na przykład zrealizować swój ambitny plan w trzy dowolne dni, zwinnie uwzględniając po drodze nieprzewidziane wydarzenia. Masz więcej możliwości.
Jeszcze lepszym rozwiązaniem będzie zorganizowanie swojego życia tak, żeby chodzić jak najwięcej. Sprzedaj samochód, chodź pieszo do pracy i biegaj na siłownię. Nie stawiaj sobie żadnych celów, ale zbuduj efektywny system, dostosowując go w miarę potrzeb i osiąganych rezultatów. „Inspect and adapt”. Nie planuj, ale mierz.
Cel czy system?
Nie chodzi o to, żeby o 23:59 zobaczyć, że na liczniku jest ledwo pięć tysięcy kroków. Jeżeli naprawdę zależy ci na robieniu 15 tysięcy dziennie, to paradoksalnie nie powinieneś skupiać się na chodzeniu, tylko na tworzeniu okazji do chodzenia. Gdy tych okazji będzie wystarczająco dużo, to osiągnięcie założonej liczby kroków zadzieje się „samo”.
Tworzenie systemów w celu osiągnięcia celów to nic innego, jak realizacja podstawowego założenia rozwiązywania problemów złożonych rodem z Cynefin framework. Ułóżmy sobie rozkład dnia tak, żeby chodzić jak najwięcej (eksperyment), zobaczmy jakie osiągamy wyniki (rozpoznanie) i zmodyfikujmy ten plan w miarę potrzeb (działanie). Pomóc w tym mogą chociażby proste listy ToDo, dzięki którym łatwiej jest zobaczyć, gdzie jeszcze można znaleźć okazję.
„Przebiegnę maraton w trzy godziny” to cel. Dieta, program treningowy i ćwiczenia to system, który prędzej czy później doprowadzi do zrealizowania tego celu. Nie ma sensu sprawdzanie swojego czasu co tydzień. Wystarczy skupić się na treningach i dobrym odżywianiu. Sukces przyjdzie „sam”.
Mając cel możemy odnieść porażkę, budując system może on co najwyżej okazać się niedoskonały. Ulepszając go nie tylko przybliżamy się do osiągania niewypowiedzianych celów, ale też unikamy pułapki stawiania sobie zbyt niskich wymagań. Bo gdy patrzymy cały czas na licznik kroków, to przestaniemy na niego zwracać uwagę po osiągnięciu założonego celu. Za to budując system i ignorując licznik, może okazać się, że przekroczymy nasze oczekiwania.
Scrum, jako reprezentant metodyk zwinnych, nie obiecuje nam, że nasze cele osiągniemy możliwie najszybciej i najmniejszym kosztem. Scrum to system, który pozwala nam kiedyś ewentualnie osiągnąć wizję przekazaną przez Product Ownera. A po drodze na pewno będziemy zaliczać jeden cel za drugim.
Cel czy potrzeba?
Stawianie sobie celów przypomina skupianie się na rozwiązaniach, zamiast na problemach. „Potrzebujemy mieć możliwość wprowadzenia na tym ekranie następujących danych” w ogóle nie bierze pod uwagę, że te dane mogą już być dostępne w naszym systemie. Nie wspominając już o tym, że mogą być one zupełnie bezużyteczne.
„Będę robił co najmniej 15000 kroków dziennie” to też próba rozwiązania niewypowiedzianego problemu. Jeśli chcemy poprawić wydolność naszego organizmu – ma to jeszcze jakiś sens. Jeżeli natomiast chcemy poprawić naszą sylwetkę, to wystarczy wyeliminowanie większości węglowodanów z diety, dostarczanie odpowiednio dużo białka i regularne ćwiczenia z obciążeniem. Nie są to jednak cele, ale elementy składowe systemu.
Produktem ubocznym dobrego systemu jest spełnianie celów.
Z punktu widzenia naszego umysłu niezwykle ważne jest, żeby te „przypadkowo” osiągane cele realizowały nasze wewnętrzne potrzeby. Cel, który został nam narzucony lub jest z nami niekompatybilny będzie niezwykle trudny do osiągnięcia. I to nieważne czy będziemy się do niego zmuszać, czy będziemy próbować budować system. Podświadomie będziemy unikać niechcianych czynności.
Za to cel wynikający z naszej wewnętrznej potrzeby będzie „realizował się sam”, szczególnie jeśli mu w tym pomożemy budując system.
Cel, a wizja
W tym całym zamieszaniu umknęła nam jeszcze definicja wizji, która ściśle się z naszym systemem wiąże. Wskazuje nam ona kierunek, w którym podążamy, chociaż sama w sobie nie jest celem.
Wizja to jakiś migawka z przyszłości. Obraz tego, jak pewnego dnia będzie wyglądał dany aspekt rzeczywistości. Jeśli widzimy siebie z sześciopakiem na plaży, to jest to nasza wizja. Nasz system, to wszystko, co przybliża nas do ziszczenia się tej wizji. Cele, jeżeli już musimy sobie jakieś stawiać, to będą po prostu kolejne kamienie milowe, stojące na drodze do ideału.
W skali wszechświata nie ma znaczenia w jakim dokładnie kierunku ani z jaką prędkością się poruszamy, o ile nasze działania przybliżają nas do urzeczywistnienia się naszej wizji. Jeśli mam za dużo tkanki tłuszczowej, a za mało mięśniowej to zarówno redukcja tej pierwszej, jak i nabieranie tej drugiej to kroki w dobrą stronę. Jeżeli chcę napisać książkę, to każda kolejna strona przybliża mnie do tego celu. Nawet, jeśli z dziesięciu napisanych wyrzucę potem dziewięć.
Każdy, kto kiedykolwiek omijał wielki korek dłuższą trasą wie, że są takie sytuacje, w której jazda nie w tym kierunku co trzeba, jest najlepszym wyjściem. I nawet jeśli koniec końców zajmuje nam to tyle samo czasu, to mamy lepsze samopoczucie, gdy nie stoimy bezczynnie.
Czujemy się lepiej i działamy bardziej skutecznie, jeśli unikamy „porażek” związanych z bezsensownie stawianymi celami. A już w ogóle jesteśmy spokojni, jeżeli widzimy, że zbudowany przez nas system działa. Jeżeli coraz lepiej znamy naszą wizję i ciągle ulepszamy nasz system, to nie ma siły – w końcu ją zrealizujemy. Po drodze, oczywiście, osiągając jakieś cele.
Jednym z bardziej istotnych elementów w Scrumie jest zarządzanie Backlogiem Produktu. W dzisiejszym artykule przyjrzymy się temu zagadnieniu bliżej: czym jest, kto je wykonuje, jak to się robi, dlaczego jest ważne i jakie są typowe metody zarządzania.
Strona [tcb_pagination_current_page] z [tcb_pagination_total_pages]