Palvelumuotoilua ja yhteiskehittelyä

Unelma tuottaa
yhdessä kehittäen
palvelun arkeen.

Kysyt, kuuntelet,
suunnittelet, mallinnat;
palvelu kantaa.

Palvelumuotoilutyöpajassa Otavan Opiston Helsingin tiloissa 12.5.2014 professori Satu Miettinen Lapin yliopistosta painotti palvelumuotoilua strategisen johtamisen välineenä. Hän kertoi urastaan kuvataiteista kiinnostuneena tekstiilitaiteilijana, joka on työskennnellyt matkailuhankkeen projektipäällikkönä ja väitellyt palvelumuotoilusta vuonna 2007, ensimmäisenä Suomessa. Ajatuksiaan hän jakaa Muotoiluajattelu-blogissaan, jossa on yli 50 000 kävijää. Hän luonnehti sitä muotoiluajattelun vapaaksi avoimeksi oppimisympäristöksi. Jatka lukemista “Palvelumuotoilua ja yhteiskehittelyä”

Käyttäjä kiittää, some markkinoi

Liikut ulkona
opaskoira ja keppi
kanssasi, yksin.

Kuulet Blindsquaren
kertovan paikkatiedon
ympäriltäsi.

Avoin data
ja some tarjoavat
innovaation.

Tietotekniikan liiton liittokokouksessa 25.4.2013 Ilkka Pirttimaa  kertoi kehittämästään BlindSquaresta, vuoden tietotekniikkatuotteesta. Jatka lukemista “Käyttäjä kiittää, some markkinoi”

Projektijohtaminen on tiedettä ja taidetta

Innovaatiot
tehokkuuden lähteinä,
ei työuupumus.

Projekti muuttaa
prosessin. Stressaantuuko
pieni ihminen?

Projektipäivät keräsi kahdeksansataa projektipäällikköä ja muuta projektiammattilaista Dipoliin 13. – 14.11.2012. Jatka lukemista “Projektijohtaminen on tiedettä ja taidetta”

Kulttuuria, hengittämistä ja avoimuutta

Mene museoon,
hengitä ja keskity;
elät pidempään.

Ole arjessa
läsnä, rauhoita mielen
poukkoilu hetkeen.

Helsingin yliopiston Sosiologian alumnit lupasivat selvittää, miten työelämässä selviää hengissä, vaikka muutos murjoo ja tulospaineet tuupertavat. Kymmenet alumnit kokoontuivat 7.11.12 Social- och kommunalhögskolanin luentosaliin kuulemaan, millaisia neuvoja työhyvinvointiin tarjoavat ylilääkäri Markku T. Hyyppä, Mindfulness-kouluttaja Reija Suntio ja Futuricen henkilöstöpäällikkö Lenita Lempainen. Jatka lukemista “Kulttuuria, hengittämistä ja avoimuutta”

Ketterä monimutkaisuus

susi vai lammas
tylsyys vai yksinäisyys?
valitse siitä

unohda mallit
luokittelut, kuuntele
hiljaa kaaosta

Scandinavian Agile Conference 2012  keräsi naistenpäivästä huolimatta miesvoittoisen esiintyjäkaartin ja yleisön Helsingin Marina Congress Centeriin 8.3.2012. Pääsin mukaan TTL:n Systeemityöyhdistys Sytyken edustajana. Avaussanoissa todettiin, että IT-alalla työskentelijöistä vain 6-8 % on naisia, ja naisia kaivataan alalle lisää. Konferenssissa twiitattiin hashtagilla #scanagile.
Dave Snowden  ehdotti kielteisten määrittelyjen muuttamista myönteisiksi ja teorian vuorovaikutusta käytännön kanssa. Usein merkitykselliset asiat syntyvät sattumalta. Mukautumisen sijaa pitäisi etsiä poikkeuksia.
Järjestelmäkehityksessä ei voida olettaa, että asiakkaat aina tietäisivät, mitä haluavat. Heidät pitäisi johtaa tilanteisiin, joissa he oivaltavat tarpeensa. Tätä havainnollisti järjestystä kuvaava pieni pursi ja kaoottisesti vyöryvä valtameri. Järjestys asettaa rajoituksia ja liika kontrolli tuhlaa työpanosta. Satunnainen systeemi on kaoottinen; ei voida ennustaa, mitä tapahtuu, kun lähestyt toista – eikä tilannetta voida toistaa.
Hiljainen tieto on tärkeä voimavara organisaatiossa, mutta yleensä asiat alkavat tapahtua, kun ne tehdään näkyviksi.
Perinteisessä systeemiajattelussa kiinnitetään tavoitetila ja askeleet siihen, muu ympäristö jäädytetään eikä jätetä tilaa oppimiselle. Monimutkaisessa systeemissä taas tavoitetilaa ei voida tarkkaan määritellä. Inhimillistä toimintaa yritetään kuvata mallilla, jotta sitä voitaisiin kontrolloida, mutta monimutkaisuutta ei voi mallintaa. Tätä havainnollisti yksinkertaistettu malli monimutkaisesta liikenneympyrästä.
Ihminen käyttäytyy eri paikoissa ja eri tilanteissa eri tavoin; ihminen on kotonaan erilainen kuin työpaikallaan. Monimutkaisuus ei välttämättä ole hyvä, mutta se on osa elämää. Ihmisen pitäisi oppia kuuntelemaan omaa inhimillisyyttään.
Monissa organisaatioissa tietohallinnon toiminnot periytyvät 1980-luvulta. Tietohallinnon pitäisi olla taidetta, jolla nopeutetaan asiakkaan pääsyä tavoitteeseensa. Päivittäiset tarinat ja päiväkirjat avaavat todelliset tarpeet nopeammin kuin tarpeiden kyseleminen.
Suuressa organisaatiossa valtaosa ajasta kuluu säilyttämiseen ja vain pieni osa todelliseen työhön. Lampaan elämä voi olla tylsää kun taas susi voi tuntea itsensä yksinäiseksi. Valitse siitä! Inhimillinen heikkous on parempi kuin robotin voima. Kulttuuri on kaikkein monimutkaisin. Eikä monimutkaisuus pääty milloinkaan.
Joseph Pelrine  aloitti esityksensä kysymällä, miksi ketteryys toimii tai toimiiko ketteryys. Aikoinaan Dracula hämmensi todellisuutta, kun oli totuttu siihen, että ihminen oli joko elävä tai kuollut eikä muita vaihtoehtoja ollut. Kun ihminen joutuu pois mukavuusalueeltaan, hän alkaa oppia – päästäkseen uudelleen mukavuusalueelleen.
Ihmiset eivät ole rationaalisesti ajattelevia muurahaisia, Bobeja, jotka voisi korvata toisillaan. Jokaisella ihmisellä on ainutlaatuinen historiansa, muisti, josta ammentaa; siksi yritykset ihmisen toiminnan luokittelemiseksi ja mallintamiseksi pitäisi hylätä.
Perinteisessä tietojärjestelmän kehittämisessä on kyse monimutkaisesta epäjärjestystilanteesta, jossa ennustaminen tulee mahdottomaksi. Jälkikäteen on toki helppo nähdä, paljonko aikaa eri vaiheisiin meni ja miksi. Mutta se ei helpota seuraavassa arviointitilanteessa, jossa on taas kysymys monimutkaisesta epäjärjestyksestä.
Joseph Pelrine esitteli Dave Snowdenin Cynefic-rakennetta. Ketterä järjestelmäkehitys sopii monimutkaisiin tilanteisiin. Kaikki menetelmät, myös vesiputousmalli, toimivat, kun niitä käytetään niihin sopivissa tilanteissa. Jos jokin voidaan tehdä yksinkertaisesti, niin miksi se pitäisi tehdä monimutkaisemmin? Vasara ja naula eivät kuitenkaan ole kaikissa tilanteissa oikeita työkaluja.
Kati Vilkki Nokia Siemens Networkilta keräsi salin täyteen yleisöä kuuntelemaan konkreettisia kokemuksia siitä, miten luodaan jatkuvasti kehittyvä kulttuuri.
Ihmisille pitää antaa aikaa oppia ja kehittää, jatkuva kehittyminenhän on ketteryyden ja leanin kulmakivi. Jos halutaan erilaisia tuloksia, niin jotain pitää tehdä eri tavalla; tarvitaan uudenlaista ajattelua ja vanhan poisoppimista.
Kati Vilkki kysyi, mitä arvelisimme tavalliselle ihmiselle ensimmäisenä tulevan mieleen, jos hänelle puhuu ohjelmistosta. Niinpä: ongelmat, esimerkiksi kun viime syksynä junalippuja ei voinut ostaa.
Jos yritys pyrkii minimoimaan kustannuksia, se ennen pitkää minimoi laatua. Tuottavuus ei ole sitä, että kustannukset painetaan alas; tuottavuus on sitä, että tuotos suhteessa kustannuksiin olisi mahdollisimman suuri.
Monissa organisaatioissa palautekierros on niin pitkä, että voi kestää vuosia ennen kuin yritysjohto saa palautteen.  Palautekierrosta voidaan lyhentää keräämällä jatkuvasti tietoa (data) ja tarinoita.
Oppiminen on arvo sinänsä; sitä ei saa sysätä hetkeen, jolloin sattuu olemaan aikaa. Oppimisen pitää olla turvallista; ihmisellä pitää olla mahdollisuus sanoa: “En tiedä.” Tiimillä pitää olla tunne vastuustaan ja vaikutusmahdollisuuksistaan, myös vakautta ja tietoa tilastaan. Johtamisen pitäisi perustua merkityksiin, ei numeroihin.
Oppiminen on vaikeaa. Hämmennys on terveellinen tila mielelle. Kokemuksesta oppiminen tarkoittaa tekemisen tuloksen reflektointia ja analysointia, uuden työskentelyteorian muodostamista ja uudenlaista tekemistä.
Mitä on viisaus? Sitä, ettei tee samaa virhettä kahteen kertaan; nimenomaan sitä, että oppii kokemuksestaan.
Scrumin retrospektioita pidetään tylsinä. Ensimmäisellä kerralla voidaan vielä olla innostuneita, mutta kun samaa listaa toistetaan kerrasta toiseen, innostus laantuu. Retrospektioista voisi tehdä retrospektioita; miten tylsän asian voisi tehdä toisin? Kuitenkin tarvitaan palautetta, muuten ei tiedetä, missä ollaan ja miten tilannetta parannetaan. Tarvitaan yhteisöllistä, systemaattista ongelmanratkaisua ja syvällistä suunnittelua: Mikä on ongelma? Miksi se on ongelma? Mitä siitä seuraa? Miten ongelma ratkaistaan?
Voimmeko vaikuttaa toisiimme? Ketään ei saa halukkaasti tekemään asioita, joista tämä ei pidä. Jokainen pitkään naimisissa ollut on huomannut sen – tai jokainen muistellessaan, miltä tuntui lapsena, kun äiti käski huonetta siivoamaan.
Vuorovaikutus on paras tapa vaikuttaa. Kun toinen pyytää apua, auttamisesta nauttii, esimerkiksi lastenvaunujen kanssa julkisissa liikennevälineissä. Miten vähän tätä käytetään organisaatioissa? Kun muutamme omaa käyttäytymistapaamme, toinen ei voi käyttäytyä vanhalla tavalla. Ihmiset kuuntelevat uskottavaa ja merkityksellistä puhetta, joka on heidän puolellaan.
Ajattele työuraasi: Milloin olit täynnä energiaa? Parin minuutin porinatuokio toi esiin tilanteita, joissa ihminen oli kokenut voivansa itse vaikuttaa tekemisiinsä.
Laura Snellman-Junna Reaktorilta kertoi empaattisuuden mekanismeista. Ihmiset unohtavat sanasi ja tekosi, mutta eivät sitä, millaisia tunteita olet heissä herättänyt. Omat lapset ovat opettaneet empaattisuutta enemmän kuin koulu tai työelämä.
Empaattisuus tuo informaatiota päätöksentekoon, tehostaa keskustelua ja on perusta kaikille inhimillisille suhteille. Miten tulkitsemme toisen tunteita? Ensin kuulemme sanat, tarkkailemme kehon kieltä ja lopuksi kuuntelemme omaa sydäntämme.
Ryhmäempatiaan kuuluu ryhmän kehittämät omat normit, joilla ryhmä pysyy koossa. Ne vaikuttavat ihmissuhteisiin, tekemiseen, luovuuteen ja tuloksiin. Ryhmäempatia helpottaa keskustelussa ja synnyttää luottamusta.
Kysy enemmän, oleta vähemmän! Havainnoi, ole avoin! Meditoi; se kasvattaa empaattisuutta, emotionaalista itseohjautuvuutta ja itsetietoisuutta.
Empaattisuuteen liittyviä mekanismeja havainnollistettiin kuvilla ja värillisillä liimalapuilla, kynällä suussa ja muutamalla videolla. Videoiden äänentoisto vaati luovuutta: kokousmikrofonia pidettiin Macin kaiuttimen luona.
Marko Taipale Huitaleelta näytti sellaista, jota ei voi nähdä (showing unseen), tapauskertomuksia erilaisista ketteristä ohjelmistokehityksistä. Piirros ja tarina auttaa yleensä asian ymmärtämistä.
Miksi projekti ei etene? Kun projektihuoneessa on fäppejä liimalappuineen, mutta ei projektitiimiä. Työn eri vaiheiden kesto olisi yhteensä ollut kolme kuukautta, mutta  odotteluun vaiheiden välissä kului puolitoista vuotta. Mitä opittiin? Koko arvovirta (value stream) pitäisi optimoida.
Toisessa tapauskertomuksessa ohjelmistokehityksen dokumentit eivät täsmänneet. Vähitellen selvisi, ettei kellään ollut kokonaisvastuuta vaan jokainen vastasi vain tietyistä yksityiskohdista. Kun tästä otettiin oppia seuraavassa projektissa, säästettiin miljoonia euroja vuodessa. Mitä opittiin? Näyttäminen ei vielä ole kuntoon saattamista. Haluatko oikeutta vai olla avulias? Unohda dogmit, kuuntele ja näe tarpeet!
Kolmannessa tapauskertomuksessa tiimi kehitti samaa osaa ohjelmistosta, jota jo edellisenä vuonna oli kehitetty. Asiakas hermostui, kun toimittajan edustajat kyselivät samoja asioita uudestaan. Tilanne selittyi sillä, että tiimin kaikki jäsenet olivat välillä vaihtuneet eikä edellisen kehityksen tuloksia ollut otettu käyttöön, kun ne olisivat vaikuttaneet moneen muuhun tietojärjestelmään.
Visualisointi on hyvä keino, mutta se ei ratkaise kaikkea. Kuvatuissa tapauskertomuksissa ongelmat olivat johtamisessa. Konsultti voi näyttää totuuden, mutta hänen ei kannata leikkiä muulia vaan hakea tukea.
Lopuksi Reidar Wasenius  tutustutti meidät Aivobiciin, jota voi harrastaa mm. vasta avatussa Aivokuntokeskuksessa. Monen asian tekeminen samanaikaisesti, multitasking, on tärkeää, mutta siinä on jo menty liian pitkälle. Ihmiset ovat hajamielisiä eivätkä osaa keskittyä. Niinpä konferenssipäivän päätteeksi istuimme silmät kiinni ja musiikin rytmissä luettelimme Reidar Waseniuksen johdolla mielessämme helpohkoja numerosarjoja – keskityimme hetkeen, jossa olimme!

