Tiimiakatemia on Jyväskylän Ammattikorkeakoulun yrittäjyyden huippuyksikkö

SCRUM: Twice the work in half the time

Kirjoitettu 15.12.16
Esseen kirjoittaja: Mikko Tammilehto
Kirjapisteet: 3
Kirja: SCRUM: Twice the work in half the time
Kirjan kirjoittaja: Jeff Sutherland
Kategoriat: 2.2. Tiimityön taidot ja työkalut, 3.2. Yrittäjän taidot ja työkalut, 4. Johtaminen, 4.2. Johjajan / valmentajan taidot ja työkalut

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Aiemmin keväällä oli tiimimme kesken ollut puhetta tästä upeasta projektinhallintatyökalusta, eniten ääntä siitä oli pitänyt Joona. Päätimme kevään mittaan ottaa käyttöön tämän työkalun oman tiimimme projektien etenemisen seuraamisessa. Luulimme tietävämme, mitä teemme, mutta todellisuus tulisi valkenemaan joillekin meistä täysin toisella tavalla. Lähtölaskenta tulevaan viisauteemme alkoi, kun Joona otti yhteyttä Reaktor -nimiseen yritykseen, joka kaiken muun tekemisensä ohella järjestää myös ScrumMaster -koulutuksia. Muutama henkilö tiimistämme ilmoittautuikin koulutukseen, tavoitteena oppia ja ymmärtää paremmin sekä syvällisemmin Scrumin toimintaa, jotta voisimme myöhemmin tiimimme kanssa kehittää omaa yhteistä tekemistämme tehokkaammaksi.

 

Kun aloitimme tiimin kanssa Scrumin Joonan toimiessa Scrum Masterina, teimme aluksi ruututaulukon, jonne merkattiin jokaisen nimi kolmeen eri kohtaan; To Do, Doing, Done. Se oli hyvä alku ja näin tehdään myös oikeassa Scrumissa. Hyvästä alusta huolimatta, emme tienneet yhtään, mihin olimme ryhtymässä, sillä vaikka Scrum on helppo ymmärtää ja viedä käytäntöön hieman soveltaen, on oma soveltaminen turhaa sähellystä, eikä sitä silloin voi kutsua Scrumiksi. Scrumin toiminta onkin helppo ymmärtää, mutta vaikeaa osata hyvin.

 

Teoriapohjana tiimimme ”Scrumissa” meillä oli tieto tästä samaisesta kirjasta, josta kirjoitan nyt esseetä, eli ”Scrum – The Art of Doing Twice the Work in Half the Time”.

 

Scrum on projektinhallintatyökalu, jolla yritetään saada tiimeistä paras mahdollinen potentiaali irti, sekä saamaan ryhmä toimimaan saumattomasti kohti yhteistä päämäärää, joka Scrumissa on aina joko lopputuote, tai lopullisen tuotteen käytettävä osa, eli Scrumin termeillä ”product increment”. Itse ajattelimme Scrumin olevan jotain ihan muuta, eikä siksi tiimin kanssa tekemämme Scrum ollut lähelläkään oikeaa versiota, vaan pikemminkin pitkälle muokattu ja ”rikottu” versio siitä. Otimme Scrumista joitain työkaluja käyttöön, mutta emme tehneet sitä aktiivisesti. Lähinnä meidän versiomme siitä oli vain jokaisen henkilökohtaista seurantaa post-itien avulla, joka oli tavallaan hyödytöntä, koska harvemmin intolaisia näkyi toimistolla ylipäätään. Teimme siitä vain sen osan, jonka katsoimme sopivan meille. Jälkeenpäin ajateltuna koko sähellys vaikuttaakin omalla tavallaan haaskatulta ajalta, koska jos nyt ollaan ihan rehellisiä niin ei koko homma oikein toiminut tai luistanut kuten olimme sen ajatelleet.

 

 

