W poprzednich wpisach z cyklu zwinny BIM przedstawiliśmy przyczyny niskiej produktywności w branży budowlanej oraz brytyjskie pomysły na jej przezwyciężenie. Jednym z wielu proponowanych rozwiązań jest wdrożenie metodyki Building Information Modeling (BIM), czyli przede wszystkim usprawnienie komunikacji, gromadzenia, wymiany i dostępu do informacji. W tym wpisie przybliżymy ideę zwinnych metod zarządzania (Agile), a w kolejnych przetłumaczymy zasady Agile na język BIM.

Już w 15 kwietnia organizujemy szkolenie AGILE BIM on-line dla wszystkich zainteresowanych tematyką zwinnych metod w BIM

Formularz zapisów dostępny na stronie terminarza TUTAJ

Inspiracje i początki zwinnych metod zarządzania

Mówiąc rozwoju i zastosowaniu Agile najczęściej myśli się o firmach z branży IT, a jako początek przyjmuje się opublikowany w 2001 roku “Manifest agile”. W rzeczywistości początki i inspiracje należy szukać znacznie wcześniej w branży wytwórczej. W artykule z 1993 roku “The new product development game” [4] przeanalizowano kilka produktów, które przez producentów były uznawane za przełomowe, wnoszące nowoczesne funkcjonalności oraz które odniosły sukces na rynku: Kopiarka Fuji-Xerox FX-3500 z 1978 roku, kopiarka Canon PC-10 z 1982 roku, samochód Honda City z silnikiem 1200cc z 1981 roku, komputer osobisty NEC PC 8000 z 1979 roku, lustrzanka Canon AE-1 z 1976 roku, aparat kompaktowy Canon Auto Boy z 1979 roku. Na podstawie badań wyznaczono 6 charakterystycznych, wspólnych elementów procesu tworzenia nowych produktów, które oddzielnie nie miały znaczenia, a stosowane wspólnie stanowiły receptę na sukces.

Harmonogram prac, źródło: www.businesswire.com

Zostały one określone jako:

Wbudowana niestabilność:

zespół dostaje ambitny cel oraz swobodę w zakresie wykonania projektu. Pozwala to uwolnić się od schematów i utartych ścieżek, aby zaproponować ambitne rozwiązanie.

Samoorganizujące się zespoły:

Kadra kierownicza ogranicza swój udział do wskazówek, finansowania i wsparcia, a samoorganizujące się zespoły w krótkim czasie zaczynają działać podobnie do startup’ów, tworzyć własne nowatorskie pomysły, podejmować ryzyko i uczyć się na błędach. Przykładowo, Honda postawiła na zespół którego średnia wieku wynosiła 27 lat, ponieważ celem projektu było zaprojektowanie samochodu dla ludzi młodych. Zespół potrafił uwolnić się od przyjętych standardów i utartych wzorców i zaproponować zupełnie nową jakość. Aby takie zespoły mogły sprawnie działać, muszą być złożone z przedstawicieli różnych specjalizacji, dzięki temu pojawiały się i były weryfikowane pomysły z różnych punktów widzenia.

Nachodzące na siebie fazy procesu wytwarzania:

Zauważono, że skutkiem ubocznym zespołów składających się z członków o różnej specjalności było nakładanie się etapów procesu tworzenia produktu. Specjalizacje i role zostały rozmyte, cały zespół czuł się współodpowiedzialny za wykonanie zadania, a to spowodowało zmniejszenie ilości błędów i problemów przy przechodzeniu z jednego etapu do drugiego

Wielopłaszczyznowe uczenie się:

Aby zespoły mogły szybko reagować na zmieniające się warunki, powinny stale korzystać z zewnętrznych źródeł informacji oraz metodami prób i błędów szybko zlokalizować i ograniczyć liczbę działających rozwiązań

Subtelna kontrola:

Nadmierna zewnętrzna kontrola zabija spontaniczność i kreatywność, lepszym rozwiązaniem jest połączenie samokontroli zespołu z kontrolą przez presję koleżeńską wynikającą z dążenia do wspólnego celu.

Transfer wiedzy w organizacji:

Zauważono potrzebę transferu dobrych rozwiązań i pomysłów wewnątrz organizacji. Jeden z pomysłów polegał na przesuwaniu kilku posiadających ponadstandardowe umiejętności pracowników pomiędzy projektami.

