Omaan ketteryyteen on helppo kompastua
Scrum! Ketteryys! Nopeus ja tehokkuus! Kuulostaa hienolta ja käytännölliseltä. Näitä hyveitä soveltaen ei mikään voi mennä pieleen! Motivaatio on huipussaan ja tekeminen alkaa hampaat hulmuten. Jossain vaiheessa tie kuitenkin käy kiviseksi.
Liikkuvia lajeja harrastaneena voin kertoa, että liika luottamus omaan ketteryyteen ja nopeuteen ei vie kovin pitkälle. Juosten ja kärrynpyöriä/voltteja tehden liikkuminen näyttää tyylikkäältä ja vakuuttavalta, mutta suorittajan kannalta on valittu juurikin se mahdollisimman epäedullinen liikkumismuoto.
Kävellessä ehtii havainnoimaan paljon enemmän mitä ympärillä tapahtuu, kompastumisen vaara on huomattavasti pienempi ja liikkuminen on myös tehokkaampaa. Kävellessä on aikaa katsoa mihin seuraavan askeleen astuu.
Nokkelimmat saattoivat jo päätellä tämän metaforan juontavan työtapojen kehittymiseen. Maltillinen ja jatkuvan tarkkailun alla oleva muutos on aina lopputulokseltaan tehokkaampi kuin päätäpahkaa metsään juokseminen. “Kokeillaan toimiiko tämä, koska se toimi myös naapurin organisaatiossa!” -mentaliteetti johtaa väistämättä ongelmiin. Jokainen organisaatio on erilainen. Jokainen organisaatio vaatii erilaisia työmenetelmiä.
Kuinka sitten ketteryys näkyy käytännön työelämässä? Valitettavan monissa projekteissa ei osata naulata seinälle selkeitä toimintatapoja, joita kaikkien on helppo noudattaa. Valitettavan monissa projekteissa menettelytavat ovat jatkuvasti suunnittelu- ja muutostilassa. Ei ehditä kokeilemaan mitään tapaa kunnolla ja kokemukset jäävät keräämättä. Parhaat käytännöt jäävät oppimatta.
Valitettavan useat firmat ovat sokaistuneet sanan Scrum valovoimasta ja ajautuvat aina vain kauemmaksi tehokkaan kehityksen tieltä. Lopulta ne vieraantuvat tuotekehityksen todellisuudesta. Tekijät, tiimipäälliköt ja sadanpäämiehet istutetaan samaan suureen tilaan siinä toivossa, että tieto kulkisi vaivattomammin. Työkaluiksi valitaan massiivisia ja kalliita multimonitoimi-vasaraporamittanauharuuvimeisseli-työkaluja, joiden pitäisi tukea Scrumin periaatteita. Tämäkö on sitä ketterää ohjelmistokehitystä?
Lare Lekman on listannut Ketteryys.fi blogissa Scrumin tärkeimpiä asioita:
- Toimita säännöllisesti jotain
- Varmista, että toimitat korkeimman prioriteetin asiat
- Pyri parempaan jokaisessa iteraatiossa/julkaisussa
Ketteryys ohjelmistokehityksessä perustuu selkeisiin suuntaviivoihin, joita kaikki pystyvät noudattamaan. Se ei ole jatkuvasti muuttuvaa sekameteliä tai nopean näköistä sähläystä. Se on asiantuntemuksella otettuja hallittuja askelia. Jatkuvaa liikettä eteenpäin.
Kiireelliset deadlinet eivät muuta toimintatapaa tyylikkäiksi juoksuaskeliksi. “Toimita säännöllisesti jotain” ei tarkoita, että merkataan keskeneräinen taski valmiiksi. Sähläten puoliksi implementoitu done tuottaa varmasti enemmän ylimääräisiä kustannuksia kuin vähän myöhemmin kunnolla implementoitu done. Siitä myös testaus pitää huolen.
Oikeaa ketteryyttä on siis ottaa laadukkaita, tasapainoisia ja riittävän lyhyitä askeleita tavoite kirkkaana mielessä.
Suosittelemme myös:
Mikä on kun ei taidot riitä?
Ilma oli sakea, tunnelma tiivis ja noin 100 kilttiä koululaista nojautui kuuntelemaan väkeviä tarinoita myynnin ihmeellisestä maailmasta. Istuin...
Oivalluksellakin on hintansa
Jos kysymys ei ole uskomattomasta munkista, mäihästä tai tuurista, niin onnistumisilla on aina hintansa. Hinta on mahdollista maksaa etukäteen ja...
Jo vain! En ole koskaan perustanut satojen lippujen ja lappujen täyttämisestä saati lukemisesta. Super-pitkästä sähköpostistakin luen vain otsikon. Jos asia ei mahdu virkkeeseen, niin sitten se ei ole enää skoopissa.
Minä tiivistäisin ketterien menetelmien määrittelyn sananparteen ’maalaisjärki’. Yhtään lappua ei tule täyttää sen vuoksi, että jossain lukee niin. Jokaisen täytetyn lapun tulee perustua siihen, että siitä on projektille hyötyä eli lapun täyttämiseen käytetystä ajasta saadaan jotain irti.
Ohjelmistokehittäjä on taiteilija isolla T:llä. Työn alla oleva ohjelmisto on taideteos. No sitten kysyn, että miten tästä taideteoksesta edes voisi tulla hyvä silloin kun on miljardi sääntöä ja lappua jotka nujertavat taiteilijan (ohjelmistokehittäjän) luomisen tuskan heti kärkeen? Ja kun siihen vielä lätkästään hyper-monimutkainen pensseli (multimonitoimi-vasaraporamittanauharuuvimeisseli), niin mitä lopputuloksen oikeastaan edes kuvitellaan olevan?
Ohjelmistoalalla on toki monenlaisia tehtäviä, mutta jos nyt puhutaan uuden luomisesta eli ennen näkemättömästä softasta jolla on tarkoitus tehdä gillaa niin että tulee ikkunoista ja ovista, niin silloin on ymmärrettävä se, että ohjelmistokehittäjä on taiteilija ja hänen pitää antaa tehdä taideteostaan luovasti. Varsinkin meillä täällä Suomessa on sen verran rajallisesti insinöörejä käytössä, että ainoa mahdollisuutemme ylipäätäänkin on olla luova.
Omaan ketteryyteen on helppo kompastua. Jos kuitenkin näkee big picturen selkeästi, niin voi ymmärtää paremmin mitä on tekemässä.
Yksi insinöörielämän perusongelmista taitaa olla se, että kaikki pitäisi yrittää sovittaa teorioihin, oppikirjamalleihin ja prosessikuvauksiin. Eli hyvin perinteiseen insinöörin ajatusmaailmaan. Lisäksi hilavitkuttimien käyttö ja konffaaminen on vaan niin perhanan mukavaa, että se olennainen työ joskus unohtuu.
Se lienee sama pakkopaita, mistä Jussi puhui myös aikaisemmassa tekstissään.
Olen vahvasti samaa mieltä kanssasi siinä, että uuden luominen usein on pohjimmiltaan enemmän taiteen tekemistä, kuin insinööriveivaamista. Se vain pitäisi osata ymmärtää ja hyväksyä.
Ammattitestaajan kuuluttama maalaisjärki taitaa olla katoava luonnonvara nykyaikaisessa tietoyhteiskunnassa. 🙁
Mitä isommassa organisaatiossa työskennellään, sitä enemmän on erinäisten turhakkeiden lippujen ja lappujen täyttämistä. Mutta pitäähän sitä ihmisillä töitä riittää! Ohjelmistokehitystä tukevat työkalut ovat kehittyneet jo niin pitkälle, että Taiteilijallamme ns. tärkeään tekemiseen kulutettu aika on huomattavasti lyhyempi kuin kymmenen vuotta sitten. Kun tärkeää tekemistä on vähemmän, täytyy limbotilaa täyttää vähemmän tärkeällä tekemisellä e.g. lippujen ja lappujen täyttämisellä tai prosessien veivaamisella. Tämä ei kuitenkaan taida olla tietoinen ratkaisu, vaan vuosien saatossa kehittynyt toimintamalli mistä on vain hankala päästä eroon. Sehän olisikin mainiota jos nopeasti tehdyn tärkeän tekemisen aiheuttaman limbotilan täyttäisikin edelleen tärkeällä tekemisellä…
Prosessimallin yksinkertaistaminen hyödyntää resursseja odottamattoman paljon. Antin mainitsema insinööriveivaaminen ja byrokratian rattaissa pyöriminen ei varmasti palvele yhdenkään ohjelmistokehitysprojektin tarkoitusperiä. Toistaiseksi sitä vain ei vielä taideta osata ymmärtää taikka hyväksyä. Odotan haikein mielin aikakautta, jolloin Taiteilijamme saa toteuttaa itseään ilman prosessin tai putkinäköisten esimiesten lukitsemia kahleita.