…wszystko działa dobrze, ponieważ wszyscy po prostu robią to, co trzeba, z czystej pasji, tak płynnie, że obserwator mógłby dojść do wniosku, że wszyscy mają zdolność czytania sobie w myślach. Jednak wraz z rozwojem organizacji i produktu rośnie ilość informacji, które zespoły muszą opanować, zarządzać nimi i dzielić się nimi, aby wykonać swoją pracę. Decyzje stają się coraz bardziej wrażliwe na kontekst (zarówno zespołów, jak i produktów), a złożoność wymaga pewnego rodzaju struktury, która pozwoli utrzymać płynność działania w miarę dojrzewania organizacji. Szukasz struktury organizacyjnej, która zoptymalizuje zdolność zespołu do załatwiania spraw w celu stworzenia Największej Wartości.

✥ ✥ ✥

Efektywna komunikacja i informacja zwrotna są w sercu efektywnego rozwoju złożonych systemów, a struktura organizacyjna powinna być zoptymalizowana pod kątem najbardziej kluczowych ścieżek komunikacji. Komunikacja i regularne informacje zwrotne, wraz z samoorganizacją, są sercem agile. Interakcja ludzi o zróżnicowanych, przekrojowych problemach leży u podstaw innowacji ().

Zespoły rozwojowe pracujące nad złożonymi produktami nieustannie zmagają się z dwoistą naturą funkcji i formy. Mamy tendencję do tworzenia granic pomiędzy działaniami rozwojowymi i jednostkami organizacyjnymi wzdłuż tych linii. Jednak funkcja i forma to tylko społecznie skonstruowane i nieco arbitralne kategorie: niezawodność może być równie istotną kwestią dla danego systemu, podczas gdy piękno, kompatybilność wsteczna lub inne kwestie mogą zdominować dany wysiłek rozwojowy. W każdym przypadku, biznes zostanie najlepiej obsłużony, jeśli Zespół Deweloperski zorganizuje się wokół najbardziej kluczowych problemów biznesowych – niezależnie od tego, czym one są.

Jak Twój zespół zaczyna dojrzewać w swoich początkach i zaczyna zmierzać w kierunku budowania Zespołu Scrum, masz więcej ludzi, którzy mogą wygodnie pracować jako jedna jednostka organizacyjna, aby pokryć wszystkie funkcje biznesu (planowanie wydania, rozwój i rozwój zawodowy). Ale wzrost i dojrzałość powodują również dyskomfort, ponieważ zespoły tęsknią za nieustrukturyzowaną efektywnością prostych dni pracy nieformalnej. Jednak wzrost i właściwe zarządzanie produktem na rynku wymaga nieco zdyscyplinowanej struktury organizacyjnej i lekkiego zarządzania.

Kultury mają nieodłączną potrzebę struktury dla efektywnego funkcjonowania całości. Najbardziej efektywna komunikacja zawsze odbywa się lokalnie, w obrębie tego, co znane, więc kluczowe jest zlokalizowanie procesu decyzyjnego wokół najbardziej kluczowych problemów organizacyjnych. W każdej nietrywialnej organizacji społecznej ważne jest, aby ludzie szybko byli w stanie skojarzyć każdą daną dziedzinę zainteresowania z najbardziej efektywnym „miejscem, do którego mogą się udać”, gdy potrzebują informacji o tej dziedzinie lub muszą podjąć działania w tej dziedzinie.

Prosty podział organizacyjny (tj. hierarchia) jest wystarczający w prostych dziedzinach, które muszą zajmować się tylko jednym zestawem rozłącznych problemów. Ale podejście hierarchiczne załamuje się w bardziej typowym przypadku wysiłków rozwojowych z wieloma nakładającymi się problemami. To popycha w kierunku większych, bardziej złożonych jednostek organizacyjnych, które próbują rozwiązać problem za pomocą ekonomii zakresu. Jednak najbardziej skuteczne zespoły robocze są Małe zespoły, i trzeba podzielić pracę jakoś.

Jednakże żaden zespół nie jest wyspą, a naród rozwoju jest więcej niż zbiór wysp. Zespoły indywidualnie rozwijają swoją tożsamość, przy czym naturalne poczucie ksenofobii (potrzeba tego, co znane) powoduje, że zespoły nadają jedynie drugorzędną rangę sprawom pochodzącym spoza ich kręgu społecznego. Jeśli ograniczasz przedsiębiorstwo do jednego zestawu interakcji społecznych, opartych na jednym prostym podziale, odcinasz się od pomysłów wychodzących poza granice, które napędzają innowacje.