Hiljaista tyhjäkäyntiä

it pyörittää
tyhjäkäyntimyllyä
ylläpidossa

hiljainen tieto
huutaa, kodifioidaan
tietokantoihin

innovoimalla
muisti talteen, liikkeelle
osaamiseksi

Sytyken jäsentilaisuudessa Nokialla 31.3.11 Pentti Salmela pohdiskeli, miten hiljainen tieto saadaan talteen ja tuottamaan it:n avulla. Suomihan on jonkin tilaston mukaan pudonnut tietoyhteiskuntakehityksessä sijalle 20.
Pentti Salmela puhui it-toiminnan tyhjäkäyntimyllystä: perustason järjestelmiä ja laitteita uudistetaan jatkuvasti, seuraavalla tasolla rakennetaan kalliita erppejä, joiden takaisinmaksuaika on pitkä, eikä koskaan päästä ylimmälle tasolle, jossa it:n avulla saavutettaisiin liiketoiminnan uudistumista, muutosta ja kilpailuetua. Yli 90 % it-toiminnasta menee kertaalleen tuotettujen järjestelmien ylläpitoon. Pyörittävätkö laitetoimittajat tätä myllyä?
Yleisön joukosta todettiin, että teknologia kehittyy luontoystävällisemmäksi ja prosessorit kehittyvät jatkuvasti tehokkaammiksi, joten järjestelmiä ja laitteita pitää uudistaa.
Pentti Salmelan mukaan it-tuottavuus löytyy uudelta tasolta. Organisaation tiedosta vain 5 % on eksplisiittistä ja kodifioitua eli tietokantaan tai käyttöoppaaseen tallennettua, loput 95 % on hiljaista tietoa. Tässä on it-toiminnan potentiaali. Hiljainen tieto voidaan dokumentoida puhumalla ja strukturoida digitaaliseen muotoon. Tästä voidaan johtaa seuraava malli:

  • hiljainen tieto ->
  • puhuttu tieto ->
  • dokumentoitu tieto ->
  • tietokoneohjelman käsittelemä data.

Yleisön joukosta ehdotettiin toisaalta tunteen lisäämistä malliin ennen hiljaista tietoa, toisaalta puhutun ja dokumentoidun tiedon yhdistämistä kommunikoinniksi.
Hiljaista tietoa voidaan tarkastella useasta eri näkökulmasta:

  • filosofisesta – data, informaatio, tieto, älykkyys, viisaus
  • sosiaalisesta – esim. miten organisaatiosta lähtevien työntekijöiden hiljainen tieto saadaan talteen?
  • informaatiologistisesta – miten tieto, joka on osa organisaation muistia,  saadaan liikkumaan, talteen ja tuottamaan?

Miten uusi tieto syntyy organisaatiossa? Projektiryhmä, joka kehittää uutta tietojärjestelmää, tarvitsee kaiken kyseistä järjestelmää koskevan tiedon. Organisaation kehittäminen on yhtä tehokasta kuin muistin liike.
Yleisön joukosta kysyttiin, voidaanko hiljaisen tiedon välitysmekanismi kodifioida, vaikka kaikkea hiljaista tietoa ei haluttaisi kodifioida. Välitysmekanismiksi tarjottiin leirinuotioita, mentorointia ja kisälli-oppipoikajärjestelmää.
Toteamus “Osaan kävellä, mutten tiedä, miten kävellään” kuvannee hiljaista tietoa.
Innovaatio-, projekti- ja it-toiminnan avulla voidaan siirtää tietoa asiakkaan ja käyttäjän uudeksi osaamiseksi. Tähän tarvitaan uudenlaisia menetelmiä. Kun verrataan organisaation toiminnallista mallia ja teknistä toteutusmallia, niin ketterässä kehityksessä nämä saadaan nopeammin lähemmäs toisiaan kuin perinteisessä iteroivan vesiputousmallin mukaisessa systeemityössä.
Pitäisikö it-strategiaa kehittää tietämyksenhallintastrategiaksi?