Scrumin toiminta käytännössä

 

Scrumin ytimessä on selkeät ja ajallisesti rajatut työvaiheet. Työvaiheet ja kaiken ajan rajallisuus on tässä huikeassa ryhmätyön muodossa ytimessä siinä mielessä, että se pakottaa ratkaisuihin ja tehokkuuteen. Jokaiselle vaiheelle on määritelty ennalta aika, jossa pysytään ilman poikkeuksia. Ilman rajattua aikaa tai jos ajoista rupeaa lipsumaan, kannattaa unohtaa Scrumin tekeminen kokonaan ja siirtyä tekemään jotain muuta, koska silloin se ei toimi.
Alkuvaiheessa jokaisella ryhmällä käy varmasti niin, että eri työvaiheissa aika loppuu kesken. Se ei haittaa, koska Scrum-ryhmän tavoite tuotteiden tekemisen lisäksi on opetella tekemään Scrumia kunnolla. Scrumin tekeminen kunnolla täytyy opetella tekemällä siksi, että tuotteita pystytään tekemään entistä tehokkaammin ja varmemmin, jolloin kaikki muu tekeminen organisaatiossa helpottuu, asiat sujuvat jouhevasti ja kokonaisvaltainen luottamus organisaation toimintaa kohtaan kasvaa. Scrumissa on tietysti myös jokaisen sprintin jälkeen ”jälkimotorola”, jossa puidaan mennyttä sprinttiä ja keskustellaan siitä, mitä siinä pitäisi kehittää.

 

 

Sprintin tavoite

 

Scrumissa jokaisen sprintin tavoitteena on saada tehtyä yksi suoraan käyttöön vietävä osa tuotteesta, jota kutsutaan nimellä Product Increment. Sprinttiin valitaan aina vain sen verran tehtävää, joka keretään tekemään sprintin rajatun ajan puitteissa.

 

 

Sprintin pituus

 

Sprintin hyvä maksimipituus on neljä viikkoa. Sprintit voivat toki olla lyhyempiäkin, esimerkiksi kaksi viikkoa. Sprintin pituus myös määrittelee sen, kuinka pitkät sprintin sisällä tehtävät Scrumiin liittyvät asiat ovat. Esimerkiksi neljän viikon sprintissä Planning -vaiheeseen on hyvä varata aikaa kahdeksan tunnin verran. Sprint Review kestää neljän viikon sprintissä neljä tuntia ja Sprint Retrospective kolme tuntia. Ainoa tapahtuma, jonka aikaan ei vaikuta sprintin pituus, on Daily Scrum. Sen pituus on aina viisitoista minuuttia.

 

 

Sprint Planning: 1 & 2

 

Scrum alkaa sprintin suunnittelusta. Se tapahtuu, kun Product Owner (esimies, asiakas, tuotepäällikkö tai joku muu ihminen, joka kuuluu Scrum -ryhmään) esittelee Product Backlogin. Sprint Planning on aikarajallinen tapahtuma, kuten kaikki muutkin Scrumin tapahtumat. Product Backlog on lista tai joku muu kuvaus tuotteesta, joka tuo ilmi sen, mitä kaikkea tuotteeseen kuuluu ja sisältyy. Sprint Planningissa valitaan Product Backlogilta tehtäviä toiselle listalle, jota kutsutaan Sprint Backlogiksi. Sprint Backlog on käytännössä se lista tehtäviä, joista yhden sprintin aikana Scrum -ryhmä ajattelee, että saadaan tehtyä ja valmiiksi. Kun sopiva määrä tehtäviä on valittu Sprint Backlogille, pilkkoo ryhmä nämä tehtävät seuraavaksi niin pieniin osiin, että jokainen osa vaatii vähemmän aikaa, kuin yhden päivän työ. Hyvä asia on myös verrata tulevaa sprinttiä ja sen tehtävämääriä vanhojen kanssa, jotta saadaan mahdollisesti tarkempaa kuvaa siitä, millä tahdilla täytyy työskennellä. Myös tällä tavoin Scrumin tekeminen oikein kehittyy.

 

 

