…lucrurile merg bine, deoarece toată lumea face ceea ce trebuie făcut din pură pasiune, atât de desăvârșită încât un observator ar putea concluziona că toți au capacitatea de a-și citi gândurile unii altora. Cu toate acestea, pe măsură ce organizația și produsul cresc, crește și cantitatea de informații pe care echipele trebuie să le stăpânească, să le gestioneze și să le împărtășească pentru a-și face treaba. Deciziile devin din ce în ce mai sensibile la context (atât al echipelor, cât și al produselor), cu o complexitate care imploră un anumit tip de structură pentru ca lucrurile să funcționeze fără probleme pe măsură ce organizația se maturizează. Căutați o structură organizațională care să optimizeze capacitatea echipei de a face lucrurile pentru a crea cea mai mare valoare.

✥ ✥ ✥ ✥

Comunicarea eficientă și feedback-ul sunt în centrul dezvoltării eficiente a sistemelor complexe, iar structura organizațională ar trebui să fie optimizată pentru cele mai importante căi de comunicare. Comunicarea și feedback-ul regulat, împreună cu autoorganizarea, reprezintă inima agilă. Interacțiunea oamenilor cu preocupări diverse și transversale se află în centrul inovării ().

Echipele de dezvoltare care lucrează la produse complexe se luptă continuu cu natura duală a funcției și a formei. Avem tendința de a crea granițe între activitățile de dezvoltare și unitățile organizaționale pe această linie. Cu toate acestea, funcția și forma sunt doar categorii construite social și oarecum arbitrare: fiabilitatea ar putea fi o preocupare la fel de convingătoare pentru un anumit sistem, în timp ce frumusețea, compatibilitatea retroactivă sau o altă preocupare ar putea domina un anumit efort de dezvoltare. În fiecare caz, afacerea va fi servită cel mai bine dacă echipa de dezvoltare se organizează în jurul celor mai cruciale preocupări ale afacerii – oricare ar fi acestea.

Cum echipa dvs. abia începe să se maturizeze în primele zile și începe să se îndrepte spre construirea unei echipe Scrum, aveți mai multe persoane care pot lucra în mod convenabil ca o singură unitate organizațională pentru a acoperi toate funcțiile unei afaceri (planificarea versiunilor, dezvoltarea și creșterea profesională). Dar creșterea și maturitatea provoacă, de asemenea, disconfort, deoarece echipele tânjesc după eficacitatea nestructurată a zilelor simple de lucru informal. Cu toate acestea, pentru a crește și pentru a gestiona corect produsul pe piață este nevoie de o structură organizațională oarecum disciplinată și de o anumită guvernanță ușoară.

Culturile au o nevoie intrinsecă de structură pentru funcționarea eficientă a întregului. Cea mai eficientă comunicare are loc întotdeauna la nivel local, în cadrul tărâmului familiar, așa că este crucială localizarea procesului decizional în jurul celor mai importante preocupări organizaționale. Este important, în orice organizație socială non-trivială, ca oamenii să fie capabili să asocieze rapid orice domeniu de interes dat cu cel mai eficient „loc unde trebuie să se ducă” atunci când au nevoie de informații despre acel domeniu sau trebuie să acționeze în acel domeniu.

O simplă partiționare organizațională (adică o ierarhie) este suficientă în domeniile simple care trebuie să se ocupe de un singur set de preocupări separabile. Dar abordarea ierarhică se prăbușește în cazul mai tipic al eforturilor de dezvoltare cu multiple preocupări care se suprapun. Acest lucru împinge spre unități organizatorice mai mari, mai complexe, care încearcă să corecteze problema prin economii de anvergură. Cu toate acestea, cele mai eficiente echipe de lucru sunt echipele mici și trebuie să partiționați cumva munca.