Zauważono również potrzebę oduczania się, ponieważ niekiedy wiedza i przekonania mogą ograniczać rozwój. Myślę że to najlepiej wyjaśnia powiedzenie “zrobił to, bo nie wiedział że tak się nie da”

Powyższe obserwacje i wnioski stanowią dobrą bazę bo zrozumienia założeń Agile i możliwości jego implementacji z BIM.

Mechanizmy Agile, w formie jaka jest znana obecnie, pojawiły się jako odpowiedź na problemy z realizacją projektów w branży IT. Oprogramowanie było dostarczane zbyt późno i ze sporą ilością błędów, pomimo dużego zaangażowania zespołów i pracy pod presją.

Jaki z tego można wyciągnąć wniosek?

Skoro pracownicy mają odpowiednią wiedzę, pracują ciężko i z zaangażowaniem, a projekty nie osiągają wymaganej jakości i terminowości, oznacza to, że problem znajduje się po stronie organizacji pracy i procesów.

Podobne obserwacje poczynił znacznie wcześniej Edwards Deming, który jest uważany za twórcę sukcesu gospodarczego Japonii po 2 wojnie światowej. Uważał on, że 94% wszystkich błędów w pracy wynika z procesów i systemów, które zależą od kierownictwa, a tylko 6 % od pracownika. Deming był zdecydowanym wrogiem kontroli oraz metod zarządzania przez cele i zarządzania przez wyniki. Uważał że decyzje w sprawach dotyczących procesów i jakości powinny być podejmowane razem z pracownikami, ponieważ to oni wykonują pracę i najlepiej znają proces.

Zadania o różnym stopniu ważności źródło: www.asana.com

Manifest Agile

Część dotyczącą zwinnych metod zarządzania zacznę od omówienia opublikowanego w 2001 roku “Manifest Agile”[1]. Co ważne, pozycje z prawej strony tabeli również są istotne, ale większą wartość przypisuje się tym z lewej strony.

Podstawowe zasady Agile

Z manifestem Agile ściśle związane jest 12 zasad, które rozwinę, tam gdzie to konieczne, w formie niezwiązanej bezpośrednio z branżą IT (poniższe punkty są cytatami bezpośrednio z oryginalnych zasad Agile stworzonych na potrzeby branży IT, więc używanych tam określeń nie należy czytać bez tego kontekstu. np Architektura w punkcie 11 oznacza architekturę oprogramowania, a nie architekturą jako projektowanie budynków) [2] [3]:

1. "Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania."

Celem pracy nie jest zadowolenie biura projektu, generalnego wykonawcy ani spełnienie wszystkich wymagań jakości, ale dostarczenie produktu spełniającego realne oczekiwania klienta. Nie chodzi tu oczywiście o bezrefleksyjne i bez przeprowadzenia odpowiedniej analizy zgadzanie się na wszystko co chce klient, bo to w dłuższej perspektywie doprowadzi do pogorszenia jakości. Warto zwrócić uwagę na łącznik "dzięki", podkreśla on, że satysfakcja klienta jest konsekwencją dostarczenia wartościowego, spełniającego oczekiwania klienta projektu/produktu i na tym należy się skupić. W tym miejscu wrócę do przykładu remontu mieszkania z poprzedniego wpisu z cyklu "zwinny BIM" (7/10). Załóżmy że tym razem rzeczywistym celem będzie zadowolenie Zamawiającego, a nie jedynie spełnienie ustalonych parametrów i ustalonej jakości. Aby to osiągnąć generalny wykonawca (mąż) dzieli pracę na mniejsze kawałki, np dwudniowe, na zakończenie których przedstawia Zamawiającemu (Żonie) to co zostało wykonane. Jeśli okazuje się że zamysł Zamawiającego (Żony) był przez nas inaczej zrozumiany, to jest to dobry moment żeby wprowadzić zmiany. Gdyby ten przykład odnieść do doświadczeń Nas samych, jako wykonujących remonty w swoich domach, okazałoby się, że intuicyjnie bez przypisywania nazwy Agile” postępujemy właśnie w taki zwinny sposób.

2. "Bądźcie gotowi na zmiany wymagań, nawet na późnych etapach projektu. Proces Agile wykorzystuje zmianę do osiągnięcia przewagi we współzawodnictwie na korzyść klienta."

