Tehdäänkö niin kuin aina vai kokeillaanko jotain uutta ja ketterää?

“Ennen vanhoina hyvinä aikoina…” Kuulen tämän lausahduksen työssäni usein. Toisinaan vastaan tähän kysymyksellä “milloin nämä ‘vanhat hyvät ajat’ olivat?”, tuskin koskaan saamatta vastausta.

Nykypäivänä muutos on oikeastaan ainoa vakio elämässämme. Maailma muuttuu ympärillämme, halusimme sitä tai emme, ja hyvä niin. On siis välttämätöntä että myös me muutumme sopeutuaksemme uuteen ympäristöön.

Fasilitoidessani muutosta kohtaan lähes jokaisessa hankkeessa muutosvastarintaa. Se on useimmiten pelonsekainen reaktio, kun tuttuja ja turvallisia olosuhteita muutetaan. Reaktio on lähellä eläinkuntaa: tuntematonta pelätään ja sen kimppuun hyökätään. Näissä tilanteissa myös suljetaan silmät kaikelta, mistä voisi olla hyötyä itsellemme! Emme siis uskalla lähteä seikkailuun, edes “matkaoppaan” tuella.

IT-alalla liiallinen tyytyväisyys on suuri uhka niin onnistuneiden hankkeiden läpiviemiseen kuin ajan hermolla pysymiseen.

 

“Tyytyväisyys tappaa kehityksen”; aivan! Jos olisimme olleet tyytyväisiä luolamajoitukseen, asuisimme edelleen luolissa. Meillä on siis luontainen tarve jatkuvaan kehitykseen. IT-alalla liiallinen tyytyväisyys on suuri uhka niin onnistuneiden hankkeiden läpiviemiseen kuin ajan hermolla pysymiseen. Sillä hetkellä, kun olemme ”riittävän hyviä”, kilpailijamme menee meistä ohi oikealta ja vasemmalta. Se miten asioita tehtiin ennen, ei välttämättä ole toimivin tapa juuri nyt.

Mitä on sitten Agile ja miksi se olisi parempi kuin muut IT-kehitysmenetelmät?

Me emme aina pysty ymmärtämään ja tunnistamaan kaikkia vaatimuksia, riskejä ja riippuvuuksia ennen hankkeen toteutuksen alkua. Ajatuskin on tavallaan absurdi. Vesiputous-malliin kuuluu aina (vähintään) neljä työvaihetta aikajanasta riippumatta

1. Vaatimusten määrittely
2. Toteutuksen suunnittelu
3. Toteutus ja testaus sekä
4. Julkaisu.

Kuulostaa hyvältä, mutta… Työvaiheet eivät ole vesiputous-mallin ongelma, vaan aikajana ja yksi julkaisu. Pitäisi siis pystyä tunnistamaan ja analysoimaan kaikki vaatimukset ilman riviäkään koodia.

Agile-malleissa sama tehdään hyvin erilailla, esimerkkinä SCRUM-prosessi. Suunnittelun pääpaino on liiketoimen vaatimusten, busineksen ja loppukäyttäjän tarpeiden ymmärtämisessä. Tämän pohjalta rakennetaan kehitysjono, jota toteutetaan ja ylläpidetään aktiivisesti koko hankkeen toteutuksen ajan. Toteutus tehdään tiimityönä lyhyissä, 2–4 viikon inkrementeissä (sykleissä), joiden sisältö sovitaan tarkasti. Yhdessä inkrementissä valmistuneelle työlle haetaan palaute ja hyväksyntä asiakkaalta ja (jopa) loppukäyttäjiltä. Näin siis varmistetaan, että tehdään oikeita asioita, oikeaan aikaan ja oikea määrä, laadusta tinkimättä. Tämän tuotoksen pitää olla tarvittaessa vietävissä tuotantoon.

Pysyäksemme motivoituneina meidän tulee luoda voittoja, jatkuvasti. Jos voitot realisoituvat liian harvoin, motivaatiomme laskee! Tämän takia Agile-tiimi pyrkii minimoimaan yhtäaikaisen työn määrän saadakseen jatkuvasti työtä valmiiksi. Tällöin koemme onnistumisia ja voittoja usein ja niistä tulee vähitellen kiinteä osa työtämme. Me olemme usein hyviä työssämme, miksi emme kuulutettaisi sitä kaikelle kansalle?

Rohkaisen kaikkia kokeilemaan uusia ratkaisuja vanhoihin ongelmiin, vaikkakin se tuntuisi alkuun mahdottomalta (muutos on vaikeaa)! Vain kokeilemalla voimme löytää uusia kulmia jokapäiväiseen tekemiseemme. Niin kuin Mary ja Tom Poppendieck, sanovat:

”Think big, act small, fail fast, learn rapidly!”

Varma kesän merkki on jääkiekon MM-kisat. Tällä kertaa Suomen joukkue voitti hopeaa ja ihmiset itkivät pitkin turuja ja toreja! Miksi? Joukkueemmehan voitti yhdeksästä pelistään kahdeksan! Eli viiden miljoonan ihmisen kansa pystyi luomaan maailman 2. parhaan joukkueen. Eikö tästä saisi olla ylpeä? Edellämme on vain Kanada, jossa jääkiekolla on lähes uskontoa vastaava status. Menestyksemme mahdollisti pelaajien ja valmentajien saumaton tiimityö, joka on hyvin agilemaista toimintaa! Peliä ei voi etukäteen käsikirjoittaa.