Ohjelmistoprojektien johtaminen ja ryhmädynamiikka Harjoitus 3

Ohjelmistoprojektien johtaminen ja ryhmädynamiikka Harjoitus 3 Ryhmä IPA: Petri Kallio, Pentti Korpela, Simo Mäkinen, Riku Rytkönen Helsinki 2.12.2014 Harjoitusraportti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Sisältö i 1 Johdanto 1 2 Johtaminen ja johtajuus ohjelmistoprojekteissa 2 3 Lean-johtajuus ja ryhmädynamiikka 2 3.1 Itseorganisoituvat kehitystiimit..................... 4 3.2 Tavoitteenasettelu ja metriikat...................... 5 3.3 Informaation jakaminen......................... 7 3.4 Tiimin sitoutuneisuus........................... 8 4 Yhteenveto 9 Lähteet 10

1 Johdanto Harjoituksessa oli tehtävänä kirjoittaa vierailijaluennoitsija Fabian Fagerholmin 25. marraskuuta 2014 pitämästä luennosta harjoitustyöryhmän kanssa raportti, jossa keskitytään erityisesti johonkin ryhmädynamiikan kannalta erityisen kiinnostavaan näkökulmaan. Valitsimme näkökulmaksi johtajuuden. Nykyään ohjelmistotuotannossa on havaittavissa, että organisaatiot ovat siirtyneet tai siirtymässä vesiputousmallissa kohti ketteriä menetelmiä. Ketterien menetelmien nähdään tuovan joustavuutta prosesseihin kustannustehokkaasti ja näin ollen saamaan nopeammin, laadukkaammin tuotteita markkinoille. Ketterät menetelmät korostavat esimerkiksi riskien- ja dokumentaation minimointia sekä tiimien merkitystä ohjelmistojen kehitystyössä. Johtajuus ja sen ilmeneminen ohjelmistotuotannossa on muuttunut paljon viimeisen 20 vuoden aikana, joten tämänkin takia ryhmämme päätti valita tehtävään juuri johtajuuden näkökulman. Näkökulman tekee mielenkiintoiseksi myös, että juuri ketterissä menetelmissä korostetaan tiimien merkitystä ja perinteinen johtajuuden ajatusmalli on muovautunut uudelleen niin, että johtajuus on ikään kuin sulautettuna osana ryhmää. Koimme myös mielenkiintoiseksi perehtyä, kuinka itse ryhmä näkee johtajuuden ja miten johtajuus vaikuttaa ryhmädynamiikkaan. Ryhmällä tarkoitetaan tässä yhteydessä yleisesti ottaen jonkinlaista kehitystiimiä, jolla on toisiaan täydentäviä taitoja. On syytä kuitenkin huomioida, että työryhmän ja tiimin määritelmä ei ole täysin yhtenevä siten, että työryhmäksi voidaan lukea tiimiä epäyhtenäisempi joukko yksilöitä, kun taas tiimi on käsitteellisellä tasolla yhtenäisempi ja mahdollisesti vastuuta enemmän jakava joukko [RoJ09]. Käsitteellisestä erosta huolimatta käytämme termejä ryhmä ja tiimi pääsääntöisesti toistensa synonyymeina. Tässä raportissa on tarkoitus selvittämään mitä on johtajuus, mitkä on sen eri ilmentymät ja miten johtajuus ilmenee ketterässä ohjelmistotuotannossa, kuten esimerkiksi Lean -prosessimallissa. Tarkoituksena on myös selvittää itseorganisoituvien tiimien merkitystä johtajuudessa sekä havainnollistaa, kuinka ketterissä menetelmissä informaation jakaminen ryhmän sisällä tapahtuu.

