Tampere Goes Agile 2013

I have a two year old tradition of going to TGA with a friend of mine. Its usually the only trip to Tampere each year for both of us. So I thought since going there is a tradition, why not writing a blog summary about the event as well.

I was really tired this year after only a few hours of sleep the night before so it might have brought some bias, but I didn't feel quite the same level of good vibes and community as last year. I'm thinking the venue (Tampere-talo) might have something to do with this. The place is ultra clean and areas between presentations weren't really good for sparking ad hoc discussion.

So here are the presentations that I saw and what inspired me.

Note I didn't see all of the presentations and who knows how amazing things I missed. Not being mentioned here is not a sign your favourite presentation wasn't great in my opinion.

Science!

Laurent Bossavit: The Art of Being Wrong. How good are your guesses and estimates? How well calibrated are you and do you ever check your assumptions after the fact? These were the questions Laurent brought up. I've written about this same topic earlier in my own blog - only more focused on testing.

Laurent is the author of a book I intend to read, called The Leprechauns of Software Engineering. Superficially it looks very similar to the book  What We Actually Know About Software Development, and Why We Believe It's True which I did read earlier this year. I believe the topic is important, but Wilson's and Oram's book was more like a collection of academic papers demanding more academic research about software engineering. Which is good and great, but honestly not a very useful read for a practicing engineer like myself. So I'm really looking forward to reading Laurent's book and will get back to the subject once I've read it.

Lean!

Next interesting presentation was by Marko Taipale. He was a presenter last year as well and did a very similar presentation about Lean Startup methodology. This time Marko drilled deeper and specifically into how his own company uses lean startup tools in developing their own business models. Lean thinking and Lean Startup -movement is a huge topic and I will not go much deeper here. Instead, I'll just provide a link to Marko's presentation.

Ok I will say one thing about Lean Startup -movement after all. Its starting to get real criticism as well which is always a good sign. It means its being used and people have opinions and hopefully even hypothesis about if and how well it works. To balance things out a bit, read for example some good critique by Dan Norris. Would love to have Marko Taipale and Dan Norris in a panel discussion about Lean Startup!

Contracts!

I'm a freelance contractor myself, been for about 3 years now. And even before that I was a consultant for 10 years doing hour-based contracting for various companies. Antti Kirjavainen from Houston Inc did a very thought provoking and important presentation about the current state of manhour-based contracting work and why it sucks so much for everybody. 

I'm hereby officially giving the Best of TGA 2013 prize to Antti! I might return and write a whole blog entry about the topic, but for now, here is Antti's presentation.

Contracting and how the dynamics in it are built right now will end up hurting everyone in our industry at some point. Delivering warmed seats instead of identifiable value and treating each developer as seat warmer for which the hourly price needs to be minimised, is a doomed model and needs to change at some point.

I was honestly too tired to have a chat about this with Antti at TGA, but I will definitely do so at some point if I get the chance.

#noestimates

Nice to have a word for what I've done intuitively as a team lead if there has been no pressure for strict Scrum or other Methodology! Henri Karhatsu did a very inspiring presentation from a real life project he had been leading, transforming the process from poorly working traditional agile planning to a much more streamlined custom process without estimates.

I got a few new ideas to try out from Henri's presentation. I really can't say if my next project will use estimates or not. Sometimes they are good. Sometimes they aren't that useful. There is no predefined rule on how to determine which is the case beforehand.

What I really liked about Henri's presentation was advocation of thinking for yourself. This worked for him, but might not work for you - at least not copied blindly. 

What often most ticks me off about Methodologies in software engineering, is that they are essentially attempts in externalising thinking. "Read this book and follow the steps and you won't have to think for yourself. We have solved this for you". 

Do what makes your developers happy and result in correct business need being fulfilled

This needs to be fine tuned and figured out in every company, in every project of any significance. That's just how it is. Learn to live with it. Hire a Henri to figure these things for you :)

And finally...

Very much thanks and hugs for the wonderful people who organised this free (!) event and the sponsors who paid for it all! 