Cu toate acestea, nicio echipă nu este o insulă, iar o națiune de dezvoltare este mai mult decât o colecție de insule. Echipele își dezvoltă individual propria identitate, unde un sentiment natural de xenofobie (nevoia de familiar) face ca echipele să acorde doar o statura secundară preocupărilor care vin din afara cercului lor social. Dacă limitați întreprinderea la un singur set de interacțiuni sociale, bazate pe o singură partiție simplă, închideți ideile din afara limitelor care alimentează inovația.

Viteza de luare a deciziilor este primordială. Unele probleme sunt urgente („Suntem atacați de un alt trib și trebuie să organizăm o apărare împotriva lor”), în timp ce altele, deși importante, tolerează sau chiar cer o deliberare mai lungă („Care este cea mai bună locație pentru noua sală de ședințe?”). Termenul de straturi de forfecare descrie procese conexe care se deplasează cu viteze diferite, după noțiunea de plăci tectonice care se deplasează una peste alta, cum ar fi cele care conduc la un cutremur. Atât arhitecții de clădiri (), cât și domeniul arhitecturii software (a se vedea ) au adoptat această expresie pentru a descrie structuri sau preocupări cu viteze diferite de schimbare într-un sistem strâns cuplat. O companie ar trebui să își structureze organizația astfel încât să fie capabilă să răspundă rapid la problemele din prima categorie fără a-și distruge eficiența pentru problemele din a doua.

Un alt principiu agil este acela că suntem orientați spre exterior: adică ne concentrăm și ne preocupăm mai degrabă asupra utilizatorului final, a pieței și a clienților decât asupra instrumentelor și tehnologiilor pe care le folosim pentru a ne face munca. Organizația ar trebui să reflecte, de asemenea, această preocupare, deoarece este esențială pentru propunerea de valoare și pentru construcția întregului flux de valoare al dezvoltării.

În final, structura organizației ar trebui să aibă la fel de mult de-a face cu structura procesului ca și cu structura produsului.

De aceea,

Organizați forța de muncă în echipe mici de mai mult sau mai puțin de cinci persoane, împărțite în funcție de cele mai importante preocupări pentru crearea de valoare de către întreprindere. Completați această structură cu un număr mic de structuri transversale pentru preocupări secundare, dar importante, fără a uita niciodată că aceste structuri sunt doar optimizări în ceea ce este, de altfel, un mediu deschis de cooperare fără constrângeri.

Considerați o întreprindere care construiește un telefon mobil. Aceștia și-ar putea organiza echipele Scrum în jurul principalelor livrabile sau opțiuni achiziționabile. Astfel, ar putea exista o echipă pentru agenda telefonică, o alta pentru calendar și o alta pentru funcționalitatea mai tradițională a telefonului: a se vedea Domeniul de valoare. Acestea sunt preocupările principale ale afacerii. Dar pot exista și grupuri care se reunesc pentru a defini practicile, politicile și standardele corporative (de exemplu, aspectul interfeței cu utilizatorul), cuprinzând reprezentanți din fiecare echipă Scrum. Aceste grupuri nu construiesc produse, dar servesc ca schimburi de informații și ca surse de standarde care ghidează dezvoltarea. În organizațiile sănătoase există o suprapunere aproape completă între componența acestor ultime grupuri și componența echipelor de dezvoltare.

În majoritatea mediilor, structura organizatorică primară reflectă structura principală a părților interesate, care este, de obicei, piața. Din acest motiv, nu organizăm echipele Scrum în funcție de împărțirea artefactelor interne și nici în funcție de locațiile de expertiză în domeniu, ci mai degrabă în funcție de produsele livrabile pe piață, cum ar fi caracteristicile. Organizarea în funcție de caracteristici sau de alte livrabile ale pieței este, de asemenea, un avantaj pentru capacitatea de reacție a pieței și pentru reducerea timpului de lansare pe piață, deoarece echipa este locul în care se desfășoară toate lucrările necesare pentru a implementa o caracteristică. Astfel, coordonarea se menține în cadrul unei limite organizaționale. Dacă subansamblurile de lucru sau competențele de bază conduc structura organizațională, atunci schimbările pe piață sau în natura produsului livrabil vor implica probabil coordonarea între mai multe echipe sau organizații – reducând capacitatea de reacție și crescând timpul de luare a deciziilor.