2 Johtaminen ja johtajuus ohjelmistoprojekteissa 2 Johtamiselle on monta määritelmää ja sitä yritetään mallintaa erilaisilla malleilla. Yhteistä näille johtajuuden kuvauksille on se oletus, että yhdellä henkilöllä on valta vaikuttaa muiden henkilöiden työskentelyyn. Tällä vaikutus mahdollisuudella johtaja sitten saa ryhmän tehokkaammaksi tai ylipäätään toteuttamaan tietty tehtävä. Kuinka sitten Lean-johtajuus eroaa aikaisemmasta perinteisestä johtajuudesta? Perinteinen johtajuus on ollut käskevää ja ylhäältä alaspäin tapahtuvaa toimintaa. Yleisesti ottaen paino on ollut asioiden toimivuudessa eli keskitytty suunnitteluun, organisointiin, johtamiseen, motivointiin ja valvontaan. Lean-johtajuudessa tavoitteena on asiakaskeskeisyys ja poistaa turha työ, hukka ja odottaminen. Tämäntyyppisessä johtajuudessa tavallaan tarkastellaan samoja teemoja pintaa syvemmältä kuin perinteisessä johtajuudessa. Lean-johtajuudessa painotetaan, että tehdään juuri oikeaan tarpeeseen ja just in time -ideologialla. Tuotteen suunnittelu on hyvä esimerkki. Perinteisessä mallissa kysytään kerran mitä tilaaja haluaa ja sitten toteutetaan se mitä kuvitellaan ostajan halunneen. Tässä prosessissa johtaja valvoo, että ihmiset tuottavat tilatun kaltaisen tuotteen. Leanjohtaja taas vaatii, että työn suunta ja oikeellisuus tarkistetaan tilaajalta kerran viikossa. Tässä asiakasyhteistyötä painotetaan enemmän kuin sopimusneuvotteluita. Lean-johtaja on myös hyvin fokusoitunut prosessiin ja ei pelkästään prosessin toimintaan, kuten perinteisessä mallissa olisi, vaan lähtökohta on jatkuva kehittäminen. Leanissä johtajuudessa painotetaan enemmän yksilöitä ja vuorovaikutusta enemmän kuin prosesseja ja työkaluja. Eli Lean-johtaja pitäisi organisaatiorakenteen matalana ja lisäisi samalla organisaation reagointinopeutta ongelmiin. Paino olisi myös, siinä että voitaisiin reagoida muutoksiin nopeammin ja voitaisiin muuttaa aikaisempia suunnitelmia. 3 Lean-johtajuus ja ryhmädynamiikka Lean-johtamisfilosofiassa keskitytään erilaisten turhuuksien poistamiseen, jotka eivät tuota projektissa arvoa. Eli tarkoituksena on keskittyä poistamaan prosesseista kaikki turha, aikaa vievä hukka ja vastaavasti keskittyä tehokkuuden maksimoimiseen. Lean-johtamisfilosofiaan voidaan maalaisjärjellä ajatella olevan sitä, että tehdään projektissa enemmän arvoa tuottavaa työtä juuri oikeaan aikaan ja oikeaan tarpeeseen. Tärkeitä seikkoja ovat muun muassa yhteistyön sujuvuus, tavoitteen selkeys

3 ja seurattavuus, informaation jakaminen ja vastuun ottaminen omasta työstä. Lean-johtaja toimii tiimissä suunnan antajan ja pitää huolen siitä, että tiimin työ edesauttaa suuremman tavoitteen saavuttamista. Esimerkiksi yrityksessä, jossa toteutetaan rinnakkain useampaa projektia, tulee johtajien olla selvillä yhteisestä tavoitteesta ja kommunikoida tavoite tiimin jäsenille. Voidaan ajatella, että johtaja toimii strategisena suunnittelijana, jonka tehtävänä on mahdollistaa työn sujuva eteneminen. Johtaja on sisäryhmän prototyyppi silloin kun hän edustaa tiimin sosiaalista identiteettiä, arvoja ja toimintatapoja. Tiimi kuuntelee ja noudattaa sellaista johtajaa, joka on omalla toiminnallaan osoittanut tiimille olevansa pätevä johtamaan kyseistä tiimiä. Johtamistapoja on useita ja ketterissä menetelmissä johtajuus kumpuaa asiantuntevuudesta ja tämän vuoksi johtajuus on monessa tapauksessa tilannesidonnaista. Tiimin sisältä voidaankin valita kuhunkin tilanteeseen parhaiten sopiva tehtävä- ja/tai tunnejohtaja. Tällöin tiimillä ei ole nimettyä yhtä johtajaa. Joissain projekteissa on kuitenkin tarpeen käyttää nimettyä johtajaa tiimin sisältä tai ulkopuolelta, sillä esimerkiksi paljon koordinaatiota, kommunikointia ja selvittelyä vaativat projektit saattavat työllistää yhden tiimin jäsenen kokonaan. Hyvä Lean-johtaja täyttää kuusi kriteeriä: prosessien noudattaminen, työn tarkoituksenmukaisuus, ongelmien ratkaisukyky, ihmisten sitouttaminen, suorituskyvyn maksimointi ja kumppanuussuhteiden muodostaminen [CoV11]. Prosesseja noudattamalla kaikkien tiimin jäsenten toiminta on suoraviivaisempaa ja selkeämpää. Mikäli toimintamalleissa huomataan parannettavaa, niin niitä muutetaan tiimin ja yksilön suorituskyvyn parantamiseksi. Tällöin myös turhan työn määrä pienenee. Vastaavasti itse työn sisältö tulee olla tarkoituksenmukaista ja mitattavaa, jotta turhalta työltä vältytään. Tiimissä ihmiset sitoutetaan projektiin ja jokaiselle annetaan vapaus ja vastuu oman osuuden tekemisestä. Kumppanuussuhteiden avulla taas pyritään kommunikoinnin parantamiseen tiimin ja projektin jäsenten ja sidosryhmien kanssa. Esimerkiksi projektin siirtyessä vaiheesta toiseen, uusien henkilöiden mukaan tuominen ja potentiaalisten esteiden tunnistaminen ja selvittäminen edesauttaa projektin valmistumista aikataulussa. Käsittelemme seuraavissa luvuissa neljää tärkeäksi kokemaamme Lean-johtamisperiaatetta: itseorganisoituvat kehitystiimit, tavoitteenasettelu ja metriikat, informaation jakaminen ja tiimin sitoutuneisuus. Tarkastelemme näitä kohtia ryhmädynamiikan näkökulmasta.