Oppimalla muutokseen

into oppia
organisaatiossa
johtaa muutosta

luodaan tavoitteet
kuunnellaan, ymmärretään
muutos tulevaan

Sytyken Prosyn ja Haaga-Helian Prolabin järjestämä miniseminaari Organisaatioiden kehittäminen ja muutos 2015 keräsi toistasataa aktiivista ja tiedonjanoista asiantuntijaa eri organisaatioista Haaga-Helian Pasilan auditorioon 17.3.2011.
Ketterä ja dynaaminen lean-konsultti Ari Tikka aloitti kysymällä, miten hyvin luottamus, huolenpito ja rakkaus toteutuvat omassa organisaatiossasi tai tiimissäsi. Hän kuvasi organisaatiokulttuurin voimaa jäävuorella, joka vahvistuu, kun näkyvä huippu ja piilossa olevat toteutuvat arvot ja perusoletukset tukevat toisiaan. Ahdistuksen hallintaan ja ulkoisista ongelmista selviytymiseen löydetään tavat, jotka opetetaan organisaation uusille jäsenille oikeana tapana havaita, ajatella ja tuntea.
Organisaatiokulttuuri muodostuu tarinoista, joita kerromme itsestämme. Hiljainen tieto voi muutoksissa vanhentua. Yksittäiset tehtävät voivat muuttua nopeasti, ajattelu ja osaaminen hitaammin ja arvot vielä hitaammin.
Halutaanko oppimisen johtavan muutokseen? Luoko ymmärrys oikeaa toimintaa uusissa tilanteissa? Syventävässä oppimisessa sovelletaan opittua omaan ainutlaatuiseen tilanteeseen ja rakennetaan omaa identiteettiä. Kokemuksellisessa oppimisessa osallistujat tuovat prosessiin omat merkityksensä. Kun törmätään rajoihin, verkosto auttaa voimaantumisessa.
Ari Tikka kuvasi muutoshanketta kolmiolla, jonka huipulla istuu hankkeen johtoryhmä ja pohjalla luodaan yhteistä kieltä tietoiskuin ja keskusteluin.  Peruskurssien päälle asettuvat syventävät, soveltavat kurssit ja näiden yläpuolelle johtoryhmän alle muutosagentit.
Muutos voidaan aloittaa jostain pilotista ja laajentaa uusi kulttuuri ja osaaminen vähitellen koko organisaatioon.
Organisaation vieraantuminen syntyy ylierikoistumisella, konfliktien välttämisellä vaikenemalla niin, että ne paisuvat liian suuriksi ennen kuin niihin tartutaan. Vieraantumista voidaan torjua leveällä vastuulla, oppimisen intohimolla ja asioiden käsittelyllä jatkuvana virtana.
Pertti Melonen aloitti mukaansatempaavan esityksensä kysymyksin. “Onko muutosta ilmassa?” Vuodenajoista päätelleen ainakin jonkin verran. “Kuka tuntee olevansa muutosagentti?” Kaikkien pitäisi nostaa kätensä! Me kaikkihan haluamme vaikuttaa siihen, mihin yhdessä olemme matkalla ja miksi.
Muutoksen johtaminen on tavoitteiden luomista, läsnäoloa ja keskustelua yhteisillä foorumeilla, kykyä kuunnella ja ymmärtää, myös sietää erilaisia pölinöitä. Muutosvastarinta on ihmisen henkilökohtainen tapa ottaa itselleen aikaa muutokseen, mutta missään organisaatiossa ei oikeasti ole ihmisiä, jotka vastustaisivat tulevaisuuteen suuntautuvaa muutosta.
Muutoksessa tarvitaan kipinää, viestintää ja kuohuntaa. Esimiehen esimerkki ja suhtautuminen ovat ratkaisevia. Ihmiselle turvallisuus ja elämänhallinta ovat olennaisia. Organisaatiokulttuurin muutoksen pitäisi edetä pienin askelin oppimalla.
Missä on foorumi, jossa yhdessä keskustellaan muutoksesta? Onko muutos taakka vai mahdollisuus? Muutos vaatii energiaa; energisoiko se ihmistä? Muutos vaatii myös epävarmuuden ja keskeneräisyyden sietokykyä. Muutoksen pitää perustua tosiasioihin eikä sen tavoitetta saa kadottaa matkan aikana.
Vesa Ilama luotsasi englanninkielisin dioin meidät hankejohtamisen maailmaan. Hankehallinnassa olennaista on johtaminen, leadership.
Projektipäällikkö katsoo projektiaan laatikon sisältä; huolehtii siitä, että toimitaan annettujen speksien mukaan. Hankepäällikkö näkee laatikon ulkopuolelta – itse asiassa monia laatikoita – ja ottaa huomioon niihin vaikuttavat muutokset.
Portfolion hallinnassa poimitaan uudet bisnesideat ja laaditaan niistä esiselvitykset ja esivalmistelut, tarkistetaan bisnesideoiden suhde strategiaan. Yrityksen portfoliossahan ei saisi olla useita päällekkäisiä tuotteita. Ylläpito on myös hanke ja siinä tarvitaan vähintään yhtä paljon osaamista kuin kehitystöissä.
Muutoshankkeessa mikä tahansa voi muuttua. Osa muutoksista tulee sisältä, osa ulkoa, osa tunnistetuista riskeistä. Niihin pitäisi tarttua proaktiivisesti eikä jäädä katsomaan peräpeiliin.
Hankkeeseen pitäisi jättää tilaa muutoksille ja suunnitteluun pitäisi varata riittävästi aikaa. Ketterät menetelmät auttavat. Hankkeen voi myydä kokonaisuutena, mutta määritellä vain puolet, jolloin muutoksille jää tilaa.
Hyviä mittareita ovat sellaiset, jotka voidaan mitata ja jotka vetävät tekemistä oikeaan suuntaan.
Miniseminaarin päätteeksi, kun osa mikrofoneista oli jo mykistynyt, Pertti Melonen valotti meille muutosjohtamista organisaation näkökulmasta. Jokaisella organisaatiolla on historia, nykytila ja tulevaisuus. Hyvä organisaatio osaa ennakoida toimintaympäristön muutoksia ja tunnistaa muutosvoimat.
Muutosten tuoksinassa organisaation pitää muistaa perustehtävänsä, joihin muutokset aina kytkeytyvät. Millä keinoin erottua muista? Yhteistyökumppanit tuovat lisäarvoa, mutta heille ei pidä luovuttaa strategisia asioita. Strategiasta nousevat keskeiset muutosvoimat, mutta strategia pitää muuntaa eri organisaatiotasoille ymmärrettäväksi.
Mihin muutoksella pyritään? Millaista osaamista tarvitsemme tulevaisuudessa? Johtamiseen liittyvää vastuuta ei voi delegoida. Jos johtaja ei tiedä muutoksen tavoitetta, hänen pitää se tunnustaa ja ottaa tavoitteesta selvää. Olisi tärkeää kerätä myös muutoksen vastustajien ajatukset, kokemukset ja ideat.
Muutokseen liittyvät kriittiset vaiheet ovat:

  1. muutostarpeen määrittely
  2. yhteinen visio
  3. muutosvalmiudet
  4. ensimmäiset toimenpiteet
  5. prosessit.

Ketteryys ja hoikkuus pilvessä

hoikka ketterä
pilvipalvelu, Akva
suuntaa tulevaan

turvallisuutta
osaamista, viestintää
huumori suolaa