Dacă aceasta este singura structură, ea susține doar viziunea de piață și marginalizează o serie de alte preocupări de afaceri valide. Pentru ca această structură să funcționeze, ea trebuie să fie completată de structuri transversale care susțin un al doilea nivel de eficiență a comunicării, de exemplu, cele legate de competențele de bază. Așadar, acest model apare aproape întotdeauna împreună cu un model precum Birds of a Feather și cu modelul descris în Domain Expertise in Roles. Structura organizațională a rolurilor taie zidurile care se formează în mod natural între echipe. Implică eforturile de produs din cadrul unei întreprinderi să se conecteze între ele și cu managementul executiv prin intermediul MetaScrum-ului. Echipele care au dezvoltat un grad de mândrie de echipă (a se vedea Mândrie de echipă) vor fi mai eficiente, deoarece aceasta sau o altă forță echivalentă va încuraja responsabilitatea. Acest lucru ajută la asigurarea faptului că aceste structuri rămân în joc în ciuda efectelor xenofobe ale apartenenței la o echipă.

Ajustați totul cu un mediu deschis, fără pereți și fără uși. Echipele de dezvoltare sunt unități doar de angajament de dezvoltare și nu ar trebui să existe nicio interferență care să limiteze libera interlucrare între dezvoltatorii din cadrul echipelor. Adăugați mici încăperi în apropiere pentru perioade scurte de liniște, de reflecție serioasă și pentru mici întâlniri.

Care componentă a valorii este un joc corect ca și criteriu de organizare. De exemplu, Scrum apreciază foarte mult colocarea membrilor echipei, astfel încât cele mai de bază limite organizaționale sunt susceptibile de a corespunde echipelor colocate.

✥ ✥ ✥ ✥

Rețineți că există două niveluri ale Legii lui Conway într-un Scrum bun: unul condus de o concentrare pe produs și altul condus de o concentrare pe domeniile de competență. La nivelul de suprafață, organizăm echipa în funcție de proces; aceasta este preocuparea principală atât pentru aspectele de proces orientate spre interior, cât și pentru cele orientate spre exterior. Așadar, cele trei sfere de dominare a procesului sunt:

• echipa de dezvoltare, care deține deciziile privind utilizarea adecvată a tehnologiei și tehnicii în construirea produsului;
• proprietarul produsului, care deține definirea și direcția produsului; și,
• ScrumMaster, care este responsabil de faptul că procesul sprijină livrarea regulată a echipei de dezvoltare.

Echipele de dezvoltare Scrum sunt echipe de caracteristici (produs). Adică, principiul principal de organizare al unei echipe Scrum este că aceasta se aliniază cu un tren de livrări de caracteristici de-a lungul unui flux de valori. Există o organizare ierarhică slabă și superficială în cadrul Scrum care găzduiește mai multe echipe de dezvoltare în cadrul fiecărei dezvoltări de produs, care împart un proprietar de produs comun, într-o organizație numită Scrum of Scrums. Fiecare echipă de dezvoltare din cadrul unei singure dezvoltări de produs construiește un set de caracteristici la un moment dat. În timp, factorii cheie de afaceri, cunoștințele de afaceri comune și artefactele Value Stream vor lega aceste caracteristici între ele. Nu există titluri sau subdiviziuni recunoscute în cadrul echipei de dezvoltare.

Există multe moduri de a împărți munca în echipe de caracteristici. O echipă de dezvoltare poate livra caracteristici pentru o anumită piață (a se vedea Organizația urmează piața) sau poate dezvolta produse pentru un anumit subset al spectrului tehnologic al întreprinderii (o echipă pentru telefoane și alta pentru tablete, deși ambele au în comun o mare parte din același software). În general, fiecare echipă ar trebui să fie formată în jurul unui anumit produs care să reprezinte o componentă a valorii întreprinderii: a se vedea, de asemenea, Value Stream Fork. Cu toate acestea, Scrum descurajează o structură de echipă de dezvoltare în care fiecare echipă deține o parte a produsului sau doar un subansamblu al produsului. Dacă membrii unei singure echipe pot dezvolta doar o singură parte a sistemului, atunci ei vor trebui să coordoneze mai multe decizii de dezvoltare cu alte echipe. Devine dificil pentru echipe să ia decizii la nivel local, iar rezultatele includ feedback și transferuri întârziate.

