…asiat toimivat hyvin, sillä kaikki tekevät vain sitä, mitä on tehtävä puhtaasta intohimosta, niin saumattomasti, että tarkkailija voisi päätellä, että kaikilla on kyky lukea toistensa ajatuksia. Organisaation ja tuotteen kasvaessa kasvaa kuitenkin myös tiedon määrä, jota tiimien on hallittava, hallittava ja jaettava saadakseen työnsä tehtyä. Päätökset ovat yhä herkempiä asiayhteydelle (sekä tiimeille että tuotteille), ja niiden monimutkaisuus vaatii jonkinlaista rakennetta, jotta asiat pysyisivät sujuvina organisaation kypsyessä. Etsit organisaatiorakennetta, joka optimoi tiimin kyvyn saada asiat tehtyä Suurimman arvon luomiseksi.

✥ ✥ ✥ ✥

Tehokas viestintä ja palaute ovat tehokkaan monimutkaisten järjestelmien kehittämisen ytimessä, ja organisaatiorakenne olisi optimoitava viestinnän keskeisimpiä väyliä varten. Viestintä ja säännöllinen palaute yhdessä itseorganisoitumisen kanssa ovat ketterän sydän. Erilaisia, monialaisia huolenaiheita käsittelevien ihmisten vuorovaikutus on innovaation ytimessä ().

Kehitysryhmät, jotka työskentelevät monimutkaisten tuotteiden parissa, kamppailevat jatkuvasti toiminnon ja muodon kaksoisluonteen kanssa. Meillä on taipumus luoda rajoja kehitystoimintojen ja organisaatioyksiköiden välille näiden linjojen mukaisesti. Toiminto ja muoto ovat kuitenkin vain sosiaalisesti rakennettuja ja jokseenkin mielivaltaisia kategorioita: luotettavuus saattaa olla yhtä pakottava huolenaihe tietyssä järjestelmässä, kun taas kauneus, taaksepäin yhteensopivuus tai jokin muu huolenaihe saattaa hallita tiettyä kehitystyötä. Kussakin tapauksessa liiketoimintaa palvelee parhaiten se, että kehitystiimi organisoituu keskeisimpien liiketoiminnallisten huolenaiheiden ympärille – olivatpa ne mitä tahansa.

Kun tiimisi alkaa vasta kypsyä alkuvaiheessa ja alkaa siirtyä kohti Scrum-tiimin rakentamista, sinulla on useampia henkilöitä, jotka pystyvät kätevästi työskentelemään yhtenä organisaatioyksikkönä kattaakseen kaikki liiketoiminnan toiminnot (julkaisusuunnittelun, kehitystyön ja ammatillisen kasvun). Mutta kasvu ja kypsyminen aiheuttavat myös epämukavuutta, kun tiimit kaipaavat yksinkertaisten päivien epävirallisen työskentelyn jäsentymätöntä tehokkuutta. Silti kasvaminen ja tuotteen asianmukainen hallitseminen markkinoilla edellyttää jonkin verran kurinalaista organisaatiorakennetta ja kevyttä hallintoa.

Kulttuureilla on luontainen tarve rakenteeseen kokonaisuuden tehokkaan toiminnan kannalta. Tehokkain viestintä tapahtuu aina paikallisesti tutun piirissä, joten on ratkaisevan tärkeää lokalisoida päätöksentekoprosessi tärkeimpien organisatoristen huolenaiheiden ympärille. Missä tahansa muussa kuin triviaalissa sosiaalisessa organisaatiossa on tärkeää, että ihmiset pystyvät nopeasti yhdistämään minkä tahansa kiinnostuksen kohteen tehokkaimpaan ”paikkaan mennä”, kun he tarvitsevat tietoa kyseisestä alueesta tai kun heidän on ryhdyttävä toimiin kyseisellä alueella.

Yksinkertainen organisatorinen jako (eli hierarkia) riittää yksinkertaisilla alueilla, joilla on käsiteltävä vain yhtä joukkoa erotettavissa olevia asioita. Hierarkkinen lähestymistapa hajoaa kuitenkin tyypillisemmässä tapauksessa, kun kehitystyössä on useita päällekkäisiä huolenaiheita. Tämä johtaa suurempiin ja monimutkaisempiin organisaatioyksiköihin, jotka pyrkivät korjaamaan ongelman mittakaavaetujen avulla. Tehokkaimmat työryhmät ovat kuitenkin pieniä tiimejä, ja työ on jollakin tavalla jaettava.