Akvan laivaseminaari Ketteryys ja pilvipalvelut 29.9.-1.10.2010 kokosi Vikingin auditorion täyteen innokkaita ict-ammattilaisia bongaamaan uutta tietoa ja verkostoitumaan. Tilaisuuden juontanut Jari Petersen-Jessen toivotti meidät tervetulleiksi ja kertoi Akvasta.
Avauspuheessaan Robert Serén Tietotekniikan liitosta korosti seminaarin ja ict-alan naisvaltaisuutta,  ict:n roolia yhteiskunnassa ja julkishallinnon suurta osuutta koko Suomen ict-markkinoista.
Ketterästi pilvessä
Arto Saario Ixonokselta kertoi, miten pilvipalvelut mahdollistavat ketterän toiminnan. Menestyvillä yrityksillä on toimiva organisaatiokulttuuri, jatkuvan organisaatiomuutoksen sykli. Ketteryys näkyy muutostilanteissa: muutos tunnistetaan, selvitetään sen vaikutukset prosesseihin ja sidosryhmiin, koordinoidaan ja toteutetaan. Muutoksen monimutkaisuutta on vaikea ennustaa.
Perinteisesti palveluita on kehitetty eri yksiköille, vaikka horisontaalinen, kokonaisvaltainen kehittäminen palvelisi paremmin koko organisaatiota. Infrastruktuuri pilvipalveluna IaaS voisi olla sopiva ratkaisu. Alkuinvestointi on pieni, koska pilvipalvelu kestää mahdolliset käyttöpiikit. Pilvimarkkinan kotimaiset palvelut puuttuvat vielä.
Pilvipalveluiden oikeudellisia ongelmia
Pia Ek Asianajotoimisto Hannes Snellmanista valotti meille pilvipalveluiden oikeudellisia ongelmia. ”Insinöörien tehtävänä on keksiä ongelmiin ratkaisut, juristien tehtävänä keksiä ratkaisujen ongelmat.” Ulkoistus ei ole samaa kuin pilvipalvelut (vrt. juokseminen ja lenkkarit).
Jos rekisterinpitäjä on suomalainen, voidaan soveltaa Suomen lakia. Rekisterinpitäjä on osapuoli, joka määrittelee käsittelyn tarkoituksen ja keinot. Sen tulee valita sopivat henkilötietojen käsittelijät ja turvata rekisteröityjen oikeudet sopimusteitse: Miten tietoja käsitellään? Kuka pääsee niihin käsiksi? Missä maassa tiedot sijaitsevat? Lainsäätäjä olettaa, että yksi rekisterinpitäjä vastaa tiedoista. Henkilötietojen käsittelijä on “mykkä toimija”.
Pilvipalvelut vähentävät suoraa kontrollia, mutta lainsäätäjän mielestä kontrollia pitää olla – vaikka   tieto olisi päivällä jossain ja yöllä jossain muualla sen mukaan, missä milloinkin tiedon säilyttäminen olisi halvinta.
EU- ja ETA-alueen ulkopuolella tietosuojan kannalta turvallisia maita ovat Argentiina, Kanada ja Sveitsi. Yhdysvalloissa tietosuojaa ei ole juuri lainkaan. Siellä Safe Harbour -säännöksiin liittyneiden palveluntarjoajien kanssa tilanne on hiukan helpompi, mutta silti nyrkkisääntö on, että kannattaa käyttää ainoastaan sellaista pilvipalveluntarjoajaa, jonka tietokeskus sijaitsee EU- tai ETA-alueella. Kannattaa myös varmistaa, että sopimuksessa pilvipalveluntarjoajan kanssa käytetään komission hyväksymiä mallilausekkeita, ja ottaa huomioon mahdollinen alihankinta.
Palvelusopimusmaailman viidakosta löytyvät palvelutasosopimus (SLA), joka takaa palveluiden toimimisen sovitulla tavalla, vuokrasopimus esimerkiksi ASP-palveluissa, palvelusopimus ja ulkoistussopimus. Pilvipalvelut tarjoavat matalan kynnyksen sisäänpääsyn ja mitoitusmahdollisuudet, mutta monet julkisesti saatavilla olevista pilvipalvelusopimuksista rajoittavat tarjoajan vastuuta niin paljon, ettei se ole linjassa mahdollisen riskin kanssa. Mistä saadaan korvaus, jos ei päästä pilvessä olevaan kirjanpito-ohjelmistoon? Millaiset ehdot ovat asiakkaan kannalta? Voiko hintoja tarkistaa? Voiko niitä yksipuolisesti muuttaa?
Tarkastus- ja auditointivaatimukset on hyvä ottaa huomioon. Mihin fyysisesti menet auditoimaan palveluntarjoajan aineistoa? Mitä teet, jos palveluntarjoaja menee konkurssiin? Mitä lakia sopimukseen sovelletaan?
Pilvipalvelut ovat harmaita pilviä juristin näkökulmasta. Toimittaja haluaisi yhtenäistettyjä palveluita ja pitkäaikaisia sopimuksia, mahdollisuutta nopeaan hinnan tarkistukseen ja pakettiratkaisuihin ilman asiakaskohtaista palvelutasosopimusta. Asiakas taas haluaisi räätälöityjä, muokattavia palveluita, varmuutta ja joustavuutta, vakaata hinnoittelua.
Palvelusopimuksissa palvelu pitäisi kuvata selkeästi, palvelutasosopimuksessa määritellä palvelutaso sanktioineen. Onko sopimuksissa määritelty vasteaika, korjausaika ja korjauskeinot? Onko varmistettu tiedon erottelu pilvessä kolmansien osapuolien tiedoista? Mitä tiedoille tehdään, kun sopimus päättyy? Mikä on tietojen palautusstrategia? Pitäisi pyrkiä sopimaan, että oman maan lakeja sovelletaan, mutta onnistuuko se aina?
Pilvipalvelun hankkijan muistilistalla pitäisi olla:

  • SLA:t sekä sopimuksen muodossa että käytännössä
  • Sovellettavat standardit
  • Kenellä on pääsy tietoihin? Alihankinta?
  • Missä tietoja säilytetään? Mitä lakia sovelletaan?
  • Miten ylivoimainen este on määritelty?
  • Sopimuksen päättyminen ja tarjottavat palvelut tietojen siirtämiseen?
  • Hinnoittelu?

