Agile dla biznesu: Wdrażanie i zarządzanie zmianą

Wybór projektu Diagram Vanna

Wdrożenie & Zarządzanie zmianą

Każdy wie, że “wprowadzenie zmiany organizacyjnej” wymaga czasu i wysiłku. Niestety nie każdy wie dokładnie, co to oznacza. Przed wprowadzeniem jakiejkolwiek zmiany procesu (“jak pracujemy”) należy zadać sobie kilka kluczowych pytań. W przeciwnym razie prędzej czy później (raczej prędzej) będziesz musiał stawić czoła dokładnie tym samym pytaniom bezpośrednio od osób, których te zmiany dotyczą. Nie ma od tego ucieczki, ponieważ jeśli Twoim celem jest skuteczna zmiana procesów, musisz wiedzieć, jak skutecznie zaangażować ludzi w to, dlaczego muszą zmienić “jak pracujemy”.

Moim zdaniem 3 kluczowe pytania, które należy sobie zadać to: 

    .

  1. Czy wiem, jak ludzie reagują na zmiany?
  2. Jakie są rzeczywiste koszty w porównaniu z potencjalnymi korzyściami tej zmiany?
  3. Ile czasu potrzeba, aby zobaczyć wyniki po wdrożeniu zmiany?

Ad. A)  jak ludzie reagują na zmiany?

Ten prosty wykres pochodzi z książki Raya Immelmana “Great Boss Dead Boss”.Jest raczej oczywisty. Pokaż to wszystkim zaangażowanym w jakąkolwiek zmianę procesu.Ludzie zmieniają postawy w czasie i nie ma w tym nic złego. Musimy to po prostu zaakceptować i utrzymać wszystkich na tej samej stronie z obecnym stanem “gdzie jesteśmy”. To, na czym powinniśmy się skupić, to identyfikacja przeszkód, zbieranie jasnych informacji zwrotnych i jasne przedstawianie powodów zmian wszystkim, których one dotyczą.

Ad. B) Jakie są rzeczywiste koszty i potencjalne korzyści planowanej zmiany?

.

To jest prawdziwy kompromis, którego należy dokonać. Zmiana procesów wymaga zarówno czasu, zasobów, jak i siły woli osób zaangażowanych w zmianę. Jeśli radykalnie nie docenisz, jak duży jest ten podatek, narazisz się na ogromne ryzyko. Obniżenie tymczasowej ilości i jakości dostarczanego produktu końcowego jest jednym z tych zagrożeń, ale jeszcze bardziej niebezpieczne jest „wyciskanie” psychiki ludzi. Im bardziej wyrafinowany jest produkt końcowy (oprogramowanie jest dość wyrafinowane), tym większe wypalenie zespołu można zaobserwować w wyniku wymuszania zmian w procesach, które nie są odpowiednio zarządzane. Zadaj sobie pytanie, czy ryzyko utraty kluczowych członków zespołu jest czymś, co możesz zaakceptować.

Potencjalne korzyści płynące ze zmian są w większości przypadków o wiele bardziej wyeksponowane i błyszczące niż rzeczywiste koszty. Musimy zawsze właściwie ocenić, czy ta “piękna przyszłość” jest naprawdę tak jasna i warta sumy wysiłku.

>

Ogólnie rzecz biorąc, istnieje ryzyko zarówno zbyt częstych zmian, jak i braku jakichkolwiek zmian. Nie ma jasnej definicji, gdzie jest optymalna równowaga między tymi dwoma, ale z pewnością warto ją znaleźć.

Ad. C) Ile czasu potrzeba, aby zobaczyć wyniki po wdrożeniu zmiany?

.

Nikt nie chce angażować się w zmianę procesu, która nie przyniesie żadnych rezultatów. Nawet jeśli wynik jest wyraźnie negatywny, testowanie hipotezy ma pewną wartość.Powinniśmy zaakceptować fakt, że jeśli zmiana nie przyniesie rezultatów, zawsze możemy zrobić krok wstecz. To, czego powinniśmy unikać, to utknięcie w sytuacji, w której nie obserwuje się żadnych wyników zmian (ani dobrych, ani złych) i nie ustalono jasnych ram czasowych/planu reakcji.

Czego unikać podczas wdrażania frameworków/narzędzi Agile? 

Wdrożenie frameworka Agile jest naprawdę trudnym i złożonym zadaniem, ale można je nieco ułatwić, koncentrując się na rzeczach, które są naprawdę ważne w danym momencie (przeczytaj Teorię Ograniczeń – link na dole tego artykułu). 

Podczas pierwszych kroków staraj się skupić na