Osa 1: Scoping

 

Sprint Planning on kaksiosainen työvaihe, jossa Product Owner esiintyy vain ensimmäisessä osassa. Product Ownerin roolina on kertoa Scrum -ryhmälle uusimmista muutoksista asiakaskentässä, uusimmista vaatimuksista ja kaikesta, mikä tuotteeseen liittyy. Näin voidaan ketterällä tavalla vastata muutoksiin, kun uutta sprinttiä suunnitellaan. Ensimmäistä vaihetta kutsutaan nimellä Scoping.

 

Scopingiin sisältyy myös viimeisen viiden sprintin tarkastelu, jossa lähinnä tarkastellaan niiden työmääriä ja tehtyjen tehtävien määrää, jotta saadaan selville Scrum -ryhmän oma ”nopeus” työssä. Tämän perusteella tehdään myös valintoja sen suhteen, kuinka monta tehtävää Product Backlogilta otetaan tällä kertaa työstettäväksi. Scopingissa Scrum -ryhmällä on mahdollisuus kysyä tarkentavia kysymyksiä tuotteeseen ja sen osiin liittyen Product Ownerilta. Scopingin lopuksi uudet tehtävät on valittu, ja Product Owner usein poistuu huoneesta.

 

 

Osa 2: Plan

 

Toisessa osassa Scrum -ryhmä pilkkoo isot tehtävät pieniin osiin. Näiden pienten osien täytyy olla niin pieniä, että niiden tekemiseen menee vähemmän, kuin yhden päivän työaika. Seuraavaksi ryhmä tarkastelee vielä kerran edellisiä sprinttejä ja niiden työmääriä sekä nopeuksia, jotta saataisiin kirkkaampi kuva ryhmän tämän hetkisestä vauhdista ja potentiaalista saada tehtävät tehtyä. Tässä vaiheessa on vielä mahdollista pudottaa tehtävälistalta jotain pois, jos ryhmä on yhtä mieltä siitä, ettei kaikkea saada tehtyä tulevalla sprintillä. Lopuksi ryhmä esittelee oman listansa vielä kerran Product Ownerille, joka ei välttämättä osallistu Planningin toiseen vaiheeseen. Siitä huolimatta, hänen kannattaa olla vähintäänkin puhelimen päässä, jotta ryhmä voi varmuuden vuoksi kysyä jotain uutta mieleen tullutta asiaa.

 

 

Daily Scrum

 

Scrumin perusajatuksena on tuotteiden tekeminen nopeasti ja tehokkaasti. Scrumia täytyy siksi tehdä joka päivä, mutta myös sen takia, että ryhmä kehittyy Scrumin tekemisessä. Scrum on helppo ymmärtää, mutta äärimmäisen vaikea osata. Tämän seuraavan osan nimi on juuri siksi Daily Scrum, koska se on tehtävä joka päivä. Se on todella tehokas viidentoista minuutin tuokio, jonka aikana jokainen seisoo ja jossa käydään läpi edellisen päivän tekemisiä. Daily Scrum on se syke, joka pitää tiimin koko ajan kartalla siitä, mitä on tapahtunut, mitä tapahtuu ja mitä muutoksia tai muita asioita, jotka liittyvät olennaisesti käsillä olevan Incrementin tekemiseen on tullut työn aikana ilmi ja kuinka siihen suhtaudutaan. Tämä on myös tärkeä työvaihe siksi, koska jos tulee jotain olennaisia muutoksia, niihin voidaan keksiä ratkaisuja jo samana päivänä yhdessä. Daily Scrumissa jokainen ryhmän jäsen jakaa myös nämä kolme asiaa:

 