Zakładamy że lista rzeczy do zrobienia jest płynna i można dodawać do niej nowe wymagania, modyfikować istniejące, usuwać zbędne. Nie potrzeba do tego procesów zarządzania zmianą (np. renegocjacji kontraktu). Zawsze będziemy zajmowali się wymaganiami o najwyższym priorytecie. Gotowość na zmiany nie oznacza pracy w chaosie czy też natychmiastową reakcję na zmiany poprzez gaszenie kolejnych pożarów. Zasada ta oznacza skupienie się na gotowości i implementacji zmian nawet na późnym etapie rozwoju produktu dzięki wprowadzeniu odpowiednich technik zarządczych. Należy przestać być zaskakiwanym zmianami i zwinnie się do nich dopasowywać.

3. Dostarczaj funkcjonujące oprogramowanie często, w odstępach od kilku tygodni do kilku miesięcy, im częściej tym lepiej"

W tym punkcie przede wszystkim chodzi o pozyskanie wartościowej informacji zwrotnej, więc nie oznacza to, że trzeba dostarczyć cokolwiek, aby sprawiać wrażenie szybkiego postępu prac. Należy dostarczać tylko te fragmenty produktu/projektu, które spełniają założone kryteria ukończenia, aby na podstawie informacji zwrotnej skorygować kolejne działania.

Waterfall vs. Agile źródło: www.techguide.com.au

4. “Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu"

Metody zwinne działają dzięki krótkiej pętli informacji zwrotnej. Informacje są częste, więc najczęściej szkoda czasu na zbyt sformalizowane zasady i na komunikacje inna niż bezpośrednia. Główną przyczyną nieporozumień podczas pracy nad projektem jest przepaść komunikacyjna między uczestnikami projektu, w tym również między biznesem, projektantami różnych branż, generalnym wykonawcą, klientem. Jednym ze sposobów na zbliżenie tych dwóch światów jest połączenie ich na co dzień. Współpraca w Agile oznacza sprawną komunikację, negocjacje i tam gdzie to konieczne kompromisy. Nie należy jej jednak rozumieć jako rozmycie zakresu obowiązków i przerzucanie zadań pomiędzy członkami zespołu. Każda rola musi mieć jasno określony zestaw zadań i obowiązków za które jest odpowiedzialna.

5. “Projekty powierzaj zmotywowanym jednostkom. Daj im środowisko i wsparcie którego potrzebują i zaufaj im że praca zostanie wykonana”

Głównymi czynnikami blokującymi zwinność projektów jest kontrola i brak zaufania ze strony kierownictwa. W zespołach Agile mamy do czynienia z tzw "mikromanagementem". Rola kierownictwa jest ograniczona do wspierania zespołu, zapewnienia wszystkich elementów niezbędnych do wykonania pracy i usuwania przeszkód. Dobrą analogią roli kierownictwa jest praca ogrodnika. Nie ma on bezpośredniego wpływu jak szybko rośnie roślina, ile wyda owoców, jakiej wielkości i jakości, może stworzyć środowisko, nawozić nawadniać i usuwać chwasty aby wspierać niezagrożony wzrost roślin. Zapewnienie odpowiedniego środowiska nie powinno jednak przybierać formy "matkowania" tzn usuwania każdej możliwej przeszkody, niedopuszczenie do popełnienia błędów, ochronę przed negatywna informacją zwrotną, bo spowoduje to brak samodzielności i nie uczenie się na błędach. Zamiast tego powinno skupiać się na dążeniu do samodzielności, samoorganizacji i uczeniu się na błędach. Warto podkreślić że dla kierownictwa pozbycie się chęci kontrolowania wszystkiego i szukania winnych popełnianych błędów jest niesamowicie trudnym procesem. Warto zrozumieć że popełnianie błędów leży w naturze ludzkiej, skoro ich nie unikniemy to należy je wykorzystać do zdobycia przewagi konkurencyjnej.

6. “Najskuteczniejsza i najwydajniejsza metoda przekazywania informacji zespołowi i wewnątrz niego jest bezpośrednia rozmowa”.