4 3.1 Itseorganisoituvat kehitystiimit Projekti koostuu ihmisistä, jotka pyrkivät määrätietoisesti määrättyyn lopputulokseen. Kun puhutaan Lean -johtajuudessa tämä tarkoittaa, että johdon ja esimiesten pitää ensin ymmärtää, mitä ollaan tekemässä ja miten tämä tehdään omassa organisaatiossa. Esimerkiksi Toyotalla johtaminen ja parantaminen on yksi sama asia, kun taas usein johtajuus mielletään erillisenä toimijana. Ketterät menetelmät korostavat vuorovaikutusta, jonka avulla ihmiset tekevät yhteistyötä. Vuorovaikutus ja Lean johtamisfilosofia voidaan nähdä jatkuvana kehittymisenä, jossa motivoituneet ihmiset saavat aikaan hyviä tuloksia. Lean-johtamisfilosofiassa vapaat ja luovat yksilöt muodostavat itseorganisoituvia ryhmiä. Ryhmille taas kehittyy omat norminsa ja kulttuuri, joiden rajoissa ihmiset tekevät yhteistyötä. Normit liittyvät vahvasti ryhmän tavoitteisiin ja ne auttavat tehtävien koordinoinnissa sekä luovat omalta osaltaan ennalta-arvattavuutta tilanteisiin [Bro00]. Fagerholm kertoi luennolla ketterästä Scrum-menetelmästä ja siitä, kuinka menetelmää käytettäessä ohjelmistotiimin johtajaa ei ole välttämättä erikseen nimetty. Ryhmälle jää siis suuri vastuu järjestää työtehtävänsä parhaaksi katsomallaan tavalla päivittäisessä toiminnassa; erillisen projektijohtajan ei katsota kuuluvan tuotetta tekevään ydintiimin. Työntekijöiden voimaannuttaminen (empowerment) tällä tavoin voidaan nähdä yhtenä keskeisenä Lean-ohjelmistokehityksen osana [Pop05]. Ryhmien autonomista asemaa on tutkittu aiemmin ketterien ohjelmistoprosessien näkökulmasta. Hoda ja kumppanit tutkivat vuosia kestäneessä hankkeessaan millaisia eri rooleja itseorganisoituvissa ohjelmistotiimeissä esiintyy [HNM13]. He tunnistivat kaiken kaikkiaan kuusi eri jäsenille soveltuvaa epämuodollista roolia, joita käytettiin joustavasti tilanteen mukaan. Osa Hodan ja kumppaneiden määrittelemistä rooleista on tiimin sisäisiä rooleja, ja osa enemmän ulospäinsuuntautuneita. Mentori-roolissa oleva henkilö voi auttaa muita ryhmäläisiä työskentelemään itseorganisoituvasti, kun taas koordinaattori ja tulkki koordinoivat asiakasvaatimuksia tiimille, ja pystyvät kääntämään vaatimukset teknisimmiksi kehitystehtäviksi. Kuten koordinaattori ja tulkki, promoottori toimii asiakkaiden suuntaan kannustaen asiakasta toimimaan ketterien ohjelmistoperiaatteiden mukaisesti. Sankari-roolin ottaja toimii sen sijaan organisaation sisällä ryhmän puolestapuhujana ja pyrkii vakuuttamaan organisaation johdossa, eli selkeästi ulkoryhmässä olevat, kehitystiimin toiminnan tuotteliaisuudesta. Viimeisenä roolina Hoda ja kumppanit listaavat ryhmään sopeutumattomien yksilöiden poista-