Hoikka ja ketterä ohjelmistoturvallisuus
Antti Vähä-Sipilä Nokialta kertoi, miten turvallisuus ja laatu kulkevat käsi kädessä. Ohjelmistoturvallisuudessa avainasia on riittävä koulutus. Turvallinen ohjelmistokehitys sisältää uhka-analyysin, kontrollien valinnan ja jäännösriskien hyväksymisen. Aktiviteettilistoja on useita, esim.  bsimm2, opensamm, ms, safecode.
Uhat analysoidaan vapaamuotoisesti keskustellen, ehkä musta hattu päässä miettien, mitä kaikkea voisi tapahtua. Askel askeleelta -prosesseja ovat tietovuoanalyysi ja STRIDE-malli, jossa kuvataan kaikki prosessit fläppitaululle ja mietitään kunkin uhat. Väärinkäyttötapausten-mallia käytetään vaatimustenhallinnassa: business caseihin lisätään käyttäjätarinoita siitä, mitä ei saisi tapahtua.
Lean tulee sanasta leanness, hoikkuus. Lean tarkoittaa, että kaikki pyritään tekemään mahdollisimman vähäisellä turhuudella. Miten riskienhallintasyklin osat voidaan jalkauttaa niin, etteivät ne riko hoikkuutta? Lean-periaatteen rikkominen rikkoo myös scrumin. Kaikki järjestelmään lisättävät asiat pitää lean-testata. Esimerkiksi hoikkuus rikkoutuu ja flow tuhoutuu, jos keskitetyltä tietoturvatiimiltä pitää hakea hyväksyntä jokaiselle tehtävälle asialle. Hyväksyttävät asiat kasautuvat ja käsiteltäväksi jää isoja möhkäleitä. Hoikkuus säilyy, jos jokainen tiimi hoitaa asian itse ”soihdunkantajan” johdolla käyttämällä valmiita malleja – ja pyytää neuvoa keskitetyltä tietoturvatiimiltä vain tarvittaessa. Soihdunkantaja, keskitetty tiimin sisäinen konsultti, on henkilö, joka kysyy juuri ne hankalat kysymykset.
Hoikkuus rikkoutuu, jos uhka-analyysit ja tietoturvatestaus tehdään muun ohessa, omassa sprint-työjaksossaan tai erikseen järjestettynä aktiviteettina, koska sellaista ei pystytä hallinnoimaan srcumilla. Tietoturvatyö kannattaisi aikatauluttaa samanlaisiksi backlog-tehtäviksi kuin muutkin työt.
Tietoturva pitäisi analysoida vaatimusmäärittelyssä ja suunnittelussa. Koodin mukana toimitetaan jäännösriski koodin vastaanottajan hyväksyttäväksi. Kukin hyväksyy jäännösriskin omalla tasollaan, jolloin epäonnistuminen ei ole katastrofi ja ylempänä on aina veto-oikeus. Virheellinen hyväksyntä hukkaa korkeintaan yhden sprintin työn, jos ylempänä todetaan toisin.
Ohjelmistokehityksessä erotetaan vaatimustenhallinnan ja toteutuksen taso. Edelliseen liittyvät käyttötapaukset ja bisness caset, jälkimmäiseen koodi ja bitit. Vaatimustenhallinnassa ohjelmistoturvallisuudesta huolehditaan niin, että tuotteen omistaja käy lävitse käyttäjäkertomuksia ja generoi niistä turvallisuuskertomuksia mallien pohjalta (jotka heijastavat yrityksen ongelmia) ja väärinkäyttökertomuksia (mitä ei saa tapahtua; hyökkääjänä en saa pystyä tekemään tätä ja tätä, jotta tätä ei tapahtuisi). Näitä voidaan käyttää toiminnallisina vaatimuksina tai testitapauksina. Turvallisuuskertomukset ovat toiminnallisia tietoturvavaatimuksia.
Ohjelmistoturvallisuus scrumissa tarkoittaa, että scrum-tiimi ottaa tehtävän backlogista ja katsoo, pitääkö tehdä uhkatarkastus; käsitteleekö tehtävä käyttäjätietoja tai luottokorttitietoja? Näin uhka-analyysitehtävät aikataulutetaan ja voidaan sanoa, onko ne tehty vai ei. Erillistä listaa kontrolleista ei tarvita vaan kaikki syötetään tehtäväjonoon.
Jäännösriski hyväksytään sprintin katselmuksessa, jossa päätetään, ovatko sprintin tehtävät valmiita. Tällöin tarkastellaan suorituskykyä ja tietoturvaa: Kun otetaan huomioon uhat, jotka olemme löytäneet, niin onko tehty työ kunnossa turvallisuusnäkökulmasta? Koodin mukana tuleva jäännösriski voidaan esittää esimerkiksi wikisivulla.
Ketterä ostaminen
Perttu Tolvanen Sinisestä meteoriitista pohdiskeli ketterää ostamista. Organisaatio voi hankkia uuden tiedonhallintojärjestelmän tai toiminnanohjausjärjestelmän, mutta miten se saa yksilöt työskentelemään yhteisillä alueilla henkilökohtaisten alueiden sijaan? Ihmisiähän ei voi pakottaa muuttamaan toimintaansa.
Tiedonhallintajärjestelmiä on tuotteistettu aktiivisesti yli 10 vuotta, niillä on tietynlainen filosofia, jonka mukaan ne toimivat, ja se vaikuttaa tuotteiden ratkaisuihin. Kuitenkaan ei ole vain yhtä oikeaa tapaa tehdä ryhmätöitä. Järjestelmiä ei voi määritellä kuoliaiksi: tärkeimmät käyttötapaukset selviävät ja hioutuvat vasta käyttöönoton jälkeen. Ensimmäiset kuusi kuukautta ovat ratkaisevia, niiden aikana uusi järjestelmä muovataan tutkemaan tietotyöläisten tarpeita.
Kustannustehokkuus ja hyvä käytettävyys syntyvät siitä, että tuotteita käytetään niiden filosofian mukaisesti, kun taas tuotteiden taivuttaminen filosofiasta eriäviin käyttötarkoituksiin on vaikeaa ja kallista. Järjestelmä pitäisi saada käyttöön mahdollisimman pian, jotta päästään keräämään käyttökokemuksia.
Korjauksiin pitää varautua heti käyttöönoton jälkeen ja tiedot virhetilanteista välittää toimittajalle heti. Jos niitä kerätään palaute-exceliin ja soitetaan toimittajalle, niin tämä ehkä löytää aikaa listan läpikäyntiin vasta kuukausien kuluttua, jolloin saattaa mennä vuosi ennen kuin käyttäjien ensimmäisenä päivänä havaitsemat virheet on korjattu. Tiedonhallinta- ja tuotepohjaisilla järjestelmillä pitäisi aina edetä pilotilla.
Asiakkaan pitää ottaa vastuu hankinnoistaan, tehdä riittävän hyvä esitutkimus ja priorisoitu vaatimusmääritys. Enää ei voida lähettää tarjouspyyntöjä toimittajille ja odottaa, että nämä vastaisivat jotain fiksua, ei myöskään lähettää pitkää ominaisuuslistaa ja kysyä, vastaako tuote niihin. Järkevämpää on selvittää, miten kentällä olevat tuotteet hoitaisivat kymmenen tärkeintä vaatimusta. Asiakkaan on valittava, haluaako hän valmiin tuotteen vai räätälöidyn tuotteen, ne eivät toimi filosofisesti yhdessä. Maailmassa on myyty miljoonia maksavia portaaliratkaisuja asiakkaille, jotka eivät olisi sellaista tarvinneet.
Ketterä hankinta
Petri Heiramo Agilecraftista totesi, että ketteryys on haastavaa ja tarjouspyynnössä luodaan pohja onnistumiselle tai epäonnistumiselle. Jos pyydetään vaiheittaista toimitusta, toimittaja ei voi toimittaa ketterästi. Hankintalainsäädännön mukaisesti on hankalaa tilata ketterästi, muttei mahdotonta. Ketterässä hankinnassa asiakas sitoutuu ohjaamaan projektia koko ajan ja ottaa siitä vastuun.
Ketteryys koskettaa koko organisaatiota ja johto määrittelee viime kädessä ketteryyden onnistumisen. Ongelmat on tunnustettava ja korjattava, muuten mikään ei muutu. Ketteryys tuottaa kustannussäästöjä pitkällä tähtäimellä, mutta alkuvaiheen kustannukset ovat isot.
Laatu ei ole parametri, josta voidaan neuvotella. Mitä enemmän on tehty purkkaa ja teknistä velkaa, sitä vaikeammaksi tulee tiimin ketteryys. Jos hyväksytään tavoitteeksi 95 %:n laatu, ei kasvateta nälkää tehdä hyvin.
Älä yritä liian suurta kerralla, koska ympäristö muuttuu jatkuvasti eikä isoa projektia ole helppo ohjata. Jos tuloksia ei tule, vaihda toimittajaa. Ketterässä projektissa budjettivastuu siirtyy asiakkaalle, tuotepohjaisessa pikselien viilaaminen on kallista. Jos tietoturva on tärkeää, siihen pitää käyttää aikaa ja rahaa. Tiimi voi kertoa, mitä oikeasti tapahtuu. Tiimillä pitäisi olla suora yhteys todellisiin käyttäjiin, ei vain tilaajaan. Vaatimusten tarkentamiseen ja priorisointiin tarvitaan aikaa.
Älä hajauta, jos se ei ole välttämätön pakko. Viestintä on ketteryydessä olennaista ja hajautus luo aina kynnyksiä keskustelulle. Jos ulkoistat Kaukoitään, niin vaikka työvoima siellä olisi paikallista  halvempaa, kustannuksia syntyy ja yleensä alihankintatyöt ovat muita kalliimpia. Ainoat järkevät syyt ulkoistamiselle ovat joko se, että läheltä ei saa tarvittavaa osaamista tai että läheltä ei saa riittävästi kapasiteettia. Mikään ei muutu, jos mitään ei muuteta.
Allekirjoitus pilvessä
Kai Linnervuo Signomista totesi, että sopimuksia ja muita asiakirjoja tulostetaan ja allekirjoitetaan yhä vielä käsin, vaikka sähköinen allekirjoitus on teknisesti mahdollista. Perinteinen tapa sopimusten allekirjoittamiseen on tuttu: tulostetaan nippu sopimuksia, lähetetään ne postitse allekirjoitettaviksi, odotetaan, kysellään perään muutaman kuukauden kuluttua. Onko meillä todellinen varmuus siitä, että tietyllä henkilöllä on valtuudet allekirjoittaa ja onko allekirjoitus kyseisen henkilön? Kun sopimukset sitten tulevat allekirjoituskierrokselta, ne arkistoidaan mappeihin hyllyyn ja mahdollisesti skannataan arkistointijärjestelmiin.
Yritykset allekirjoittavat vuosittain satoja sopimuksia. Signom-tavassa sopimukset allekirjoitetaan luontevasti osana sopimusprosessia. Luotettavuus saavutetaan, kun kolmas osapuoli, patentti- ja rekisterihallitus, autentikoi sopimukset. Allekirjoittaja todennetaan vahvan tunnistamisen menetelmällä, tarkistetaan toimivalta ja varmistetaan allekirjoitettavan sopimuksen eheys. Järjestelmä on juridisesti vahvempi ja parempi kuin perinteinen.
Signomin allakirjoitusprosessissa vaihdetaan ja hiotaan sähköpostitse ensin doc-tiedostoja, kuten perinteisessäkin prosessissa. Kun sopimuksen lopullinen sanamuoto on valmis, sopimus muutetaan pdf-muotoon. Toinen osapuoli lataa sopimuksen Signomin palveluun ja kertoo toisen osapuolen, valitsee kielen ja maksutavan, esim. sopimuksen lähettäjä maksaa vastaanottajan puolesta kuten perinteisissä vakuutusyhtiön ja asiakkaan välisissä sopimuksissa ”vastaanottaja maksaa kulut” -vastauskuorineen. Järjestelmä tarkistaa lähettäjän oikeudet ja lähettää sopimuksen kryptatulla varmenteella vastaanottajalle. Vastaanottaja voi allekirjoittaa sähköisesti, mutta halutessaan hän voi tulostaa sopimuksen ja allekirjoittaa sen perinteiseen tapaan.
Jos allekirjoittajia on useita, palvelu tarkistaa, että allekirjoitetut versiot täsmäävät. Kun sopimus on allekirjoitettu, jokainen osapuoli saa viestin ja voi vuorokauden sisällä ladata allekirjoitetun sopimuksen itselleen. Sopimus poistetaan järjestelmästä, mutta sopimusloki jää jäljelle, jotta riitatapauksessa vuosien kuluttua voidaan nähdä, kuka on allekirjoittanut ja millaisin tunnuksin.
Tavoitteena on, että Signomin sähköinen allekirjoitus olisi standardi vuoteen 2016 mennessä.
Muistan hyvin perinteisen allekirjoitusprosessin Tietie-yhteistyön ja Virtuaaliammattikorkeakoulun sopimuksista 2000-luvun alkupuolelta. Itsekin kannoin sopimuksia rehtorillemme allekirjoitettavaksi, postittelin niitä muihin oppilaitoksiin ja soittelin perään, kun sopimusnippu oli kesälomalla juuttunut jonkun pöydälle.
Elisan pilvet
Kari Terho Elisalta kertoi eCloud-palveluista. Asiakas saa tarvitsemansa kapasiteetin ja maksaa vain siitä. eCloud joustaa myös alaspäin. Palvelimet saa käyttöön minuuteissa, virtuaalisen tietokonekeskuksen perustamiseen menee noin puoli tuntia, kun perinteisen konesalin perustamiseen menisi useita viikkoja.
Yrityspilvi – EnterpriseCloud, sisältää intergrointipalvelut ja vahvan tunnistuksen. Pilven ohjelmisto on auditoitavissa, sitä voi tulla vaikka taputtelemaan. Kari Terho vakuutti myös, että Elisa ei mene konkurssiin.
Tulevaisuuden pilvipalvelut
Janne Järvinen F-Securelta kertoi Tivitin kanssa käynnissä olevasta tutkimushankkeesta, jonka tavoitteena on luoda uudenlaista suomalaista liiketoimintaa. Tunnistettuja haasteita ovat kasvavat käyttäjävaatimukset, nopeus vaihtaa palvelusta toiseen ja palvelutason jatkuva nostaminen. Avoimet palvelut tulevat ja niitä voidaan yhdistää pilvessä, mutta kuka vastaa tietoturvasta?
Perinteisen ohjelmistotuotannon sijaan painopiste on pilven ohjelmistokehityksessä. Millaisia olisivat tulevaisuuden pilvipalvelut? Organisaation pitäisi olla huipputehokas ja sen pitäisi tavoitella  kestävää kehitystä, ylivertaista käyttäjäkokemusta ja tietoturvaa. Millainen olisi hoikin ja ketterin ict-organisaatio? Lean-konferensseissa kehitetään hoikkia arvoketjuja toiminnan tehostamiseksi, mutta ohjelmistoalan yrityksiä siellä ei juurikaan tapaa.
Projektin laajuuden arviointi
Paula Männistö Qentineliltä puhui projektin työmääräarviosta, joka perustuu vaatimuksiin. Projektin laajuuteen vaikuttavat halutut ominaisuudet ja niiden toteuttamiseen tarvittava työmäärä. Kohdealue nähdään usein pilvenä. Kuinka tarkasti pitäisi määritellä, ettei määriteltäisi kuoliaaksi?
Vaatimusmäärittelyä tarvitaan tarjouspyyntöön ja tarjoukseen ja testaukseen. Jokaisen pienen käyttäjän tarpeet pitäisi selvittää, samoin yhteydet muihin järjestelmiin. Vaatimusten kerääminen ja kirjoittaminen eivät ole helppoja tehtäviä, mutta ilman niitä ulkopuolisen toimittajan on vaikea laatia tarjousta. oskus kuvaus voi olla niin sekava, että oikeiden asioiden löytäminen on vaikeaa. Joskus taas vaatimuksia kirjoitetaan testausvaiheessa, jotta pystytään testaamaan. Mitenkähän järjestelmä on rakennettu ilman vaatimuksia?
Kumpi tärkeämpää, asiakkaan vai toimittajan osaaminen? Keskustellaanko paperinipun kanssa vai keskustelevatko ihmiset keskenään? Kaikki toimittajat pitäisi saada saman pöydän ääreen. Jos projektin alkupäässä hommat viivästyvät, niin pidetäänkö silti kiinni sovitusta valmistumisajankohdasta? Muutosten hallintaan liittyy vaatimusten hallinta, jossa sekä asiakas että toimittaja oppivat.
Paula Männistö havainnollisti tilannetta kolmiolla, jonka kärjissä olivat osaaminen, prosessi ja esitystapa ja jonka keskellä oli viestintä ja yhteistyö.
Keskustelussa pohdittiin, haluaako tilaaja oikeasti tietojärjestelmää vai jotain ihan muuta. Onnistuneissa projekteissa tavoitteena on yleensä jokin toiminnan muutos, ja tietojärjestelmän kehittäminen on vain osa toiminnan muutosta. Valitettavan usein kuitenkin tilataan vain tietojärjestelmää eikä toiminnan muutos näy toimittajalle asti.
Prosessien kuvaukset helpottavat kokonaistilanteen hahmottamista. Käyttäjien ja roolien avulla  pitäisi löytää vaatimukset. Tilaajan vastuulla on tehtävien jatkuva priorisointi, toimittaja ei priorisoida.
Ketteryys Itellassa
Pipsa Ylä-Mononen kertoi ketteryydestä Itellassa, jossa scrumia on käytetty nelisen vuotta aikatauluvaatimusten vuoksi. Vaatimukset syvenevät, niitä arvioidaan ja todennetaan jatkuvasti. Toteutustapa on testauslähtöinen ja liiketoiminta pääsee konkreettisesti iholle, vaikka liiketoiminnan edustajat eivät pääse ulkoistamaan vastuutaan.
Projekteja katselmoidaan säännöllisesti kahden viikon iteraatioissa. Varttitunnin mittaisia scrum-kokouksia pidetään päivittäin. Projekteissa tarvitaan avointa ja jatkuvaa viestintää. Parhaiten se onnistuisi samassa työhuoneessa, mutta joskus tiimin edustajat ovat eri kaupungeissa. Jos asiantuntijat eivät saa vaatimuksia paperille, joudutaan lypsämään, työstämään ja esittämään hypoteeseja siitä, miten asia voisi olla.
Projekti eri vaiheissaan onnistuu parhaiten tasaisesti työskennellen ja huumorilla ammatti- ja viestintätaitoisten ihmisten kanssa. Jos ostetaan ulkoa, kuvataan prosessit ja niiden muutokset sekä käyttötapaukset. Jos tehdään itse, kootaan ryhmä omia suunnittelijoita eri taloista, koodataan parityöskentelynä ja valvotaan laatua sisäisesti.
Scrum ei tee tai automatisoi määrittelyä tai tahtotilaa, ei hyväksymis- tai käyttöliittymätestausta eikä arkkitehtuuri- ja teknologiavalintoja. Tilaaja päättää, onko järjestelmä valmis. Scrumiin liittyvät käsitteet täytyy kouluttaa, jotta ihmiset ymmärtävät, mistä on kyse. Taannoin joku tuli puolen vuoden kuluttua kysymään, mitä inkrementti on, kun siitä oli koko syksy puhuttu. Käsite olisi pitänyt selittää ja avata heti alussa.
Onnistumisen edellytyksiä ovat jatkuvan ja avoimen tiedonkulun varmistaminen, riittävä suunnittelu, sprintin ulkopuolisten tehtävien vaatiman työajan ennakointi ja tiimin itseohjautuvuus. Liiketoimintayksiköistä tarvitaan riittävää resurssointia, sitoutumista ja priorisointia. Jos sama henkilö on ydinasiantuntija yli kymmenessä projektissa, miten hän jakaa aikansa? Lojaalisuus ja ymmärrys järjestelmien linkittymisestä toisiinsa on uskomatonta kavereilla, jotka ovat olleet talossa kymmeniä vuosia, mutta mitä tapahtuu, kun he jäävät eläkkeelle?
Tekemällä oppii, muutaman sprintin jälkeen tekeminen lähtee kunnolla käyntiin. Testaus on osa sprinttiä. Joka sprintillä on oma bugibudjettinsa, jotta virheet eivät kasaantuisi. Bugittomia tarinoita seurataan. Kun sprintti meni ilman bugeja, jaetaan kakkua kaikille, kun bugeja tulee paljon, istutaan töttöröhattu päässä – idea oli suunnittelijoiden oma. Olennaista kuitenkin on, ettei haeta syyllisiä vaan tehdään uutta ja katselmoidaan se, ettei tarvitsisi myöhemmin ihmetellä.
Itellassa tiimille hankittiin oma valkotaulu ja pöytä – josta sai aika pitkään keskustella arkkitehdin kanssa. Tiimihengen luominen ja motivaatio on tärkeää, jotta tiimi toimisi itseohjautuvana asianomistajana ja kehittäisi laatua oma-aloitteisesti.
Ketterä testaus