My sincere suggestion for next year is that the event wouldn't be entirely free anymore. Now apparently over 60 people who had registered never showed up. Make it 50e a pop and people might not reserve a seat just in case they feel like going. 

Ajatuksia Apotista

This blog post is in Finnish because of the topic. 



Apotti-hanke on herättänyt ennennäkemättömän määrän keskustelua sekä Suomen IT-piireissä, että julkisuudessa. Mahdollisesti ensimmäistä kertaa yleiseen keskusteluun on noussut se, miten ongelmallisia ja kalliita julkisin varoin toteutettavat IT-järjestelmät ovat.

Olen mielenkiinnolla seurannut aiheen ympärille syntynyttä Facebook-ryhmää. Keskustelun laatu on korkeatasoista ja siihen osallistuvat sekä IT-alan että terveydenhuollon ammattilaiset.

Tämän kirjoituksen tarkoituksena on kerätä teemoja, jotka vallitsevat keskustelun taustalla - valitettavasti usein hukkuen yksityiskohtien ja tarkan argumentoinnin sekaan. Pyrin nostamaan tarkasteltavan ongelman sellaiselle tasolle, että voidaan päästää irti kehää kiertävistä argumenteista (esimerkki: "ketterät menetelmät auttaisivat - ei voi käyttää koska X, Y, Z"). Yritän myös tuoda keskusteluun muutaman uuden käsitteen ja idean, jotka ehkä jäsentävät aihetta niiden mielissä, jotka tämän kirjoituksen lukevat.


Millaista on hyvä ohjelmistokehitys?

Jotta voitaisiin verrata vaikkapa Apotin toimintamalleja johonkin, esittelen ensin oman parhaan näkemykseni siitä, miten järjestäytyy toimivia, kestäviä ja kauniita ohjelmistoja tuottava kehitysmalli. Listaan ominaisuuksia, joita tällaisella mallilla voisi olla. Mitä enemmän näitä saadaan käyttöön samassa hankkeessa, sitä varmemmin se tuottaa arvokkaita tuotoksia.

1. Ekosysteemeitä hierarkkisen hallinnon sijaan.
2. Varhainen ja usein toistuva altistuminen todellisuudelle.
3. Osapuolilla on tasapainoinen riskijakauma. 
4. Ohjelmiston rakenne tukee kohtaa 1.

Katso mitä Apple, Google, Facebook ja muut uuden sukupolven teknologiayritykset tekevät, niin ymmärrät. Onko erityisiä syitä, miksi näin ei voitaisi toimia julkishallinnon IT-hankkeissa? Varmasti tuhat syytä. En vain usko, että mikään niistä kestää tarkempaa tarkastelua.

Ekosysteemeitä hierarkkisen hallinnon sijaan

Julkishallinnon IT-hankkeissa istuu norsu keskellä huonetta. Kaikesta muusta keskustellaan, mutta silmiini ei ole osunut kritiikkiä sitä kohtaan, että hankkeita vedetään täysin ylhäältä alaspäin johdettuna. Korkeintaan vaaditaan parempaa osaamista sinne norsunluutornin huipulle.

Parempi suunta olisi pyrkiä minimoimaan hallinnon määrä ja keskittyä siihen, että pystytään reagoimaan nopeasti ärsykkeisiin.  

Tähän päästään mielestäni niin, että luodaan pieni ja erittäin asiantunteva organisaatio, jolla on niin korkean tason mandaatti "tehdä kaikki tarvittava onnistumisen varmistamiseksi", että asioiden hyvin tekeminen ei muutu mahdottomaksi.  

Tällainen organisaatio omistaa kaiken koodin, infran yms. mitä hankkeessa syntyy. Erityisesti tämä organisaatio vastaa ns. ytimestä, joka löytyy jokaisen hyvin tehdyn tietojärjestelmän keskeltä. Käyttöjärjestelmissä sen nimi on "kernel", potilastietojärjestelmässä se on potilastietojen optimoitu tietomalli, sen toteuttava tietokanta ja nämä kaksi yhdistävä logiikka. Tämä ydin on suojattu rajapinnoilla, jotka tämä organisaatio omistaa ja joiden kehityksestä ja muutoksesta se vastaa.

