Jak nie wprowadzać usprawnień?

Lubimy zarówno teksty z cyklu „How To”, jak i te w których na negatywnych przykładach pokazujemy “How Not To”. Dziś więc przyjrzymy się temu, jak łatwo można przedobrzyć z wprowadzaniem usprawnień.

 

Co jest wrogiem dobrego?

Na naszym blogu zdarzyło nam się już zajmować tematem CI, czyli Continuous Improvement. Przy okazji tamtego tekstu przypomnieliśmy, że lepsze faktycznie może być wrogiem dobrego. Nie ma sensu na siłę usprawniać wszystkiego, szczególnie, jeśli coś działa wystarczająco dobrze.

Oczywiście, bardzo często chcemy więcej, dalej, lepiej, szybciej, ale musimy umieć postawić sobie granicę tego, co jest faktycznie wystarczające dla naszego odbiorcy. Pomoże nam w tym nasz przyjaciel MVP.

Jako zwinne zespoły powinniśmy skupiać się na dostarczaniu wartości do klientów/użytkowników końcowych poprzez realizację wymagań z backlogu. Ale poza tym powinniśmy też dbać o efektywność naszej pracy i procesów. Pośrednio ma to też wpływ na zadowolenie naszego odbiorcy.

Maksymalizować dostarczaną wartość możemy na wiele sposobów. Najbardziej oczywisty, to skuteczne zarządzanie backlogiem i wybieranie do realizacji najbardziej wartościowych wymagań. Ale zwiększenie efektywności pracy, ograniczenie marnotrawstwa oraz optymalizacja całego procesu również pozytywnie wpłynie na nasz produkt.

Dla wyjaśnienia: mówiąc o optymalizacji procesu mam na myśli na przykład sposób wykorzystania frameworku Scrum. Ta metodyka to przepis, który można różnie wykorzystać. Jeżeli damy radę zorganizować się tak, żeby na przykład realizować więcej mniejszych wymagań i dostarczać je szybciej, to na pewno podniesiemy w ten sposób wartość z punktu widzenia zamawiającego i/lub klienta.

Wszystko to – zarządzanie backlogiem, praca Product Ownera, samoorganizacja zespołów, efektywne wykorzystanie Scruma – musi być elementem całościowego spojrzenia. A to znaczy, że optymalizować będziemy wiele różnych aspektów naszej działalności, co z kolei przekłada się na nieuchronne zmiany.

 

Jak się nie zabierać za usprawnienia?

Najczęstszą bolączką większości transformacji agile jest próba zrobienia wszystkiego na raz. Zmieńmy strukturę organizacyjną, wprowadźmy Scrum, DevOps, zbudujmy od nowa listy wymagań i zróbmy kilkudniowe planowanie wydania. Brzmi jak przepis na katastrofę.

Zacznijmy od podstawowego założenia: każda rzecz, która jest dla nas nowa, jest cokolwiek niebezpieczna. Skoro się na czymś nie znamy, to mamy ogromną szansę popełnić błąd. Im bardziej skomplikowane jest nasze przedsięwzięcie (patrz: Cynefin Framework) tym pewniejsze są porażki, potknięcia i nieporozumienia.

W tekście pod tytułem “Zmiany, zmiany, zmiany” przedstawialiśmy założenia modelu Kubler-Ross, który można też zaadaptować do typowej reakcji na zmianę. Powtórzmy to więc jeszcze raz, bo często spotykamy się z niedowierzaniem: każda zmiana, nawet najbardziej pomocna, może na początku zaszkodzić. Może, ale nie musi. Nie bądźmy jednak zdziwieni, gdy nasz nowy lepszy system wspierający pracę powoduje opóźnienia. Ludzie muszą przejść etap wyparcia i/lub nauczyć się jego obsługi.

Dlatego też, jeżeli zmieniamy na raz kilkanaście rzeczy, to w najgorszym przypadku jedna trzecia z nich zaszkodzi, jedna trzecia pomoże, a reszta nie będzie miała żadnego wpływu. I bądź tu teraz mądry i zgaduj, która zmiana okazała się korzystna, a która szkodliwa…

 

Jak usprawniać?

Jeden z działających przepisów na usprawnienia podaliśmy ostatnio w tekście o kryteriach SMART. Z jednej strony pokazaliśmy cechy, jakie powinny mieć dobre cele i akcje naprawcze wprowadzane na przykład po Sprint Retrospective. Z drugiej natomiast zasugerowaliśmy, żeby nigdy nie planować więcej niż dwóch-trzech akcji na iterację.

Powody są oczywiste i zostały wymienione powyżej – nie będziemy w stanie przewidzieć, które zmiany okazały się korzystne, a które wręcz przeciwnie. Ponadto, planując mniej usprawnień możemy się na nich naprawdę skupić i doprowadzić wszystkie do końca. Rozmienianie się na drobne zwykle powoduje, że nie dzieje się nic. Zresztą, zasada Pareto mówi, że 80% efektu pochodzi od 20% działań. Znajdźmy więc te mityczne 20%.

Dlatego właśnie wszystkie zmiany i usprawnienia wprowadzamy iteracyjnie, za każdym razem identyfikując co jest dla nas w danej chwili najważniejsze. Szczególnie w przypadku transformacji nasza organizacja ewoluuje bardzo szybko. Warto co kilka tygodni sprawdzać, czy na pewno obrany przez nas kierunek jest nadal tym optymalnym.

Pamiętajmy też, że punktowe usprawnienia tylko na poziomie zespołu to zwykle plaster naklejany na złamanie otwarte. Potrzebujemy stabilnej, dobrze określonej wizji na poziomie organizacji. Zespoły zazwyczaj sobie poradzą. A jeśli mamy do dyspozycji dobrych Scrum Masterów, to już na pewno. Szkoda tylko, żeby zgrane Scrum Teamy walczyły ze strukturą organizacyjną, managementem i trywialnymi problemami.

Połączmy więc stabilną, promowaną na każdym szczeblu docelową wizję wraz z drobnymi, wprowadzanymi w regularnych odstępach czasu zmianami. W ten sposób wiemy dokąd zmierzamy i ciągle czujemy, że podążamy w dobrym kierunku. A gdybyśmy przypadkiem po drodze się potknęli, szybko uda nam się to zauważyć i skorygować.

I tak zatoczyliśmy koło i skończyliśmy na wałkowanym przez nas wielokrotnie temacie empiryzmu. Czyli wydawałoby się, że to już wszystko wiecie!

 

Przypominam, że poza blogiem, który właśnie czytasz, prowadzimy także aktywny kanał na YouTube. Zapraszamy do subskrypcji!

Tomasz Dzierżek

17 lat doświadczenia w IT, 9 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: