Jos yksi tiimiläisesi jäisi tänään bussin alle, rampauttaisiko se koko tiimin toiminnan?

Jos yksi tiimiläisesi jäisi tänään bussin alle, rampauttaisiko se koko tiimin toiminnan?

Tätä (toivottavasti) hypoteettista tilannetta kutsutaan ”bussifaktoriksi”.

Sillä testataan, kuinka haavoittuvainen tiimi on.

Pahimmillaan kriittinen tieto on vain yhden ihmisen takana. 

Se voi aiheuttaa isoja ongelmia.

Tästä esimerkin kertoo ohjelmistoarkkitehti Marko Pukari:

”Vuosia sitten olin eräässä projektissa scrum-masterina. 

Sen liidinä toimi erinomainen devaaja. 

Hän tunsi kehitettävän tuotteen kuin omat taskunsa. 

Koska liidi oli taitava kääntämään bisnesongelmat teknisiksi ratkaisuiksi, hän edusti tiimiä tuotekehityskokouksissa bisnespuolen kanssa.

Siellä luodun suunnitelman mukaan hän sitten ohjeisti tiimiä.

Mutta kerran liidi jäi lomalle. 

Sinä aikana eräs toinen devaaja sai hommansa valmiiksi ja tuli kysymään minulta seuraavaa tehtävää. 

Sanoin, että mennään katsomaan taululta. Osoitin listan ensimmäistä kohtaa. 

-Ota vaikka tää.

-Öö, en tiedä yhtään, miten toi pitäis toteuttaa. 

Osoitin seuraavaa.

-No, entäs tää?

-Ei mitään hajua. Kysytään liidiltä.

Katsoin häntä epäuskoisena.

-Se on lomalla vielä viikon. 

Kävimme koko taulun listan läpi. Sama lopputulos. 

Sitten kyselin muilta tiimiläisiltä. Paljastui, ettei kukaan tiennyt, miten edetä.

Hommat olisivat jäissä liidin loman loppuun asti. Se tarkoitti kallista käsien päällä istumista.

Tajusimme, että meillä on iso ongelma. 

Kun liidi palasi, pidimme tiimin kesken hyvässä hengessä retrospektiivin. 

Kaikki olivat samaa mieltä: tilanne on kestämätön. 

Liidikin ymmärsi heti, mikä on tiimin ja kokonaisuuden edun mukaista.

Siltä seisomalta muutimme työskentelytapoja. 

Liidi siirtyi kehittämään tuoteominaisuuksia, ja kukin devaaja vuorollaan pääsi edustamaan koko tiimiä bisnespuolen suuntaan. 

Hetkellisesti siirtymävaihe hidasti projektin etenemistä, mutta lopulta pääsimme takaisin aikatauluun.

Muutos lisäsi selvästi tiimin toimintakykyä.

Ja itsevarmuutta. Nimittäin jokainen devaaja oppi kääntämään bisnesongelmat teknisiksi ratkaisuiksi ja tiesi, missä kokonaisuuden tasolla mennään. 

Ja kun liidi ei enää kantanut harteillaan korvaamattomuuden painolastia, hän saattoi myöhemmin irtautua muihin tehtäviin talon sisällä.”

Seuraa meitä Linkedinissä niin tiedät aina, mitkä ovat ohjelmistokehityksen toimivimmat käytännöt juuri nyt.

Tuntuuko, että...

 …teidän softakehitystiimissä sekä palautteen antaminen että vastaanottaminen on vaikeaa?

Tilaa ilmainen miniopas tilanteen ratkaisemiseksi tästä:

    Kun tilaat oppaan, liityt samalla uutiskirjeemme tilaajaksi, ja saat lisää inhimillisen johtamisen vinkkejä. Voit poistua listalta koska vain.

    eNPS-mittaus perustuu Fred Reichheldin kehittämään Net Promoter Score -mittariin, jolla alunperin tutkittiin yritysten asiakaskokemusta ja asiakastyytyväisyyttä. Myöhemmin sitä on alettu käyttää myös työntekijätyytyväisyyden tutkimiseen (e niin kuin employee + NPS).

    Näin mittaus tehdään.

    Kysymme työntekijöiltämme kerran kertaa vuodessa, että “kuinka todennäköisesti suosittelisit työpaikkaasi ystäville tai tutuille asteikolla 0-10?”. Sen jälkeen pyydämme tarkennusta avoimella kysymyksellä: ”mistä syystä annoit tämän tuloksen?”.

    Niitä, jotka antavat luvuksi 9 tai 10, kutsutaan suosittelijoiksi. Niitä, jotka antavat luvuksi 0-6, kutsutaan kriitikoiksi.

    eNPS-tulos lasketaan vähentämällä suosittelijoiden suhteellisesta prosenttiosuudesta kriitikoiden suhteellinen prosenttiosuus. Muut vastaukset saavat arvon 0.

    Mittarin tulokset voivat olla mitä vain -100 ja +100 väliltä. Yli nollan nousevat tulokset ovat tyydyttäviä. +10 ja +30 välillä olevia tuloksia pidetään hyvänä, ja yli +50 olevia tuloksia pidetään erinomaisena.