Jokainen ekosysteemi siis tarvitsee ytimen. Applella on AppStore. Linuxissa on Linus Torvaldsin hallinnoima Linux Kernel. Tällaisen ytimen päälle voidaan tuottaa erilaisia laajennuksia, käyttöliittymiä, sovelluksia. Mutta niin, ettei mikään yksittäinen osa pysty rikkomaan kokonaisuutta.

Tällaisessa mallissa pärjätään pienellä ydinorganisaatiolla, muu työ voidaan kilpailuttaa. Mikä parasta se voidaan kilpailuttaa pienilläkin yrityksillä, jolloin ei olla jumissa kahdessa tai kolmessa toimittajassa, joiden välillä on ehkä kilpailua, mutta ei juurikaan eroa lopputuloksen laadussa tai hinnassa (lue: huono ja kallis).

Kun tähän lisätään hyvin tehty käyttöliittymästandardi, ei pitäisi käytettävyydessä olla suuria eroja eri osajärjestelmien kesken.

Varhainen ja usein toistuva altistuminen todellisuudelle

Sähköisen reseptin viimeaikainen uutiskynnyksen ylittänyt kompurointi on tästä mainio esimerkki. Hanketta on jossain muodossa kehitetty tai valmisteltu 1980-luvulta asti. Vuonna 2013, kun se on saatu pikkuhiljaa käyttöön, käy ilmi että järjestelmä ei ihan vastaakaan todellisuuden tarpeita.

Ei. Oikea vastaus tähän haasteeseen ei ole entistä tarkempi ja perinpohjaisempi määrittelyprojekti. Ei, vastaus ei myöskään ole juristiarmeijan laatimat sopimukset, jotka kieltävät virheiden tekemisen toimittajilta.

Ohjelmisto, joka altistuu todellisuudelle vasta kun se on valmis, on kuin ihminen joka altistuisi elämälle vasta 18-vuotiaana. Kompleksit järjestelmät (ihminen, ohjelmistot) vaativat evoluutiota tullakseen toimiviksi. 

Tämä on tärkein yksittäinen asia, minkä ketterä kehitys on tuonut (takaisin) ohjelmistokehitykseen. 

Todellisuus on niin monimutkainen, että sen kanssa toimivan järjestelmän on pakko kompuroida ensin, että siitä saadaan toimiva.

Ja juuri niinhän nyt on sähköisen reseptinkin kanssa käymässä. Ongelma vain on, että altistuminen tapahtuu liian myöhään. Lisäksi järjestelmä ja varsinkin sen hallinto ovat liian kankeita pystyäkseen mukautumaan tällaisiin "yllätyksiin". Sen sijaan nyt joudutaan odottamaan puolitoista vuotta(!), jotta loppukäyttäjän näkökulmasta täysin triviaali muutos saadaan tehtyä.

Osapuolilla on oltava tasapainoinen riskijakauma

Englannin kielessä on osuva sanonta "to have skin in the game".  Siitä tässä on kysymys.

Julkishallinnon IT-hankkeissa erityisesti ja julkishallinnossa ylipäätään on valtava ongelma tässä suhteessa. Virheistä, vakavistakaan, ei yleensä tule seuraamuksia sen tekijöille. Toisaalta myöskään onnistumisesta ei palkita. Tämä on virkamiesjärjestelmämme pimeä puoli.

Vapailla markkinoilla sekä virheistä että onnistumisista rangaistaan/palkitaan. Käynnissä on jatkuva evoluutio, joka tuottaa koko ajan parempia ratkaisuja todellisiin ongelmiin.

Aiemmin mainitsemassani ytimen omistavassa organisaatiossa työskentelevillä julkishallinnon työntekijöillä olisi aivan ehdottomasti oltava "nahkaa pelissä". Tuntuvat rahalliset korvaukset, jos hanke onnistuu. Potkut koko porukalle, jos epäonnistuu. Näin karrikoidusti. Palkitsemisjärjestelmien asiantuntijoilla on varmasti hienosyisempiä malleja.