Najprościej mówiąc komunikacja to proces przekazywania informacji od nadawcy do odbiorcy. Jest ona efektywna, jeśli odbiorca potwierdził że dostał komunikat i go zrozumiał. Można wyróżnić 3 rodzaje sposobów komunikacji: mowa ciałą, brzmienie głosu i słowa. Wszystkie 3 elementy są obecne podczas bezpośredniej rozmowy lub wideokonferencji. Podczas rozmowy telefonicznej znika mowa ciała, w komunikacji pisemnej również brzmienie głosu. Dodatkowo powszechnie używana komunikacja e-mail to komunikacja jednokierunkowa - nie otrzymujemy od razu informacji zwrotnej, a odpowiedź można często odłożyć na później. Tam gdzie to jest możliwe należy wykorzystać rozmowy bezpośrednie lub wideokonferencje, dbając jednak przy tym, aby nie zamieniły się w długie i nużące spotkania.

7. “Działające oprogramowanie jest podstawową miarą sukcesu”

Powszechną praktyką tradycyjnie zarządzanych projektów budowlanych jest zdefiniowanie mierzalnych wskaźników postępu projektu, tworzenie różnego rodzaju raportów, arkuszy kalkulacyjnych i prezentacji które dają złudne poczucie kontroli postępu projektu. Często powoduje to podążanie przez zespoły za spełnieniem wymaganego wskaźnika, a nie stojącego za nim celu. Pracując zgodnie z Agile nie jest ważne ile wskaźników osiągnął zespół, tylko jaki jest efekt jego pracy. Przykładowo, nie jest wartością samą w sobie ile błędów i kolizji wykrył zespół w modelu 3D, tylko czy w założonym zakresie jest on skończony i ich pozbawiony. Warto zwrócić uwagę na występujące w tej regule słowo “podstawową”. Istnieje wiele miar które można wykorzystać i warto z nich korzystać, jednak nie powinny być celem samym w sobie.

8. “Procesy zwinne umożliwiają zrównoważony rozwój, wszyscy powinni być w stanie utrzymać równe tempo pracy.”

Praktyka pokazuje, że członkowie zespołów pracujący w nadgodzinach popełniają więcej błędów wskutek przemęczenia. Brak czasu na odpoczynek i odreagowanie stresu źle wpływa na atmosferę w pracy oraz na kreatywność zespołu. Wspólna praca zespołu daje możliwość rozwoju i satysfakcji, ale należy dbać o zachowanie równowagi.

9. “Ciągła koncentracja na technicznej doskonałości i dobrym projekcie poprawia zwinność”

Projekt tworzony w pośpiechu i bez przemyślenia będzie generował wiele problemów na późniejszych etapach. Na początku jest pokusa pójścia na skróty aby wykazać się szybkimi postępami prac. Wraz z zaawansowaniem projektu, wszystkie braki i pobieżnie łatane dziury powodują, że problemy zaczynają się nawarstwiać. Warto tu dodać, że skupieniu się na technicznej doskonałości nie oznacza dążenia do perfekcji, ale na przygotowaniu projektu/produktu tak, aby umożliwiał łatwe i szybkie wprowadzanie zmian w przyszłości.

10. “Prostota - sztuka zwiększania ilości pracy niewykonanej - jest niezbędna”

Oznacza to, że projektant osiągnął optymalne rozwiązanie kiedy nie ma potrzeby niczego nowego dodawać, ale jednocześnie, nic nie może być usunięte.

11. “Najlepsze rozwiązania ~~architektoniczne~~, wymagania i projekty pochodzą od samoorganizujących się zespołów.”

W tym punkcie chodzi przede wszystkim o uwolnienie kreatywności zespołów i szybkie reagowanie na pojawiające się problemy, szanse i zagrożenia. W tradycyjnym, hierarchicznym modelu zarządzania decyzje są podejmowane na wyższych poziomach w hierarchii, często przechodząc przez cały łańcuch akceptacji. Powoduje to, że decyzje nie podejmuje osoba która najlepiej zna problem (szanse) i ma największą wiedzę jak sobie z nim poradzić (wykorzystać), ale osoba, która otrzymała niepełne, przefiltrowane przez poszczególne szczeble hierarchii informacje. Dodatkowo dochodzi tu problem wydłużenia czasu potrzebnego na podjęcie decyzji, co może spowodować że decyzja będzie podjęta już dla aktualnej sytuacji. Odpowiednio zmotywowany zespół, w zakresie przypisanych mu ról i zakresów odpowiedzialności potrafi we własnym gronie skutecznie rozdzielić zadania oraz twórczo podejść do rozwiązania problemów lub wykorzystania szans. Oczywiście samoorganizacja nie oznacza przyzwolenia na anarchię, ale na zespół z doskonałą wewnętrzną dyscypliną, a rolą lidera jest pielęgnowanie odpowiedniego środowiska pracy i powstrzymanie się od narzucania swoich rozwiązań i nadmiernej kontroli.