Yksikään tiimi ei kuitenkaan ole saari, ja kehitysmaa on enemmän kuin kokoelma saaria. Tiimit kehittävät yksilöllisesti oman identiteettinsä, jossa luonnollinen muukalaisvihamielisyys (tarve tuttuun) saa tiimit antamaan vain toissijaisen aseman niiden sosiaalisen piirin ulkopuolelta tuleville huolenaiheille. Jos yritys rajataan yhteen ainoaan yksinkertaiseen jaotteluun perustuvaan sosiaaliseen vuorovaikutukseen, suljetaan rajat ylittävät ideat, jotka ruokkivat innovointia.

Päätöksenteon nopeus on ensiarvoisen tärkeää. Jotkin asiat ovat kiireellisiä (”Toinen heimo on hyökännyt kimppuumme, ja meidän on ryhdyttävä puolustautumaan heitä vastaan”), kun taas toiset, vaikkakin tärkeät, sietävät pidempää harkintaa tai jopa kerjäävät sitä (”Mikä on paras paikka uudelle kokoussalille?”). Termi leikkaavat kerrokset kuvaa toisiinsa liittyviä prosesseja, jotka etenevät eri nopeuksilla, kun otetaan mallia tektonisista lautasista, jotka liikkuvat toistensa poikki, kuten maanjäristystä edeltävässä liikkeessä. Sekä rakennusarkkitehdit () että ohjelmistoarkkitehtuurin ala (ks. ) ovat ottaneet ilmaisun käyttöön kuvaamaan rakenteita tai huolenaiheita, joilla on erilainen muutosnopeus tiukasti kytketyssä järjestelmässä. Yrityksen olisi rakennettava organisaationsa niin, että se pystyy reagoimaan nopeasti ensimmäisen kategorian ongelmiin tuhoamatta tehokkuuttaan toisen kategorian ongelmien osalta.

Toinen ketterä periaate on se, että olemme ulospäin suuntautuneita: eli keskitymme ja huolehdimme pikemminkin loppukäyttäjistä, markkinoista ja asiakkaista kuin työvälineistä ja teknologioista, joita käytämme työmme tekemiseen. Organisaation tulisi heijastaa myös tätä huolenaihetta, sillä se on avainasemassa arvolupauksen ja koko kehityksen arvovirran rakentamisen kannalta.

Organisaation rakenteen tulisi loppujen lopuksi olla yhtä paljon tekemisissä prosessin rakenteen kuin tuotteen rakenteen kanssa.

Siten,

Organisoi työvoima pieniin, noin viiden hengen tiimeihin,

jotka on jaettu sen mukaan, mitkä huolenaihiot ovat tärkeimpiä yrityksen arvonluonnin kannalta. Täydennä tätä rakennetta pienellä määrällä poikkihallinnollisia rakenteita toissijaisia mutta tärkeitä huolenaiheita varten unohtamatta koskaan, että nämä rakenteet ovat vain optimointeja muutoin avoimessa ja rajoittamattoman yhteistyön ympäristössä.

Harkitse yritystä, joka rakentaa matkapuhelinta. Se saattaa järjestää Scrum-tiiminsä tärkeimpien tuotosten tai ostettavien vaihtoehtojen ympärille. Niinpä voi olla yksi tiimi osoitekirjaa varten, toinen kalenteria varten ja kolmas perinteisempiä puhelintoimintoja varten: katso Arvoalue. Ne ovat liiketoiminnan ensisijaisia huolenaiheita. Voi kuitenkin olla ryhmiä, jotka kokoontuvat määrittelemään käytäntöjä, toimintatapoja ja yritysstandardeja (esim. käyttöliittymän ulkoasua) ja jotka koostuvat kunkin Scrum-tiimin edustajista. Nämä ryhmät eivät rakenna tuotetta, vaan toimivat tiedonvaihtona ja kehitystä ohjaavien standardien lähteinä. Terveissä organisaatioissa näiden jälkimmäisten ryhmien jäsenyys ja kehitystiimien jäsenyys ovat lähes täysin päällekkäisiä.

Useimmissa ympäristöissä ensisijainen organisaatiorakenne heijastaa ensisijaista sidosryhmärakennetta, joka on yleensä markkinat. Tästä syystä emme organisoi Scrum-tiimejä sisäisten artefaktien jaottelun mukaan, emmekä toimialan asiantuntemuksen lokaatioiden mukaan, vaan pikemminkin markkinatoimitusten, kuten ominaisuuksien, mukaan. Ominaisuuksien tai muiden markkinatoimitusten ympärille organisoituminen edistää myös markkinoiden reagointikykyä ja lyhentää markkinoille tuloaikaa, koska tiimi on kaiken ominaisuuden toteuttamiseen tarvittavan työn sijaintipaikka. Näin koordinointi pysyy organisaatiorajojen sisällä. Jos työn osakokonaisuudet tai ydinosaamisalueet ohjaavat organisaatiorakennetta, muutokset markkinoilla tai suoritteen luonteessa edellyttävät todennäköisesti koordinointia useiden tiimien tai organisaatioiden välillä – mikä vähentää reagointikykyä ja lisää päätöksentekoaikaa.