a) wyborze frameworka/narzędzia, które będzie najbardziej pasować do procesu rozwoju produktu (ale nie denerwuj się, gdy pierwszy wybór ostatecznie nie będzie trwały, po prostu spróbuj innego, jeśli jest w nim wystarczająco dużo potencjalnej wartości)

Kluczowe jest zrównoważenie czasu spędzonego na zastanawianiu się, który framework wybrać, z czasem spędzonym na faktycznej implementacji. Nie ma sensu tracić czasu na forsowanie jakiegoś rozwiązania, gdy jest jasne, że nie przynosi ono wystarczającej wartości. Lepiej być otwartym na zmianę kierunku. Z drugiej strony, jeśli nigdy nie podejmiesz decyzji, nigdy nie przetestujesz żadnego rozwiązania.b) nauczanie o podstawach i ważnych elementach niektórych zwinnych frameworków / narzędzi. 

b) nauczanie o podstawach & ważnych elementach niektórych zwinnych frameworków / narzędzi.

Jest absolutnie konieczne, aby każdy pracujący w określonym frameworku/narzędziu rozumiał, dlaczego i jak będzie go używał. Im szerzej uznawany i akceptowany jest ten powód, tym płynniejszy i mniej stresujący będzie proces transformacji. .  

>

c) nie stawanie się policjantem Agile, który wyraża potrzebę każdej małej zmiany z osobna (bez kontekstu) czytając tylko głośno krótkie fragmenty Scrum Guide (lub podręcznika KanBan).

Zawsze wyrażaj dlaczego jest wartość w danym podejściu/metodzie/zasadzie/artefakcie/wydarzeniu i co możemy stracić jeśli nie zmienimy “jak pracujemy”. Stworzy to wzajemne zrozumienie i rozłoży odpowiedzialność na całą grupę dotkniętą wprowadzeniem zwinnego frameworka.

>

d) nie forsowanie szczegółowych i zbyt szczegółowych rozwiązań dla każdego problemu, który pojawia się podczas adaptacji. 

>

Twoją rolą jest wprowadzenie określonego sposobu myślenia, granic i odpowiedzialności, ale nie faktyczne wprowadzanie zmian w zachowaniu poprzez mikrozarządzanie. Niektórzy członkowie zespołu/interesariusze będą potrzebować Twojej pomocy, aby lepiej zrozumieć rozumowanie, ale ostatecznie to ich zadaniem jest rozwinięcie się w nową odpowiedzialność. Twoim zadaniem jest również ciągłe (przynajmniej w każdej retrospektywie) wywoływanie wyjaśnień i otwieranie dyskusji w celu znalezienia pierwotnej przyczyny pojawiającego się problemu, aby zaangażowane osoby mogły zareagować i samodzielnie znaleźć rozwiązanie.

>

Który projekt wybrać do wdrożenia frameworka Agile?

Nie ma jednoznacznej odpowiedzi na to pytanie, ale z pewnością ten schemat/graf pomoże ci wybrać pewną klasę projektów/produktów.

Najlepszym wyborem będzie projekt/produkt, który jest jednocześnie:
– krytyczny do tego stopnia, że cała organizacja będzie nawet dbać o jego postęp lub regres  ;
– posiadający “przyszłość” pod względem czasu i potencjalnego wzrostu zespołu, aby dać możliwość obserwowania, czy transformacja przyniosła oczekiwaną wartość; 
– wspierany przez klienta/sponsora, który jest “stabilny” zarówno pod względem finansowym, jak i jakości współpracy. Konieczne będzie, aby wszyscy interesariusze zrozumieli, co będzie dla nich oznaczać planowana transformacja. (zmiana sposobu dostarczania wartości, ilość i jakość wartości itp.)

Autor

Łukasz Pawłowski

CEO of Sailing Byte

Prowadzę Sailing Byte – Software House, który koncentruje się na technologiach Laravel i React, ale nie ogranicza się tylko do nich; realizowaliśmy również projekty z wykorzystaniem C#, Unity, Fluttera, SwiftUI i innych technologii. Moja rola polega na organizowaniu i dostarczaniu oprogramowania w metodyce Agile – poprzez zapewnianie doświadczenia, wiedzy i odpowiedniego zestawu narzędzi do współpracy z naszymi klientami. Podczas tej podróży poznałem wielu wspaniałych ludzi, którzy również przyczynili się do rozwoju Sailing Byte jako polskiego Software House’u, dostarczającego wysokiej jakości rozwiązania programistyczne w Europie, Wielkiej Brytanii i Stanach Zjednoczonych.

Powiązane studium przypadku