Vältä Pimeä Agile

Ketterästä ohjelmistokehityksestä, agilesta, pidetään niin paljon ääntä, että voisi luulla aivan kaikkien harjoittavan sitä. Ikävä kyllä agile on alkanut kärsiä vapaasti muuttuvien kuvausten ongelmasta, vähän kuin kilpailua syrjivää sääntelyä kutsutaan kapitalismiksi. Maailmalla on paljon esimerkkejä, että itse asiassa monet, jotka sanovat olevansa agileja, eivät sitä oikeasti ole. Nämä tahot harjoittavat Pimeää Agilea, ja näin sinä voit välttää syyllistymästä samaan.

Houkutus on suuri
Houkutus on suuri

Muista, mistä agilessa on kyse

Jotta voi välttää antautumasta agilen pimeälle puolelle, täytyy ensin muistaa mistä agilessa on kyse. Liike alkoi n. 15-20 vuotta sitten eri ideoiden koheesiosta. Ohjelmistokehitys oli hidasta ja kankeaa. Ohjelmoijat saivat olla kiitollisia jos näkivät saman koodin kehittyvän iteraatioissa, muuten kaikki tehtiin kerralla hyvin suunnitellusti. Agilen kenties tärkein vaikuttaja oli Extreme Programming -nimellä kulkeva joukko menetelmiä. Kirjoittamalla yksikkötestejä ja modulaarista koodia, harjoittamalla pariohjelmointia ja muokkaamalla koodia usein pystyy toimittamaan toimivia ratkaisuja hyvinkin nopeasti.

Scrum pähkinänkuoressa

Scrum on menetelmä, joka jakaa muutaman yksinkertaisen roolin kehittäjien ja liiketoiminnan kesken, antaen muutoin vapaat kädet toimia. Liikepuolelta kuullaan mitä tarvitaan. Tuoteomistaja päättää mitä voi ja pitää tehdä, toki pitäen liiketoiminnan mielessä. Kehitystiimi päättää aikataulut.

Päämääränä luottamus osapuolten välille

Liikepuolelle yrityksessä tämä on vaikea pala, koska hehän tuovat rahat sisään elättääkseen ohjelmoijia! Toisaalta, ohjelmoijat mahdollistavat tämän rahan tuomisen. Tällainen menetelmä, jolla laadukasta ohjelmistoa toimitetaan nopeasti, on tarkoitettu parantamaan luottamusta osapuolten välille. Liikemiesten ei tarvitse enää hönkiä ohjelmoijaparan niskaan kuukausikaupalla kun näytettävää tulee nopeammin. Ohjelmistopuoli alkaa luottaa liikemiehiin enemmän, kun palautetta saa nopeammin.

Ketterän ohjelmistokehityksen julistus kuvastaa muutamalla ranskalaisella viivalla ydinperiaatteet.

Tule pimeälle puolelle…

Ei mennyt kovinkaan kauaa, kunnes agilen pimeä puoli alkoi houkutella. Perinteiselle projektijohdolle Scrum Master -koulutus on tietysti yksi natsa CV:ssä muiden joukossa, mutta alunperin Scrummasterin piti olla yksi kehittäjistä. Mieluusti vähän väliä eri kehittäjä. Syyllistämättä tämän enempää projektipäälliköitä on käynyt niin, että ulkopuolinen Scrummaster lähestyy tilannetta usein komentavasti, ei fasilitoivasti.

Sen lisäksi, että Scrummasterin, tiimin fasilitaattorin, pitäisi olla kiinteä osa tiimiä, hänen pitäisi olla tekninen. Ymmärtämättä Extreme Programmingin tärkeyttä saatetaan ajautua tilanteeseen, jossa testit irrotetaan koodista tai kannustetaan ohjelmoijaa kirjoittamaan monoliitti, koska rajapintasuunnitteluun menee pidempi aika. Tai mitä tahansa muuta, johon ohjelmoijat samaistuvat pimeänä puolena. On valitettavaa, ettei Agile Manifesto nosta tätä yhdeksi periaatteeksi.

Toisin sanoen, Scrummasterin, tai minkä tahansa vastaavan, työ on puolustaa Scrumia ja teknistä laatua, eikä mitään muuta. Jos tämä ei pidä paikkaansa, et harjoita Scrumia, etkä luultavasti agilea muutenkaan.

Mistä tiedät siirtyneesi Pimeään Agileen?

