Scrum może Ci pomóc, jeśli w Twojej firmie źle się dzieje , a Ty nie wiesz, gdzie dokładnie tkwi błąd. Bezlitośnie obnaża wszystkie braki, zachęca pracowników do wzięcia odpowiedzialność, a Ciebie... do jej oddania. Jest prosty i można zastosować go w każdej branży, ale nie jest łatwy, bo każe Ci zmierzyć się z rzeczywistością.
Co to takiego ten tajemniczy Scrum i jak zmienia życie przedsiębiorców? O tym opowiada Tomasz Wykowski, jedyny w Polsce Certyfikowany Trener Scruma i autor książki na temat tej metody.
Dlaczego postanowił Pan napisać książkę Biznes odczarowany. Scrum: jak osiągać cele, gdy wszystko się zmienia?
Od lat uczę Scruma. Kilka lat temu zauważyłem, że w świecie IT jest on już dość dobrze znany, ale poza tym środowiskiem niewiele firm wykorzystuje jego możliwości, a szkoda.
Chciałem tak opowiedzieć o tym temacie, żeby każdy właściciel firmy przekonał się, że Scrum to coś, co może mu pomóc w prowadzeniu biznesu, żeby mógł wziąć książkę do ręki i zacząć u siebie eksperymentować. Chciałem napisać to językiem, który będzie zrozumiały dla każdego, a nie tylko dla branży software’owej.
Rozumiem, że u Was eksperymentujecie, więc chyba mi się udało.
Tak. W Coraz Lepszej Firmie pracujemy m.in. za pomocą metody Scrum. Jestem ciekawa, jak wyjaśni ten termin Certyfikowany Trener Scruma.
Chętnie to zrobię, ale żeby pokazać cały kontekst, cofnijmy się o 100 lat…
W fabrykach na początku XX wieku kierowano się taką zasadą: są ludzie, którzy myślą – niebieskie kołnierzyki – i ludzie, którzy robią – białe kołnierzyki. Niestety, mamy początek XXI wieku, a w wielu organizacjach ten podział nadal się utrzymuje.
Po wojnie w japońskich firmach pojawiły się równolegle pewne idee. Toyota stworzyła wtedy swój słynny system produkcyjny (Toyota Production System) i na nim właśnie bazuje kultura Lean, czyli kultura szczupłej produkcji. To pewna metodyka, sposób działania.
Toyota zmieniła swoje fabryki, wykorzystując potencjał swoich pracowników, wykorzystując inteligencję ludzi, którzy montują samochód. Firma nie traktowała ich jak pary rąk, tylko jak parę rąk i mózg. To spowodowało, że Toyota zaczęła gwałtownie usprawniać swój proces. W jednej z fabryk w Stanach Zjednoczonych była w stanie w ciągu jednego roku wprowadzić 80 tysięcy usprawnień procesu. Większość pomysłów pochodziła nie od ludzi z wykształceniem inżynieryjnym, tylko od tych, którzy przykręcali śrubki. Efekt można zobaczyć, analizując wyniki finansowe firmy.
Z kolei w latach 90. w tworzeniu oprogramowania dążono do odgórnego zarządzania i planowania. Rolę dewelopera sprowadzono do dwóch rąk, które miały zakodować. Na szczęście w końcu pojawił się ruch, który głosił: „Wykorzystajmy potencjał pracowników, wykorzystajmy ich inteligencję i nie twórzmy produktów na zasadzie: zaplanuj i wykonaj plan, bo to nie działa”. W 2001 roku ci ludzie, którzy pracowali w inny sposób, spotkali się w Stanach Zjednoczonych w ośrodku narciarskim w Utah i stworzyli coś, co się nazywa Agile Manifesto. To było dosłownie dwie strony informacji na temat tego, jak trzeba pracować, jakich zasad przestrzegać. Agile, czyli zwinność, to pewna kultura, sposób myślenia, zbiór wartości.
Jakich konkretnie?
Pierwsza i najważniejsza rzecz – zauważenie, że za wszystkimi elementami, które występują podczas tworzenia, stoją ludzie. Niezależnie od tego, jak fantastyczne procesy zrobimy, to jeżeli nie uwzględnimy czynnika ludzkiego, po prostu nie zadziałają. To było widoczne zwłaszcza w latach 90., kiedy próbowano w softwarze realizować bardzo trudne projekty i one fantastycznie wyglądały na papierze, ale po prostu nie działały. Zapomniano o tym, że istotny jest czynnik ludzki.
Kolejną wartością jest skupienie się na użytkowniku końcowym, czyli na dostarczeniu wartości. Wcześniej koncepcja była taka, że podpisujemy kontrakt i naszym głównym celem jest jego realizacja, a nie rozwiązanie problemu użytkownika. W Agile mówimy: „Skupmy się na użytkowniku, a nie na samej umowie”.
I trzeci taki obszar to informacja zwrotna. Dokumentacja projektu może być fantastyczna, ale dopóki nie wiemy, że coś działa, to nie wiemy, że to działa. To jest dosyć istotne w oprogramowaniu, ale nie tylko. Bo w oprogramowaniu tworzono ogromne ilości dokumentacji, a na koniec dnia nie dowożono sprawnego produktu. Dlatego zaczęto wszystko robić małymi krokami, żeby szybko dostać informację zwrotną, zauważyć, jeżeli doszło do pomyłki, i odpowiednio zareagować, a nie brnąć bezmyślnie w błędne założenia.
Jeżeli nie skupimy się na tym, czego potrzebuje użytkownik, to istnieje duże prawdopodobieństwo, że mu tego nie dostarczymy. Więc jeśli nie mamy monopolu na rynku, to zwinność ma duży sens. Zwłaszcza teraz koszty zmiany dostawcy dowolnej usługi są bardzo niskie. Jeżeli nie utrzymamy relacji z klientem, to odejdzie od nas, gdy tylko się dowie, że ktoś robi naszą robotę lepiej.
A gdzie w tym wszystkim jest Scrum?
Scrum to bardzo proste ramy działania, które są na tyle ogólne, że można zastosować je w różnym kontekście i w różnych branżach, wszędzie tam, gdzie wartości Agile są ważne.
W 2001 roku Scrum nie był najbardziej popularnym podejściem, ale później to właśnie on w pewien sposób zdominował ruch agilowy. Większość firm czy zespołów agilowych twierdzi, że używa tej metody. Tutaj wyraźnie zaakcentuję „twierdzi”, bo w rzeczywistości różnie to bywa.
Ramy, które zapewnia Scrum, mają bardzo silny wpływ na to, co dzieje się wewnątrz organizacji. Po pierwsze bardzo szybko pokazują, jakie są problemy, po drugie pozwalają zespołowi przejąć odpowiedzialność, a po trzecie pomagają uzyskać szybką informację zwrotną.
Jak w takim razie pracować, wykorzystując Scruma?
Pomysł jest trywialny, ale bardzo trudny do wykonania, dlatego mówimy, że Scrum jest prosty, ale nie jest łatwy. Koncepcja jest taka: dostarczamy wartość, wartość z punktu widzenia użytkownika zewnętrznego, dowiadujemy się, jak ten użytkownik zareagował na tę wartość, i na podstawie tego ewentualnie zmieniamy sposób działania. Działamy cyklicznie, w okresach miesięcznych, dwutygodniowych czy tygodniowych.
Na przykład jeżeli robimy oprogramowanie, to chcemy mieć jakieś nowe funkcje, jeżeli robimy marketing, to chcemy mieć nowe kampanie marketingowe czy content marketingowy. Generalnie chcemy mieć coś, co jest ważne z punktu widzenia użytkownika. I na koniec cyklu rozmawiamy na temat tego, czy idziemy w dobrym kierunku, czy efektywnie działamy. Jeżeli nie, to zmieniamy sposób działania.
Teoretycznie to bardzo intuicyjne, bardzo proste, natomiast w praktyce, ponieważ musimy trzymać się tej cykliczności i dostarczać wartość co chwila, to bardzo trudne do wykonania.
W swojej książce napisał Pan, że Scrum jest jak teściowa.
Tak, bo żadnego problemu nie rozwiąże, ale wszystkie pokaże. Jeżeli na przykład mówimy ludziom, że są zespołem, ale członkowie dostają cele, które ze sobą kolidują, czyli każdy ciągnie w swoją stronę, każdy ma swoje poletko, to Scrum szybko to pokaże, ale tego nie rozwiąże.
Kto jest potrzebny, żeby można było działać w Scrumie?
Mamy jednego człowieka odpowiedzialnego za końcową decyzję biznesową, ustalenie, co jest najważniejsze w danym momencie – nazywamy go właścicielem produktu, Product Ownerem. Jego celem jest odpowiednie priorytetyzowanie pracy, zrozumienie, jaka jest wizja tego, co robimy, jaka jest strategia jej realizacji, czym jest nasz produkt, jaki problem rozwiązujemy.
Mamy też zespół, w Scrumie nazywa się go Zespołem Developerskim, który ma dostarczać wartość. Nie rozróżniamy żadnych ról wewnątrz zespołu, żeby unikać wzajemnego obwiniania, nie prowokować podejścia typu „ja zrobiłem, a u ciebie to nie było zrobione, więc nie dostarczyliśmy, ale to nie z mojej winy”. Zamiast tego mówimy: „Ty, drogi zespole, jesteś odpowiedzialny za dostarczenie wartości na koniec cyklu”.
No i w końcu fajnie, jeśli jest też Scrum Master – osoba, która obserwuje dynamikę działania i sprawdza, czy naprawdę korzystamy ze Scruma. Czy dostajemy informację zwrotną i czy na nią reagujemy.
Na przykład jeśli za pomocą Scruma pracuje zespół marketingowy, który ma dostarczyć treść, to rynek może mu mówić, że nikt tego contentu nie czyta. I teraz są dwie opcje: albo zespół zacznie coś z tym robić, zmieni formę prowadzenia bloga, może wstawi więcej obrazków, a może zdecyduje się na krótsze artykuły; albo powie: „Nie. Zaplanowaliśmy, że blog wygląda tak, jak wygląda, i trzymamy się dalej tego planu”. To brzmi bezsensownie, ale mimo wszystko wiele firm po tym, jak zaplanowało swój projekt, trzyma się go kurczowo, nawet jeśli się on nie sprawdza.
I po to właśnie jest Scrum Master. Mówi: „Słuchajcie, dostajemy informację zwrotną z rynku, że nie powinniśmy tego robić. Pora coś zmienić”.
Scrum Master powinien się wywodzić z zespołu, z szefostwa czy w ogóle przyjść z zewnątrz?
Dążymy do tego, żeby ludzie działający w Scrumie byli partnerami. Żeby te trzy role były na poziomie partnerskim. Kiedy jest duży dystans pomiędzy Scrum Masterem a zespołem, to szansa, że ktoś z zespołu powie: „Słuchaj, coś u nas nie działa” albo „Zawaliłem”, jest mniejsza.
Z drugiej strony, jeżeli Scrum Master byłby osobą bardzo słabo umocowaną w organizacji, a problem leżałby na zewnątrz zespołu, to szansa, że ten Scrum Master się przebije, byłaby dużo mniejsza.
Zwykle zalecam, żeby człowiek pełniący tę rolę stał na tyle wysoko, żeby miał prawo przekazywać informacje w całej organizacji, a nie tylko wewnątrz zespołu, ale też nie zbyt wysoko, żeby nie onieśmielał ludzi i żeby mogli być wobec niego zupełnie szczerzy.
Znów potwierdza się, jak ważny jest czynnik ludzki.
Ten czynnik ludzki to jest tak naprawdę pamiętanie, że pracownik przychodzi do pracy ze wszystkim. Nie tylko z parą rąk. On jest kreatywny, może rozwiązywać problemy, tylko musimy mu stworzyć środowisko, żeby miał możliwość to robić. Uwzględniajmy to, że ludzie są inteligentni, uwzględniajmy to, że chcą dużo z siebie dawać. Dajmy im taką możliwość.
W przeciwnym wypadku szef będzie musiał uprawiać zarządzanie przez szwendanie: każdemu przypisywać szczegółowe zadania, co więcej, pilnować, czy są realizowane, czy tempo jest odpowiednie. To bardzo czasochłonne i męczące mikrozarządzanie. Ale można też inaczej. Można powiedzieć ludziom: „Słuchajcie, to jest problem, który mamy do rozwiązania, pokażcie mi wynik”.
I w tym drugim przypadku bardzo przydaje się Scrum. Mamy w nim m.in. Review, czyli przegląd tego, co zaplanowaliśmy i co udało się zrealizować na koniec cyklu, nazywanego Sprintem.
Co się dzieje podczas takiego spotkania?
Najlepsze są te przeglądy, które są prowadzone w paradygmacie biznesowego punktu widzenia, czyli nie mówimy, co dostarczyliśmy, tylko jakie problemy użytkownika rozwiązaliśmy i jak użytkownik na to zareagował.
Niestety często spotykam się z tym, że członkowie zespołu przychodzą na spotkanie, pokazują, co każdy z nich zrobił, i rozchodzą się do swoich zajęć. Nie ma to zbyt wiele wspólnego z informacją zwrotną – to bardziej raportowanie. Każdy mówi: „Ja w tym Sprincie zrobiłem to czy tamto”. Wartość biznesowa, informacja zwrotna niewielkie, prawda?
Trochę lepsze zespoły mówią, co zrobiły wspólnie. Natomiast najfajniejsze są zespoły, które przychodzą i opowiadają, jaka jest wartość biznesowa tego, co zrobiły. Czyli z jednej strony, jaki jest feedback od użytkowników, a z drugiej strony, jaki jest feedback od organizacji, czyli ludzi, którzy przyszli na to spotkanie.
Jeszcze raz podkreślę, że dobrze robiony przegląd polega na tym, że rozmawiamy o wartości biznesowej. O tym, jakie mamy opcje, dlaczego idziemy w tym, a nie w innym kierunku.
Czyli ważne jest to, co będziemy mierzyli, jakie dane uwzględnimy?
Tak. Weźmy przykład bloga. Mogę na Review pokazać: A – umieściłem 10 artykułów na blogu, lub B – mieliśmy 2500 odsłon, albo nawet C – w związku z odsłonami sprzedało się tyle i tyle produktów, było tyle i tyle telefonów. Pytanie, które metryki weźmiemy pod uwagę i jak chcemy na to patrzeć.
Scrum nie powie nam, co mamy mierzyć, pokaże tylko, czy idziemy w dobrym kierunku. Jeżeli sobie zdefiniujemy bezsensowne metryki, to będziemy mieć bezsensowne wyniki.
Im bardziej możemy się skupić na wartości biznesowej, tym lepiej.
Żeby nie zgubić tej wartości gdzieś podczas Sprintu, są też w Scrumie codzienne spotkania zespołu, prawda?
Tak. Są potrzebne, gdy pracujemy zespołowo. Jeśli ja potrzebuję czegoś od kogoś, ktoś potrzebuje ode mnie, to codziennie się spotkajmy, pogadajmy, co się dzieje. A jeżeli członkowie zespołu nie potrzebują niczego od pozostałych osób, wtedy nie pracują jako zespół.
Zrobienie z pracowników zespołu nie jest chyba łatwe. Żeby zmobilizować ludzi do współpracy, nie wystarczy przecież powiedzieć: „Pracujemy w Scrumie, a wy jesteście zespołem”.
Tu znowu wracamy do tego, że Scrum wygląda na prosty, ale jest trudny. Nagle pracownik musi zmienić sposób myślenia i postrzeganie tego, jaka jest jego rola w firmie – czy jest w niej człowiekiem od pisania bloga, kodu, czy jest od rozwiązywania problemów klientów. Dopóki będzie się trzymał tej wersji, że musi tylko realizować swoje zadania, i co więcej, firma będzie go w tym wspierała, nagradzając takie zachowanie, dopóty Scrum będzie sprzeczny z tym, co firma mu mówi.
Najwyraźniej widać to w dużych organizacjach. Ludzie nie wiedzą tam, co tak naprawdę robią. Dostają listę zadań i nie mają pojęcia, czy to ma jakikolwiek wpływ na klienta, czy gdyby przestali to robić, to czy klient by to zauważył. Z drugiej strony, jeżeli taki pracownik zobaczy użytkownika, który korzysta z jego produktu, dostanie od niego feedback, to przestaje się czuć jak gość, który montuje śrubki, kod czy artykuły.
Im większa firma, tym ta odległość między człowiekiem wewnątrz firmy a użytkownikiem końcowym jest większa. I Scrum ma tę barierę znieść.
Jeżeli pracownik dostaje feedback od użytkownika na przykład co dwa tygodnie, to może być motywujące. Ale – uwaga – może być też demotywujące, jeżeli się dowie, że użytkownika nie interesuje to, co robi. Jeżeli nikt nie używa jego produktu – Scrum to pokaże. Bez Scruma można iść dalej, robić ten produkt kolejne dwa lata, jeżeli jest budżet. I w dużych firmach to się niestety dzieje, to znaczy z jednej strony rynek mówi, że produkt jest bez sensu, że nie powinny go robić, a z drugiej strony premie zależą od zrealizowania projektu i nagle się okazuje, że te firmy dalej w niego brną.
Myślę, że inną trudnością w Scrumie, poza tym, że jest lustrem, w którym możemy zobaczyć, jak naprawdę nasza praca wygląda i czy ma sens, może być zaufanie, jakim szef, przedsiębiorca, musi obdarzyć pracowników.
Tak, i dopóki nie zaufa ludziom, dopóty będzie robił wszystko, żeby ich kontrolować. Pracując w Scrumie, szef zakłada, że jego ludzie są kompetentni. Jednak z drugiej strony zyskuje też dużą przejrzystość tego, co robią, bo każdy Sprint, czyli ten ustalony cykl, mu to pokazuje. Jeśli zespół nic nie zrobi przez dwa tygodnie, no to Review z szefem firmy będzie bardzo bolesne.
Ale nawet jeśli nie uda się uzyskać zakładanych rezultatów, to od tego jest w Scrumie retrospektywa, żeby poprawić swój proces.
Scrum jest wymagający, ale skuteczny. Jeżeli nie dostarczasz wartości biznesowej, pokaże, w czym tkwi problem. Choć go nie rozwiąże.
I wymaga dojrzałości od liderów.
Owszem, dlatego my jako ProCognita rozwijamy tych liderów. Bo dopóki lider nie da ludziom przestrzeni, to nic się nie wydarzy. I to jest trochę blokada.
To, co my musimy zrobić w takiej sytuacji, to pracować z liderem. Zapewnić mu to bezpieczeństwo, pokazać, że na przykład co dwa tygodnie zobaczy wyniki, ale jednocześnie odwieść go od mikrozarządzania, zupełnie zmienić jego rolę w firmie.
Na jaką?
Cenię koncepcję przywództwa służebnego. Lepiej brzmi to po angielsku – servant leadership. Jej twórcą jest Robert K. Greenleaf. Polega ona na tym, że jeśli jestem liderem, muszę wspierać zespół. Odchodzimy od menedżera, którego rolą jest wyłącznie przypisywanie zadań i podejmowanie wszystkich decyzji. Kiedy idziemy w kierunku zespołu, który sam decyduje, rola menedżera zaczyna być rolą wspierającą.
Jeżeli komuś się bardzo nie podoba sformułowanie servant leadership, to powstał też termin host leadership, taki „organizator przyjęcia”. Jeżeli zaprasza Pani ludzi do domu, to przecież nie tylko po to, żeby patrzyli, jak Pani coś pięknie robi albo jak dziecko pięknie gra na pianinie. Goście nie przyszli wyłącznie dla Pani. Oni się mają dobrze bawić. Trzeba przypilnować, żeby tak było, i ewentualnie zareagować, jeśli ktoś zachowuje się w nieodpowiedni sposób, jeśli stwarza niebezpieczeństwo dla grupy.
To jest nowa rola lidera, menedżera, szefa. Firma nie jest wyłącznie dla niego, nie jest po to, żeby on się dobrze bawił. Jego rolą jest wspomóc swoich ludzi, żeby mogli efektywnie pracować, powinien usunąć wszelkie przeszkody i pozwolić się ludziom rozwijać.
To może być trudne zwłaszcza wtedy, gdy poczucie wartości szefa wynika z władzy, jaką ma w firmie. To nawet na pewno jest trudne, bo w pewnym sensie oddaje się tę władzę, czyli deleguje. Musimy jednak pamiętać, że delegowanie bardzo często jest traktowane zerojedynkowo. Czyli albo sam to robię, albo wcale tego nie robię. A przecież istnieje jakaś skala szarości, czyli na przykład: „Powiedz mi, zanim to zrobisz” albo „Ja ci zasugeruję, ty podejmij decyzję”, albo „Ty mi zasugeruj, ja podejmę decyzję”.
To wszystko łączy się ze Scrumem. Takie zarządzanie jest po prostu konieczne.
Musi też być bardzo motywujące dla pracowników, którzy, po pierwsze, zyskują wpływ na swoją pracę, po drugie, zyskują szefa, który nie rozkazuje, tylko troszczy się o nich, i jeszcze pyta ich o zdanie; i w dodatku chce, żeby się rozwijali.
Tak, to daje fajne efekty i jednocześnie… to jest trudne, zwłaszcza jeśli firma nauczyła ludzi, że nie muszą brać odpowiedzialności. Bo ludzie rodzą się kreatywni, twórczy, chcą podejmować inicjatywę. Ale kiedy wchodzą do firmy i 5 razy odbiją się od szklanego sufitu, to za kolejnym powiedzą: „Dobra, chromolę, nie robię”.
W związku z tym to przejście na inny sposób zarządzania nie wymaga jedynie oddania odpowiedzialności pracownikom, ale również wzięcia odpowiedzialności przez zespół. To się bardzo często dzieje samoczynnie, jednak jeżeli organizacja trwała w danym sposobie działania przez ostatnie 10 lat, to tak łatwo się to nie zadzieje.
Co dokładnie robi ProCognita, kiedy przychodzi do niej taki lider, szef z problemem?
Zwykle mówi nam wtedy: „Coś nie działa, a ja nie wiem, co się dzieje”. Albo druga opcja: „Mieliśmy stabilny rynek, przyszedł covid i nasz rynek się gwałtownie zmienił. Nie możemy już spokojnie pracować i planować działań na rok do przodu”.
W takich sytuacjach najpierw staramy się zrozumieć przyczynę problemów, potem edukujemy klienta, żeby i on mógł je zrozumieć, a w końcu dajemy mu odpowiednie narzędzia, żeby mógł rozwiązać problemy.
Scrum jest na przykład jednym z tych narzędzi, które pomagają naszym klientom zobaczyć, co dokładnie dzieje się w ich firmie.
Waszymi klientami są zwykle korporacje?
To się zmienia. Ja lubię pracować z firmami niedużymi, które rosną. Tam dość szybko można zobaczyć wyniki naszej pracy. Nieduże to dla mnie 20, 40, 100 czy nawet 200 osób.
Z kolei kiedy zaczynamy wprowadzać zmiany w dużej organizacji, to zanim pojawią się wyniki, mija pół roku, rok, czasem więcej. Bo tam ta inercja firmy zwykle jest większa. Oczywiście to nie zależy wyłącznie od liczby pracowników, bardziej od kultury firmy. Bo są małe biznesy, które są mocno usztywnione, i wtedy ten czas się też wydłuża. I są duże organizacje, które są znacznie bardziej dynamiczne.
Proponujecie tym firmom zajęcia dla pracowników, ćwiczenia dla menedżerów, mentoring?
Dopasowujemy podejście do potrzeb klientów. Warsztaty, szkolenia i tak dalej to jest edukacja. To jest wyrównanie wiedzy, to jest wspólne zrozumienie, skąd się bierze problem. Jednocześnie musimy też dać im konkretne narzędzia, sposoby działania, które pomogą go rozwiązać. Tutaj pojawia się mentoring zarówno dla indywidualnych liderów, zespołów, jak i dla całej organizacji.
À propos problemów, podobno lubi Pan podróżować po świecie i odwiedzać różne firmy, obserwując, jak sobie z tymi problemami radzą.
Jedną z rzeczy, które dostałem, przechodząc do własnej firmy, jest to, że jak sobie zaplanuję z wyprzedzeniem podróż, to mogę lecieć. Niestety covid pokrzyżował nam wiele planów. Szkolenia w Indiach musieliśmy odwołać w ostatniej chwili. Ze szkolenia w Amsterdamie też musiałem zrezygnować.
Z jednej strony staram się wykorzystać to, że jestem swoim własnym szefem, i pooglądać świat, a z drugiej próbuję połączyć przyjemne z pożytecznym, czyli jak jestem w jakimś dziwnym kraju, to patrzę, czy na przykład mogę tam wpaść na jakieś spotkanie agilowe. Tak zrobiliśmy z żoną, gdy byliśmy jakiś czas temu w Grecji. Przeprowadziliśmy prezentację dla grupy w Atenach.
Sam też założył Pan grupę agilową w Polsce, prawda?
Tak. ALE Kraków to przede wszystkim przestrzeń wymiany wiedzy bazująca na wartościach agilowych. To też fajny eksperyment społeczny z punktu widzenia tego, jak można budować grupę bez żadnej struktury formalnej, bez takiej idącej z góry decyzyjności.
Bo nie ma formalnego zarządu tej grupy. Dowolna osoba może przyjść z inicjatywą, coś zaproponować, przeprowadzić, chyba że spotka się ze sprzeciwem grupy. Naszym głównym celem jest dzielenie się wiedzą, budowanie zrozumienia.
Ale wracając do podróży, to oprócz tych spotkań agilowych jednocześnie próbujemy też zobaczyć, jak radzą sobie lokalne firmy. Dzięki temu mogliśmy się przekonać, jak działa Google, Amazon, Facebook czy Toyota.
Toyota to był szczególny przypadek, bo ta firma od 10 lat mnie fascynuje. Porównanie tego, jak to wygląda naprawdę, z tym, co czytałem, było bardzo ciekawe. Sprawiło zresztą, że wylądowałem potem jeszcze raz w Toyocie, ale w Polsce. W każdej firmie jedno to jest to, co się ogłasza na zewnątrz, a drugie – co można zobaczyć w środku.
To znaczy, że nie jest tam tak pięknie, jak mówią?
Nie wiem, czy nie tak pięknie, bo to jest perspektywa kogoś z zewnątrz. My byliśmy w szoku, kiedy zobaczyliśmy tempo pracy w Japonii. Jednak pomimo tego dostanie roboty w Toyocie jest w tamtym kraju jak złapanie Pana Boga za nogi. Co ciekawe w Wałbrzychu tempo jest już takie jakby dla mnie naturalniejsze.
Czego się Pan nauczył, obserwując różne firmy na świecie?
Toyota na przykład nadal ma bardzo proste systemy do przekazywania informacji, do wizualizacji. W Wałbrzychu chcieli zwizualizować stan zapasów różnych części oraz wiedzieć, które były najwcześniej wyprodukowane. W branży IT prawdopodobnie zrobilibyśmy do tego oprogramowanie, które byłoby strasznie skomplikowane i drogie. W Toyocie zrobili coś takiego: przywiercili do ściany plastikową pleksę i włożyli w nią specjalne klocki, na których był numer miejsca danego ładunku. Jeżeli ktoś chciał wziąć część X, to szedł do tej tablicy, patrzył na część X i wyciągał klocek z dołu – tam było napisane, gdzie jest ta część. W związku z tym zawsze prawidłowo brał najstarszą część. Wizualnie to było bardzo proste i skuteczne rozwiązanie. I nawet prądu do tego nie potrzebowali.
Poza tym w Toyocie nadal system zgłaszania problemów opiera się na pociągnięciu sznurka, a nie na jakimś skomplikowanym systemie raportowania. Relacje z kilku naszych wizyt umieściliśmy na naszym blogu.
Dzięki podróżom i przyglądaniu się firmom mogę, pracując z klientami, podać im fajne przykłady, żeby pokazać, jak pewne rzeczy działają i jak również oni mogą uprościć sobie życie: usunąć zbędne procesy czy zbyt skomplikowany system.
A czy w Pana firmie coś jeszcze wymaga usunięcia albo uproszczenia? A może wszystko jest super?
Oczywiście, że nie jest super. Gdyby było super, to dopiero wtedy byłoby niebezpiecznie. Właśnie w Toyocie w Wałbrzychu dowiedziałem się, że lider musi tam zrobić obchód po fabryce i znaleźć problemy. Jeśli ich nie znajdzie, wraca do swojego szefa i on mu towarzyszy podczas kolejnego podejścia, bo nieznalezienie problemów nie znaczy, że ich nie ma, tylko że ten konkretny człowiek nie potrafił ich dostrzec.
To jest ta kultura Toyoty, ciągłe poszukiwanie usprawnień, uparcie się, że nawet jeśli zaoszczędzą sekundę tu i sekundę tam, to nagle w skali całej firmy spowoduje to gigantyczne oszczędności.
Czy my mamy przestrzeń do poprawy? Oczywiście, jak każda firma. Na szczęście jesteśmy tego świadomi. Staramy się najpierw ustalić, co jest dla nas najważniejsze. Potem zastanawiamy się, jak to poprawić. A na koniec dowiadujemy się, dlaczego się myliliśmy i jak możemy zrobić to lepiej.
Jakie błędy najczęściej zauważa Pan w firmach swoich klientów?
Po pierwsze robienie wszystkiego naraz. Po drugie robienie różnych rzeczy nie wiadomo po co. Widać to zwłaszcza przy tworzeniu oprogramowania. Dodaje się funkcje, produkt staje się coraz bardziej skomplikowany, a zupełnie nie wiadomo, jaki to mam mieć cel albo sens.
Po trzecie firmy, próbując rozwiązać problem, sprawiają, że staje się on jeszcze bardziej skomplikowany.
Po czwarte mają, powiedzmy, 5 osób i nazywają je zespołem, a tak naprawdę one zespołu nawet nie przypominają.
Piąty z najczęstszych problemów to rozbieżność między tym, do czego dąży organizacja, a tym, czego potrzebuje jej klient.
Odwróćmy w takim razie moje poprzednie pytanie: jakie powinny być firmy?
Wspieram ludzi, żeby byli w stanie budować efektywne organizacje. Takie, które mogą szybko zareagować. Takie, które cały czas się uczą. Takie, które są na tyle dynamiczne, że w momencie, kiedy coś się dzieje, nie chowają głowy w piasek i nie trzymają się kurczowo starego planu, tylko mówią: „Dobra, wiemy coś nowego i możemy odpowiednio zadziałać”. I robią to efektywnie.
Mówimy na to zwinne organizacje, uczące się organizacje. Chodzi o to, żeby firma umiała zobaczyć i zrozumieć, co dzieje się na rynku, i adekwatnie zareagować.
Ale to się nie wydarzy bez odpowiednich liderów. Dlatego ProCognita bardzo ich wspiera.
Dziękuję za rozmowę.
Rozmawiała: Martyna Kosienkowska
Pobierz wideo i checklistę
Jak usprawnić spotkania w firmie
Bądź lepszym szefem –
przestań marnować swoje pieniądze i potencjał swoich ludzi
W 15 minut dowiesz się:
- jakie błędy zabijają skuteczność spotkań
- jak szybciej podejmować decyzje
- co zrobić, żeby pracownicy byli aktywni
- jakich zasad przestrzegać, żeby najlepiej wykorzystać czas.
Mogę cofnąć zgodę w każdej chwili. Dane będą przetwarzane do czasu cofnięcia zgody.
Martyna Kosienkowska
Redaktor bloga Coraz Lepszej Firmy. Wcześniej redaktor prowadzący w wydawnictwach biznesowo-marketingowym i medycznym. Prowadziła kilka blogów internetowych, m.in. o e-handlu i zdrowiu. Współpracowała z wydawnictwami uniwersyteckimi, dbając o wysoki poziom językowy książek.