Szybkość podejmowania decyzji jest najważniejsza. Niektóre kwestie są pilne („Atakuje nas inne plemię i musimy się przed nim bronić”), podczas gdy inne, choć ważne, tolerują lub wręcz błagają o dłuższe zastanowienie („Jaka jest najlepsza lokalizacja dla nowej sali spotkań?”). Termin „warstwy tnące” opisuje powiązane procesy, które poruszają się z różnymi prędkościami, na wzór płyt tektonicznych, które przesuwają się względem siebie, co prowadzi do trzęsienia ziemi. Zarówno architekci budynków (), jak i dziedzina architektury oprogramowania (patrz ) przyjęli ten zwrot do opisania struktur lub problemów o różnym tempie zmian w ściśle sprzężonym systemie. Firma powinna tak skonstruować swoją organizację, aby była w stanie szybko reagować na problemy z pierwszej kategorii, nie niszcząc przy tym swojej skuteczności w przypadku problemów z drugiej kategorii.

Inną zasadą zwinności jest to, że jesteśmy skierowani na zewnątrz: to znaczy, że nasza uwaga i troska skupiają się na użytkowniku końcowym, rynku i klientach, a nie na narzędziach i technologiach, których używamy do wykonywania naszej pracy. Organizacja powinna również odzwierciedlać tę troskę, ponieważ jest ona kluczowa dla propozycji wartości i budowy całego Strumienia Wartości rozwoju.

W końcu struktura organizacji powinna mieć tyle samo wspólnego ze strukturą procesu, co struktura produktu.

W związku z tym,

Zorganizuj siłę roboczą w Małe Zespoły składające się z mniej więcej pięciu osób, podzielone zgodnie z najważniejszymi troskami związanymi z tworzeniem wartości przez przedsiębiorstwo. Uzupełnij tę strukturę niewielką liczbą struktur przekrojowych dla drugorzędnych, ale ważnych spraw, nigdy nie zapominając, że te struktury są tylko optymalizacją w otwartym środowisku nieograniczonej współpracy.

Rozważmy przedsiębiorstwo, które buduje telefon komórkowy. Może zorganizować swoje zespoły Scrum wokół głównych produktów lub możliwych do kupienia opcji. Tak więc może być jeden zespół dla książki adresowej, inny dla kalendarza, a jeszcze inny dla bardziej tradycyjnej funkcjonalności telefonu: patrz Obszar Wartości. To są główne problemy biznesowe. Ale mogą istnieć grupy, które zbierają się, aby zdefiniować praktyki, polityki i standardy korporacyjne (np. wygląd i działanie interfejsu użytkownika), składające się z przedstawicieli każdego Zespołu Scrumowego. Grupy te nie budują produktu, ale służą do wymiany informacji i jako źródła standardów, które kierują rozwojem. W zdrowych organizacjach członkostwo w tych ostatnich grupach niemal całkowicie pokrywa się z członkostwem w zespołach programistycznych.

W większości środowisk podstawowa struktura organizacyjna odzwierciedla podstawową strukturę interesariuszy, którą zazwyczaj jest rynek. Z tego powodu, nie organizujemy Zespołów Scrum wzdłuż podziału wewnętrznych artefaktów, ani według loci ekspertyzy domeny, ale raczej wzdłuż linii produktów rynkowych, takich jak cechy. Organizacja wokół cech lub innych produktów rynkowych jest również korzystna dla szybkości reakcji rynku i skrócenia czasu wprowadzenia na rynek, ponieważ zespół jest miejscem, w którym wykonywana jest cała praca niezbędna do wdrożenia cechy. To utrzymuje koordynację w granicach organizacyjnych. Jeśli podzespoły pracy lub podstawowe kompetencje napędzają strukturę organizacyjną, wtedy zmiany na rynku lub w naturze dostarczanych produktów będą prawdopodobnie wymagały koordynacji między wieloma zespołami lub organizacjami – zmniejszając reaktywność i zwiększając czas podejmowania decyzji.

