Zwinna struktura organizacji

Punkty widzenia

Zwinna struktura organizacji

Zwinne Organizacje | Podcast o agile | odc. 12

Przejście na zwinne sposoby pracy może się wiązać z wprowadzeniem gruntownych zmian w organizacji. Przełamanie silosów staje się koniecznością, która wpływa na potrzebę przeprojektowania struktury. Jak powinna wyglądać zwinna struktura organizacji?

W dwunastym odcinku podcastu „Zwinne organizacje” Paweł Tomkiel i Aleksandra Korzunowicz rozmawiają o tym, co musi się wydarzyć, jeśli myślimy o skalowaniu zwinności na całą organizację. Przejście na zwinne sposoby pracy może się wiązać z gruntownymi zmianami. Do takich należy modyfikacja struktury organizacyjnej, a o tym, jak na nowo ją zaprojektować, dowiesz się z dzisiejszego odcinka.

Słuchasz podcastu Deloitte „Zwinne organizacje”, gdzie wraz z naszymi gośćmi dzielimy się najlepszymi praktykami wdrażania metodyk zwinnych w pojedynczych zespołach, jak i całych organizacjach. Notatki do tego i innych odcinków znajdziesz na naszym blogu Zwinne organizacje

Ola: Cześć, jestem Ola Korzunowicz.

Paweł: Paweł Tomkiel.

Ola: I jesteśmy konsultantami w Agile Advisory w Delloite Digital.

Paweł: Wiele organizacji, kiedy zmienia model działania z tradycyjnego na bardziej zwinny, mierzy się z tym, jak poukładać w tej nowej rzeczywistości strukturę organizacyjną, czyli to, jak zespoły działają, jakie mają odpowiedzialności, jak cała organizacja jest zaprojektowana i jak współgra ze sobą. No i może Olu, zaczniemy od takiego pierwszego pytania:

Czy przejście na agile wymaga zmian w strukturze organizacyjnej?

Ola: Wszystko zależy od skali wprowadzenia zwinności w organizacji. Może być taki scenariusz, w którym zostaje uruchomiony tylko jeden pilotażowy zespół, który działa zwinnie i wtedy nie musimy dokonywać zmian w obszarze całej organizacji. Natomiast, jeżeli zaczynamy już skalować podejście zwinne w organizacji, możemy wybrać jedną z dwóch dróg do zmiany struktury. Jedną jest stworzenie wirtualnej struktury projektowej obok takiej formalnej struktury raportowania liniowego lub wprowadzić trwałe zmiany w takiej formalnej, oficjalnej strukturze.

Paweł: To pierwsze, co powiedziałaś, czyli jeden zespół Agile’owy, to jest chyba coś najczęściej spotykanego na rynku, gdzie organizacja już istnieje trochę lat. Zespoły, szczególnie deweloperskie, zespoły techniczne, dowiadują się o Scrumie, zaczynają Scruma używać i te zespoły mianują się zespołami zwinnymi. Używają jakiegoś frameworka zwinnego będąc zespołem deweloperskim. Tylko najczęściej to jest jeden zespół oderwany od reszty organizacji. To znaczy ten zespół najczęściej dostarcza jakieś oprogramowanie i nie przechodzi na taką pełną zwinność, bo nie ma władzy nad pełnym procesem od pomysłu do wdrożenia. Taki zespół najczęściej przekazuje efekt swojej pracy po prostu do testów.

Ola: To prawda. I wiążę się to z wieloma problemami, które napotykają organizacje, ponieważ chociaż sam zespół chce pracować zwinnie, to środowisko dookoła niego najczęściej zwinne nie jest. Wiąże się to z tym, że w organizacji istnieją różne procesy, na przykład budżetowania, rozliczania potem tego budżetu, alokowania zasobów do poszczególnych projektów. I biorąc pod uwagę, że zwinne zespoły dostarczają wartość częściej, w krótszych odstępach czasu, to może nastąpić konflikt z pozostałymi funkcjami i procesami.

