Tehtävä 3 Fabian Fagerholm: Ketteristä menetelmistä ja niiden ryhmädynamiikasta

1 Tehtävä 3 Fabian Fagerholm: Ketteristä menetelmistä ja niiden ryhmädynamiikasta Ohjelmistoprojektien johtaminen ja ryhmädynamiikka 4.12.2014 Ryhmä: Kolmio Kasper Hirvikoski Riku Niittymäki Kari Korpinen

2 Johdanto Tämä raportti käsittelee Fabian Fagerholmin 25.11.2014 pitämää vierailijaluentoa, joka käsitteli ketteriä ohjelmistokehitysmenetelmiä ryhmädynamiikan näkökulmasta. Luennolla otettiin katsaus joidenkin ketterien menetelmien syntyyn ja niiden periaatteisiin. Kuulijoita pyydettiin myös tarkastelemaan ketteriä menetelmiä sosiaalidynamiikan kautta, muun muassa sosiaalisten representaatioiden avulla. Luennon toinen osa käsitteli sosiaalipsykologian ilmiöitä ketterissä ohjelmistotuotantotiimeissä käytännönläheisesti ja konkreettisten ketterien ohjelmistoprosessien kautta. Aiheissa sivuttiin myös pienryhmien muodostumista ja johtamista. Luennon viimeinen osa käsitteli luennoitsijan omaa väitöskirjatutkimusta kehittäjäkokemuksesta (Developer Experience) ja havaintoja aiheesta muun muassa Software Factoryn kautta. Ohjelmistotuotanto systemaattiseksi Ohjelmistotuotanto on systemaattista työtä, joka kattaa elinkaaren ohjelmistojen suunnittelusta, kehittämiseen ja ylläpitoon. Ohjelmistotuotannon prosessimallit pyrkivät ohjaamaan ohjelmistokehitystä [Fab14, s. 6]. Kehitettävät ohjelmistot ovat usein monimutkaisia ja niiden kehitykseen vaaditaan yleensä lukuisia ihmisiä. Kehittäminen tapahtuu ohjelmistotuotantotiimeissä ja näitä pienryhmiä voidaan tarkastella sosiaalipsykologian näkökulmasta. Kaikissa ryhmissä esiintyy ilmiöitä, joita voidaan selvittää sosiaalipsykologian keinoin. Ohjelmistotuotannon prosessimalleja on kehitetty ja tutkittu 1960-luvulta asti. Ennen tätä, ohjelmistotuotanto oli keskittynyt noudattamaan muissa insinöörialoissa kehittyneisiin käytänteisiin. Kehitys nähtiin insinöörityönä, jota sovellettiin laitteiden suunnitteluun. Ala oli ajautunut kriisiin, jonka tuloksena ohjelmistotuotteiden laadukkuus kärsi. Vuonna 1968, Nato perusti tiedekomitean valmistelemaan ratkaisuja miten laadukkaita ohjelmistoja pystyttäisiin tuottamaan paremmin. Prosessimallit nähtiin yhtenä ratkaisuna kriisiin. Prosessimallien tarkoitus on parantaa kehitettävien ohjelmistojen laatua tekemällä kehitystyöstä systemaattista, toistettavaa ja mitattavaa. Näin prosesseista pystytään tekemään kvantitatiivisia ja kvalitatiivisia arvioita. Ensimmäiset ohjelmistotuotantomallit olivat hyvin suunnittelupainotteisia ja keskittyivät raskaaseen kirjalliseen dokumentointiin.