– Mitä olen tehnyt sitten viime Daily Scrumin?
– Mitä teen ennen seuraavaa Daily Scrumia?
– MItkä asiat hidastavat tai estävät minun toimintaani?

 

Myös kaikki muu informaatio, jota ryhmän jäsenet katsovat hyödylliseksi jakaa, jaetaan tässä tilaisuudessa. Kun viisitoista minuuttia on kulunut, on Daily Scrum ohitse. Lisäaikaa ei myönnetä myöskään tässä.

 

 

Sprint Review

 

Kun sprintti kiihtyy kohti loppuaan, on Sprint Review’n aika. Tämä on se työvaihe, jossa katsotaan taaksepäin ja käydään läpi asioita, joita sprintin aikana on tehty. Tässä vaiheessa myös katsotaan, mikä on projektin tilanne kokonaisuudessaan ja kuinka paljon tekemistä vielä on, jotta koko tuote olisi valmis.

 

Tässä tilaisuudessa ryhmä esittelee oman sprinttinsä tulokset: Mitä saatiin aikaan ja mitä mahdollisesti jäi tekemättä. Jotkut ryhmät esittelevät työnsä tulokset yksinkertaisesti käytettävällä demolla, riippuen aina tietysti tuotteesta. Voi olla, että tässä vaiheessa demo on jo sellainen, jota asiakas voi jo käyttää ja antaa palautetta sen toimivuudesta.

 

Tähän tilaisuuteen voi osallistua organisaatiosta muitakin ihmisiä, jotta kaikki näkevät missä mennään. Review’n tarkoitus ei olekaan yksin demon esittely, vaan kokonaisvaltainen esitys kaikille, jotta kaikki tietävät missä mennään juuri tällä hetkellä tuotteen kanssa. Review on ennen kaikkea Scrum -ryhmän oma ”myyntitilaisuus”, koska kaikki, mitä Incrementistä esitellään, on pitchattava jollain tapaa. Ryhmä saa itse tietysti keksiä itselleen luontevimman tavan.

 

 

Sprint Retrospective

 

”Jälkimotorola”. Ryhmän katseet kääntyvät jälleen menneeseen sprinttiin. On helppo ymmärtää, miksi tätä tehdään, koska aina on jotain kehitettävää ja aina voi oppia jotain uutta itsestään ja tekemisistään. Tässä vaiheessa ennen kaikkea tärkeää on reflektointi ja oman toiminnan kehittäminen. Tähän on olemassa hyvä tarkistuslista Scrumin eri vaiheita ajatellen. Pääasia tässä on kuitenkin oman toiminnan syvempi ymmärtäminen ja ryhmän kapasiteetin tunnistaminen. Retron täytyisi myös kohottaa työryhmän moraalia ja juhlistaa mennyttä sprinttiä. Hyvä henki luo hyvää tekemistä! Kuitenkin, kaikki mitä tässä tehdään, täytyy olla jotain konkreettista ja käytäntöön vietävää seuraavaa sprinttiä ajatellen. Sitten se tarkistuslista:

 

– Olemmeko päättäneet kehityskohteemme? Ovatko ne konkreettisia ja käytettäviä?

– Mitä päätimme viime kerralla? Onko näitä asioita tehty? Mitä opimme niistä?
– Täytyykö meidän päivittää sopimiamme työskentelytapoja?
– Voimmeko parantaa työskentelytapojamme Planningissa?

– Kuinka tyytyväisiä olemme Product Backlogin tehtävien kuvauksiin?
– Kuinka ennustettavaa työskentelynopeutemme on? Mistä mahdolliset erot nopeudessa johtuvat?
– Kuinka voisimme saada Retrospectivestä vielä hyödyllisemmän?

 

 

Scrumin Roolit

 