Paweł: Rozmawialiśmy o tym w odcinku z Maćkiem Malesą, gdzie mówiliśmy o tym, że z perspektywy zespołu od pomysłu do dostarczenia tego pomysłu może faktycznie minąć jeden sprint, dwa tygodnie, miesiąc, trzy miesiące, ale z perspektywy całej organizacji od pojawienia się takiego pomysłu w organizacji, zanim ten pomysł zostanie opisany business case’m, zanim zostanie zrobione budżetowanie, alokacja zasobów, potem to trafi do zespołu deweloperskiego, trafi do testów, finalnie trafi do zespołu wdrażającego, to taki time-to-market może wynieść nawet rok. I myślę, że to mocno ogranicza wartość, jaką możemy osiągnąć ze zwinności. John Smart mówi o tym, jako o wybraniu, czy chcemy mieć maksymalną utylizację, maksymalną alokację naszych zasobów, czy może wybieramy szybkość. Bo faktycznie w takim podejściu, gdzie te zasoby alokujemy, gdzie planujemy to wprzód, ta utylizacja jest wyższa, tak? To znaczy pracownicy zawsze będą mieli co robić. Tam, gdzie wybieramy szybkość działania, szybkość podejmowania decyzji, może nie być optymalnej utylizacji, ale jednocześnie time-to-market, który zyskujemy, będzie dużo, dużo krótszy.

Co trzeba wziąć pod uwagę projektując strukturę zwinnej organizacji?

Paweł: To teraz chyba powinniśmy przejść do punktu drugiego, to znaczy, żeby uzyskać tą maksymalną wartość ze zwinności w całej organizacji, co należałoby wziąć pod uwagę, projektując taką organizację zwinną. Jak myślisz, Ola?

Ola: Przede wszystkim poziom naszych aspiracji, to znaczy, czy chcemy zmieniać większość organizacji, wiele departamentów, czy tylko w obszarze IT? Żeby dokonać takich zmian struktury organizacyjnej, powinniśmy przeprowadzić taką gruntowną diagnozę naszego przedsiębiorstwa czy firmy. I często wiąże się to ze zoptymalizowaniem procesu tworzenia wartości. Więc musimy przeanalizować, jakie obecnie mamy stanowiska, jak wygląda w ogóle proces tworzenia wartości i cały cykl projektowy? Jakie istnieją procesy wspierające ten główny proces wytwórczy, ale także jakie mamy systemy, w jakich departamentach one są obsługiwane, w jakich jednostkach są alokowane środki do utrzymania tego systemu? Bardzo kluczowe w tworzeniu nowej struktury jest przeanalizowanie, jakie segmenty klientów obsługujemy, jakimi grupami produktów oraz jakie zyski posiadamy z każdego z tych segmentów czy grup produktów. Wiąże się to z tym, że docelowy model operacyjny może się koncentrować właśnie na jednym z tych elementów, czyli albo na segmencie klientów, albo na grupie produktowej.

Jak na nowo przeorganizować zespoły?

Paweł: No dobrze, Ola, pierwsze, co powiedziałaś, to jest przeanalizowanie, jak aktualnie wygląda struktura organizacyjna. No to teraz wyobraźmy sobie taką standardową organizację. Te działy, które są zazwyczaj i to się raczej nie zmienia, to są działy finansowe, to jest dział HR, to są wszystkie corporate functions, do tego dochodzi jakiś dział IT, który najczęściej jest w roli dostawcy, jest traktowany czasem w organizacji, jako software house - biznes zamawia, technologia dostarcza. I mamy też jakiś biznes, działy zajmujące się produktami, projektami. Załóżmy, że tak wygląda nasza organizacja. To jak teraz z takiej struktury, gdzie ten biznes i IT są w dosyć dużym rozdzieleniu, jak przejść do stanu to be? Jak sobie wyobrazić, jak można podzielić te wszystkie zespoły i ludzi, których mamy teraz na pokładzie, żeby zaprojektować nową strukturę organizacyjną?

Ola: Biorąc pod uwagę, że zespoły zwinne powinny być cross funkcjonalne, musimy wybrać sobie taki archetyp, czyli wzorzec projektowy, który mówi nam, na jakim aspekcie organizacja chce się koncentrować, czyli czy to jest obsługa konkretnej ścieżki klienta, czyli customer journey, czy właśnie grupy produktowej, czy segmentu klientów? I w związku z tym możemy tworzyć najpierw większe komórki, w modelu Spotify są to tribe’y, w Scaled Agile Framework jest to value stream, czyli strumienie wartości. I następnie potem te tribe’y lub value stream’y dekomponować na poszczególne zespoły, czyli squady albo po prostu Scrum teamy, w zależności od tego, jaką nomenklaturę chcemy przyjąć. Wtedy dany tribe koncentrujemy na przykład na grupie produktowej, czyli mamy tribe kredytów konsumenckich, produktów leasingowych czy polis majątkowych.

