Photo by Christina @ wocintechchat.com on Unsplash
Pidetäänkö lyhyt palaveri?
Ari-Pekka Piiparinen
Ari-Pekka on Memeticin toimitusjohtaja, CoachToolsin CTO ja kokenut ketterä ohjelmistosuunnittelija.
Ei pidetä, vaan annetaan tekijöille työrauha.
On vaikea keksiä asiaa mikä olisi tuhoisampaa ohjelmistosuunnittelun kannalta kuin jatkuva palaveeraaminen isolla porukalla. Ainoastaan projektien sähköpostilla ja Excelillä johtaminen voisi olla tällainen asia, mutta niistä ehkä enemmän jatkossa. Siitä ollaankin päästy jo suurimmaksi osaksi eroon projekteissa missä olen mukana.
Pahin kaikista on palaverit tulevista palavereista. Nämä turhakkeet eliminoimalla säästettäisiin varmasti kaikkien aikaa ja useimmassa tapauksessa riihikuivaa rahaa tai resursseja. Nopeaa tsekkausta tai pikaista palaveria ei ole olemassakaan. Teamsissä puhutaan yksi kerrallaan mitä on meneillään ja mitä seuraavaksi on tulossa. Yhtäkkiä neljältä henkilöltä onkin mennyt jo 4h tehokasta työaikaa Teamsin kuuntelemiseen ja riviäkään koodia ei ole syntynyt tuloksena tuotantoon vietäväksi.
"Tsekataanko nopeasti mitä ensi tiistaina käydään läpi isommalla porukalla?"
Tehdäänpä ohjelmistokehittäjälle keskimääräinen viikon palaveribudjetti. Työaikana pidetään 7,5h viitenä päivänä viikossa, mutta suoritetaan ensin hieman karsintaa.
– Slack, Teams jne. notifikaatiokeskeytykset: juuri se punainen pallo, vilahdus näytön yläreunassa mikä kiinnostaa, mutta sisältö ei usein koske itseä. Paljonkohan niiden lukemiseen menee päivässä aikaa?
– Puhelinsoitot, olkapäälle taputtava työkaveri
Olemme tältä pohjalta usein käyttäneet päivän ns. tehokkaana peliaikana viittä tai kuutta tuntia. Todellisuus on usein jopa vähemmän kuin viisi, ellei sitten venytä päivää jostain päästä ja tee ”rästihommia” => töitä mitä olisi pitänyt tehdä työaikana, mutta kun ei kerennyt palavereilta.
Palaveribudjetti
Kokemuksieni mukaan palaverit yleensä venyvät ja on harhaluuloa että hommat loppuvat tasan ennen palaverin alkua ja jatkuvat samasta pisteestä palaverin päätyttyä, joten pidetään 30min minimilukuna per palaveri.
- Daily 15 minuuttia => 25 tunnista jää viiden dailyn jälkeen 22,5h työaikaa
- Koko firman laajuinen yhteinen Teams-tuokio kerran viikossa 15 minuuttia => 22h jäljellä
- Toimitusjohtaja haluaa erikseen pitää tsekkauksen tiettyä ominaisuutta koskien että kaikki rullaa mallikkaasti 1h teams kerran viikossa => 21h jäljellä
- Työmääräarvioiden tekeminen/tarkentaminen suunnittelua varten kerran viikossa 1h => 20h jäljellä…
Photo by Jefferson Santos on Unsplash
Mitä voidaan tehdä?
Statuksien tsekkaus on monen managerin mukaan tehtävä juuri tässä ja nyt, mutta mitä sitten? Useimmille statuksille ei voida juuri siinä hetkessä tehdä mitään (muuten ne toimenpiteet olisi tehty jo). Täytyykö kaikkien oikeasti saada tämä informaatio juuri nyt? Ajaako se kaiken sen tekemisen ohi mitä on suunniteltu tehtäväksi? Useimmiten asia on ok, vaikka tiedon saisikin Teams palaverin sijaan muistiosta luettuna hiukan myöhemmin, tai vaikka seuraavan dailyn yhteydessä sovitussa 1 vs 1 keskustelussa, jos esimerkiksi Product Ownerin asiantuntemusta tai mielipidettä tarvitaan asian ratkaisemiseksi.
Jos ohjelmiston määrittelyjä on tarvetta tarkentaa jatkuvasti palavereissa suunnitellun tekemisen ohi, eikö silloin kannattaisi taklata ongelmaa ja keskittyä tekemään parempaa määrittelyä? Jos meillä on ohjelmistoprojektin hallintaan työkaluja olemassa, niin käytetään niitä työkaluja Teamsin sijaan.
"When something’s written up, people can absorb it on their own time when they have the time."
Uskon vahvasti että Friedin idea toimii hienosti itseohjautuvaan työskentelyyn pyrkivien ketterien etätiimien työtehtävien organisoimisessa. Yritän seuraavien kuukausien aikana
- Vähentää palavereihin kuluvaa työaikaa
- Tehostaa palaverikäytäntöjä esim. automatisaatiolla
- Ketteröittää tiimin toimintaa
Tässä tapauksessa tarkoitan ketteryydellä nopeampaa reagointia asiakkaiden tarpeisiin ja paremmin kohdistettua arvontuottoa yrityksen tuote- ja osaamisresursseilla.
Termit
Päiväpalaveri (engl. Daily Scrum / Daily) on yleensä 15 minuutin mittainen aikarajattu palaveri, jossa kehitystiimi tahdistaa keskinäiset työnsä ja luo suunnitelman seuraaville 24 tunnille.
Product Owner eli tuoteomistaja on ketterissä tuotekehitystiimeissä rooli, jonka vastuulla on edustaa asiakkaiden ja sidosryhmien ääntä tiimille sekä priorisoida tiimin tekemistä.