Jeśli jest to jedyna struktura, obsługuje tylko widok rynku i marginalizuje mnóstwo innych ważnych problemów biznesowych. Aby ta struktura działała, musi być uzupełniona o struktury przekrojowe, które wspierają drugi poziom efektywności komunikacji, np. te związane z podstawowymi kompetencjami. Tak więc ten wzorzec prawie zawsze pojawia się razem z wzorcem takim jak Birds of a Feather oraz wzorcem opisanym w Domain Expertise in Roles. Struktura ról organizacyjnych przełamuje mury, które w naturalny sposób tworzą się pomiędzy zespołami. Zaangażuj wysiłki produktowe w przedsiębiorstwie, aby połączyć się ze sobą i z kierownictwem poprzez MetaScrum. Zespoły, które rozwinęły pewien stopień dumy zespołowej (patrz Team Pride) będą bardziej efektywne, ponieważ ta lub inna równoważna siła będzie zachęcać do odpowiedzialności. Pomaga to zapewnić, że te struktury pozostaną w grze pomimo ksenofobicznych skutków członkostwa w zespole.

Wiąż to wszystko razem z otwartym środowiskiem bez ścian i drzwi. Zespoły deweloperskie są jednostkami wyłącznie zaangażowanymi w rozwój i nie powinno być żadnych zakłóceń ograniczających swobodną współpracę pomiędzy deweloperami w różnych zespołach. Dodaj małe pokoje w pobliżu dla krótkich okresów cichej, poważnej refleksji i małych spotkań.

Każdy składnik wartości jest uczciwą grą jako kryterium organizacyjne. Na przykład, Scrum wysoko ceni kolokację członków zespołu, więc najbardziej podstawowe granice organizacyjne będą prawdopodobnie odpowiadać Zespołom Kolokowanym.

✥ ✥ ✥

Zauważ, że w dobrym Scrumie istnieją dwa poziomy Prawa Conwaya: jeden napędzany przez skupienie się na produkcie, a drugi przez skupienie się na obszarach kompetencji. Na poziomie powierzchniowym organizujemy zespół zgodnie z procesem; jest to główna troska zarówno dla wewnętrznych, jak i zewnętrznych aspektów procesu. Zatem trzy sfery panowania nad procesem to:

• Zespół Deweloperski, który jest właścicielem decyzji dotyczących odpowiedniego wykorzystania technologii i techniki w budowaniu produktu;
• Właściciel Produktu, który jest właścicielem definicji i kierunku produktu; oraz,
• Mistrz Scrumowy, który jest odpowiedzialny za to, że proces wspiera regularne dostarczanie produktów przez Zespół Deweloperski.

Zespoły Deweloperskie Scrum są zespołami cechowymi (produktowymi). Oznacza to, że podstawową zasadą organizacyjną Zespołu Scrum jest to, że dostosowuje się on do ciągu dostaw cech wzdłuż Strumienia Wartości. W Scrumie istnieje słaba, płytka organizacja hierarchiczna, która pozwala na istnienie wielu Zespołów Rozwojowych w ramach każdego rozwoju produktu, dzielących wspólnego Właściciela Produktu, w organizacji zwanej Scrumem Scrumów. Każdy Zespół Deweloperski w ramach jednego rozwoju produktu buduje jeden zestaw cech w danym czasie. Z czasem, kluczowe czynniki biznesowe, wspólna wiedza biznesowa i artefakty Strumienia Wartości połączą te cechy w całość. Nie ma uznanych tytułów ani poddziałów w ramach Zespołu Deweloperskiego.

Istnieje wiele sposobów podziału pracy na zespoły cech. Zespół programistów może dostarczać funkcje na dany rynek (patrz: Organizacja podąża za rynkiem) lub tworzyć produkt dla jakiegoś podzbioru spektrum technologii przedsiębiorstwa (jeden zespół dla telefonów, a drugi dla tabletów, choć oba korzystają z tego samego oprogramowania). Ogólnie rzecz biorąc, każdy zespół powinien być uformowany wokół jakiegoś produktu, który stanowi składnik wartości przedsiębiorstwa (patrz również Widły Strumienia Wartości). Jednak Scrum odradza strukturę Zespołu Deweloperskiego, w której każdy zespół jest właścicielem jednej części produktu lub tylko jego podzespołu. Jeśli członkowie jednego zespołu mogą rozwijać tylko jedną część systemu, to będą musieli koordynować więcej decyzji rozwojowych z innymi zespołami. Zespołom trudno jest podejmować decyzje lokalnie, co skutkuje opóźnieniami w przekazywaniu informacji zwrotnych i handoffami.

