Aikaisemmassa blogissamme mietimme sitä, mitkä ovat useimmin vastaan tulevia ongelmia tiimin siirtyessä Scrumista Kanbaniin. Tässä jatko-osassa paneudumme uusiin Kanbanin sudenkuoppiin ja siihen, kuinka vältät ne helposti ja näppärästi!
Sinua mahdollisesti kiinnostaa myös:
Sileä siirtymä Scrumista Kanbaniin
Ketterät tiimit valitsevat usein toiminnanohjausmetodikseen joko Scrumin tai Kanbanin. Näistä Scrum on yleisempi, mutta kaikissa tiimeissä se ei välttämättä toimi parhaalla mahdollisella tavalla. Tässä blogissa neuvomme, kuinka vaihdat sujuvasti Scrumista Kanbaniin!
Backlog-altaassa uudet ideat kulkevat pinnalta kohti syvää päätyä
Usein backlogia ajatellaan joko suppilona tai pinona asioita, jossa tärkeimmät asiat ovat päällimmäisenä ja helposti otettavissa. Tämäkin on hyvä ajatusmalli, mutta backlogia voi ajatella myös toisella tavalla. Tulkaapa mukaan ajatusleikkiin, jossa backlog on uima-allas!
Ideoiden eutanasia – miksi se on niin vaikeaa?
Kehitettävien asioiden syöttö tuotekehitystiimille muistuttaa tietynkaltaista suppiloa. Suppilon kapea pää lähempänä tuotekehitystiimiä sisältää tuotebacklogin, ja on pääasiassa tuoteomistajan vastuulla. Se suppilon leveämpi pää, joka sisältää varhaisemmassa kehitysvaiheessa olevia ideoita, onkin mielenkiintoinen asia.
Batman lomalle – Välttäkää sankarisuorituksia ja laittakaa laatuongelma kuriin!
Kaikilla tuotekehityksessä töitä tehneillä on varmasti muistissa projekteja ja hankkeita, joissa jossain vaiheessa oli ”kriisi” ja jouduttiin haalimaan kasaan task-forceja ja superyksilöitä joko korjaamaan jotain pahaa ongelmaa tai jopa taklaamaan suurempaa laatuongelmaa tai bugimassaa. Tällaiset ”buginkorjausrypistykset” muodostuvat helposti tilanteiksi, joissa työtunteja ei enää tarkasti lasketa, vaan superyksilöt tekevät ympäri kellon töitä ja ”pelastavat” tilanteen.
SAFe+JIRA = täydellinen pari ketterään kehitykseen ja toiminnanohjaukseen?
Ketterissä tuotekehitystiimeissä on optimaalisesti 4-6 jäsentä, jolloin työ säilyy tehokkaana. Kun kehitettävä ratkaisu on isompi, tiimiä ei kannata suurentaa, vaan lisätä tiimien määrää. Kuinka koordinoida tilannetta, kun tiimejä alkaa olla useampia?
Tuoteomistaja on yksi tuotekehityksen merkkihenkilöistä!
Joskus on sellainen fiilis, että tuoteomistajuuden vaikutusta lopputulokseen ei organisaatioissa täysin ymmärretä. On ehkä hankalaa perustella, miksi yhden ei-kehittäjä-ihmisen pitäisi olla liitettynä aika täysipäiväisesti tiimin kylkeen. Jos teidänkin organisaatiossa tämä asia tuntuu hankalalta perustella muille, toivon, että saatte tästä blogista vähän ajatuksia. Blogissa nimittäin kerron, miksi tuoteomistajuudella on suuri vaikutus. Product Ownerin suuren vaikutusvallan ymmärtää, kun oivaltaa, miten ketterä tuotekehitystiimi toimii.
If it works, fix it! – Refaktorointi kannattaa aina
Refaktorointi, eli toimivan koodin muokkaaminen, on monessa tuotekehitysorganisaatiossa vähän vaikea asia. Usein karsastetaan ajatusta käyttää aikaa jo toteutetun koodin muuttamiseen, ja voimavarat laitetaan mieluummin uuden toiminnallisuuden tekemiseen. Tässä blogissa kuitenkin kerromme, miksi refaktorointi kannattaa.
Karvaa, älä arvaa! – Ennaltaehkäise bugit ja vältä turhat arvailut
Bugien estimoinnin sijaan projektin kannattaisi yksinkertaisesti seurata bugien inflowta ja outflowta. Lisäksi olisi hyvä ajatella, että tehtäisiin hyvää laatua mahdollisimman vähällä bugimäärällä – ennaltaehkäistään, eli siis karvataan! Bugien ennaltaehkäisy säästää aikaa ja auttaa myös välttämään turhat arvailut.
Huonot kokoukset ovat työelämän syöpä
Kokoukset ovat osa nykyistä työelämää. Niissä keskustellaan ja päätetään asioita ja niitä ilman ei vaan tulla toimeen. Aika usein kokouksissa on kuitenkin paljonkin toivomisen varaa. Tässä blogipostauksessa kerromme, miksi.
Yksinkertaista, rakas Watson – Järjestelmällinen ongelmanratkaisu auttaa selvittämään mysteeribugit
Tuotekehityksessä työskentelevien olisi hyvä osata käyttää järjestelmällisen ongelmanratkaisun keinoja, sillä niiden avulla esimerkiksi mysteeribugien selvitys helpottuu ja nopeutuu huomattavasti. Ongelmanratkaisun metodiikkaa onkin syytä opetella ja harjoitella – se on todellista salapoliisityötä!
Alkukankeutta? Näin käynnistät projektisi vauhdikkaammin.
Suuren projektin käynnistyksessä on valtava työ. Ponnistuksissa on monta sudenkuoppaa, jotka hidastuttavat helposti prosessin aloittamista. Mitä isompi projekti, sitä tärkeämpää olisikin käyttää ulkoista apua!