Jos tämä on ainoa rakenne, se tukee vain markkinanäkemystä ja syrjäyttää monia muita perusteltuja liiketoiminnallisia huolenaiheita. Jotta tämä rakenne toimisi, sitä on täydennettävä poikkihallinnollisilla rakenteilla, jotka tukevat viestintätehokkuuden toista tasoa, esimerkiksi ydinosaamiseen liittyviä rakenteita. Niinpä tämä malli esiintyy lähes aina yhdessä Birds of a Feather -tyyppisen mallin ja kohdassa Domain Expertise in Roles kuvatun mallin kanssa. Organisaation roolirakenne leikkaa tiimien välille luonnostaan muodostuvat muurit. Yrityksen tuoteponnistelut saadaan kytkeytymään toisiinsa ja johtoon MetaScrumin avulla. Tiimit, jotka ovat kehittäneet tiimiylpeyttä (ks. Tiimiylpeys), ovat tehokkaampia, koska tämä tai jokin muu vastaava voima kannustaa vastuullisuuteen. Tämä auttaa varmistamaan, että nämä rakenteet pysyvät toiminnassa tiimiin kuulumisen muukalaisvihamielisistä vaikutuksista huolimatta.

Sido kaikki yhteen avoimella ympäristöllä, jossa ei ole seiniä eikä ovia. Kehitystiimit ovat ainoastaan kehityssitoumuksen yksiköitä, eikä niissä pitäisi olla mitään häiriöitä, jotka rajoittavat kehittäjien vapaata yhteistoimintaa tiimien välillä. Lisää lähelle pieniä huoneita lyhyitä hiljaisia, vakavia pohdintajaksoja ja pieniä kokouksia varten.

Jokainen arvokomponentti on reilu peli järjestämiskriteerinä. Esimerkiksi Scrumissa arvostetaan suuresti tiimin jäsenten yhteistoimintaa, joten perustavanlaatuisimmat organisaatiorajat vastaavat todennäköisesti yhteistoiminnallisia tiimejä.

✥ ✥ ✥ ✥

Huomaa, että hyvässä Scrumissa on kaksi Conwayn lain tasoa: toista ohjaa keskittyminen tuotteeseen ja toista ohjaa keskittyminen osaamisalueisiin. Pintatasolla organisoimme tiimin prosessin mukaan; se on ensisijainen huolenaihe sekä sisäänpäin että ulospäin suuntautuvissa prosessin osa-alueissa. Toisin sanoen Scrum-tiimin ensisijainen järjestämisperiaate on, että se on linjassa arvovirtaa pitkin kulkevan ominaisuustoimitusten junan kanssa. Scrumissa on heikko, matala hierarkkinen organisaatio, johon mahtuu useita kehitystiimejä kunkin tuotekehityksen sisällä, joilla on yhteinen tuoteomistaja, organisaatiossa, jota kutsutaan Scrum of Scrumiksi. Yksittäisen tuotekehityksen sisällä kukin kehitystiimi rakentaa yhden joukon ominaisuuksia kerrallaan. Ajan myötä keskeiset liiketoiminta-ajurit, jaettu liiketoimintatieto ja arvovirran artefaktit sitovat nämä ominaisuudet yhteen. Kehitystiimin sisällä ei ole tunnustettuja titteleitä tai alajaotteluja.

Työn jakaminen ominaisuustiimeihin voi tapahtua monella tavalla. Kehitystiimi voi toimittaa ominaisuuksia tietyille markkinoille (ks. Organisaatio seuraa markkinoita) tai kehittää tuotetta jollekin yritysteknologian osajoukolle (yksi tiimi puhelimille ja toinen tableteille, vaikka molemmissa on paljon samaa ohjelmistoa). Yleensä jokainen tiimi olisi muodostettava jonkin sellaisen tuotteen ympärille, joka muodostaa osan yrityksen arvosta: katso myös arvovirran haarukka. Scrum ei kuitenkaan suosi kehitystiimirakennetta, jossa kukin tiimi omistaa yhden osan tuotteesta tai vain tuotteen osakokonaisuuden. Jos yksittäisen tiimin jäsenet voivat kehittää vain yhtä järjestelmän osaa, heidän on koordinoitava enemmän kehityspäätöksiä muiden tiimien kanssa. Tiimien on vaikea tehdä päätöksiä paikallisesti, ja tuloksena on muun muassa viivästynyt palaute ja luovutukset.