On paljon tunnusmerkkejä, joista tietää lipsuvansa:

  • Työskentelyssä väheksytään suunnittelua, koska sehän olisi vanhanaikaista. Tiimin täytyy ymmärtää, että nopea koodin muokattavuus ei ole hyväksyttävä peruste aikaa hukkaavalle uudelleenkirjoittelulle, jos kerran voi suunnitella paremmin etukäteen.
  • Tuoteomistaja on suorittavalla tasolla tekemisissä ohjelmoijien kanssa, vaikuttaen (tai edes yrittäen vaikuttaa) työskentelyyn. Tuoteomistajan rooli on selventää työtehtäviä, ei muuttaa niitä työn aikana tai kertoa ohjelmoijille miten työ kuuluu tehdä.
  • On olemassa projektipäällikkö, joka pääsee häiritsemään esimerkiksi Scrumin sprinttien pituutta.
  • Vähintään viikottaisia isompia tehtävälistan muutoksia. Tekemättömien töiden listaa voi olla järkevää hienosäätää vaikka jatkuvasti, mutta sprintin tavoitteeseen ei saa kajota kun se on lyöty lukkoon.
  • Yksittäiset pienet alitehtävät tai vastaavat yksityiskohdat näkyvät ulospäin. Liiketoiminnan ei pitäisi välittää kuin päätason tehtävistä ja bugikorjauksista.

Pysy agilen valoisalla puolella

Mitä täytyy sitten pitää mielessä, että pysyisimme agilen valoisalla puolella? Ladon tähän listan, joka pätee melko hyvin, oli käytössä Scrum tai jokin täysin itsekeksitty juuri sinun tiimillesi toimiva malli.

  • Valmiin määritelmä, Definition of Done, sisältää aina vähintään yksikkötestit ja mahdollisesti muita laatukriteerejä. Kukaan tiimin ulkopuolelta ei saa vaatia kriteerien poistamista tai heikentämistä. Ketteryys vaatii laadukasta työtä, joten tiimin täytyy aina varata puskuria mahdollisille ongelmille, olivat ne tiukasta laadunvarmistuksesta huolimatta ilmenneitä bugeja tai jotakin muuta. Kukaan tiimin ulkopuolelta ei saa vaikuttaa ajanvarauksiin tai deadlineihin.
  • Tiimin on ansaittava luottamusta kertomalla tiimin jäsenille ongelmista. Scrummasterin on fasilitoitava ongelmat pois tieltä.
  • Tuoteomistajan on luotettava tiimiin. Jos jotain jää tekemättä sprintissä, sille on varmasti syy ja siitä tulee keskustella, mutta ei syyllistää.
  • Liiketoiminnan ei tarvitse myöskään tietää mistään story pointeista tai velocitystä tai muusta tiimin sisäisestä kirjanpidosta. Ihanteellisesti liiketoiminnan, poislukien tuoteomistajan tai muun yhteyshenkilön, ei tarvitse edes tietää harjoittaako tiimi Scrumia vai jotakin muuta.

Loppuun pari havainnollistavaa Youtube-videota:

 

 

***
Ylin kuva: Flickr CC, Holley & Chris Melton

Mihin leania tarvitaan – eikö terve järki riitä?

Lean-menetelmiin ensimmäisiä kertoja tutustuva kysyy usein, mihin moisia lähestymistapoja tarvitaan? Eikö terve järki riitä? Eikö prosessimallit ole tehty vain ylemmän johdon iloksi? Voiko yksikään prosessikehitystekniikka itse asiassa tuoda mitään uutta jos ongelmaa on jo ratkaisemassa alan paras ammattilainen tai firman kokenein osaaja?

Hyviä kysymyksiä. Itselleni hyötyjen ymmärtäminen oli välttämätön ensimmäinen askel lean-menetelmiin tutustumisessa.

1) Osastokohtainen korjaaminen ei riitä

Lean-metodit ovat parhaimmillaan silloin, kun katsotaan kokonaista prosessia hankinnasta asiakaspalveluun saakka. Tätä kokonaisuutta ei yksityiskohtaisesti tunne kukaan asiantuntija yrityksessä; päinvastoin, osaaminen on pilkottu siiloihin. Tässä kohtaa ammattiylpeys estää kysymästä naapurisiilon toiminnasta oikeita kysymyksiä, jotka voisivat tuottaa parhaan tuloksen. Väärät luulot muiden tarpeista tekevät todellisen muutoksen mahdottomaksi. Tyypillisessä organisaatiossa kunkin siilon prosesseja kehitetään itsenäisesti, miettien talousosaston, varaston tai tuotekehityksen tehokkuutta yrityksen kokonaisedun sijaan.