Maaret Pyhäjärvi Ilmarisesta kertoi ketterästä testaamisesta. Testauksessa on yleensä rajallinen budjetti, kohteena monimutkainen ja laaja kokonaisuus,  jossa tulee vastaan yllättäviä ongelmia ja  jatkuvaa muutosta, jolloin on mahdotonta suunnitella mitään yksityiskohtaisesti etukäteen.
Maaret Pyhäjärvi havainnollisti testausta 20 kysymyksen budjetilla, videolla 14 koripalloilijasta sekä wordpadin fonttidialogiin syötetystä luvusta 1639. Videon katselu osoitti, miten perinteinen testaus tekee sokeaksi emmekä huomaa olennaisia virheitä, joita emme osaa odottaa. Wordpadin fonttidialogista Maaret Pyhäjärvi totesi, että testauksessa pitää olla hauskaa, bugeista pitää nauttia, kun niitä löytää. Testaukseen tarvitaan riittävästi vapausasteita, jos halutaan todellisia tuloksia.
Tutkivan testauksen guru on twiitannut: ”Miksi kutsutaan ammattitaitoista lääkäriä? Lääkäriksi. Entä ammattitaitoista testaajaa? Tutkivaksi testaajaksi.”
Testaaja osaa kertoa omasta työkentästään. Maaret Pyhäjärvi kertoi kysyvänsä muutaman kerran viikossa testaajilta, mihin heidän aikansa on kulunut ja trendi on mielenkiintoinen. Toimittajien testausmallien muuttaminen vienee kuitenkin vuosia.
Ketterässä tiimissä testaus on ketterää. Testaajilla on vastuu kokonaislaadusta; ei eletä päiväunissa vaan katsotaan, että päiväunet toteutuvat. Sprintin aikana käytetään automatisoituja testejä. Yksikkötestaus pitäisi määritellä ennen toteutusta. Testiohjattu koodaus ei sovi kaikille, joillekin se aiheuttaa ahdistusta, joten muitakin toimintatapoja sallitaan.
Virheet ja vaatimusmuutokset pitää suhteuttaa hintalappuun. Bugi on bugi, mutta ketterässä kehityksessä se voi löytyä jo alkumetreillä eikä vasta lopussa. Suorituskyky pitää testata niin, että tiimi saa siitä myös palautteen.
Ketterää kehitystä ei tehdä ilman määritystä. Vaatimukset voidaan kirjoittaa vaikka valkotaululle ja kuvata eri värein ja täydentää ja lopuksi muokata parempaan muotoon. Palautemekanismi, tuotebacklogi ja muutosten hallinta ovat olennaisia.
Kaikki tiimissä testaavat ja testaaja on tiimin jäsen. Lyhyet sprintit alkuun ovat hyviä, koska ne edistävät oppimista. Tiimi paranee jokaisen sprintin aikana.
Onnistumisen mahdollisuudet lisääntyvät, kun ihmiset saadaan lähemmäs toisiaan ja keskustelemaan. Testaus on  osaavien ja tahtovien ihmisten yhteistyötä, jonka edellytyksinä ovat sopiminen ja sopimukset, työrauha ja luottamus.
Ulkoistaminen
Katriina Joki Tiedosta kertoi ketteristä menetelmistä ja ulkoistamisesta. Vaatimusmääritys tehdään edelleen samalla tavalla kuin aikaisemminkin. Odotusten pitää olla realistiset: Suomen työeläkeosaaaminen on hankittu vuosien aikana eikä sitä hetkessä siirretä muualle eivätkä hinnat putoa heti kun ulkoistetaan. Jokainen suomalainen tietää, mikä on lapsilisä ja millainen ongelma syntyy, jos sen maksu viivästyy – mutta intialainen ei ymmärrä.
Ulkoistamiseen liittyy vastarintaa ja epäluuloja. Monet asiakkaat haluavat dokumentoida suomeksi ja on osa-alueita, joilla ei kunnollista englanninkielistä termistöä olekaan. Ihminen saattaa pelätä menettävänsä työnsä; muualla tehdään sitä, mitä tein aikaisemmin! Voidaanko luottaa siihen, että poissa näkyvistä oleva etäprojektilainen tekee sitä mitä häneltä odotetaan? Entä mitä etäjohtaja tekee, jos jossain työtehtävässä ei voida edetä?
Projektin henkilöstölle pitäisi viestiä selvästi, mitä he ulkoistamisesta hyötyvät. Projektibudjetissa pitää varautua koulutukseen ja matkustamiseen. Matkustaminen ei ole niin kallista kuin miltä se ensin tuntuu, koska toimittajan ja asiakkaan kohtaaminen on tärkeää ja projektiin osallistuvien pitää oppia ymmärtämään muiden osapuolten mallia. Liiketoimintatukeen ja selvittelyyn tarvitaan tavallista enemmän resursseja, työnohjaukseen pitää kiinnittää huomiota ja aikatauluissa pitää varautua tekstien kääntämiseen. Miten projektin organisointi muuttuu, kun maailman ympärillä muuttuu? Miten käännösprosessi etenee, kun määritys ja toteutus iteroidaan?
Kulttuurieroja ei pidä kieltää. Intiassa vaihtuvuus on suurta, ja kuitenkin ihmiset pitäisi sitouttaa projektiin. Intialaisten on vaikea myöntää ongelmiaan, tarvitaan ilmapiiriä, jossa ongelmista voidaan puhua.Tarvitaan myös jämäkkyyttä ja herkkyyttä, erilaisuuden sietämistä ja tasaista työkuormaa, tuska ja kiitos täytyy jakaa kaikille.
Älä hajauta

  • jos et osaa laskea hajauttamisen kustannuksia
  • jos sinulla ei ole työkaluja kokouksiin
  • jos et kouluta ja sitouta henkilöstöä
  • jos laiminlyöt viestinnän etkä kerro, mitä ihmiset hajauttamisesta saavat
  • jos et ole valmis kohtaamaan uutta ja erilaista.