La cel de-al doilea nivel al Legii lui Conway în cadrul Scrum, oamenii se organizează în jurul domeniilor de competență în care competența generează valoare. Aceste Păsări de Pană îi ajută pe membri să își aprofundeze facilitatea într-un anumit domeniu profesional sau tehnic pe măsură ce fac schimb de idei sau urmează cursuri de formare. Majoritatea oamenilor au o dorință înnăscută de a se îmbunătăți (a se vedea ), iar aceste grupuri alimentează mândria individuală pe măsură ce membrii echipei învață și se dezvoltă. Dar, din nou, aceste grupuri nu formează o structură de raportare și orice membru al echipei poate face parte din mai multe Birds of a Feather, precum și din propria echipă Scrum. A se vedea, de asemenea, Domain Expertise în Roles.

Limitele și identitatea echipei de dezvoltare, precum și limitele și identitatea echipei Scrum sunt explicite. Noțiunea de identitate a echipei este esențială pentru mândria echipei și pentru funcționarea eficientă a organizației, deoarece identitatea echipei aduce contextul social care ajută la optimizarea procesului decizional. Orice noțiune de identitate organizațională dincolo de acestea două ar trebui să fie mai degrabă tacită decât explicită sau administrată. Din nou, în cadrul echipei de dezvoltare nu există alte titluri formale decât „dezvoltator”. Dacă există o singură regulă inviolabilă, aceasta este aceea că niciun individ nu-și poate folosi postul tacit de expertiză pentru a anula un consens de echipă sau pentru a diminua în orice alt mod spiritul de lucru în echipă, ca în „Spiritul jocului”. O Normă de conduită elaborată în comun este un vestitor puternic al identității echipei.

Poate exista expertiză în roluri la nivel individual, dar este important să se completeze acest tipar cu echipe interfuncționale ori de câte ori este posibil pentru a optimiza posibilitatea de a lua decizii la nivel local.

Legea lui Conway originală a apărut din software (vezi , pp. 28-31). Există multe mituri asociate cu originea și practica Legii lui Conway. S-a susținut mult timp că orientarea pe obiecte susținea Legea lui Conway prin localizarea preocupărilor de piață în interiorul claselor. Acest lucru este pe jumătate adevărat; clasele tind să încapsuleze preocupările pe termen lung ale competenței de bază a organizației. Cu toate acestea, orientarea pe obiecte pare să se concentreze pe legătura dintre expertiza dezvoltatorilor și artefactele pe care le dezvoltă, mai degrabă decât pe orice legătură cu piața sau cu cazurile de utilizare. Preocupările pentru alinierea cu structura pieței ar trebui să prevaleze asupra preocupărilor legate de viziunea dezvoltatorilor asupra procesului și produsului lor.

Stilul de dezvoltare în cascadă a avut apogeul său. În organizațiile în cascadă, structura organizațională primară urmărea etapele procesului: analiza cerințelor, proiectarea, implementarea și testarea (, pp. 1-9). Conform legii lui Conway, structura organizațională reflecta aceste preocupări de proces. Software-ul ar putea foarte bine să reflecte și el acele faze: de exemplu, o arhitectură orientată pe servicii (SOA) va evidenția majoritatea cerințelor cu valoare adăugată în stratul de integrare a serviciilor, în timp ce serviciile individuale se găsesc în alt strat. Waterfall pune toate caracteristicile în mâinile dezvoltatorilor deodată, ceea ce sprijină raționamentul cu privire la interacțiunile dintre caracteristici. În timp ce abordările de proiectare a software-ului din epoca cascadelor încercau să alinieze preocupările pieței (cazurile de utilizare) la arhitectură, structura organizațională a tăiat această taxonomie. Același lucru se poate spune despre organizarea pe linie de asamblare în fabrici.