Ongelmat, jotka jäävät hierarkisten siilojen rajoille, eivät helposti ratkea hierarkisen johtamisen menetelmillä. Tarvitaan jotain muuta.

2) Yhteinen kieli ja ymmärrys välttämättömiä

Muutoksen johtaminen vaatii yhteisen sanaston ja termistön. Lean-sanasto on luonteva valinta, sillä sitä ei tarvitse itse keksiä eikä se jää organisaation sisäiseksi omaksi slangiksi. Varsin suoraviivaiset ja helposti omaksuttavat termit ja niiden takana olevat mallit on kehitetty jatkuvan kehittämisen viemiseen tehdastyöhön ja ovat myöhemmin osoittautuneet toimiviksi sekä toimistoissa että tuotantopuolella. Ilman yhteistä kieltä ei voi olla yhteistä muutosta. Wittgensteiniä siteeraten: ”Mistä ei voi puhua, siitä on vaiettava.”

3) Radikaali tehostaminen

Lean-filosofiassa osa kannattavuuden parantamisen arvoista ovat päälaellaan totuttuun länsimaiseen toteutustapaan nähden. Liialliset varastot nähdään turhana ja liiallinen testaus nähdään liian huonona laatuna prosessin edellisessä vaiheessa. Nämä uudet arvot ja uusi kokonaisuuden hallintatapa on ollut Toyotan salaisuus, jolla valmistaja on noussut pienestä paikallisesta yrityksestä alan suurimmaksi noin 50 vuodessa. Kun kaikki tehdään hyvin, säästö on odotettua suurempi.

4) Pomottelu kielletty

Lean-filosofia lähtee mittaamisesta, sekä ennen muutosta, että muutoksen jälkeen. Tämä näennäisen vaatimaton vaihe muuttaa  päätöksenteon kokonaan. Useimmissa hierarkisissa organisaatioissa prosessimuutokset ovat esimiestyönä tehtyjä valintoja, jotka heijastavat voimakkaasti päätöksentekijän persoonaa ja preferenssejä. Jälkipuheet ja kaipuu vanhaan ovat tavallisia muutoksen jälkeisiä reaktioita, jos muutoksen hyödyt eivät ole näkyviä. Lean-muutoksia mitataan aina. Hyöty tehdään näkyväksi, epäonnistumiset myös. Muutosta on tämän jälkeen vaikea käyttää tai nähdä vallankäytön välineenä.

5) Nopea käyttöönotto ytimessä

Todellisen muutoksen suurin este on usein muutoksen suunnittelijat ja jopa kokonaiset muutoksen suunnitteluyksiköt. Tällaisten kehityspäälliköiden helmasynti on suunnittelun korostaminen ja tekemisen viivyttely. Lean-menetelmän ytimessä on joukko hyväksi havaittuja tapoja, joilla havaitut muutostarpeet voidaan viedä käytäntöön välittömästi. Keskittymällä niihin muutoksiin, joilla on suurin vaikutus ja jotka voi helpoimmin viedä käytäntöön muutoshanke alkaa tuottaa hyötyä nopeasti. Tehokkuuden parantuessa prosessiin kuuluvilla on enemmän aikaa tehdä vaikeampia ja hitaammin käyttöönotettavia muutoksia.

Terveellä järjellä voi muuttaa oman työnsä ja oman osastonsa toimintatapoja, mutta kokonaisen monen osaston prosessin parantamiseen kannattaa ottaa käyttöön parhaiksi havaitut ajattelun työkalut. Lean-menetelmät kuuluvat ehdottomasti tähän joukkoon. Kun lean-työtä on tehty aikansa, lean-filosofiasta tulee osa koko yrityksen terveen järjen käyttöä.

PyCon Finland 2016

Viikon sisään kaksi konferenssia! Sokerina pohjalla molempien aiheena oli Python-ohjelmointikieli. Ensimmäinen oli PyCon Finland ja toinen PyCon Ireland.  Julkaisen PyCon Irelandista kertovan blogauksen myöhemmin.