Scrumissa jokaiselle henkilölle on määritelty tarkat roolit, joihin jokaisen tulee keskittyä. Vaikka kyseessä onkin ketterän työskentelyn ja ongelmanratkaisun metodi, on tarkat roolit suunniteltu ainoastaan auttamaan koko prosessia ja siksi niistä täytyy pitää kiinni. Eri roolit eivät siis suinkaan tarkoita millään tapaa hierarkkista järjestelmää Scrumin sisällä, koska koko metodin idea on siinä, että kaikki ovat samanarvoisia ja assosiaatioesteet on mahdollisimman pitkälle minimoitu.

 

 

Product Owner

 

Tämä rooli on koko Scrum -ryhmän ”linkki muualle maailmaan”. Hän pitää huolen siitä, että koko tiimin panostukset ovat oikeasti hyödyllisiä ja merkityksellisiä. Hän on omalla tavallaan Development Teamin ”asiakas”, koska hän toimii asiakkaiden kanssa, kuuntelee heitä ja tuo kaiken tarvittavan informaation muun ryhmän tietoisuuteen.

 

Viime kädessä tämä henkilö päättää, onko tuote tai sen osa valmis esiteltäväksi ja käytäntöön vietäväksi, eli suomeksi sanottuna valmis tuotantoon. Hän siis toimii koko ryhmän bisnesaivoina ja -ajattelijana ja siksi priorisoi ryhmän tekemisiä sitä kohti, mikä on juuri nyt haluttua tavaraa. Ja jotta kaikkien yhteiselo olisi vieläkin sujuvampaa, hän vastaa muun ryhmän kysymyksiin ja kirkastaa kaiken jargonin oikeaksi puheeksi ja kirjoitukseksi, jotta ryhmä varmasti tietää mitä tekee.

 

 

Development Team

 

Devaajat ovat se ryhmä, joka tekee kaiken ”oikean” työn. Yhdessä muun tiimin kanssa, he suunnittelevat sprintin alussa, mitä he valitsevat tällä kertaa töikseen Product Backlogilta. Nämä ihmiset ovat se tehdas, joka tekee kaikki tuotteen osaset valmiiksi, jotta lopputuote toimii ja saadaan markkinoille. Heidän roolinsa on myös auttaa Product Owneria kertomalla hänelle aikatauluja siitä, kuinka kauan minkäkin osan tekemiseen menee. Tämä ryhmä on se, joka päättää, montako tuotteen osasta keretään tekemään tämän sprintin aikana. He myös suurimmilta osin päättävät, mitkä ovat tämän sprintin tavoitteet ja mikä on valmiin määritelmä.

 

Tässä ryhmässä on monenlaista osaamista ja erilaista tietoa, jota jaetaan jatkuvasti keskenään. Ryhmä organisoituu itsenäisesti tekemään asioita keskenään, hyödyntäen jokaisen tietotaitoa yhteisten tavoitteiden saavuttamiseksi. He myös jatkuvasti pyrkivät oppimaan uutta ja parantamaan yhteisiä työskentelytapojaan tehokkaammaksi.

 

 

Scrum Master

 

Äkkiseltään luulisi, että Scrum Master on vain puuhastelija, joka hieman juttelee Scrum -ryhmän ja muiden ihmisten kanssa Scrumista ja sen toiminnasta ja loput ajasta keittelee ja juo kahvia taukohuoneessa. Tämä mielikuva kuitenkin romuttuu nopeammin, kuin kiinalainen olympiavoittaja kärähtää kielletyistä aineista, astuessasi hetkeksi Scrum Masterin saappaisiin edes mielikuvituksessasi.

 