3 Ohjelmistokehitys nähtiin tuolloin prosessina, joka voidaan jakaa peräkkäin suoritettaviin yksilöllisiin osiin. Käytetyin malli oli vesiputousmalli, joka jakaa prosessin seitsemään osaan [WiWa]. Malli on ajan kuluessa todettu erittäin huonosti ohjelmistokehitykseen sopivaksi. Se etenee vaatimusmäärittelystä ja suunnittelusta toteutuksen kautta ylläpitoon. Mallin suurin puute on se, että siinä lähdetään oletuksesta, että kaikki vaatimukset voidaan määritellä kehitystyön alussa ja, että jokainen osa on toteutettavissa irrallaan toisistaan. Vaatimusmäärittelyyn tulee palata vain jos myöhäisemmässä vaiheessa ne todetaan virheelliseksi. Kuitenkin käytännössä vaatimukset muuttuvat lähes aina kehitystyön edetessä, kun asiakas ja kehittäjät oppivat tuntemaan sovellusaluetta, sen ongelmaa ja ratkaisua paremmin. Vesiputousmalli tuottikin helposti tuotteita, jotka eivät ratkaisseet asiakkaan ongelmaa. Täytyi löytää uusi suunta. Ketterät menetelmät ratkaisuna Ketterät menetelmät kehitettiin tarjoamaan vaihtoehto raskaille dokumentaatio- ja prosessivetoisille ohjelmistotuotantomalleille. 17 ohjelmistoalan ammattilaista järjesti vuonna 2001 tapaamisen hiihtokeskuksessa, jonka ajatus- ja keskustelutyön tuloksena syntyi ketterän ohjelmistokehityksen manifesti [AgMa]. Raskaat prosessit eivät toimineet ja tähän täytyi löytyä ratkaisu. Julistus syntyi sosiaalidynaamisen prosessin kautta. Siksi julistusta onkin moitittu enemmän sosiaaliseksi liikkeeksi kuin ohjelmistotuotantoprosessiksi. Julistus koostuu neljästä kohdasta, jotka alleviivaavat ohjelmistokehityksen osa-alueita, joihin kehitystyössä tulee panostaa. Nämä neljä kohtaa ovat: 1.) Yksilöt ja vuorovaikutus ovat prosessia ja työkaluja tärkeämpiä. 2.) Toimiva tuote on ensijaisesti tärkeämpää kuin kattava dokumentaatio. 3.) Kehitystyössä täytyy painottaa yhteistyötä asiakkaan kanssa sopimusneuvotteluiden sijaan. 4.) Muutoksiin tulee varautua suunnitelmien noudattamisen sijaan. Nämä eivät ole kuitenkaan toisiaan poissulkevia periaatteita. Toisin sanoen ketterän ohjelmistokehityksen julistus ei totea, että kattava dokumentaatio olisi huono asia vaan, että toimiva ohjelmisto on tärkeämpi tavoite. Ketterän kehityksen manifesti on saanut myös paljon kritiikkiä. Keskeisimmät vastaväitteet ovat kritisoineet menetelmän painotusta arvoihin ja kulttuuriin. Nämä painotukset ovat kritiikin mielestä liian riskialttiita laadukkaaseen ohjelmistokehitykseen. Menetelmää on myös pidetty liian ideologisena, joka ei ota huomioon joskus jopa hyvinkin jäykkää yrityskulttuuria.

4 Nykyaikaiset ketterät menetelmät Monet nykyaikaiset ketterät menetelmät (Agile/Lean), kuten Scrum, sisältävät käytänteitä ja menetelmiä, jotka toteuttavat ketterän manifestin periaatteita. Scrum kuvaa enemmän mukautuvan kehyksen ketterälle prosessille, kun taas esimerkiksi XP (Extreme Programming) määrittelee konkreettisia käytänteitä näiden tueksi. Kaikkien ketterien menetelmien perusteena on iteratiivinen-kehitys. Sen sijaan, että kehitystä tehdään inkrementaalisesti yksi vaihe kerrallaan, iteratiivinen kehitys toteuttaa kaikki ohjelmistotuotannon vaiheet pienissä erissä. Jokaisen vaiheen olisi tarkoitus tuottaa toimiva ominaisuus asiakkaalle. Asiakkaan ottaminen osaksi prosessia on keskeistä. Ohjelmistotiimi käy läpi kaikki ohjelmistotuotannon vaiheet jokaisessa iteraatiossa. Yksittäinen ominaisuus suunnitellaan, toteutetaan ja testataan valmiiksi. Asiakas pystyy tämän jälkeen vaikuttamaan nopeasti tuotteen suuntaan. Yksi Scrum-prosessimallin käytänteistä on lyhyt seisaalta suoritettava päiväkokous. Kokouksen tarkoituksena on antaa kaikille kehitystiimin jäsenille kuva siitä, miten nykyinen iteraatio etenee kunkin osapuolen osalta ja mitä ongelmia on kohdattu ja miten nämä voitaisiin ratkaista. Näin ollen tietämys leviää tiimissä ja tarjotaan kaikille mahdollisuuden osallistua ongelmien poistamiseen. Useat ketterät menetelmät suosivat myös avointa yhteistä työskentelytilaa kehitystiimille, joka myös osaltaan auttaa tietämyksen leviämisessä. Avoimen tilan hyötynä on myös se, että kaikki kehitystiimin jäsenet työskentelevät läheisesti keskenään. Tämä mahdollistaa myös muiden visuaalisten työvälineiden käytön. Muun muassa Kanban-taulua käytetään prosessin, tuotteen ominaisuuksien ja yksittäisten tehtävien seuraamiseen. Vastareaktiona, esimerkiksi avoin tila saattaa kuitenkin joidenkin yksilöiden mielestä olla varsinkin aluksi ahdistavaa. Ryhmän uudet jäsenet voivat helposti joutua muun ryhmän silmätikuiksi. Ketterät käytänteet tarvitsevatkin tasapuolisen, avoimen ja keskustelevan työkulttuurin toimiakseen. Ketterät menetelmien yhteydessä suositellaan, että kehitystiimit ovat itseorganisoituvia ryhmiä ja ettei ryhmän jäsenillä ole tiukasti määritelty tai ulkopäin annettuja rooleja. Kaikki pyrkivät osaamisen mukaan tekemään kaikkia ohjelmiston kehittämiseen liittyviä tehtäviä. Ohjelmistotuotantoprosessissa, joka on vahvasti jaoteltu eri toteutusvaiheisiin, joista vastaa oma osasto, on mahdollista syntyä negatiivinen tehtäväriippuvuus kahden ryhmän välille. Esimerkiksi tilanteessa, jossa testausosaston tuottavuuden mittariksi valitaan sen löytämien ohjelmistovirheiden määrä ja kääntäen kehitystiimin mittariksi sen tuottamista ohjelmiston osista

