Niedawno rozmyślałem o popularnych Agile'owych frameworkach oraz podejściach do transformacji Agile. Wydaje mi się, że są one zbyt mechaniczne i również wydaje mi się to jedną z przyczyn niepowodzenia wielu procesów transformacji organizacyjnej. W poprzednim poście pisałem o sytuacjach, w których zmiany powodują zbyt duży ból w organizacji, a to prowadzi do odrzucenia nowych procesów (lub ich mutacji).

Udana transformacja Agile pociąga za sobą zmianę kultury, sposobu myślenia i wzorców zachowań. Psychologia od dawna zajmuje się tym samym problemem (z innymi celami i warunkami), więc prawdopodobnie ma kilka rzeczy, które moglibyśmy zaadaptować do celów transformacyjnych.

W swojej książce "Counseling and Psychotherapy: Newer Concepts in Practice" Carl Rogers (jeden z najbardziej wpływowych psychologów XX wieku) podaje zestaw pytań, które terapeuta powinien wziąć pod uwagę podczas pracy z klientem. Te pytania odgrywają kluczową rolę w wyborze odpowiedniego leczenia. Przy nieznacznej adaptacji, pytania te można wykorzystać w kontekście transformacji Agile, aby określić podejście do zmiany.

Czy klient jest pod presją?

"Jedną z pierwszych obserwacji, jaką dokona mądry klinicysta, jest stopień, w jakim klient znajduje się w stanie napięcia lub stresu." - pisze Rogers. "Doradztwo może być pomocne tylko wtedy, gdy występuje pewien stres psychiczny wynikający ze stanu nierównowagi."

Czy ma to zastosowanie w naszej sytuacji? Zdecydowanie tak. Jeśli ludzie w organizacji są usatysfakcjonowani tym jak się sprawy mają, zmiana będzie odbierana jako niepożądane zakłócenie. Stworzy to bardzo silny opór przed zmianami, powodując szansę zmiany niemalże niemożliwą. Ale jeśli ludzie czują, że rzeczy nie są takie jak by chcieli; jeśli czują, że coś musi być zrobione inaczej - taki rodzaj stresu może dostarczyć wystarczającego bólu, który usprawiedliwi stres wywołany samą zmianą.

"Zasadniczo najdokładniejsze stwierdzenie tej sytuacji wydaje się, że zanim poradnictwo może być skuteczne, napięcia wywołane tymi sprzecznymi pragnieniami i żądaniami muszą być bardziej bolesne dla jednostki, niż ból i stres związany ze znalezieniem rozwiązania konfliktu.". Dlatego uczeni zarządzania i inteligentni menedżerowie podkreślają znaczenie pielęgnowania poczucia pilności i niezadowolenia przy rozpoczynaniu zmiany. Niezadowolenie i nagła potrzeba powodują stres potrzebny do usprawiedliwienia (choćby nawet pożądania) bólu zmiany.

Czy klient jest w stanie poradzić sobie z sytuacją?

"Czasami zapomina się, że każdy rodzaj psychoterapii zależy od jej rezultatów przy założeniu, że jeśli dana osoba otrzyma pomoc w reorientacji, reorganizacji swojej postawy w nowych wzorcach, może bardziej normalnie i przy mniejszym wysiłku sprostać dostosowaniom swojego życia i może znaleźć zdrowe satysfakcje w społecznie zaaprobowany sposób."

To pytanie jest bardzo ważne dla każdego procesu transformacji Agile. Jeśli organizacja, którą pomagasz przekształcić, nie jest w stanie poradzić sobie z nowymi sposobami pracy, nie może się przekształcić. Wyobraź sobie zespół, który customizuje oprogramowanie opracowane przez dużą firmę. 98% ich customizacji zależy od pewnych aktualizacji, które dostają od firmy. Producent oprogramowania dostarcza te aktualizacje dwa razy w roku w dużych partiach. Zespół spędza więc większość czasu w stanie bezczynności, oczekując na nową aktualizację.

Czy ten zespół może czerpać jakiekolwiek korzyści z wdrożenia zasady dotyczącej wydawania małych partii z 2-tygodniową iteracją? Być może, ale większość iteracji będzie bezczynnych (z zerowymi wydaniami). Taka zmiana doprowadzi do frustracji członków zespołu i nie stworzy żadnych korzyści dla zespołu ani klienta.
Innymi przykładami może być podzespół pracujący w środowisku opartym na planach w Scrumie. Oczywiście mogliby oni czerpać korzyści z ulepszonej współpracy i częstego planowania, ale korzyści te będą ograniczone przez fakt, że mają zbyt wiele zewnętrznych zależności, aby dostarczyć każdy Sprint. W tym przypadku Scrum prawdopodobnie przyniesie zbyt duży ogólny koszt w porównaniu do korzyści.

Ciąg dalszy nastąpi.

Sergey Makarkin
Chief Program Manager