Scrum Masterin työtä on helppo ylenkatsoa, jos ei tiedä, mitä kaikkea siihen kuuluu. Työ on haastavaa juuri siksi, että Scrum on helppo metodi ymmärtää teoriassa, mutta vaikea osata ja hallita käytännössä. Scrum Masterin rooliin odotetusti kuuluu Scrumin toiminnan varmistaminen ja sen aikataulujen noudattaminen. Hän toimii Scrum -ryhmän valmentajana kohti parempaa ja tehokkaampaa työskentelyä, koska hän vaalii Scrumia kuin äiti vastasyntynyttä lastaan. Hänen rooliinsa voi kuulua myös useamman Scrum -ryhmän samanaikainen valmentaminen, joka tekee työstä entistä hektisempää.
Scrum Masterin työn ytimessä on rikkoa rajat ja luoda yhteishenki uudenlaiselle tekemiselle Scrumin kautta. Hänen ainoa tarkoituksensa on fasilitoida Scrumia ryhmänsä toiminnan edistämiseksi ja pitää ryhmä siinä mielessä kurissa, että sen sääntöjä noudatetaan. Scrumin toimivuuden lisäksi hänen täytyy suojella Scrum -ryhmää ulkoisilta ärsykkeiltä ja häiriöiltä, kuten esimiehiltä, jotka mahdollisesti tulevat ”lainaamaan yhtä devaajaa nopeasti”, ”kysymään yhtä juttua” tai jolla on ”yks nopee pikku homma”. Tämän tapahtuessa Scrum Master sanoo ”voi voi, mene kysymään Product Ownerilta”, joka neuvottelee asian oikeasta tarpeellisuudesta verrattuna siihen, mitä ryhmä juuri tällä hetkellä tekee.

 

Scrum Master auttaa myös Product Owneria muotoilemaan Product Backlogia selkeämmäksi, jotta muulla ryhmällä olisi myöhemmin helpompaa ja nopeampaa valita tehtävät työt selkeiden ohjeiden vuoksi.

 

Scrum Masterin tulee myös ymmärtää, mitkä ovat kullakin hetkellä ryhmän kehityksen kohteet Scrumia ajatellen, jotta hän voi fasilitoida Scrumia sitä mukaa kehittävämmäksi ja painottaa joitain tiettyjä asioita enemmän. Mitä siis ikinä Scrum Master tekeekin, kuuluu sen olla vain jna ainoastaan Scrumin toimintaa ryhmän sisällä kehittävää työtä.

 

 

Käytännön kokeilu

 

Koulutuksessa toteutimme tietenkin mini-scrumin, eli käytännön pikakokeilun siitä, miten scrum toimii. Käytimme kaikkia Scrumin periaatteita kouluttajan esittäessä asiakasta. Asiakas oli lelufirma, joka halusi uuden lelun markkinoille. Saimme häneltä erilaisia vaatimuksia siitä, minkälainen lelun tulisi olla. Lelulle oli erittäin tarkat kriteetit, mutta asiat muuttuivat myös jatkuvasti. Saimme tehtäväksemme tehdä sellaisen lelun, joka vastasi mahdollisimman paljon vaatimuksissa esitettyjä kuvauksia.

Avainasemassa tässä oli asiakkaan rooli. Asiakkaalta täytyy aina tietenkin kysyä, mikä hänelle on tärkeää. Tässä tapauksessa Product Owner hoiti sen asian.
Ennen kuin huomasimmekaan, olimme melkein pulassa. Deadlinet puskivat päälle ja meillä oli mahdottoman paljon tehtävää. Valitsimme Sprint Backlogille kuitenkin aina sopivan määrän tavaraa, jotta kerkesimme tehdä kaiken yhden sprintin ajalle valitun työn. Product Backlog ei kuitenkaan anna armoa, joten meidän oli pakko kiristää tahtia saadaksemme lelun valmiiksi. Kysyimme asiakkaalta, mitkä olivat tärkeimpiä asioita ja päätimme tehdä ensin ne. Kaikki muu olisi siis vain plussaa. Juuri se on Scrumin ydin; olla yhteydessä asiakkaaseen, mutta tehdä työ silti tehokkaasti ja hyvin. Scrum myös on rehellinen siinä mielessä, että se mitä ei kerkeä tekemään määrätyssä ajassa jää automaattisesti pois lopputuotteesta. Asiakkaan on myös valittava ja oltava selkeä sen kanssa, mitä hän tuotteelta haluaa. Hän ei voi vaan lyödä rahoja tiskiin ja odottaa mahdottomia. Asiakkaalla on suurin vastuu omasta tuotteestaan, jolloin se täytyy tuntea läpikotaisin. Scrum ja Scrum -ryhmä on vain apuna toteuttamassa asiakkaan toiveita mahdollisimman tehokkaalla tavalla. Juuri siksi se on niin hieno systeemi, koska se pakottaa rehellisyyteen.

 

