Avoimuus ja läpinäkyvyys - tiimin askelmat luottamukseen

Tänään aamulla keittäessäni toimistolla aamukahvia, minulle tuli hyvin outo olo. Ei – syynä ei ole eilisillan juhlinta (kirjoittaessani tätä on tiistai) eikä edes aamusmoothieen lisätty pakuriuute, vaan se, että kaffenpuruja suodattimeen lisätessäni minulle tuli ahaa-elämys: olemmeko ME Contribytellä avoimia? Mitä se avoimuus oikeasti tarkoittaa? Nämä kysymykset saivat pontta siitä, että oli muutamia asioita, joiden tilannetta en tiennyt – ja ajattelin että ehkä minun pitää kysyä. Ja sitten pysähdyin miettimään, että jos olisimme oikeasti avoimia, niin pitäisikö minun edes kysyä?

Jos minun pitää pyytää tietoa, niin missä on ongelma?

Siinä kahvin valumista odottaessani minulle tuli vielä toinen kysymys – mitä eroa on avoimuudella ja läpinäkyvyydellä (engl.: openness ja transparency). En ollut koskaan oikein pysähtynyt miettimään, mitä näillä sanoilla tarkoitetaan. Tarkoittavatko ne samaa asiaa? Molemmat pyrkivät kyllä siihen, että organisaatiossa olisi enemmän luottamusta, mutta miten nämä käsitteet eroavat; ja miksi Scrumissa käytetään nimenomaan "openness" termiä eikä "transparent" termiä?

Jos ovi on auki, se on avoin. Jos se on lasia, sen läpi näkee.

Kun asiaa tutkii, niin virallisesti termi avoimuus määritellään niin, että se tarkoittaa ehkä yksinkertaisimmillaan sitä, että on vastaanottavainen uusille ajatuksille ja palautteelle. Läpinäkyvyydellä taas tarkoitetaan sitä, että kaikki tieto ja toiminta on saatavilla tai nähtävillä. Termit eroavatkin siis hyvin paljon toisistaan. Jos joku sanoo, että meillä on kaikki avointa, se on ihan eri asia kuin se, että jos sanoo, että meillä on kaikki läpinäkyvää. Avoimuus on asenne ja läpinäkyvyys on tila tai toimintamalli. Tietenkin voi olla myös niin, että termit ymmärtää eri tavalla, ja jos tarkoittaa läpinäkyvyyttä, voi käyttää sanaa avoimuus. Ja ehkä toisinpäinkin.

Avoimuus voi siis tarkoittaa sitä, että tiimi voi kertoa, miten asiat etenee, mitä ongelmia on, ja esimerkiksi antaa ideoiden lentää ja palautetta annettaessa ei tarvitse kenenkään pelätä. Ideoita ei reaktionomaisesti kritisoida eikä kenenkään tarvitse arastella antaa huonoa palautetta tai siis kehotusta parantaa toimintaa. Läpinäkyvyys tarkoittaisi taas sitä, että tiimi pystyy pitämään kaiken työn ja tiedon kaikkien saatavilla ja helposti löydettävissä. Se voi myös tarkoittaa sitä, että kommunikaatiota on paljon, ja suuri osa siitä on "FYI", eli pyytämättä annettua, tiedottavaa.

Läpinäkyvyys tulee ensin, avoimuus rakentuu sille

Avoimuus on ehkä myös kiinnostusta siitä, mitä muut tekevät. Voi olla niin että tekeminen organisaatiossa on hyvinkin läpinäkyvää, tieto ja tekeminen on kaikkien tiedossa. Mutta voi silti olla niin, että läpinäkyvässä organisaatiossa on ongelmia sen kanssa, että ei ollakaan avoimia.

Toisaalta, voi myös ajatella, että ihmiset voivat kokea ylimenevän liiallisen läpinäkyvyyden keinona kontrolloida omaa tekemistä. Jos tiimin tapana on kertoa kaikesta aina kaikille kaikki, miksi näin tehdään? Onko syynä tiedon jakaminen, vai kenties se, että annetaan muille mahdollisuus reagoida ja kontrolloida tekemistä? Toimiiko tällainen läpinäkyvyys luottamusta lisäävänä vai vähentävänä tekijänä?

Luottamusportaikon askelmat

Ehkä voisi ajatella, että tietyntasoinen läpinäkyvyys tarvitaan, jotta voitaisiin mennä todella arvokkaaseen ja avoimeen tiimityöhön. Ja lopputulos, kolmas askelma mihin näillä päästään, on lisääntynyt luottamus.

Mutta voi olla myös, että liiallinen läpinäkyvyys haittaa tiimiä, tulee liikaa taustahälinää ja ihmisille olo, että ei enää pysty keskittymään tärkeään, ja enkö saa hoitaa mitään ilman että kerron siitä muille. "Läpinäkyvyysaskelma" on liian korkea.

Mutta todelliseen luottamukseen ei kuitenkaan riitä pelkkä avoimuus, vaan tarvitaan myös sopivasti läpinäkyvyyttä. Eli liian vähän läpinäkyvyyttä, niin avoimuusaskelma on liian korkea.

Pitäkääpä oman luottamusportaikon askelmanne sopivan korkuisina! Avoimin terveisin Agile-rakennustarkastaja Arto

Onko tiimin kehittäminen ajankohtaista? Käy lukemassa lisää aiheesta!

Arto on urallaan nähnyt tuotekehitystä monista eri näkökulmista. Hänellä on kokemusta mm. Product Ownerin, Scrum Masterin ja tuotekehitysjohtajan tehtävistä. Niin isojen kuin pientenkin firmojen toimintatavat ovat tulleet tutuiksi. Arto rakastaa parantaa organisaatioiden oppimista sekä tuoteomistajien osaamista, ja kirjoittaa blogeja eri aiheista. Koska retrospektiivit on yksi Arton suosikkiaiheista, ovat jotkut asiakkaat antaneet hänelle lisänimen "Retromies". Vapaa-aikana Arto yrittää elää terveellisesti, ostaa mahdollisimman paljon autoja, katsoo yhä uudelleen Tähtiportti-sarjan jaksoja ja opiskelee Personal Traineriksi. Arto on kirjoittanut kirjan "OWN IT – 8 Simple Secrets of Product Owner Success". Lisää Arton ajatuksia voi lukea täältä.