Suomen konferenssi kesti yhden maanantaipäivän, mutta oli sitäkin paremmin täynnä ohjelmaa. Päivän alussa järjestettiin salamapuheet, nuo korkeintaan viisi minuuttia kestävät esitykset, joiden aihe on vapaa. Yleensä nämä pidetään tapahtuman päätteeksi, mutta tapahtuman lopussa kannettavien ja projektorien kanssa säätämisen välttämiseksi nämä oli siirretty alkuun. Tämä tosin rajoitti kenties osallistumista, koska usein ideoita voi tulla konferenssin aikana aiheista, joista puhua. Ehkä ajatuksena oli, että ei päätetä konferenssia turhautumiseen ja ainakin salamapuheet olivat hyviä. Varsinaisista esityksistä minulle mieleenpainuvimmat olivat tietojenkäsittelyyn ja tekoälyyn liittyviä.

Käsialatunnistustietokanta

Aleksei Tiulpinin esitys Machine Learning with Python havainnollisti MNISTin käsialantunnistustietokannan käyttöä www-palveluna. Hän kävi läpi teoriaa ja esitteli sitten tekemäänsä ohjelmistoa, jossa selaimeen pystyi piirtämään numeron ja palvelun takana pyörivä tekoäly kertoi minkä numeron luulee olevan kyseessä milläkin todennäköisyydellä.

Tekoälyä työpaikkailmoituksiin

Myös Clemens Westrupin Representation Learning and Deep Sequential Modeling for Predicting Topics of Sentences in Job Advertisements oli mainio. Puhuja kävi läpi miten Oikotien englanninkielisiä työpaikkailmoituksia voi luokitella tekoälyn avulla, kunhan ensin saa kerättyä dataa siitä, mitä sisältö yleensä on.

Yksikkötestit data-analyysin maailmassa

Viimeisenä tästä kategoriasta täytyy mainita Unit Testing in the Scientific Python Stack, jonka piti Antti Kaihola. Tässä puhuja näytti, miten data-analyysin maailmassa voidaan suorittaa yksikkötestejä – eri menetelmiä ja havaintoja sekä bugin kirjastossa.

Valtavirran unohtama ZODB

Lisäksi nostaisin Asko Soukan ZODB-esityksen korkealle. ZODB on valtavirran kenties unohtama – tai tiedostamaton – Python-objektitietokanta. Tähän tietokantaan voi tallentaa suoraan Python-ohjelman ajonaikaisia rakenteita. Yleensä ajonaikaiset rakenteet käännetään JSON-muotoon tallennettavaksi, joten oli mielenkiintoista kuulla miten muutoin tämän voi tehdä. Lisäksi ZODB:ssä on suurin osa vakiintuneiden tietokantojen ominaisuuksista.

Älä unohda tietoturvaa

Päällekkäisyyksien takia ainakin Joona Hoikkalan CertBot-aiheinen esitys Closing the gap with TLS adoption täytyy ehdottomasti katsoa Youtubesta. Tietoturva on tärkeä asia, joka laiminlyödään liian usein.

***
Kuva: Flickr Creative Commons, Chris Parker.

Vastuunoton lyhyt oppimäärä

Kävin pari viikkoa sitten Wakarun DevOps-seminaarissa puhumassa vastuusta; siitä mitä se on, kuinka siihen päästään ja mitä esteitä matkan varrella on. Puheeni taustalla on Christopher Averyn vastuuprosessi, englanniksi the responsibility process. Vastuuprosessi kuvaa, kuinka ihmismieli reagoi ongelmiin ja vastoinkäymisiin.

Vastuuprosessi toimii näin:

Elämässä tulee vastaan ongelma, esimerkiksi aamun kiireessä kadonneet auton avaimet tai projektipalaveri, joka alkaa aina aina myöhässä.

Ensimmäinen refleksimme on syyttää jotakin toista henkilöä ongelmasta:

“Kamala kiire ja auton avaimet hukassa, hitto vie vaimo on taas ne siirtänyt!”

“Palaveri alkaa taas vartin myöhässä, saamarin projektipäällikkö kun se aina myöhästelee!”

Kun tilanne hieman kypsyy, seuraavaksi selittelemme, miksi ongelma on ympäristön syy:

“Noh, tämähän nyt on vain sitä lapsiperheen arkea: huusholli sekaisin ja kaikki hukassa.”

“Meidän yrityskulttuuri on sitten syvältä kun kaikki ovat aina myöhässä eikä ketään kiinnosta.”

Hetken kuluttua siirrymme seuraavaan vaiheeseen, häpeään:

“Pöh, olenpa tyhmä. Olisinhan minä voinut ne avaimet laittaa valmiiksi illalla.”