Scrumissa Conwayn lain toisella tasolla ihmiset organisoituvat osaamisalueiden ympärille, joilla osaaminen tuottaa arvoa. Nämä Birds of a Feather -ryhmät auttavat jäseniä syventämään valmiuksiaan jollakin ammatillisella tai teknisellä alueella, kun he jakavat ideoita tai osallistuvat koulutukseen. Useimmilla ihmisillä on synnynnäinen halu kehittyä (ks. ), ja nämä ryhmät ruokkivat yksilöllistä ylpeyttä, kun tiimin jäsenet oppivat ja kasvavat. Nämä ryhmät eivät kuitenkaan muodosta raportointirakennetta, ja kuka tahansa tiimin jäsen voi kuulua useisiin Birds of a Feather -ryhmiin sekä omaan Scrum-tiimiinsä. Katso myös Domain Expertise in Roles.

Kehitystiimin rajat ja identiteetti sekä Scrum-tiimin rajat ja identiteetti ovat yksiselitteisiä. Tiimin identiteetin käsite on avainasemassa tiimiylpeyden ja organisaation tehokkaan toiminnan kannalta, sillä tiimin identiteetti tuo sosiaalisen kontekstin, joka auttaa optimoimaan päätöksentekoa. Kaikkien näiden kahden identiteetin ulkopuolisten organisaatioidentiteetin käsitteiden tulisi olla pikemminkin hiljaisia kuin eksplisiittisiä tai hallinnoituja. Kehitystiimissä ei ole muita virallisia titteleitä kuin ”kehittäjä”. Jos on olemassa vain yksi loukkaamaton sääntö, se on se, että yksikään yksilö ei voi käyttää hiljaista asiantuntemustaan ohittaakseen tiimin konsensuksen tai millään muulla tavoin heikentääkseen tiimityön henkeä, kuten The Spirit of the Gamessa. Yhteisesti kehitetyt käyttäytymisnormit ovat vahva tiimin identiteetin edelläkävijä.

Rooleissa voi olla asiantuntemusta yksilötasolla, mutta on tärkeää täydentää tätä kuviota poikkitoiminnallisilla tiimeillä aina kun se on mahdollista paikallisen päätöksenteon mahdollisuuksien optimoimiseksi.

Alkuperäinen Conwayn laki syntyi ohjelmistojen parissa (ks. , s. 28-31). Conwayn lain alkuperään ja käytäntöön liittyy monia myyttejä. Pitkään katsottiin, että olio-orientaatio tuki Conwayn lakia lokalisoimalla markkinahuolet luokkien sisälle. Tämä on puoliksi totta; luokilla on taipumus kiteyttää organisaation ydinosaamiseen liittyvät pitkän aikavälin huolenaiheet. Oliosuuntautuneisuus näyttää kuitenkin keskittyvän pikemminkin kehittäjien asiantuntemuksen ja heidän kehittämiensä artefaktien väliseen yhteyteen kuin yhteyteen markkinoihin tai käyttötapauksiin. Huoli mukautumisesta markkinarakenteeseen pitäisi päihittää huoli kehittäjien maailmankuvasta heidän prosessinsa ja tuotteensa suhteen.

Kehityksen vesiputous-tyylillä oli kukoistuskautensa. Vesiputousorganisaatioissa ensisijainen organisaatiorakenne noudatti prosessin vaiheita: vaatimusanalyysi, suunnittelu, toteutus ja testaus (, s. 1-9). Conwayn lain mukaan organisaatiorakenne heijasti näitä prosessihuolia. Ohjelmisto saattaa hyvinkin heijastaa myös noita vaiheita: esimerkiksi palvelukeskeinen arkkitehtuuri (SOA) todistaa suurimman osan lisäarvovaatimuksista palveluintegraatiokerroksessa, kun taas yksittäiset palvelut löytyvät toisesta kerroksesta. Vesiputous antaa kaikki ominaisuudet kerralla kehittäjien käsiin, mikä tukee ominaisuuksien välisten vuorovaikutusten päättelyä. Vaikka vesiputousaikakauden ohjelmistosuunnittelulähestymistavat pyrkivät saattamaan markkinoiden huolenaiheet (käyttötapaukset) yhdenmukaisiksi arkkitehtuurin kanssa, organisaatiorakenne katkaisi tämän taksonomian. Samaa voidaan sanoa tehtaiden liukuhihnaorganisaatiosta.