5 miseen erikoistuvan terminaattorin, joka tunnistaa sosiaalisesta normista ja itseorganisoituvuuden periaatteista liiaksi poikkeavat henkilöt, ja ilmoittaa havaintonsa organisaation johdolle. Kuten minkä tahansa ryhmän, autonomisen ja itseorganisoituvan ohjelmistokehitystiimin toiminta ei suinkaan aina ole ongelmatonta. Ketterissä ohjelmistokehitystiimeissä esiintyy mm. persoonallisista ominaisuuksista kumpuavia konflikteja, jotka vaikuttavat ryhmäläisten tuottavuuteen, ja konfliktit saattavat johtaa työvoiman vaihtuvuuteen [MCK13]. Ehkä tästä syystä ryhmässä tarvitaan Hodan ja kumppaneiden [HNM13] mainitsema terminaattori, joka voi nostaa henkilövaihdoksiin liittyviä asioita esiin. Fagerholm mainitsee esityskalvoissaan Pennington ryhmän kiinteyttä ja koheesiota lisääviä tekijöitä, joista yhtenä listassa on ryhmän pieni koko. Ryhmän pienen koon hyödyllisistä vaikutuksista koheesioon onkin saatu ohjelmistoprojekteissa viitteitä, ja myös ryhmän heterogeenisuus työkokemuksen suhteen on havaittu positiivisesti vaikuttavaksi tekijäksi [MCK13]. 3.2 Tavoitteenasettelu ja metriikat Ketterien menetelmien avulla toteutetuissa ohjelmistotuotantoprojekteissa suositaan selkeästi asetettuja tavoitteita, joita on helppo seurata. Tavoitteiden pitää olla myös tarpeeksi selkeästi ryhmän tiedossa ja epäkohtiin tulisi puuttua mahdollisimman aikaisessa vaiheessa. Ketterät menetelmät ja Lean johtamisfilosofiassa yksi keskeinen tavoite on tehostaa toimintaa ja luoda toiminnasta sopeutuva, notkea ja sutjakka. Tällä tarkoitetaan, että voidaan esimerkiksi mitata tehtävän läpimenoajan mahdollista lyhentymistä. Erilaiset metriikat antava tietoa kehityksen nykytilasta ja kertovat esimerkiksi suorituskykyyn liittyneistä epäkohdista, joihin voidaan puuttua. Lean-periaatteiden mukaisesti tuotantoprosessista voidaan mitata monenlaisia asioita, ja mittareita voidaan käyttää tuotantoprosessien ja työntekijöiden jatkuvaan parantamiseen [DuC07]. Koska Leanin alkuperä on teollisessa tuotannossa, kaikkia mittareita on vaikea soveltaa sellaisenaan ohjelmistoprojekteissa. Abstrakteille ohjelmistotuotteille ei ole ehkä järkevää mitata esimerkiksi komponenttien siirtoetäisyyksiä tuotantolinjalle, eräajojen määriä tai muita tuotteiden fyysisiin ominaisuuksiin liittyviä mittareita. Leanin perusperiaatteet ovat kuitenkin sovellettavissa ohjelmistotuotantoon ja ohjel-