Ohjelmiston rakenteen on tuettava ekosysteemin rakentamista

Apotin kaltainen monoliittinen ostos (jos ollaan edelleen ostamassa Epic-järjestelmää) ei toteuta tätä vaatimusta. Kovan ytimen tunnistaminen, suunnitteleminen ja rakentaminen on erittäin vaativaa. Vielä vaativampaa on sellaisen ostaminen. En oikeastaan osaa edes kuvitella, miten sellainen ostettaisiin "valmiina".

Ihan lonkalta heitettynä miettisin itse vaikkapa Suomen terveydenhuollon IT:n omaa pilviarkkitehtuuria. Tässä pilvessä sitten ajettaisiin ytimiä, joiden ympärille voidaan vapailla markkinoilla tuottaa toimivia osasia. Tätä on ansiokkaasti edistetty Taltioni-palvelussa.

Totta kai tässäkin tarvitaan hallintoa ja valvontaa. Mutta kyseessä ei ole edelleenkään rakettitiede. Apple tutkii ja hyväksyy jokaisen sovelluksen ennen sen päästämistä AppStoreen. Ongelma on aivan varmasti ratkaistavissa, jos keskitytään ongelman ratkaisuun, eikä byrokratian laajentamiseen.

Kenties olisi kannattavampaa viedä julkisen IT:n hallinta pois puhtaasti julkishallinnollisen byrokratian piiristä, jos näyttää siltä, että asioita ei yksinkertaisesti saada toimimaan? Toimiva ratkaisu olisi valtion omistama voittoa tavoittelematon yritys. Sen henkilökunta ei olisi virkamiehiä, vaan kunnollisilla kannustimilla motivoituja ammattilaisia.

Big Bang

Lopuksi vielä muutama sananen aiheesta, josta on ainakin Facebook-ryhmässä keskusteltu, ja joka kaipaisi laajempaakin huomiota.

Suomen julkishallinnon ja etenkin terveydenhuollon rakenne on todella hajanainen. Toimijoita ja erilaisia prosesseja, johtamistapoja ja eritysvaatimuksia on käsittämätön määrä näin vähäväkiselle valtiolle. Tämä ongelma on pyörinyt paljon niissä argumenteissa, joilla on haluttu puolustaa nykyistä tehotonta ja kallista toimintakulttuuria.

Kyllä, prosesseja on muutettava, eikä tietojärjestelmä voi korjata huonoja toimintatapoja. Tietojärjestelmä voi vain tehostaa (parhaimmillaan) sitä toimintatapaa ja prosessia, jonka mukaan toimitaan muutenkin.

Mielestäni Apotissa yritetään saada aikaan ns. Big Bang, eli paljon muutosta aikaan kerralla ja keskusjohtoisesti. Ehkä ajatellaan, että vain tarpeeksi suuri ja mahtipontinen hankejärkäle saa byrokratian juoksuhaudat revittyä auki. Voi olla, mutta tulokset eivät näytä kovin vaikuttavilta tähän mennessä.

Paljon helpommin hallittavissa oleva lähestymistapa olisi rakentaa Apotin ydinjärjestelmä ja joku rajattu määrä sovelluksia ytimen päälle yhteistyössä yhden pienen ja muutokselle valmiin sairaanhoitopiirin (tai jopa yksittäisen laitoksen) kanssa. Mieluusti vielä niin, että tulevat loppukäyttäjät ovat mukana varmistamassa toteutuksen altistumista todellisuudelle alusta asti.

Kun on saatu yksi onnistuminen, voidaan alkaa neuvottelemaan muiden yksiköiden kanssa. Tässä kohtaa mielestäni vaaditaan raakaa liikemiestaitoa ja mahdollisesti jopa lainsäätäjän painostusta siihen, että jokaiselle sairaanhoitopiirille ja peräkylän terveyskeskukselle ei tehdä poikkeuksia järjestelmiin, varsinkaan sen ytimeen. Joko käytät yhteistä järjestelmää ja muutat prosessit sen kanssa yhteensopiviksi tai sitten olet oman onnesi nojassa.