12. “W regularnych odstępach czasu zespół zastanawia się jak zwiększyć wydajność, a następnie odpowiednio dopasowuje swoje działania do wyciągniętych wniosków”

Podobna zasada zalecająca wyciągania wniosków na przyszłość pojawia się w wielu podejściach do zarządzania projektami. Dla ukończonego projektu takie wnioski są już bezużyteczne, choć oczywiście mogą i powinny być wykorzystane w przyszłych projektach, jednak kto dokładnie pamięta na końcu projektu co wydarzyło się np rok wcześniej? Dużo lepszą praktyką jest wyciąganie wniosków częściej w trakcie trwania projektu. Kiedy zajmujemy się jakimś zadaniem, jesteśmy w niego tak mocno zanurzeni że nie dostrzegamy pełnego otoczenia i wszystkich związanych z nim detali. Właśnie dlatego warto cyklicznie przeprowadzać przegląd projektu i możliwości poprawy wydajności Niezwykle istotne jest przy tym, aby szukanie możliwości poprawy lub zwiększenia wydajności nie było mylone z szukaniem winnych i wytykaniem ich palcami. To spowoduje że zespoły milkną, próbując przetrwać nie “wkopując” innych. Ciągłe wyciąganie wniosków jest jednym z ważniejszych elementów zwinności, szczera rozmowa jest w tym niezwykle ważnym punktem wyjścia do samodoskonalenia, a milczenie oznacza pozbawienie się tej możliwości.

Sprint plans źródło: www.asana.com

Powyższe zasady najlepiej podsumowuje błyskotliwe zdanie jednego z pionierów Agile Scrum, Jeff’a Sutherland’a

“W zarządzaniu zgodnym z Agile chodzi o to żeby pracować sprytniej, a nie ciężej. Nie chodzi o to, żeby wykonywać więcej pracy w krótkim czasie, ale o to, żeby wygenerować więcej wartości z mniejszej ilości pracy.”

Najlepsze praktyki Agile

Na podstawie ogólnych zasad oraz doświadczeń firm pracujących zgodnie z Agile, przedstawiam zebrane w skrócie wspólne, uniwersalne praktyki zwinnych zespołów, które sprawdzały się niezależnie od wielkości firmy, rodzaju działalności i typu projektu [4] :

1. Praca w małych seriach (zmniejszenie wszystkiego) - dzielenie pracy na mniejsze serie pozwala łatwiej sprawdzić czy są robione postępy i otrzymywać szybką informacje zwrotna.

2. Najlepiej sprawdzają się małe wszechstronne zespoły 5-15 osób (optimum 10-12).

3. W pełni ukończona porcja pracy (gotowe a nie prawie gotowe) - należy unikać powszechnie występującego stanu “prawie gotowe”. Prawie gotowe oznacza konieczność powrotu do sprawy (czyli stratę czasu na ponowne wdrożenie się) lub nie skończenie tematu (czyli cały czas przeznaczony na to zadanie był bezproduktywny).

4. Ograniczenie ilości prac w toku - bardzo ważne jest aby nie pracować równocześnie nad zbyt duża ilościa tematów, ponieważ przełączenie się pomiędzy sprawami oznacza stratę czasu na ponowne wdrożenie się w temat lub zwiększenie stanu “prawie gotowy”

5. Zespoły autonomiczne (samoorganizujące się) - firma ustala zasady ogólne, ale to zespoły powinny same decydować jak praca ma zostać wykonana

6. Praca bez przerw- w ramach krótkiego cyklu zespoły starają się pracować bez żadnych zewnętrznych przerw

7. Codzienne spotkania- dzielenie się informacjami o poczynionych postępach w celu identyfikacji przeszkód które wymagają usunięcia. Dodatkową korzyścią jest grupowe rozwiązywanie problemów. Ważne aby była to komunikacja członków zespołu, a nie kontrola lub rozliczanie.

8. Radykalna jawność - jawne publikowanie informacji (kartki na tablicy itp), tak że każdy może się zapoznać jak daleko są posunięte prace i z jakimi problemami zmaga się zespół

9. Reakcje klienta (informacja zwrotna) na koniec każdego krótkiego cyklu