“Tiesinhän minä, että palaveri myöhästyy, olinpa typerä kun hermostuin.”

Ja hetken kuluttua onkin vuorossa vaihe nimeltä pakko:

“Kaipa minun on pakko puhua vaimon kanssa, ettei koskisi avaimiini.”

“Typerä palaveri. Mutta täällä sitä on istuttava, koska pomo käski.”

Jos ongelma on vakavampi kuin avainten häviäminen tai palaveri, voi käydä niin, että häpeän tai pakon tunteminen käy niin tuskalliseksi, että mielemme pistää lapun luukulle ja luovuttaa. Tällöin kiellämme koko ongelman olemassaolon ja haemme parempaa oloa vaikkapa punaviinistä tai suklaasta.

Vastuunotto on ongelman omistamista

Mikäli edellisistä vaiheista pääsee eteenpäin, on mahdollista saapua paikkaan, jonka nimi on vastuunotto. Vastuunotto on mielentila, jossa haluamme omistaa ongelman ja jossa voimme käyttää kaikkea aivokapasiteettiamme asian ratkaisemiseen. Vastuunotto voisi kuulostaa vaikka tältä:

“Mitähän niiden autonavaimien kanssa oikein tapahtui? Ehkäpä vaimo ei niitä siivonnutkaan. Hmm. Pitääpä miettiä miten ne eivät häviäisi tulevaisuudessa. Asentaisinko vaikka avaimia varten ovensuuhun ripustuspaikan?”

“Projektipäällikkö on myöhässä joo, mutta mistähän se johtuu? Voisinkohan tehdä asialle jotakin? Miksi ylipäätään hermostuin – mikä tarpeeni ei täyttynyt, joka puolestaan aiheutti tunteen? Mitäpä jos ottaisin tämän palaverin vetääkseni? Tai itse asiassa, mietitäänpäs vielä tarvitseeko minun edes tähän palaveriin osallistua? Kuinka voisin sen perustella pomolleni?”

Syyttäminen, selittely, häpeä, pakko ja luovuttaminen ovat vastuuprosessin ensimmäiset viisi mielentilaa. Niissä ei sinänsä ole mitään pahaa tai tuomittavaa, koska me ihmiset olemme tällaisiksi kehittyneet ja kasvaneet. Ikävää näissä mielentiloissa on se, että ongelmat eivät niissä ratkea, maailma ei edisty emmekä me siellä työssämme tai ihmisinä kehity. Kun syyttelemme ja selittelemme, olemme voimattomia emmekä voi tehdä asioille mitään, koska jonkin ulkopuolisen tekijän kuten henkilön tai yrityskulttuurin on muututtava. Kun taas tunnemme häpeää tai pakkoa, olemme voimattomia, koska joko meidän pitäisi muuttua tai meidän nyt vain on pakko kestää tilanne. Luovuus tai looginen ongelmanratkaisu on näissä mielentiloissa mahdotonta.

Vastuunoton lähtökohta on vapaa tahto

Miten elämässä sitten voi ottaa enemmän vastuuta? Lähtökohtana on oma vapaa tahto ja valinta. Vastuunottoa ei voi toiselle pakottaa eikä sitä voi itseltä vaatia, koska silloin joutuu mielentilaan pakko tai häpeä. Avaimia vastuullisempaan elämään on kolme:

  1. Aikomus toimia vastuunoton mielentilasta kun ottaa päähän, eikä syyttelystä, selittelystä, häpeästä tai pakosta.
  2. Tietoisuus omasta mielentilasta, itsestä ja ympäristöstä.
  3. Haastaa itseni ja kuvani todellisuudesta ja etsiä sitä, mikä on totta.

Vastuun harjoittaminen vaatii paljon työtä ja itsensä kohtaamista. Työkaluja avuksi onneksi löytyy, esimerkiksi päiväkirjan kirjoittaminen, meditointi, toisten tarkkailu sekä harjoitusryhmät. Olennaista on harjoittaa itseään tunnistamaan mielentilojaan ja haastamaan oletuksiaan ja arvojaan. Vielä olennaisempaa on antaa itselleen anteeksi ja oppia virheistä, koska niitä kuitenkin aina tulee ja koska itsensä kehittäminen häpeän mielentilasta on vaikeaa.

Kovan työ kuitenkin kannattaa. Jumissa, pakon alla tai tilanteen uhrina olemisen kokemus voikin yhä useammin muuttua oivallukseksi, jota seuraa omistajuus ja halu toimia. Puurtamisen palkinto on omassa elämässä vapaus, valinnanvara ja voimaantuminen.