Pentru că echipele de dezvoltare sunt echipe de caracteristici, acestea ar trebui să se concentreze pe câte o caracteristică la un moment dat (ca în Swarming). Principalul livrabil de piață al Scrum este o caracteristică și, în acest sens, există o bună aliniere între structura echipei și piață. Scrum nu spune nimic despre forma arhitecturii produsului, dar, în spiritul agile, tinde să descurajeze proprietatea individuală asupra codului. Fiecare echipă de dezvoltare are licență pentru a lucra la orice parte a produsului. Putem spune că Scrum echilibrează beneficiile organizaționale ale încapsulării cu cele ale alinierii echipei cu produsul livrabil de pe piață. Proprietarul produsului, cu sprijinul echipei de dezvoltare, gestionează modul de gestionare a interacțiunilor caracteristicilor care apar în timp.

Considerați, de exemplu, că o echipă poate implementa caracteristica de așteptare a apelului pentru un sistem de telecomunicații, în timp ce o altă echipă implementează funcția de redirecționare a apelurilor. Din cauza apariției, nu puteți prevedea întotdeauna costul rezolvării dependențelor dintre oricare două elemente date din Product Backlog Items (PBI), astfel încât este, în general, imposibil să depășiți această problemă prin atribuirea PBI-urilor la echipe. În orice caz, atribuirea prematură a lucrărilor la echipe poate face imposibil ca oamenii să lucreze eficient la părțile dificile (în special cele legate de interacțiunea dintre părți) și limitează autoorganizarea la nivelul echipei Scrum. Cele două caracteristici pot fi extrem de interdependente, dar structura Scrum nu conferă o statură de primă clasă acestor interacțiuni. În acest caz, probabil că ar fi mai bine ca o singură echipă să dezvolte ambele caracteristici. Modul în care se alocă munca echipelor se bazează pe o planificare continuă și pe un proces decizional comun, începând cu Planificarea Sprintului. O echipă Scrum bună se străduiește să repartizeze munca între echipele de dezvoltare prin interacțiuni intime, dar încadrate în timp, între Product Owner și echipa de dezvoltare, ca în cazul evenimentelor pentru restabilirea continuă a unui Refined Product Backlog, precum și prin Sprint Planning.

Managementul este de obicei o componentă a mixului organizațional, deși există unele dezvoltări Scrum care funcționează fără manageri (de exemplu, a se vedea videoclipul recent despre transformarea agilă de la Bosch Software Innovations. ) Ethosul Scrum tinde să se concentreze pe oameni și pe produs, iar acest accent este întruchipat în rolurile Scrum și în organizațiile (cum ar fi echipa de dezvoltare și echipa proprietarului produsului) pe care le reprezintă. Dacă o organizație cu manageri preexistenți își propune să introducă Scrum, este prea ușor pentru efortul Scrum să respingă partea de management a organizației ca fiind din altă lume. În astfel de situații, în care o organizație fără management nu este o opțiune, este crucială Implicarea managerilor.

Steven Johnson. De unde vin ideile bune. New York: Riverhead Trade, 2011.

Stewart Brand. Cum învață clădirile: What Happens After They’re Built. New York: Penguin, 1995.

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

Daniel Pink. Drive: Adevărul uimitor despre ceea ce ne motivează. New York: Riverhead Books, 2011.

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

Dr. Winston W. Royce. „Managing the Development of Large Software Systems.ˮ În Proceedings IEEE WESCON, august 1970, pp. 1-9. (Publicat inițial de TRW.)

Bosch Software Innovations. „Lecții învățate: Agile organization at Bosch Software Innovations.ˮ YouTube.com, 15 iunie 2018, https://www.youtube.com/watch?v=CwodQs7D8BY.

Credite imagine: Imagini furnizate de PresenterMedia.com.

.