Nextdoor
Marko Taipale Huitaleesta kertoi nextdoor.fi-verkkopalvelusta,  josta kuluttajat voivat ostaa kotitalouspalveluita. Tuotteen rakentamiseen meni 20 miestyöpäivää. Ensimmäisenä päivänä hankittiin tietokone, 70 päivää meni toiminnallisuuden ja 50 päivää käyttöliittymän rakentamiseen ja hiomiseen. Tuotteen elinkaaren eri vaiheissa syntyi erilaisia käyttöliittymiä.
Mikään kuluttajatuote ei elä verkossa yksin. Nextdoorin Facebookin sivulla on 30 000 vierailijaa kuukaudessa ja yli 2000 aktiivista käyttäjää, ilmoitustaulu, 300 avointa ilmoitusta ja 3 päivän vastausaika.
Nextdoorin verkkopalvelua monitoroidaan automaattisesti. Liiketoimintaraportit ja varmuuskopiot tuotetaan päivittäin. Verkkopalveluun imetään Uranuksesta keikkailmoituksia, jotka saavat entistä laajempaa näkyvyyttä.
Verkkopalvelun kehittämisessä teemat selvitetään kahden tunnin istunnossa, jossa kerätään liiketoimintaraportteja, kilpailija-analyyseja ja käytettävyyteen liittyviä pyyntöjä. Teemoista poimitaan kolme, joita halutaan parantaa. Tämän jälkeen parin vuorokauden ideamyrskyssä nostetaan esiin konkreettisia ominaisuuksia, joilla on liiketoiminnallista arvoa ja jotka asetetaan jonoon. Kehitystyö kestää kuusi päivää, joiden päätteeksi tehty ominaisuus testataan varttitunnin automaattiajolla. Ominaisuuden julkaisemiseen menee minuutti.
Ominaisuuden matka ideasta tuotantoon kestää siis kahdeksan päivää. Jos tuotejonossa on seitsemän ominaisuutta, läpimenoaika = (7*8)/2 = 28 päivää.
Ongelmatiimi kuvaa ongelman, jonka ratkaisutiimi ratkaisee. Aiemmin ominaisuus ei mennyt tuotantoon, jos sitä ei hyväksytty. Nyt se menee tuotantoon, jos prosessia ei keskeytetä. Järjestelmästä ajetaan tilastoja ominaisuuksien käytöstä ja poistetaan ne ominaisuudet, joita ei käytetä. Minkä tahansa lapun voi ottaa pois, lapun seinältä tai keskeneräisen tai valmiin palan sovelluksesta.
Huitaleen blogista löytyy yksityiskohtainen kuvaus siitä, miten scrum tähän taipui.
Ketterä ostaminen
Ralf Sontag Huoltovarmuuskeskuksesta kertoi ketterästä ostamisesta. Projektin alussa koulutettiin kaikki projektin organisatioon kuuluvat. Tarjouspyynnössä painotettiin järjestelmäarkkitehtuuria, jossa kuvattiin, mitä ainakin pitäisi saada ja mitä lisäksi voisi olla. Tarjouksen jättäneet koottiin yhteiseen palaveriin, jotta kaikkia kohdeltaisiin tasa-arvoisesti.
Käyttäjätarina kehittyi projektin aikana kumulatiivisesti ja sprinteittäin. Kun määrittely oli karkealla tasolla, ei ollut yllätys, että löytyi tarkennettavia asioita. Gartner Groupin verkkopalvelussa on ketterien menetelmien vastaväitekokoelma.
Akva, 30-vuotias nuorukainen
Loppupuheenvuorossaan Akvalle, 30-vuotiaalle nuorukaiselle, Robert Serén korosti, että ict-alan palkat ovat naisten ja miesten välillä tasa-arvoisempia kuin monella muulla alalla. IT-barometri 2010 -tutkimus kertoo mm., että ict-projektien lopputulokset vastaavat yleensä sovittua, mutta projekteista iso osa ei pysy aikataulussaan ja ict-hankintojen tavoitteista saavutetaan vain puolet. Kaikesta ei tarvitse tehdä hypeä; asiat voidaan pitää yksinkertaisina.

Prosessimalli ja ihminen

globaalin haaste
innovatiivisuudelle
ketterä tiimi?