Paweł: A czy w tym kontekście finansowym, który teraz podałaś, czy bankowość elektroniczna też nie jest jednym z produktów?

Ola: Bankowość elektroniczną możemy traktować, jako kanał dotarcia do klienta. Ponieważ przez aplikację mobilną możemy sprzedawać, czy konta oszczędnościowe, czy kredyty, czy lokaty, czyli różne grupy produktów. Jest to także jeden z archetypów, który może posłużyć do projektowania organizacji i wtedy możemy mieć na przykład tribe omnichannel, tribe aplikacji mobilnej, strony internetowej czy sieci agenckiej.

Paweł: A teraz, bo tutaj nasuwa mi się też takie jedno pytanie, właśnie przechodząc z takiej struktury funkcjonalnej, gdzie mamy podzielone funkcje w organizacji, na taką strukturę bardziej produktową, to jak nałożyć te produkty, załóżmy, że są to kredyty, załóżmy, że są to jakieś grupy produktów, polisy majątkowe, jak to nałożyć na to, co wspomniałaś, czyli na kanały sprzedaży? Jak taki zespół, który zajmuje się konkretnym produktem, może mieć wpływ też na rozwój samych kanałów sprzedaży? Bo bankowość mobilna, aplikacja mobilna, bankowość elektroniczna to różne aplikacje, różne byty, kto się wtedy takimi bytami zajmuje? Kto utrzymuje bankowość elektroniczną, jeżeli mamy zespół produktowy?

Ola: To jest bardzo trudne pytanie, ale ciekawe. I projektując właśnie docelową strukturę organizacyjną, musimy sobie stworzyć pewnego rodzaju macierz, gdzie będziemy mieli z jednej strony główne procesy tworzące wartość, ale także segmenty klientów, i kanały dotarcia, i grupy produktowe, i jeszcze systemy IT. I nie umiem teraz odpowiedzieć na to pytanie, bo to wszystko zależy od tego, jak wygląda organizacja, bo może być na przykład chapter, który będzie się zajmował rozwijaniem danej platformy, na przykład aplikacji mobilnej, i wtedy w każdym squadzie będzie specjalista od takiej aplikacji, a może być zupełnie inne rozwiązanie, które również będzie sprawdzało się w danej organizacji.

Paweł: Nawiązujesz do modelu Spotify, który de facto jest właśnie taką matrycową strukturą organizacyjną, gdzie mamy zespoły produktowe, na które są nałożone zespoły nazwijmy je funkcjonalne. To może być na przykład chapter zajmujący się tylko i wyłącznie user experience, który dba o spójność user experience pomiędzy produktami. Więc ta struktura matrycowa jeszcze w dwóch wymiarach jest całkiem wyobrażalna, ale kiedy nałożymy na to jeszcze segmenty klienta customer journey i procesy, to, to co powiedziałaś wcześniej, chyba robi nam się trochę skomplikowanie, co?

Ola: Dokładnie. I dlatego warto wcześniej dokonać takiej gruntownej diagnozy organizacji, żeby móc wyeliminować jak najwięcej zależności. Ponieważ jak już uruchomimy tribe’y i squady, może się okazać, że koordynacja prac na poziomie kilkuset ludzi będzie po prostu pracą Syzyfową.

Paweł: Mocne słowa, Ola. Ja chyba skupiłbym się na tym też, o czym wspomniałaś – żeby skupić się na zminimalizowaniu zależności podczas projektowania takiej struktury organizacyjnej, bo to znacznie upraszcza nam cały system. To dbanie o zależności, pomiędzy wykonywanymi pracami, w sumie zabiera najwięcej czasu z takiej software’owej rzeczywistości. To te zależności techniczne, kiedy jeden zespół czeka na drugi.