Koska kehitystiimit ovat ominaisuustiimejä, niiden tulisi keskittyä yhteen ominaisuuteen kerrallaan (kuten Swarmingissa). Scrumin ensisijainen markkinatuotos on ominaisuus, ja tässä mielessä tiimirakenteen ja markkinoiden välillä on hyvä linjaus. Scrum vaikenee tuotearkkitehtuurin muodosta, mutta ketteryyden hengessä sillä on taipumus vähentää yksittäisen koodin omistajuutta. Jokaisella kehitystiimillä on lupa työskennellä minkä tahansa tuotteen osan parissa. Voidaan sanoa, että Scrum tasapainottaa kapseloinnin organisatoriset hyödyt ja tiimin ja markkinoitavan tuotteen yhteensovittamisen hyödyt. Tuoteomistaja hallinnoi kehitystiimin tuella sitä, miten ajan mittaan syntyviä ominaisuuksien vuorovaikutussuhteita käsitellään.

Harkitse esimerkiksi sitä, että yksi tiimi saattaa toteuttaa puhelujen odotusominaisuuden televiestintäjärjestelmään, kun taas toinen tiimi toteuttaa soitonsiirron. Esiintymisen vuoksi et voi aina ennakoida kahden tietyn Product Backlog Items (PBI) välisen riippuvuuden ratkaisemisesta aiheutuvia kustannuksia, joten tätä ongelmaa on yleensä mahdotonta ratkaista jakamalla PBI:t tiimeihin. Joka tapauksessa töiden ennenaikainen osoittaminen tiimeille voi tehdä mahdottomaksi sen, että ihmiset työskentelevät tehokkaasti vaikeiden osien parissa (erityisesti osien väliseen vuorovaikutukseen liittyvien osien parissa), ja rajoittaa itseorganisoitumista Scrum-tiimin tasolla. Nämä kaksi ominaisuutta voivat olla hyvin riippuvaisia toisistaan, mutta Scrum-rakenne ei anna ensiluokkaista statusta näille vuorovaikutuksille. Tässä tapauksessa olisi luultavasti parempi, jos yksi tiimi kehittäisi molemmat ominaisuudet. Se, miten työ jaetaan tiimeille, perustuu jatkuvaan suunnitteluun ja jaettuun päätöksentekoon, joka alkaa sprintin suunnittelusta. Hyvä Scrum-tiimi pyrkii jakamaan työn kehitystiimien kesken tuoteomistajan ja kehitystiimin välisellä intiimillä, mutta ajallisesti rajatulla vuorovaikutuksella, kuten tapahtumissa, joissa luodaan jatkuvasti uudelleen tarkennettu tuoteselvityslista (Refined Product Backlog), sekä sprinttien suunnittelun kautta.

Johto on yleensä osa organisaatiokokonaisuutta, vaikkakin on joitakin Scrum-kehitystyön kehitystyötä, jotka kulkevat ilman yhtään esimiestä (ks. esim. hiljattainen video ketterästä transformaatiosta Bosch Software Innovationsilla. ) Scrumin eetoksella on taipumus keskittyä ihmisiin ja tuotteeseen, ja keskittyminen ilmentyy Scrum-rooleissa ja niiden edustamissa organisaatioissa (kuten kehitystiimissä ja tuoteomistajatiimissä). Jos organisaatio, jossa on jo ennestään johtajia, ryhtyy ottamaan käyttöön Scrumia, Scrum-pyrkimysten on liian helppoa hylätä organisaation johtamisosa tuonpuoleisena. Tällaisissa tilanteissa, joissa johtamisesta vapaa organisaatio ei ole vaihtoehto, on ratkaisevan tärkeää ottaa johtajat mukaan.

Steven Johnson. Mistä hyvät ideat tulevat. New York: Riverhead Trade, 2011.

Stewart Brand. Kuinka rakennukset oppivat: What Happens After They’re Built. New York: Penguin, 1995.

Brian Foote ja Joseph Yoder. ”Big Ball of Mud.ˮ Teoksessa Pattern Languages of Program Design 4, Brian Foote et al., toim. London: Pearson, 2000.

Daniel Pink. Drive: Hämmästyttävä totuus siitä, mikä meitä motivoi. 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, s. 1-9. (Julkaisi alun perin TRW.)

Bosch Software Innovations. ”Lessons learned: Agile organization at Bosch Software Innovations. ”ˮ YouTube.com, 15.6.2018, https://www.youtube.com/watch?v=CwodQs7D8BY.

Picture credits: Kuvat tarjoaa PresenterMedia.com.