6 mistoprosessien parantamiseen. Sulava työvirta on yhtä tärkeä niin ohjelmistotuotannossa kuin teollisessa tuotannossa. Ohjelmistoprojekteissa voidaan esimerkiksi mitata kuinka paljon kehitystiimillä on toteutettavia ohjelmistovaatimuksia milläkin hetkellä, kuten Petersen ja Wohlin ehdottavat [PeW10]. Liiallinen määrä vaatimuksia ja toteutettavia toiminnallisuuksia voi johtaa ryhmäjäsenten stressaantumiseen ja ylikuormitukseen; toisaalta toteutettavia vaatimuksia ei myöskään tulisi olla jonossa liian vähän. Petersen ja Wohlin ehdottavat, että olisi hyvä, jos ohjelmistokehittäjät pystyisivät tarpeen tullen valitsemaan uusia työtehtäviä (pull) sen sijaan, että heille tasaisin väliajoin annetaan suuri määrä vaatimuksia kerralla (push). Teollisessa Lean-tuotannossa käytetään kanban-signalointimenetelmää, jolla kommunikoidaan tuotantovaiheeseen sillä hetkellä tarvittava osien tarve muille työntekijöille [DuC07]. Näin voidaan toteuttaa ns. pull-toimintatapa, eli työntekijät saavat haluamansa osan tarpeen mukaan oikea-aikaisesti. Kuten Fagerholm esittää luentokalvoissaan, samanlainen toimintatapa sopii myös ohjelmistoprojekteihin. Fagerholm esitteli luennolla ohjelmistoprojekteissa käytettävän Kanban-taulun toimintaperiaatteita. Kullakin työvaiheella on oma sarakkeensa, ja ohjelmistokehittäjät voivat siirtää tehtäväkuvauksen sisältäviä muistilappuja vain tietyn protokollan mukaisesti taulun sarakkeesta toiseen. Ohjelmistoprojektissa vaiheet voivat olla esimerkiksi kehitys, testaus ja tarkistus, joilla on omat sarakkeensa sisääntulevien tehtävien ja tuotannossa jo olevien tehtävien lisäksi. Mikäli johonkin tiettyyn sarakkeeseen kerääntyy liikaa tehtäviä, voidaan tästä havainnoida mahdolliset ongelmakohdat prosessissa. Kanban-taulu korostaa omalta osaltaan yksilöiden vastuuta ohjelmistokehitystoiminnan sujuvuudesta. Kehittäjät toimivat autonomisesti, ja valitsevat seuraavan työtehtävän taululla olevista parhaan käsityksenä mukaisesti. Taulun käyttö koordinoi työtä ja ohjaa ryhmäläisiä yhteistoimintaan esimerkiksi tarkastustehtävien myötä, jossa toisen kehittäjän on hyväksyttävä toisen muutokset. Kanban-taulun ja sujuvan työprosessin tarkoituksena on Helkaman ja kumppaneiden terminologian mukaisesti vähentää prosessista syntyvää koordinaatiohukkaa [HML05], mutta sillä on selkeä vaikutus koko ryhmädynaamiseen toimintaan. Kanban-taulun käyttö ohjelmistoprojekteissa voi todellakin parantaa ryhmän koordinaatiota, ja sen avulla voidaan myös mitata työvaiheiden ongelmakohtia [WCC12].