Ola: Tak, i najczęściej uważa się, że można sobie dowolnie zaprojektować strukturę organizacyjną, bo i tak zaimplementujemy jakiś framework typu Large Scaled Scrum czy Nexus, który nam rozwiąże problem zależności, a to nie jest prawda, ponieważ spotykałam się z tym w różnych organizacjach, gdzie mieliśmy siedemnaście tribe’ów i zależności były tak liczne, że żaden artefakt czy żadna ceremonia nie była w stanie rozwiązać danej zależności.

Zespoły powinny mieć wpływ na wartość, która wynika z ich pracy

Paweł: O zależnościach myślę, że możemy nagrać jeszcze całkowicie zupełny odcinek, bo szczególnie trzeba o nie dbać na tym poziomie technicznym, architektonicznym. To tam jest możliwość ich minimalizowania. Ostatnia rzecz, którą chyba chciałbym dodać do tego tematu, to znowu odwołam się do Johna Smarta, on jest autorem frameworku Better Value Sonner Safer Happier, kiedyś też już był wspomniany w tym podcaście. I on proponuje takie podejście do zaprojektowania struktury organizacyjnej, żeby value streamy, jakieś business unity, działy produktowe miały własny strumień przychodu, własny strumień wartości, tak żeby miały wpływ na tą wartość, która rzeczywiście wynika z ich pracy. Czyli takie podzielenie organizacji, gdzie to value stream, czyli strumień wartości, przynosi konkretną korzyść, ale jedną, którą jest w stanie przynosić z minimalnymi zależnościami od innych value streamów. Co o tym sądzisz, Ola?

Ola: Uważam, że jest to bardzo trudne zadanie, jeśli bierzemy pod uwagę, że istnieje już jakaś organizacja od wielu lat, jest ona bardzo duża, najczęściej jest częścią większej grupy kapitałowej, ponieważ wtedy składa się po pierwsze z wielu spółek prawnych, które muszą wykazywać osobne bilanse, gdzie te procesy są najczęściej bardzo zawiłe, gdzie często też musimy się spotykać z wieloma wymogami regulacyjnymi, które narzucają nam określone sposoby właśnie budżetowania i wykazywania, kreowania tej wartości w pieniądzu. Więc byłoby to takie bardzo idealistyczne podejście i bardzo rekomendowane, natomiast bardzo trudno jest je wdrożyć.

Podsumowanie

Czyli podsumowując, powiedzieliśmy dzisiaj, że przejście na Agile wymaga zmian w strukturze organizacyjnej, a do jej zaprojektowania musimy wziąć pod uwagę obecny model operacyjny. Warto zwrócić uwagę na strukturę, procesy oraz architekturę IT, które wskażą nam archetyp, wokół którego będziemy budować docelową organizację.

Jesteśmy ciekawi, jak wygląda zwinność w waszej organizacji, czy jest to zwinność w zespołach deweloperskich, czy może wprowadzacie też metodyki zwinne w zespołach HR, w finansach. Zapraszam na nasz blog „Zwinne organizacje” na stronie delloite.com. Odezwijcie się do nas, napiszcie nam, jak to wygląda w waszej organizacji. Jeżeli chcecie zgłębić temat, to dwukrotnie dzisiaj się pojawił John Smart, odsyłam tutaj do jego frameworku Better Value Sonner Safer Happier. Zapraszam też do naszych poprzednich rozmów z Olą, do odcinka z Maćkiem Malesą, w którym rozmawiamy o mierzeniu wydajności samego zespołu Scrum’owego. No i dziękujemy za wysłuchanie tego odcinka.

Podziel się z nami swoimi doświadczeniami. Jestem ciekaw Twojej opinii. Napisz do mnie ptomkiel@deloittece.com.

 

Zwinna struktura organizacji

„Zwinne organizacje”
Skuteczna pigułka wiedzy o agile

Nie przegap najnowszych treści

Subskrybuj podcast o agile "Zwinne organizacje"

Otrzymuj powiadomienia o nowych odcinkach:
iTunes   Android   RSS   eMail   Spotify

Potrzebujesz wsparcia w swojej organizacji? Chętnie pomożemy!
Widzimy, że produkty cyfrowe można tworzyć o wiele szybciej i taniej, jeśli ludzie będą zorganizowani wokół produktów, a nie wokół wydzielonych funkcji. Wymaga to dużej zmiany, w której pomagamy naszym Klientom. Zachęcamy do kontaktu.
Czy ta strona była pomocna?