Jälkiviisaus

 

On niin helppoa olla jälkiviisas. Ehkä se on vain sitä, että jälkeenpäin näkee uuden informaation valossa sen, mitkä kaikki asiat olisivat voineet olla paremmin myös meidän tiimillä, jos olisimme tehneet Scrumia niinkuin sitä kuuluisi tehdä. Olen vakuuttunut tämän työskentelymetodin toimivuudesta, kunhan kaikki sen osaset ovat laadukkaita. Jos organisaatiossa ei ole ennen käytetty Scrumia, alkaa kaikki silloin tietysti Scrum Masterista, heti kun päätös Scrumin käyttöönotosta on tehty. Hyvän Masterin lisäksi tarvitaan myös tietysti asiansa osaava Development Team. Scrum Master auttaa myös Product Owneria hänen roolissaan, jotta hän ymmärtäisi ja sisäistäisi sen.

 

Tiimissämme on niin monta henkilöä, että olisimme voineet muodostaa kaksikin Scrum -ryhmää, kummallakin omat Masterit ja Product Ownerit. Oppimisen lisäksi osia oltaisiin voitu vaihtaa tietyin väliajoin oppimisen merkeissä, vaikka tämä ei ehkä muualla olekaan kovin yleistä.

 

Kuinka nopeasti ja tehokkaasti olisimme saaneetkaan esimerkiksi Rakettipäivät järjestettyä, jos kaksi Scrum -ryhmää olisivat tehneet sitä yhteisestä Product Backlogista, valiten työstettäviä asioita omille Sprint Backlogeilleen? Tietysti tulokset olivat hyviä jo ilmankin sitä, mutta olisimme varmasti säästäneet ainakin jonkin verran päänvaivaa, kun olisimme laittaneet itsellemme kunnon aikapaineen ja sitä kautta kurinalaisuuden selvittää asioita heti kuin mahdollista. Toisaalta minusta taas tuntuu, että kaikki tiimimme jäsenet eivät olisi valmiita olemaan yhdessä tekemässä asioita yhteistä päämäärää kohti joka päivä, koska tiimimme on niin hajanainen ja yksilöön keskittyvä. Se vaatisi suuria asennemuutoksia ja uudenlaista ajattelua, sekä johtajuutta pitää sitä yllä. Vaikein asia on varmaan vakuuttaa porukka edes kokeilemaan sitä täysiä muutaman viikon ajan niin, ettei joltakulta lopu kärsivällisyys ja usko siihen, mitä teemme. Onhan se jo tässä vaiheessa selvää, että uusien tapojen opettelu on ihmiselle yksi vaikeimmista asioista ja se vie kaiken lisäksi niin paljon aikaa. On helppoa aina palata tuttuun ja turvalliseen uuden sijasta, sillä vanhaan voi luottaa, mutta uudesta maailmasta ei ole mitään takeita.

 

Jälkeenpäin on tietysti aina helppoa sanoa ja ajatella, kuinka sulavasti asiat menisivätkään teoriassa, mutta käytäntö on aina vaikeampaa ja kinkkisempää, ollaan me ihmiset niin vaikeita otuksia.

Keskustele artikkelista

Kirjoita kommentti

Kirjoita allaoleva koodi viereiseen kenttään roskapostin suodattamiseksi, kiitos!