Respektujesz zasady „Agile Manifesto” – uruchom wyobraźnię, emocje i empatię

Autorzy Agile Scrum Guide Ken Schwaber i Jeff Sutherland zakładają we wstępie swojego przewodnika po metodologii, że Agile Scrum jest: lekki, łatwy do zrozumienia oraz  trudny do opanowania. Na czym polega trudność w opanowaniu podstawowych zasad kilkudziesięciostronicowego bookletu?

Wszystkie role i obowiązki zostały w wyżej wspomnianym przewodniku po Agile Scrum opisane dość szczegółowo i zrozumiale, nawet dla osób niezwiązanych z zarządzaniem projektami.  Jest to swojego rodzaju “service agreement” pomiędzy członkami zespołu, w którym każdy wie jakie są jego obowiązki.

Jest natomiast jeszcze jeden bardzo istotny dokument, który daje większe pole do swobodnej interpretacji Scruma, oraz znacznie odbiega od bardziej sztywnych i oficjalnych metod waterfall’owych, czyli:

AGILE MANIFESTO

Agile Manifesto to zbiór 4 głównych zasad natury moralnej jakie muszą zostać spełnione, aby Agile Scrum jako metoda prowadzenia projektu rozwinął skrzydła w pełni.

1.“Członkowie zespołu i wzajemne relacje ponad procesy i narzędzia.” – “Individuals and interactions over processes and tools.”

Do 10 osób.

Maksymalnie tylu członków zespołu powinien mieć team AGILE, aby być w pełni produktywny i aby komunikacja w zespole przebiegała łatwo, żeby nie powiedzieć “ zwinnie”. Tak mówi o tym Scrum Guide.

Nie trzeba daleko szukać w literaturze związanej z zarządzaniem zespołami aby odnaleźć wspólny mianownik mówiący że 7 osób w rękach jednego managera, to złoty środek na sprawność w delegowaniu zadań.

“In management circles, it is common knowledge that the ideal number of direct subordinates a manager should have is 7±2 (say it with me now: “seven plus or minus two!”)”

source: https://managementforstartups.com/articles/whats-the-ideal-number-of-direct-reports/

Jednak nie w samej liczbie osób w teamie kryje się siła, a raczej w relacjach jakie panują w tak wąskiej grupie dobrze znających się ludzi. Tak mała grupa pracujących w bliskim kontakcie ze sobą specjalistów kojarzyć się może z grupą przyjaciół-pasjonatów zaangażowanych w swój własny startup. Tytuły i doświadczenie oraz ewentualne bariery w komunikacji z tym związane w ogóle nie mają miejsca. Nieformalne omawianie problemów i otwarte komunikowanie ustalonej samodzielnie ilości pracy do wykonania bardziej przypomina rozmowę przy kawie aniżeli deklaracje “ dowiezienia” pod groźba eskalacji.

Jeśli dodamy do tego osobę product ownera (zazwyczaj ze strony klienta), która umie się świetnie wkomponować w zespół oraz Scrum Mastera, który utożsamia się z zespołem developerów jako jego integralny członek, to szacunek dla takiej wartości ponad narzędzia i procesy przychodzi w sposób naturalny.

2. “Działające oprogramowanie ponad obszerną  dokumentację.” – “Working software over comprehensive documentation.”

Świetnie udokumentowane niepowodzenie projektu może być modelowym przykładem zarządzania projektem ze strony Project Managera. Nawet jeśli tego typu stwierdzenie budzi pewne kontrowersje zakładam, że większość PMów potrafi,  bazując oczywiście na doświadczeniu swoich kolegów po fachu, bo przecież nie własnym…:), przywołać choć jeden taki projekt w pamięci.

Agile Manifesto wyjaśnia to już w drugim punkcie.

Takie postawienie sprawy bardziej zwraca uwagę Scrum Mastera na ciągły dialog w stronę swojego zespołu zadając sobie i innym pytanie: Co zrobić żeby działało?, zamiast  tłumaczenia klientowi: dlaczego nie działa?

Jest jeszcze jeden element niezbędny w tego typu komunikacji a jest nim nieczęsto pojawiające się w biznesie słowo “zaufanie”. Scrum Master z  technicznym backgroundem rozumiejący szczegóły pracy developerów i potrafiący samodzielnie oszacować czas na konkretne zadania, to chodzące złoto. Nie wszystkie firmy mogą sobie jednak na taki komfort pozwolić. Dlatego też kwestia budowania otwartości i zaufania w zespole jest jednym z kluczowych motorów działającej współpracy a co z tym idzie działającego oprogramowania.

3. “ Współpraca z klientem ponad formalne ustalenia” – “ Customer collaboration over contract negotiation”

Kolejny dość odważny warunek do spełnienia. Szczególnie jeśli rozmawiamy o wielomilionowych budżetach i umowach sprawdzanych kilkukrotnie przez prawników. Dla handlowców negocjujących warunki umów wręcz kontrowersyjny. Sprowadzając natomiast tę zasadę na podwórko AGILOWE, gdzie naszym bezpośrednim klientem najczęściej jest Product Owner stanowiący integralną część zgranego zespołu, jest to kolejny element wynikający z codziennej współpracy.

Czy odnieść się pozytywnie do ostatniej rozmowy, czy do zapisu umowy?

W tym przypadku umiejętność aktywnego słuchania u Scrum Mastera jest ceniona zdecydowanie wyżej, niż umiejętność czytania ze zrozumieniem.

4. „Reagowanie na zmiany ponad podążanie za planem” – „Responding to change over following a plan”

Z punktu widzenia AGILE zmiana nie jest elementem pojawiającym się w projekcie, którym trzeba zarządzać. Zmiana jest jego integralną częścią. Takie wyjaśnienie procesu w zespole na samym początku projektu bardzo ułatwia pracę w dalszych jego fazach.

Ponadto Scrum Master nie zarządza zmianą, ale zarządza emocjami swojego zespołu w trakcie kiedy zmiany zachodzą. Najlepsi mistrzowie sztuki zarządzania, wiedzą jak obawy członków swojego zespołu zamienić na emocje oczekiwania czegoś pozytywnego, co nadchodzi wraz ze zmianą.

Zmiana w Agile Scrum to znak, że nasza idea zaczyna się klarować i różnice pomiędzy tym czego spodziewa się klient, a  tym co zostało do tej pory wytworzone maleją. Jesteśmy bliżej tego o co nam wszystkim tak naprawdę chodzi.

Podsumowanie

Co więc stanowi trudność w zwinnych metodologiach zarządzania? Zaufanie, wzajemny szacunek, otwartość, transparentność, prawo do popełniania błędu, elastyczność i inne umiejętności miękkie. Zachowania, których nie da się przyswoić w ciągu weekendowego kursu lub zakuwając podręcznik w kilka dni, a których trening zajmuje często długie lata.