Na drugim poziomie Prawa Conwaya w Scrumie ludzie organizują się wokół obszarów kompetencji, w których biegłość napędza wartość. Te Ptaki z Piór pomagają członkom pogłębiać ich umiejętności w jakimś obszarze zawodowym lub technicznym, gdy dzielą się pomysłami lub biorą udział w szkoleniach. Większość ludzi ma wrodzoną chęć doskonalenia się (patrz ), a te grupy podsycają indywidualną dumę, gdy członkowie zespołu uczą się i rozwijają. Ale ponownie, grupy te nie tworzą struktury raportowania, a każdy członek zespołu może należeć do kilku Birds of a Feather, jak również do swojego własnego Zespołu Scrumowego. Patrz również Domain Expertise w Roles.

Granice i tożsamość Zespołu Rozwojowego, jak również granice i tożsamość Zespołu Scrum, są wyraźne. Pojęcie tożsamości zespołu jest kluczowe dla Team Pride i dla efektywnego działania organizacji, ponieważ tożsamość zespołu wnosi kontekst społeczny, który pomaga zoptymalizować podejmowanie decyzji. Każda koncepcja tożsamości organizacyjnej poza tymi dwoma powinna być raczej milcząca niż jawna lub zarządzana. Ponownie, nie ma żadnych formalnych tytułów w ramach Zespołu Deweloperskiego innych niż „Deweloper”. Jeśli istnieje tylko jedna nienaruszalna zasada, to jest nią to, że żadna osoba nie może wykorzystać swojej milczącej pozycji eksperckiej, aby unieważnić konsensus zespołu lub w jakikolwiek inny sposób osłabić ducha pracy zespołowej, tak jak w The Spirit of the Game. Wspólnie opracowane Normy Postępowania są silnym zwiastunem tożsamości zespołu.

Na poziomie indywidualnym może istnieć ekspertyza w rolach, ale ważne jest, aby uzupełnić ten wzorzec Zespołami Cross-Funkcjonalnymi wszędzie tam, gdzie jest to możliwe, aby zoptymalizować możliwość podejmowania decyzji na poziomie lokalnym.

Oryginalne Prawo Conwaya powstało w oprogramowaniu (patrz , str. 28-31). Istnieje wiele mitów związanych z pochodzeniem i praktyką Prawa Conwaya. Długo utrzymywano, że orientacja obiektowa wspiera Prawo Conwaya poprzez lokalizowanie problemów rynkowych wewnątrz klas. Jest to połowiczna prawda; klasy mają tendencję do hermetyzowania długoterminowych problemów związanych z podstawową kompetencją organizacji. Jednak orientacja obiektowa wydaje się skupiać na związku pomiędzy wiedzą programistów a tworzonymi przez nich artefaktami, a nie na jakimkolwiek związku z rynkiem lub przypadkami użycia. Obawy o dostosowanie do struktury rynku powinny przeważyć nad obawami o światopogląd programistów na ich proces i produkt.

Styl wodospadowy rozwoju miał swój okres świetności. W organizacjach kaskadowych, podstawowa struktura organizacyjna podążała za etapami procesu: analizą wymagań, projektowaniem, implementacją i testowaniem (, str. 1-9). Zgodnie z prawem Conway’a, struktura organizacyjna odzwierciedlała te procesy. Oprogramowanie może bardzo dobrze odzwierciedlać te fazy, jak również: na przykład, Service-Oriented Architecture (SOA) będzie udowodnić większość wymagań o wartości dodanej w warstwie integracji usług, podczas gdy poszczególne usługi znajdują się w innej warstwie. Waterfall oddaje wszystkie funkcje w ręce programistów na raz, co wspomaga rozumowanie o interakcjach między funkcjami. Podczas gdy podejścia do projektowania oprogramowania ery wodospadowej starały się dopasować problemy rynkowe (przypadki użycia) do architektury, struktura organizacyjna przecinała tę taksonomię. To samo można powiedzieć o organizacji linii montażowej w fabrykach.