***

Tämän artikkelin on alunperin kirjoittanut Ari Tanninen. Sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Kokoustaa vai eikö – siinäpä pulma

Suomen hallitus on yhdessä työntekijä- ja työnantajajärjestöjen kanssa ryhtynyt päättäväisesti parantamaan maamme teollisuuden ja palvelutuotannon tuottavuutta ja  kilpailukykyä. Hallitus on saanut aikaan kilpailukykysopimuksen, joka pidentää työaikaa. Pidemmän työajan hallitus toivoo nostavan tuottavuutta.

Voisiko asiaa lähestyä toisin? Voisiko nykyistä työaikaa käyttää tuottavammin? Voisiko suuremman osan työajasta käyttää arvon tuottamiseen asiakkaille? Pohditaanpas.

Mihin aika kuluu?

Olen osallistunut ja seurannut työelämää 1980-luvun lopulta lähtien. Tänä aikana on tapahtunut paljon muutoksia: sähköposti tuli ja osin jo meni, internet toi kaiken tiedon välittömästi käytettäväksi wikipedioineen ja hakukoneineen, erilaiset yhteistyöalustat kehittyivät Lotus Notesin team roomeista erilaisten Intranetien kautta käytettäviin yhteiskirjoitusalustoihin. Puhelimet siirtyivät pöydiltä taskuihin ja internet seurasi perässä.

Välineet ovat muuttuneet, mutta kokoukset ovat ja pysyvät. Työssäni konsulttina olen huomannut, että täysin riippumatta välineistä ja tietotekniikan kehityksestä, ihmiset näyttävät viettävän merkittävän osan työajastaan kokouksissa. Osaa kokouksista ihmiset tuntuvat pitävän tarpeellisina, osaa eivät.

Voisiko kokousten vähentäminen ja lyhentäminen tuoda vähintäänkin saman verran lisää työaikaa arvon tuottamiseen asiakkaille kuin hallituksen aikaansaama työajan pidentäminen?

Vastaus on joko kyllä tai ei. Vastaus riippuu siitä, ovatko kokoukset hyödyllisiä ja sopivan pituisia. Onneksi tämä asia on helppoa selvittää tietotekniikkaa käyttämällä.

Kokousmittari

Kokouksiin pätevät samat kriteerit kuin kaikkeen muuhunkin työntekoon.

  1. Mitä suurempi osa kokouksesta tuottaa arvoa asiakkaalle, sitä parempi.
  2. Mitä nopeammin kokous on ohi, sen parempi

Nämä asiat ovat helposti mitattavissa. Jokaisessa organisaatiossa on kalenterijärjestelmä, Suomessa useimmiten MS Outlook, jonka avulla kokouksen koollekutsuja varaa kokoustilat ja kutsuu tarpeelliseksi katsomansa henkilöt kokoukseen. Näin ollen tiedämme, keitä missäkin kokouksessa on.

Rakentakaamme järjestelmä, joka lähettää satunnaiselle otannalle kokouksen osallistujista kyselyn kokouksen jälkeen. Kyselyssä on kaksi kysymystä.

  1. Koitko kokouksen hyödylliseksi itsesi kannalta?
  2. Kuinka suuren osan ajastasi kokouksessa tuotit arvoa asiakkaalle?

Kokouksen osallistujat vastaavat näihin kysymyksiin. Vastaaminen kestää hyvin tehdyllä käyttöliittymällä 15 sekuntia. Järjestelmä koostaa vastausten keskiarvot ja julkaisee ne organisaation intranetissä tai ruokalan seinällä olevalla suurella näytöllä osastokohtaisesti.

Kaikki näkevät oman osastonsa kokousten saamat arvosanat ja voivat verrata niitä muiden osastojen saamiin arvosanoihin. Huonojen arvosanojen saaminen toistuvasti on noloa, joten väistämättä kokousten laatu alkaa parantua. Kun jokin osasto keksii tavan nostaa arvosanojaan, muut kiinnostuvat ja kopioivat parhaat käytännöt.

Uskon, että kokouksia parantamalla on mahdollista lisätä teollisuutemme ja palveluidemme tuottavuutta ja kilpailukykyä paljon enemmän kuin työajan pidennyksellä.

***
Kuva: Flickr Creative Commons, Ivan.

Tämän artikkelin on kirjoittanut Matti Kinnunen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.