5 löydettyjen alhainen virheiden määrä. Tällöin kahden ryhmän välille syntyy kilpailuasetelma. Moscovici ja sosiaalinen representaatio Moscovici oli romanialaissyntyinen ranskalainen sosiaalipsykologi, joka kehitti sosiaalisia representaatioita kehittävän teorian. Erilaisia käsityksiä ilmiön olemuksesta Moscovici kutsui sosiaalisiksi representaatioiksi. Representaatiot ovat arvojen, ideoiden, kielikuvien, uskomusten ja käytäntöjen kooste [WiSo]. Ne mahdollistavat ihmisten suuntautumisen sosiaaliseen ja materiaaliseen maailmaan ja tekemään siitä hallittavan. Lisäksi representaatiot antavat koodit, jotka mahdollistavat yhteisön jäsenten välisen kommunikoinnin. Representaatio tekee tuntemattomasta käsitteestä tunnettua. Representaatioita on kolmea päätyyppiä [KiMa]. Hegemonisen representaation (1.) jakavat kaikki yhteisön jäsenet ja se vaikuttaa heidän toimintoihinsa. Emansipoidulla representaatiolla (2.) tarkoitetaan pienemmän alayhteisön keskenään jakamaa arkiteoriaa. Poleemiset representaatiot (3.) ovat ristiriidoissa toistensa kanssa olevia arkiteorioita. Ristiriitoja tuottavat keskenään kamppailevat ryhmät. Representaatioiden tarkastelussa Moscovici käytti termejä ankkurointi, objektivointi, naturalisointi ja personofiointi. Ankkurointi (1.) käsittää uuden asian tunnetuksi tekemistä vertaamalla sitä vanhaan. Uusi asia kategorisoidaan ja nimetään yhteisön käsitteiden ja arvojen mukaan. Objektivointi (2.) prosessissa vieras abstrakti käsite muutetaan konkreettiseen muotoon. Käsite saa lopuksi objektin. Naturalisoinnissa (3) uudet käsitykset liittyvät osaksi vallitsevaa sosiaalista todellisuutta[fab14, s. 13. Representaatioiden muodostumisessa personofiointi (4.) [LeFe] tarkoittaa kielellisten erojen merkitystä. Väitöskirjassaan 1961, Moscovici tutki miten psykoanalyysia käsiteltiin ranskalaisissa lehdissä 1950-luvulla. Hän löysi lehdistön toiminnasta kolme erilaista tapaa, jotka liittyivät vastaavaan ranskalaisen yhteiskunnan ideologiseen ryhmään. Keskiluokkaisen lehdistön neutraalia raportointia kutsuttiin termillä diffusion (1.). Konservatiivisen katolilaisen lehdistön tapaa kutsuttiin termillä propagation. (2.) Niissä muut kuin uskontoon sopivat psykoanalyyttiset ilmiöt torjuttiin. Termiä propaganda (3.) käytettiin vasemmiston ja kommunistien lehdissä esiintyneistä artikkeleista. Näissä hyökättiin porvarillisena pidettyä sosiaalipsykologiaa vastaan. Lehtien aiheesta tekemien kirjoitusten perusteella lukijoille muodostui hyvin erilainen käsitys sosiaalipsykologian merkityksestä.

6 Agile on sosiaalinen liike? Ketteriä käytänteitä voidaan tutkia sosiaalisten teorioiden pohjalta. Nämä ovat yhteisiä arkiteorioita meille tärkeistä asioista, joilla mahdollistetaan yhteisen kielen synty. Näin luodaan perusta yksilöiden väliselle kommunikaatiolle. Yksilöistä muodostuva ryhmä luo tämän ympärille oman todellisuutensa (sosiaalinen konstruktivismi). Näistä teorioista yksi on sosiaalinen representaatio, jolla pyritään selittämään käsitteen synty sosiaalisesta näkökulmasta. Ketterien menetelmien syntyä voidaan tulkita sosiaalisten representaatioiden kautta. Muutoksen tarve nousi ohjelmistoalan ammattilaisten yhteisössä, jotka halusivat vaihtoehdon raskaille ohjelmistoprosesseille. Ankkurointi vaiheeksi voidaan nähdä ketterän ohjelmistokehityksen julistus. Objektivointi vaiheessa abstraktit periaatteet muunnettiin konkreettisiksi menetelmiksi, kuten Scrum tai XP. Naturalisointi vaiheeksi voidaan katsoa muun muassa menetelmien yleinen ja laaja käyttöönotto ja hyväksyntä. Abstraktilla tasolla ketterät menetelmät voidaan perustella sosiaalisen representaation kautta. Tosin, näin voidaan perustella myös mikä tahansa muu yhteiskunnan luoma käsite. Käytänteet olivat jo olemassa olevia hyviä käytänteitä, jotka on nidottu yhteen ja otettu käyttöön osana ketteriä menetelmiä. Siitä, onko Agile-käytänteet itsessään sosiaalinen liike vai ei, voidaan kiistellä. Näkisimme kuitenkin, että ketterien periaatteiden pohjalta voi rakentaa sosiaalisen liikkeen, mutta Agile ei itsessään sitä ole. Tavoitteena oli tehdä parempia laadukkaampia ja parempia ohjelmia. Lähimpänä sosiaalista liikettä oli Agile-manifestin muodostuminen. Toisaalta samanmieliset ja -henkiset ihmiset ovat muodostaneet ketterät menetelmät yhdessä. Ihmiset ovat siis konstruoineet sen yhdessä oppimansa pohjalta (vrt. sosiaalinen konstruktivismi). Se on myös sosiaalinen liike siinä mielessä, että käytänteiden taustalla on ollut ryhmädynaaminen prosessi. Ongelmat ovat pakottaneet toimimaan toisin. Toisaalta ketterien menetelmien määrittely on vaikeaa. Ne koostuvat periaatteista, jotka eivät sinällään määritä mitään kovin määräävää. Menetelmät painottavat katsomaan käytänteiden taakse ja ymmärtämään pohjan ja ideologian niiden taustalla. Ne ovat enemmän kehyksiä, kuin vahvoja ideologioita, joita yleensä sosiaaliset liikkeet sisältävät.

7 Scrumban ja siihen liittyvät sosiaaliset ilmiöt sekä ongelmat Lean-tuotanto on lähtöisin 1950-luvulta. Toyotan autotehtaalla aloitettiin kehittämään omaa tuotantomenetelmää (Toyota Production System). Tällaista tuotantotapaa alettiin kutsumaan 1990-luvulla Lean-tuotannoksi. Keskeistä Lean-ajattelussa on hukan (waste) poistaminen tuotantoprosessista. Hukkaa on kaikki, mikä ei tuota arvoa asiakkaalle tai tuotteelle. 2000-luvulla Lean-ajattelua ja periaatteita on alettu soveltamaan myös ohjelmistotuotannossa konkreettisemmin. Lean ohjelmistotuotannon keskeisiä periaatteita ovat seuraavat [WiLP]: Hukan eliminointi Oppimisen vahvistaminen Päätösten tekeminen mahdollisimman myöhään Nopea ohjelmiston julkaiseminen Kehitystiimin voimaannuttaminen Ohjelmiston eheys Kokonaisuuden näkeminen Lean-periaatteet ovat hyvin samankaltaisia kuin ketterän ohjelmistokehityksen manifestin takana olevat periaatteet [AgMaPr] ja ne eivät ole keskenään ristiriidassa. Siksi Agile-prosessien osana käytetäänkin myös usein Lean-periaatteita. Ketterät periaatteet mahdollistavat vahvan asiakas- ja omistajalähtöisyyden. Tiimi vie prosessia eteenpäin itseohjautuvasti. Scrumban on ohjelmistoprosessi, joka yhdistää Scrumin ja Kanbanin [WiSB]. Se sisältää vaikutteita sekä ketteristä menetelmistä että Lean-tuotannosta. Scrumban ei käytä monien ketterien menetelmien suosimaa tiukasti ajoitettua iteratiivista kehitystyötä. Sen sijaan kehitystyötä ohjataan Kanbanin avulla, joka korostaa just-in-time ajattelua ja välttää kehitystiimin ylikuormittamista [WiKan]. Sen sijaan, että prosessi etenisi esimerkiksi viikon pituisten iteraatioiden kautta, Scrumbanissa keskitytään yksittäiseen ominaisuuteen, jonka valmistuttua siirrytään seuraavaan. Sanalla Kanban, tarkoitetaan signalointia korteilla. Kanbanissa ja Scrumbanissa keskeiseen rooliin nousee Kanban-taulu, jossa yksittäiset kortit kuvaavat visuaalisesti jonkin ominaisuuden etenemisen kehitysvaiheesta toiseen. Scrumban on ketterä menetelmä, joka reagoi nopeasti muutoksiin. Nopea muutoksiin reagointi mahdollistetaan rajoittamalla työn alla olevien (WIP) Kanban-korttien määrää. Kanban-taulu luo prosessille rakenteen. Suunnittelua ja analysointia tehdään tarpeen mukaan juuri ennen Kanban-kortin työn alle ottamista. Kanban-korttien kerääntyminen tiettyyn vaiheeseen Kanban-taululla, paljastaa pullonkaulat kehitystiimin sisällä. Esimerkiksi Kanban-korttien kerääntyminen

8 hyväksymätestaus-vaiheeseen on merkki siitä, että testausta tekevät henkilöt ovat ylikuormitettuja. Lean-tuotannossa tuotteet tai niiden osat virtaavat läpi tuotantoprosessin. Scrumbanin tapauksessa tämä tarkoittaa sitä, että Kanban-korttien tulisi virrata läpi Kanban-taulun jatkuvana virtana. Kanban-kortteja ei tule työntää seuraavaan vaiheeseen, vaan seuraavan vaiheen tulee vetää ne kun heille asetettu työmäärä rajoite sen sallii. Scrumban-menetelmään liittyy kuitenkin myös ongelmia. Yksi ongelma johtuu siitä, että Scrumban-menetelmässä ei käytetä aikarajoitettuja iteraatiota. Tavalliseen Scrum-menetelmään liittyy jokaisen sprintin (iteraation) lopussa pidettävä demo-tilaisuus, jossa kehittäjätiimi esittelee sprintin aikana toteutetut toiminnallisuudet asiakkaalle. Tilaisuudessa kehittäjät saavat arvokasta palautetta asiakkaalta ja asiakas voi antaa ideoita seuraavia sprinttejä varten. Tämä auttaa saavuttamaan jatkuvan kommunikaatio yhteyden asiakkaan ja kehitystiimin välillä. Scrumban menetelmässä samanlaista ei kuitenkaan luontaisesti synny, mutta toisaalta mikään ei estä Scrumban-menetelmää soveltavien kehitystiimien pitämästä samankaltaisia toistuvia demo-tilaisuuksia, mitä Scrum suosittelee. Itse asiassa yleensä Scrumban vaatii asiakkaalta vielä läheisempää yhteistyötä kehitystiimin kanssa. Ominaisuuksia olisi tarkoitus esittää asiakkaalla aina kun ne valmistuvat, jolloin asiakas pääsee antamaan palautetta seuraavasta toteutettavasta ominaisuudesta. Ajoitettujen Sprintin demo-tilaisuuden puute voi myös vaikuttaa tiimin työstään kokeman vastuun heikkenemiseen. Demo-tilaisuudessa kehittäjät joutuvat itse esittelemään omaa työtään, jolloin syntyy helpommin tilanne, jossa kehittäjät haluavat näyttää parastaan. Ketterät menetelmät tutkimuksen kohteena Ketterät menetelmät sisältävät paljon mielenkiintoisia sosiaalisia ilmiöitä. Menetelmät painottavat vahvasti sosiaalista kanssakäymistä ja vuorovaikutusta. Ryhmien tulee olla itseohjautuvia ja prosessi muodostuu ryhmien ympärille, ei toisinpäin. Ryhmät koostuvat yksilöistä, joiden tulee löytää yhteinen kommunikointikieli asioiden selvittämiseen ja ongelmien ratkomiseen. Mielenkiintoisia tutkimuskohteita ovat muun muassa: Asiakaskommunikaatio Asioiden selittäminen ja yhteisymmärrys ryhmässä Ristiriitatilanteet Ryhmäkoheesio

9 Yksilöiden kuri ja ryhmän yhteinen kuri Sääntöjen ja prosessin noudattaminen Ongelmien esiintuominen ja ratkaisut Muutoksiin varautuminen Työtehtävien jakaminen ja venyminen Ohjelmistotuotantotiimin suorituskykyä on hankala mitata. Mielestämme esimerkiksi koodirivien lukumäärä (LOC) soveltuu erittäin huonosti mittariksi. Ohjelmistoja ei voida verrata keskenään ja rivien määrän tuottaminen vaihtelee suuresti ohjelmiston elinkaaren aikana. Kuitenkin mittareita tarvitaan, jotta eri menetelmien käyttöönoton vaikutusta voidaan tutkia. Fagerholm esitteli omaa tutkimustaan ketterän tiimin suorituskyvyn kokemuksesta, joka on laadullinen ja ei-ulkoisesti mitattavissa oleva suorituskyvyn mittari. Tutkimuksesta ilmeni, että tuottavan tiimin muodostumiseen liittyy useita sosiaalipsykologian ilmiöitä kuten ryhmän identiteetti ja sen koheesio. Koheesiota lisääviä tekijöitä ovat muun muassa ryhmän pieni koko, pysyvät jäsenet ja ryhmän jäseneksi pääsemisen vaikeus. Tutkimuksesta kävi myös ilmi, että juuri sosiaalipsykologiaan liittyvät ilmiöt tuottavat eniten ongelmia ohjelmistotuotantoprojekteissa, eivät niinkään työkaluihin tai tekniikkaan liittyvät ilmiöt. Fabianin esittelemässä ketterien arvojen tutkimuksessa yhdeksi arvoksi nousi ennustettavuus ja perustelut. On luontevaa, että ohjelmistokehittäjät nostavat ennustettavuuden yhdeksi tärkeimmistä arvoista, sillä ohjelmistojen kehittäminen on luonteeltaan vaikeasti ennustettavaa. Tutkimuksen mukaan, päätösten tekeminen pitäisi perustua todisteisiin ja havaintoihin. Havaintojen tekemiseen tarvitaan mittareita ja useat ohjelmistotuotantoon liittyvät ilmiöt ovat vaikeasti mitattavia. Usein pätee myös sääntö sitä saat mitä mittaat. Ketterät menetelmät kannustavat kaikille näkyvien ja visuaalisten mittareiden käyttöä. Esimerkiksi Kanban-taulu antaa kenelle tahansa kehitystiimin työskentelytilassa vierailijalle nopeasti kuvan projektin sen hetkisestä tilanteesta. Dilbert ja esimiesasema Dilbert on Scott Adamsin luoma satiirinen sarjakuvahahmo, joka työskentelee byrokraattisessa IT-yrityksessä. Adams on kehittänyt sarjakuvahahmosta Dilbertin periaatteen [DiPr]. Siinä käsitellään yritysten järjestelmällistä toimintaa epäpätevämpien spesialistien siirtämisestä johtotehtäviin. Tällöin heidän mahdollisesti tulevaisuudessa aiheuttamaa vahinkoa saadaan rajoitettua parhaiten. Yrityksessä aikaansaavia ihmisiä, kuten sydänkirurgeja, ohjelmoijia ja muita älykkäitä ihmisiä siirretään harvemmin johtotehtäviin. He mahdollistavat työn teollaan yrityksen menestyksen.

10 Dilbertissä yritysjohto ymmärtää vähän yrityksen toiminnasta. Esimiehet pyytävät alaisiaan tekemään mielivaltaisia tehtäviä, jotka liittyvät työn näennäiseen tuottavuuteen, mutta ovat etupäässä puuhastelua vieden aikaa tärkeimmiltä tehtäviltä. Toimien seurauksina tärkeät aikataulut eivät toteudu ja asiakkaille myydään pelkkiä mielikuvia toteutuneen tuotteen asemasta. Peterin periaate [AkTa] liittyy läheisesti Dilbertin periaatteeseen. Siinä ihmiset pääsevät ylenemään tekemisensä ja osaamisensa pohjalta. Jossain vaiheessa he saavuttavat ylenemisessä tason, jossa heidän tietonsa ja taitonsa eivät ole enään päteviä. Lopulta henkilö pysyy saavuttamassaan asemassa ja toimii epäpätevästi. Työntekijä eristetään yrityksen johtoon pois tuottavien työntekijöiden tieltä. Esimiesasemaan ja byrokratiaan liittyy myös Parkinsonin lakeja [PaLa], kuten "virkamies haluaa moninkertaistaa alaisiaan, ei kilpailijoita" sekä "automaation koolla ei ole merkittävää vaikutusta byrokratian kokoon tai tehokkuuteen". Gilbertin periaatteen tapaisia toimintoja on kerätty oikeilta työpaikoilta [EaDi], kuten yrityksen esimiehen kommentti ryhmätyöstä: "Ryhmätyö on paljon ihmisiä tekemässä sanomaani asiaa". Puhelinpalveluyhtiön sisäinen kommentti: " Tiedämme, että kommunikointi on ongelma, mutta yhtiö ei aio aloittaa keskustelua siitä työntekijöidensä kanssa". Ryhmät ketterissä menetelmissä Tiimien jäsenten poistuvuus on keskeisiä ongelmia ketterissä menetelmissä. Pystyäkseen toimimaan tehokkaasti, ryhmän jäsenillä pitäisi olla tietty määrä kokemusta ohjelmistokehityksestä ja sen eteenpäin viemisestä. XP:ssä pariohjelmoinnin hyöty alkaa tulla esiin vasta muutaman kuukauden päästä. Mikäli tehokkaalla ohjelmoijalla on parinaan aloitteleva ohjelmoija, tehokkaan ohjelmoijan työteho laskee projektin alkuvaiheessa tilapäisesti. Vastaavasti uuden ohjelmoijan työpanos alkaa kasvamaan. Isoimmissa työpaikoissa voi työskennellä monta tiimiä samaan aikaan. Lisäksi tiimit ovat itse muodostuvia. Tiimin jäsen voi valita ryhmän kulloisenkin kiinnostuksen kohteensa mukaan. Mikäli yrityksessä ei ole kuin yksi tiimi, yhden pääosaajan pois lähteminen voi aiheuttaa ohjelmistokehityksen tilapäistä laskua. Tuotantohäiriöiden vähentämiseksi yritys voi pohtia erilaisia työntekijän yhtiöön sitouttamistapoja. Tärkeä tekijä on työpaikan sosiaalinen ympäristö. Vaikka käytössä olisi sama työtila informaation kulun parantamiseen, se ei tarkoita, että työilmapiiri eri henkilöiden kesken olisi sama. Ketterien järjestelmien projektipäällikön asemassa oleva Scrum-mestari voi joutua tilanteeseen, että häntä kohdellaan ulkopuolisena ryhmän jäsenenä. Tällöin hänen on hankala pysyä ajantasalla työilmapiirin tarkkailussa. Ketterien menetelmien

11 pitäisi pyrkiä lisäämään työtehon lisäksi sosiaalista yhteenkuuluvuutta. Yksi tapa yhteenkuuluvuuden lisäämiseksi on olemassa olevan ulkoisen tai keinotekoisen uhan torjuminen. Toiminnalla pyritään lisäämään ryhmän kiinteyttä (koheesiota). Scrum-mestarista voi kehittyä johtaja. Johtajana hän edustaa sisäryhmän prototyyppiä ryhmälle johon kuuluu. Johtajasta tulee tavallaan ryhmän ilmentymä. Tämä viestittää ryhmälle ja luo identiteettiä. Millainen johtaja, sellainen ryhmä. Johtajan roolissa hänestä tulee helposti osa ulkoryhmää. Johtajan pitää pystyä johtamaan toimintaa ryhmän ulkopuolelta. Tähän hän voi käyttää erilaisia tilannekohtaisia johtajia. Johtaja voi etsiä kulloiseen tilanteeseen sopivan tehtävä- ja tunnejohtajan, ja johtaa niiden kautta. Miten ryhmää pitäisi johtaa, että siitä saataisiin huipputuottava? Ryhmän muodostuminen on yksilökohtaista. Jotkut henkilöt soveltuvat hyvin Scrum ryhmään ja sen aktiiviseen toimintatapaan. Tehokkaan ryhmään jäsenet ovat sosiaalisen skaalan toisessa päässä. Monilahjakkaat ihmiset ovat yleensä sosiaalisesti taitavia [HoSo]. Tiimin luontiin liittyviä kysymyksiä: Minkälainen ryhmän identiteetti olisi? Miten tiimille tuotetaan ylemmyyden tunnetta? Minkälainen palkitsemisjärjestelmä on olemassa? Miten autetaan henkilökohtaista kehitystä? Miten saadaan luotua suoritusmotivaatiota? Pohjautuvatko ketterät menetelmät arvoihin ja jos pohjautuvat, niin minkälaisiin? Shalom Schwartz on muun muassa kaksi arvoteoriaa kehittänyt psykologi. Teoriat käsittelevät yksilöiden arvoja sekä kulttuurisia arvo-orientaatioita [ScPu]. Hän on ensimmäinen arvotutkija, joka on onnistunut kehittämään empiirisesti testattavissa olevan arvoteorian. Mittauksissa on käytössä 56 arvoa [ArKh], joista 40:llä on sama merkitys eri maissa. Schwartzin keskeinen oivallus on, että arvot liittyvät toisiinsa. Ne ovat joko toisiaan täydentäviä tai toisensa poissulkevia. Yksilön arvojen arvokartta koostuu kymmenen arvon muodostamasta arvokehästä. Arvokehän sisällä yksilön sijainti voidaan määritellä täplällä. Sijainnin perusteella voidaan havaita esimerkiksi, onko henkilö enemmän ryhmä- vai yksilökohtaisesti suuntautuva. Arvokehän vastapareja ovat esimerkiksi: itsensä ylittäminen itsensä korostaminen säilyvyys avoimuus muutokselle yhteisiä päämääriä edistävät arvot yksilön päämääriä edistävät arvot

12 Yhteenveto Ohjelmistokehitys on mitä enemmissä määrin ryhmätyötä. Ei ole siis poikkeuksellista, että sitä pystytään selittämään ja tutkimaan sosiaalipsykologisesta näkökulmasta. Kuten mitä tahansa muutakin, on näitäkin mahdollista ylitulkita. Ihmiset kehittävät oppimansa pohjalta uusia rakenteita ja menetelmiä. Niihin vaikuttaa siis keskeisesti ryhmän piirteet ja kanssakäyminen, eli sosiaalinen dynamiikka. Ellei ajatella, että Platonin-ideaoppi on vallitseva selitys ideoiden olemassaolosta, jossa ideat ja konkretia ovat täysin erillä olevia asioita, on vaikea olla pitämättä ihmisten muodostamia asioita sosiaalisena konstruktiona. Ketterät menetelmät nousivat ratkaisuna ongelmaan. Ohjelmistotuotanto oli jäykkää ja ei tuottanut laadukkaita ohjelmistoja asiakkaiden tarpeisiin. Ketterät menetelmät nostivat esille ohjelmistotuotannon ryhmädynaamisen luonteen. Ohjelmistot ovat usein lukuisten ihmisten yhteinen tuotos. Ihmisten mielipiteet muuttuvat. Mikään ei ole täysin varmaa. On siis mahdotonta määritellä ennalta täysin miten jonkin ohjelman tulisi toimia. Muutoksiin tulee varautua. Ketterät menetelmät toivat prosessin, jota on kevyt ylläpitää, joka soveltuu kunkin ryhmän tarpeisiin ja joka painottaa yksilön ja ryhmän itseohjautuvuutta. Yksilön vastuuseen tulee liittää yksilön vapaus. Läheisellä asiakaskommunikaatiolla pystytään varmistamaan, että asiakkaan idea konkretisoituu. Tässä ketterät prosessit ovat onnistuneet. On kuitenkin varsin voimakasta väittää, että ketterät prosessit olisivat sosiaalinen liike. Se on kyllä voinut syntyä sosiaalisen liikkeen pohjalta, mutta se on muodostunut jo ennalta olevien ideoiden päälle. Ketterän kehityksen pohjalta voidaan luoda sosiaalinen liike, mutta itsessään se ei sitä ole. Ketterät menetelmät syntyivät ohjelmistoalan sisällä ja sen tarpeisiin. Ketterän ohjelmistokehityksen manifesti käyttää alalle ominaista termistöä, kun taas Lean-ajattelu on syntynyt teollisen tuotannon kautta ja sen tarpeisiin. Lean-tuotannon periaatteet käyttävät abstrakteja termejä ja kielikuvia. Kumpaakin voidaan soveltaa ohjelmistotuotannossa. Mielestämme Agile manifestiä tai Lean ajattelua ei tule soveltaa kirjaimellisesti, vaan pyrkiä soveltamaan niitä tilanteen mukaan ja ymmärtämään ajattelutapaa niiden taustalla. Agile tai Lean ei tarjoa valmista ratkaisua kaikkiin ohjelmistotuotannon ongelmiin, kuten ei mikään prosessimalli tai työkalu. Lean ajattelu jättää kuitenkin ohjelmistotuotantoon sovellettaessa huomattavasti enemmän tulkinnan varaa kuin Agile.

Ohjelmistotuotannon tutkimuksessa on luontevaa käyttää apuna sosiaalipsykologiaa, sillä monet ohjelmiston kehittämisen haasteista ja ongelmista liittyvät ihmisten väliseen kommunikaatioon ja ryhmädynamiikkaan. Väheksymättä kuitenkaan teknisiä ja osaamiseen liittyviä haasteita. Useat väärinkäsitykset asiakkaan ja kehittäjien sekä kehitystiimin sisällä liittyvät yhteisten käsitteiden puuttumiseen. Asiakas ei osaa kuvailla sanoin haluamaansa ja kehittäjät eivät osaa kysyä tärkeitä kysymyksiä asiakkailta heidän ymmärtämällä kielellä. Tällaisia tilanteita voidaan tarkastella esimerkiksi sosiaalisten representaatioiden ja niiden syntymisen avulla. 13

14 Lähteet [AgMa] Beck et. al, Manifest for Agile Software Development, http://agilemanifesto.org/ [AgMaPr] Beck et. al, Principles behind the Agile Manifesto, http://agilemanifesto.org/principles.html [AkTa] Akateeminen talousblogi- Peterin periaate (Peter principle) http://blog.hse-econ.fi/?p=2015 [ArKh] Arvot, niiden muuttuvuus ja pysyvyys - Klaus Helkama http://www.etene.fi/c/document_library/get_file?folderid=276604&name=dlfe-4 604.pdf [DiPr] Dilbert principle http://en.wikipedia.org/wiki/dilbert_principle [EaDi] eal-life Dilbert quotes http://www.cs.vu.nl/~frankh/dilbert/quotes.html [Fab14] Fagerholm, Fabian, Ketteristä menetelmistä ja niiden ryhmädynamiikasta, 25.11.2014, http://www.cs.helsinki.fi/u/wikla/odyna/s2014/ketterista_menetelmista_ja_niide n_ryhm%c3%a4dynamiikasta.pdf [HoSo] How do Software Developers Experience Team Performance in Lean and Agile Environments?-Fagerholm, Ikonen, Kettunen, Münch,Roto, Abrahamsson http://www.sserg.org/publications/uploads/569e7c9ec023a41300b06d4bf470a437 9950f900.pdf [KiMa] Kirjallisuusmallivastaukset https://www.uef.fi/documents/12848/976534/yhteiskuntatieteet+kuopio+valintak oe+2012+kirjallisuusmallivastaukset.pdf/18f01341-00e0-4c12-ab2f-a302980f3e15 [LeFe] Festinger http://leonfestinger.blogspot.fi/2013/02/serge-moscovici-1925.html [PaLa] Parkinsons Law http://www.berglas.org/articles/parkinsons_law.pdf [ScPu] Schwartzin kaksi arvoteoriaa - Puohiniemi http://www.puohiniemi.fi/arvosanasto/schwartzin-kaksi-arvoteoriaa.html [WiKan] Wikipedia, Kanban (development), http://en.wikipedia.org/wiki/kanban_(development) [WiLP] Wikipedia, Lean software development - Lean principles, http://en.wikipedia.org/wiki/lean_software_development#lean_principles [WiSB] Wikipedia, Scrum-ban, http://en.wikipedia.org/wiki/scrum_(software_development)#scrum-ban [WiSo] Wikipedia, Social representation, http://en.wikipedia.org/wiki/social_representation

[WiWa] Wikipedia, Waterfall model, http://en.wikipedia.org/wiki/waterfall_model 15