Ponieważ Zespoły Deweloperskie są zespołami cech, powinny skupiać się na jednej cechę na raz (jak w Swarming). Podstawowym produktem rynkowym Scruma jest cecha, i w tym sensie istnieje dobre dopasowanie pomiędzy strukturą zespołu a rynkiem. Scrum milczy na temat formy architektury produktu, ale w duchu agile ma tendencję do zniechęcania do indywidualnej własności kodu. Każdy Zespół Deweloperski ma licencję na pracę nad dowolną częścią produktu. Można powiedzieć, że Scrum równoważy korzyści organizacyjne wynikające z hermetyzacji z korzyściami wynikającymi z dostosowania zespołu do dostarczanych na rynek produktów. Właściciel Produktu, przy wsparciu Zespołu Deweloperskiego, zarządza sposobem radzenia sobie z interakcjami cech, które pojawiają się w czasie.

Rozważmy na przykład, że jeden zespół może zaimplementować cechę Call Waiting dla systemu telekomunikacyjnego, podczas gdy inny zaimplementuje Call Forwarding. Z powodu emergencji nie zawsze można przewidzieć koszt rozwiązania zależności między dwoma dowolnymi pozycjami Rejestru Produktu (PBI), więc w zasadzie nie da się przezwyciężyć tego problemu, przypisując PBI do zespołów. W każdym razie, przedwczesne przypisanie pracy do zespołów może uniemożliwić ludziom efektywną pracę nad trudnymi częściami (szczególnie tymi związanymi z interakcją między częściami) i ogranicza samoorganizację na poziomie Zespołu Scrumowego. Te dwie cechy mogą być wysoce współzależne, ale struktura Scruma nie nadaje pierwszorzędnej rangi tym interakcjom. W tym przypadku, prawdopodobnie byłoby lepiej, gdyby jeden zespół rozwijał obie cechy. Sposób przydzielania pracy zespołom opiera się na ciągłym planowaniu i wspólnym podejmowaniu decyzji, począwszy od Planowania Sprintu. Dobry Zespół Scrumowy stara się podzielić pracę pomiędzy Zespoły Deweloperskie poprzez intymne, ale ograniczone czasowo interakcje pomiędzy Właścicielem Produktu a Zespołem Deweloperskim, tak jak w przypadku wydarzeń mających na celu ciągłe ponowne ustanowienie Ulepszonego Rejestru Produktu, jak również poprzez Planowanie Sprintu.

Zarządzanie jest zazwyczaj składnikiem mieszanki organizacyjnej, chociaż istnieją pewne projekty Scrumowe, które działają bez menedżerów (np. zobacz ostatni film o zwinnej transformacji w Bosch Software Innovations. ) Etos Scrum koncentruje się na ludziach i produkcie, a jego ucieleśnieniem są role w Scrumie i organizacje (takie jak Zespół Deweloperski i Zespół Właściciela Produktu), które reprezentują. Jeśli organizacja z istniejącymi wcześniej menedżerami rozpoczyna wprowadzanie Scruma, zbyt łatwo jest odrzucić część organizacji związaną z zarządzaniem jako coś z innego świata. W takich sytuacjach, gdy organizacja bez kierownictwa nie jest opcją, kluczowe jest Zaangażowanie Kierowników.

Steven Johnson. Where Good Ideas Come From. New York: Riverhead Trade, 2011.

Stewart Brand. How Buildings Learn: What Happens After They’re Built. New York: Penguin, 1995.

Brian Foote i Joseph Yoder. „Big Ball of Mud.ˮ In Pattern Languages of Program Design 4, Brian Foote et al., eds. London: Pearson, 2000.

Daniel Pink. Drive: Zdumiewająca prawda o tym, co nas motywuje. New York: Riverhead Books, 2011.

Melvin E. Conway. „How do committees invent?ˮ In Datamation 14(4), April, 1968, pp. 28-31.

Dr Winston W. Royce. „Managing the Development of Large Software Systems.ˮ In Proceedings IEEE WESCON, August 1970, pp. 1-9. (Pierwotnie opublikowane przez TRW.)

Bosch Software Innovations. „Lessons learned: Organizacja Agile w Bosch Software Innovations.ˮ YouTube.com, 15 czerwca 2018, https://www.youtube.com/watch?v=CwodQs7D8BY.

Picture credits: Images Provided by PresenterMedia.com.

.