prosessimalli
motivoi, mahdollistaa
ihmisen tarpeet
Laskeva aurinko sinkosi punertavat liekkinsä SYSOPENDIGIAn tornin yllä kaartuvalle taivaalle Sytyken MallinnusOSYn pienseminaarin ”Toiminnan tehostaminen prosessimallein” alussa.
Ohjelmistokehitysprosessin mallintaminen
Henrik Terävä SYSOPENDIGIAsta kertoi ohjelmistokehitysprosessin mallintamisesta ja käytöstä diplomityönsä “Software processing modelling with EPF” pohjalta. Ohjelmistokehityksen yleisiä haasteita ovat tiedonjako tiimeille, prosessien integrointi, koulutusmateriaalien ajantasaisuus ja tehokkaat prosessit. Turhan usein prosessimalli eroaa käytännön mallista, vaikka ohjelmistokehityksen pitäisi perustua ihmisen toimintaan. Prosessin pitäisi motivoida kehittäjän tarpeiden mukaiseen oikeaan toimintaan – kuten häkistä toiseen siirrettävää oravaa motivoi toisessa häkissä avoimen oven takana odottava pähkinä.
Suomalainen, avoimen lähdekoodin tuote OpenMethod säästää aikaa ja mahdollistaa tietämyksen hallinnan. Se tarjoaa standardit rajapinnat räätälöintiin ja uudelleenkäyttöön. Haasteena ovat eri kielialueet ja muutosvastarinta.
Ensimmäisessä demossa Sytyken pienseminaarin työvaiheet ja kestot mallinnettiin ohjelmistokehityksen työkaluilla, toisessa tutkittiin kirjaston staattista ja dynaamista sisältöä, vaatimusmäärittelyn tehtäviä sekä raportteja ja ohjeita, kolmannessa projektista laadittiin julkaisu asiakkaalle.
Yleisöstä kysyttiin, käytetäänkö oikeassa projektissa tällaista tuotetta: menetelmiä on muutenkin niin paljon, ettei niihin tutustumiselta ehdi tehdä oikeita töitä. Onko taustalla kuvitelma ohjelmistokehitystyön jakamisesta yksinkertaisiin paloihin? Eiväthän palat loksahda kohdalleen ilman syväosaamista.
Rami Talme RP5 Softwaresta kertoi EPF Composerin ja Rational Method Composerin käyttökokemuksistaan. Miten asiakas saataisiin osallistumaan sovelluskehitykseen? Kuvaaminen on raakaa työtä ja sisällön tuottaminen vaikeaa; tätä tosiasiaa työkalu ei muuta. EPF:n sateenvarjosta voidaan poimia tarvittava, kerätä sisältöjä eri paikoista ja menetelmistä kuten Scrumista, XP:stä ja RUPista. Menetelmät periytyvät, omia menetelmäsisältöjä ja steppejä voidaan lisätä tai poistaa.
Yleinen väärinkäsitys lienee, ettei Scrumissa tarvitse dokumentoida eikä välittää arkkitehtuureista, koska ne kasvavat prosessin mukana. Hyvä tiimi osannee toimia ilman kuvausta, mutta uudet jäsenet tarvitsevat jotain kättä pidempää. Aiemmin menetelmäkehityksessä laadittiin sisältöjä kuvaamatta niiden järjestystä tai käyttötapauksia – mikä selittänee prosessikuvausten nykytilaa.
Miksi projektia säädellään? Eikö valmis ohje sovellu omaan tilanteeseen? Malliksi voidaan ottaa osaavan tiimin prosessi ja katsoa, sopiiko se omaan tilanteeseen vai pitäisikö iteratiivisesti edeten tuunata siitä omiin tarpeisiin soveltuva.
Ohjelmistoprosessit muuttuvassa maailmassa
Antero Järvi Turun yliopistosta puhui ohjelmistoprosesseista muuttuvassa maailmassa. Muutos syntyy liiketoiminnasta, ei menetelmistä tai teknologiasta. Globaalien markkinoiden hajautetuissa hankkeissa ja lyhyissä tuotesykleissä innovaatioverkostot ja asiakas nousevat keskeisiksi.
Ketterä kehitys yhdistettyjen kompetenssien tiimeineen vastaa muuttuvan maailman tehokkuus- ja reaktiivisuusvaatimuksiin. Ohjelmistokehityksen perusyksikkö voisikin olla ketterä tiimi, jossa jokainen vastaa tekemisistään.
Miten itsenäiset ja ketterät kehitystiimit toimivat tuotehankkeessa tarkoituksenmukaisesti? Kun hallitsemme toisaalta laajat, muokattavat prosessikehykset, toisaalta ketterien menetelmien skaalauksen, tarjoaisivatko monitiimiset sovellukset nykykehitykseen optimaalisen ratkaisun?
Laajoissa prosessikehyksissä kehittämisstrategia on mietitty, riskinhallinta korostunut ja vaiheet päättyvät tarkistuspisteisiin. Työkäytänteiden tarkka kuvaaminen aiheuttaa turhia riippuvuuksia. Ketterässä kehityksessä asiakas on kiinnostunut tuotteesta ja tiimi on tuotteen kehityskone. Ketteryyteen kuuluu epävarmuus: ymmärrys siitä, mitä ollaan tekemässä, kasvaa iteratiivisessa prosessissa.
Miten tiimit suojataan prosessirajapinnalla? Yhdestä käyttötapauksesta voi tulla vaatimuksia kahteen tuotekomponenttiin, joita eri tiimit tekevät yhtaikaisesti. Tällöin tarvitaan scrum-mastereiden yhteydenpitoa ja kustomointia sprinttien aikana. Voidaanko hanketta skaalata entistä isommaksi lisäämällä scrum-tiimejä, joiden välisiä riippuvuuksia scrum-masterit selvittävät scrum-tapaamisissaan?
Kehitysprojektit kytkeytyvät liiketoimintaprosesseihin, toiminnan kehittämiseen ja organisaation oppimiseen. Tuoteprojektit tarvitsevat valmiita ratkaisuja; aikaa on turha kuluttaa organisoitumistapojen miettimiseen. Menetelmästä riippumatta tarvitaan tiimijakoa, työnkulkuja, koordinointia ja vaatimusmääritystä. Tilannekuva auttaa mukauttamaan prosesseja projektin aikana ja viestimään – ja antaa tiimeille tilaa keskittyä kehitystyöhön.
Pienseminaarin esitysmateriaali löytyy Sytyken MallinnusOsyn sivulta.

Pyrähtelevä ohjelmistokehitys

vaatimus jäätyy
putoukseen, pyrähtää
sulaen scrumiin

rup ruoppaa pienen
palan valmiiksi, muuttaa
lennossa suuntaa
Nykyaikaiset ohjelmistokehityksen mallit olivat aiheena Sytyken MallinnusOsyn jäsentilaisuudessa 17.9.07 SYSOPENDIGIAlla.
Paula Salmi Osuuspankkikeskuksesta (OPK), nykyisestä OP-Pohjolasta esitteli heidän kehittämänsä V5-mallin, Allan Halme Accenturalta pureutui RUPin teoriaan ja Lasse Koskela Reaktor Innovationsista pohdiskeli Scrumin taustaa ja todellisuutta tänään.
Yleisössä istuneet kokeneet systeemityöläiset toisaalta kritisoivat Allan Halmen turhan teoreettista esitystä RUPista, toisaalta täydensivät Lasse Koskelan esitystä omilla kokemuksillaan scrumista.
V5-malli kehittää
OP-Pohjolan organisaatiouudistus pyrki eroon eri palvelualueilla toimineiden järjestelmäkehittäjien erillisten ratkaisujen koordinointiongelmista. Ict-palvelut ostetaan keskitetystä ict-organisaatiosta, vaikka liiketoiminnan tavoitteet määritetään edelleen palvelualueilla ja liiketoiminnan edustajat päättävät hankkeiden priorisoinnista ja etenemisestä.
Kehitysprosessin vaiheet noudattelevat perinteistä systeemityömallia idean kiteyttämisestä pilotointiin, jalkauttamiseen ja hyötyjen mittaukseen. Malli on ryhdistänyt ja selkeyttänyt prosessia ja vastuunjakoa, mutta haasteet eivät ole kadonneet: tehtävät ja dokumentit ovat vielä osin päällekkäisiä ja riittävän informaation takaaminen kapulanvaihtotilanteissa eri yksiköissä toimivien määrittelijöiden ja testaajien välillä vaatii ponnisteluja.
Paula Salmi kevensi esitystään kuvalla näppikseen nojaavasta pääkallosta, jota näytöltä tuijotti teksti “Waiting for reply”. Hän kertoi ketterän kehittämisen käynnistyneen OP-Pohjolassa sertifioitujen projektipäälliköiden ja OWASP-tietoturvaan erikoistuneiden testaajien myötä.
RUP palastelee
Allan Halme vertasi RUPia vesiputousmalliin. RUPissa vaatimuksia ei jäädytetä, mutta koodaus kannattaa aloittaa vasta kun neljä viidesosaa järjestelmästä on määritelty. Kiinteähintainen tilaus edellyttää mahdollisimman hyvää vaatimusmääritystä.
Systeemityötä voi verrata Firenzen katedraalin kupolin rakentamiseen 1400-luvulla: järjestelmästä saa todellisen kuvan vasta, kun toteutus on jonkin matkaa edennyt ja nähdään, pysyykö toteutus sovituissa raameissa ja onko järjestelmän suorituskyky riittävä.
Kun tilaajalta tulee uusia tarpeita kesken projektin, RUPissa osa järjestelmästä on valmiina ja suuntaa voidaan muuttaa kohti uusia tavoitteita. Vesiputousmallissa taas kaikki olisi levällään eikä suunnan muuttamiseen löytyisi kiintopistettä.
Yleisö oli aktiivinen: Vastaava palasteleva suunnittelu-toteutus-idea kehitettiin jo 1990-luvun alussa Sytyken STST-työryhmässä, nykyisen Rela-yhteisön edeltäjässä. OP-Pohjolan V-malli ei tietenkään noudata vaihejakoa vesiputousmaisesti, kuten Allan Halme tulkitsi, vaan sisältää luonnollista iteraatiota, kun käyttäjät, ongelma, teknologia tai markkinat saattavat muuttua projektin aikana. Esitetyt RUPin työmääriä kuvaavat käyrät eivät toimi versioivassa tuotekehityksessä, jossa vaatimusmäärityksen työmäärä ei vähene työn edetessä.
Scrum pyrähtää
Lasse Koskela esitti Scrumin tausta-ideat kuvaamalla Toytan toisen maailmansodan jälkeisestä innovoivaa tuotekehityksestä, jossa pienin askelin tehokkaasti tehtiin jotain konkreettista, mikä tuotti lyhimmän kehitysajan ideasta valmiiseen tuotteeseen. Tältä pohjalta kehitettiin Scrum 1990-luvun alussa.
Asiakkaan priorisoimat tärkeät kehittämistoimenpiteet kootaan Product Backlogiin, josta kahdesta neljään viikkoon kestävän pyrähdyksen työmäärä poimitaan Sprint Backlogiin. Pyrähdyksen jälkeen tuotos on valmis eikä vaadi hiomista.
Ict-ammattilaisten velvollisuus on selvittää asiakkaalle priorisointiin ja toteutusjärjestykseen vaikuttavat tekniset asiat. Yleisön joukosta todettiin, että Scrumissa käytetään jatkuvasti aikaa Backlogin kampaamiseen, ettei se happane.
Scrumia opitaan tekemällä, ei kurssilla. Prosessi on yksinkertainen, mutta vaikea soveltaa. Scrumin toimijoita ovat tuotteen omistaja, moniosaava ja itseohjautuvat tiimi, johon kuuluu 5-9 henkilöä sekä Scrum-master. Scrum-master on kuin voi leivän välissä, poistaa esteitä ja ylimääräisiä välikäsiä sekä huolehtii prosessin järkevästä soveltamisesta.
Asiakkaiden kanssa keskustellaan heidän ymmärtämällään kielellä. Siihen ei kuulu pariohjelmointi eikä Scrum-master.