7 3.3 Informaation jakaminen Informaation jakaminen projektiin osallistuvien kesken on yksi projektin menestystekijöistä. Lean johtamisperiaatteen mukaan informaation sujuvuus auttaa organisaatiota saavuttamaan projektissa ketteryyttä. Kuten Fagerholmin tekemässä tutkimuksessa havaittiin, ohjelmistoalan huipputiimi on sellainen, jossa sosiaaliset taidot ovat myös hyvin ratkaisevassa roolissa projektin onnistumisen kannalta. Tutkimuksessa havaittiin, että sosiaaliset taidot edistävät ryhmän identiteettiä joka ylläpitää ryhmähenkeä. Usein tietoa on liikaa. Sähköpostit täyttyvät pitkistä viestiketjuista ja kommunikointi hidastuu ja vaikeutuu. Tiedon tulisi olla kuitenkin aina saatavilla. Tämä aiheuttaa kaksi haastetta: miten tietoa tulisi jakaa projektin aikana ja miten tietoon päästään käsiksi. Tasapuolinen informointi tarkoittaa useimmissa tapauksissa kaiken tiedon jakamista kaikille, joka johtaa hallitsemattomaan tilanteeseen, jossa tärkeä tieto hukkuu muun tiedon sekaan. Toinen ääripää on puolestaan tiedon jakamisen rajoittaminen vain kyseisestä asiasta vastuussa oleville henkilöille. Tämä puolestaan johtaa tilanteeseen, jossa yksittäisestä ihmisestä saattaa tulla tiimin sisällä tietopankki, jota kuormitetaan aina kun halutaan tietää hänen vastuualueeseen liittyvistä asioista. Tietoa ei siis kannata myöskään jakaa pelkästään vastuiden mukaan. Tiedon jakaja ei myöskään voi tietää ketkä tietoa milläkin hetkellä tarvitsee tai tulee tarvitsemaan. Esimerkiksi ohjelmistoarkkitehtuuritason päätökset koskevat kaikkia tiimin jäseniä eikä vain arkkitehtiä. Tiimin tulisi määritellä toimintatapa kommunikoinnille tiimin sisällä ja tiimin ulkopuolelle, mikäli yritykseltä ei tähän valmiita hyväksi koettuja prosesseja jo entuudestaan löydy. Tasapuolisuus ja tasa-arvoisuus tiedon jakamisessa on tärkeää, sillä se vaikuttaa suoraan tiimin sisäisiin arvovalta suhteisiin. Tiedonkulun pitäisi olla läpinäkyvää ja hyvin määritelty. Kaikille tiimin jäsenille tulisi olla selvillä miten tietoa jaetaan ja mistä asioista ketäkin tulee tiedottaa. Yksi vaihtoehto tiedon jakamisen prosessille on yhdistää tiedon jakaminen osaksi tiimin toimintatapaa. Ketterissä menetelmissä, kuten Scrum, päivä aloitetaan tiedonjakamistuokiolla, jossa jokainen tiimin jäsen kertoo mitä on tehnyt ja mitä aikoo tehdä. Samalla tiimin jäsenet voivat jakaa keskenään tärkeimmät projektiin liittyvät uutiset. Esimerkiksi arkkitehti kertoo muille, että tietoturvan parantamiseksi tehty muutos vaikuttaa nyt myös käyttöliittymään. Uusi arkkitehtuurikuvaus ja sen aiheuttamat muutokset ovat nyt nähtävillä projektinhallintatyökalun kautta ja kaikille tiimin jäsenille on kerrottu muutoksista ja sen vaikutuksista. Muutos vaatimuksista tehdään Kanban-taululle

omat työtehtävät. Ennakoiva tiedottaminen, tärkeimmän tiedon hallittu jakaminen suullisesti ja elektronisesti ovat tärkeä osa tiimin toiminnan tehostamista. 8 3.4 Tiimin sitoutuneisuus Projekti koostuu tehtävistä ja niitä suorittavista ihmisistä. Lean -johtamisfilosofiassa projekti ryhmä on tärkeimpiä tekijöitä joiden avulla saavutetaan hyviä lopputuloksia. Ryhmän yhteishenki tulisi olla hyvä ja parhaassa tapauksessa ryhmän jäsenet voisivat kokea jopa olevansa ylpeitä kun kuuluvat tähän ryhmään. Hyvän ryhmähengen muodostuminen, joka saa aikaan hyviä lopputuloksia ei kuitenkaan ole yksiselitteinen. Ryhmään liittymistä voidaan kuvata ryhmäsosialisaation vaiheittain etenemistä ajassa [MoL88]. Ryhmään liittymisessä tapahtuu aluksi tutkiskelevaa arvointia uutta jäsentä kohtaan. Jos liittymiseen liitetään jokin mahdollisesti vaativa tehtävä tai rituaali mikä on läpäistävä ennen kuin ryhmään liittymistä niin tämä on todettu kiinteyttävä ryhmää. Hyväksymisvaiheessa jäsen hyväksytään jäseneksi ja hän alkaa mukautumaan ryhmään ja omaksumaan ryhmän normeja, arvoja ja käyttäytymistä. Kun ryhmäläinen lopulta saavuttaa sosiaalisen statuksen ryhmässä, siirrytään ylläpitävään vaiheeseen, jossa ryhmäläinen on osana ryhmää. Ryhmässä pysymistä ja ryhmähenkeä parantavat esimerkiksi onnistuminen työssä ja siitä palkitseminen. Sitoutuneisuus ja motivaatio liittyvät toisiinsa. Työn mielekkyys ja oma kiinnostus työtä kohtaan motivoi tekemään työtä. Mikäli vastuut on jaettu kiinnostusten kohteiden ja osaamisen perusteella, niin yksilöiden tuottama tulos on keskivertoa parempi. Hyvä johtaja ottaa huomioon ryhmän jäsenten toiveet ja muodostaa käytettävissä olevista resursseita (ihmisistä) parhaan mahdollisen tiimin toteuttamaan projektia. Työtyytyväisyy parantuu, kun jokainen tietää mikä oma vastuu projektissa on. Tarkoituksenmukaisuus ja oman edistymisen seuraaminen sekä vastuun ottaminen synnyttävät henkilökohtaisia sisäisiä tavoitteita ulkoisten tavoitteiden lisäksi. Esimerkiksi projektissa, jossa mobiilisovelluksen käyttöliittymän suunnittelu on yhden ihmisen vastuulla, motivaattorina hyvälle työlle on myös ylpeys omaa tuotosta kohtaan.

4 Yhteenveto 9 Tarkastelimme tässä raportissa johtamisen kehitystä ohjelmistotuotantoprojekteissa kohti ketterämpää johtamismallia. Kävimme läpi Lean-johtajuuden tuomat muutokset projektijohtamiseen, ja pohdimme muutosten suhdetta ryhmädynaamisiin ilmiöihin Fagerholmin vierailuluennon innoittamina. Voidaankin lopuksi todeta, että projekti koostuu ihmisistä, jotka pyrkivät määrätietoisesti lopputulokseen. Tiimin jäsenet ovat onnistuneen projektin tärkein elementti. Johtajuuden, vastuun jakamisen ja tavoitteiden määrittelyn kautta projektia voidaan ohjata kohti haluttua päämäärää. Johtajuus syntyy tilanteiden, osaamisen ja motivaation kautta, varsinkin itseorganisoituvien tiimien kohdalla. Selkeät tavoitteet ja tavoitteiden täyttymisen yksiselitteinen seuraaminen edesauttaa aikataulussa pysymistä ja kunkin tiimin jäsenen oman työn hallintaa. Tiedon jakaminen tulee olla organisoitua ja selkeää, sillä ongelmat kommunikaatiossa heijastuvat kaikkeen toimintaan. Esimerkiksi vaatimusten, tehtävien ja toimintatavan kommunikointi tiimin sisällä ja ulkopuolella on hyvin tärkeää projektin onnistumisen kannalta. Sitoutunut tiimi on valmis kohtaaman projektin aikana vastaan tulevat haasteet yhdessä ja ylittämään asiakkaan vaatimukset.

Lähteet Bro00 Brown, R., Group processes: dynamics within and between groups. Blackwell Publishers, Oxford, 2000. Lisäpainokset: Repr. 2002. - Repr. 2003. - Repr. 2004. - Repr. 2005. 10 CoV11 Costello, L. ja Vlemmix, R., Building lean leaders. Teoksessa Lean Management: New Frontiers for Financial Institutions, McKinsey&Company, 2011, sivut 60 65. DuC07 MCK13 HML05 HNM13 MoL88 Pop05 PeW10 RoJ09 WCC12 Diego Fernando, M. D. ja Rivera Cadavid, L., Lean manufacturing measurement: the relationship between lean activities and lean metrics. Estudios gerenciales, 23,105(2007), sivut 69 83. de O Melo, C., S Cruzes, D., Kon, F. ja Conradi, R., Interpretative case studies on agile team productivity and management. Information and Software Technology, 55,2(2013), sivut 412 427. Helkama, K., Myllyniemi, R. ja Liebkind, K., Johdatus sosiaalipsykologiaan. Edita, Helsinki, 2005. Hoda, R., Noble, J. ja Marshall, S., Self-organizing roles on agile software development teams. Software Engineering, IEEE Transactions on, 39,3(2013), sivut 422 444. Moreland, R. L. ja Levine, J. M., Group dynamics over time: Development and socialization in small groups. (1988). Poppendieck, M. ja Poppendieck, T., Introduction to lean software development. XP, 2005, sivu 280. Petersen, K. ja Wohlin, C., Software process improvement through the lean measurement (spi-leam) method. Journal of systems and software, 83,7(2010), sivut 1275 1287. Robbins, S. P., Essentials of organizational behavior. Pearson/Prentice Hall, Upper Saddle River (NJ), 2009. Wang, X., Conboy, K. ja Cawley, O., leagile software development: An experience report analysis of the application of lean approaches in agile software development. Journal of Systems and Software, 85,6(2012), sivut 1287 1299.