Agile Toimitus 1x1: Yleiskatsaus, parhaat käytännöt ja esimerkit

Kaikki puhuvat “Agile Deliverystä”, ja siksi haluat nopean yleiskatsauksen, joitain esimerkkejä ja parhaita käytäntöjä? Löydät ne tästä artikkelista.

Agile-toimitus on menetelmä, jolla tuotetaan arvoa asiakkaille ja sidosryhmille käyttäen ketteriä periaatteita ja käytäntöjä.

Agile-toimitus perustuu iteratiivisen toimituksen ajatukseen eli tuotteen tai palvelun vaiheiden esittelyyn varhaisessa vaiheessa ja usein sekä asiakaspalautteesta ja -tiedoista oppimiseen parantamisen ja mukauttamisen mahdollistamiseksi.

Agile Delivery ei ole sama asia kuin “Waterfall Delivery”, joka on perinteinen tapa luoda arvoa, jossa suunnittelu, konseptointi, kehitys, testaus jne. suunnitellaan etukäteen ja käsitellään sitten peräkkäin.

Usein kuulee, että ketterällä tiimillä on valtava “Backlog” eli tehtäväjono, joka hallitsee seuraavia kuukausia. Ja tätä kutsutaan usein “Agile Waterfall Deliveryksi”. Haluan kuitenkin selventää, että “Agile Waterfall Deliveryä” ei ole olemassa. Ja jos joku väittää käyttävänsä sitä, silloin yhdistetään asioita, jotka eivät kuulu yhteen.

Agile Toimituksen perusteet

Agile-toimituksessa on kolme pääperiaatetta, jotka sinun on ymmärrettävä ja sovellettava:

• Toimita työtehtäviä aikaisin ja usein: Varmista, että kaikki ymmärtävät, että arvoa syntyy vasta, kun asiakkaalla on jotain hyödyllistä käsissään. Kaikki, mitä ennen sitä tapahtuu, aiheuttaa kustannuksia eikä luo arvoa. Riippumatta siitä, mitä työstetään, se on “valmis” vasta, kun asiakas voi todella käyttää sitä. Näin ollen tiimien tulisi aloittaa uutta työtä vasta, kun asiakkaat käyttävät heidän aiempaa työtään.
• Saat nopeaa ja suoraa asiakaspalautetta: Kun tiimit toimittavat työinkrementtejä varhain ja usein, he voivat saada palautetta todellisilta asiakkailta ja toimia tämän palautteen perusteella. Tämä toimii vain, jos sinulla on rakenne, joka mahdollistaa sinulle ja tiimillesi palautteen saamisen todellisilta käyttäjiltä varhaisessa vaiheessa. Yleinen sudenkuoppa: Älä anna johtajien toimia käyttäjäpalautteen sijaisina. Tee johtajille selväksi, että heillä saattaa olla “liiketoiminta-arvon” määritelmä, mutta ei “asiakasarvon” määritelmää - se kuuluu asiakkaille, ja tuoteomistajan ja tiimien tulisi tutkia sitä suoraan.
• Monialaiset tiimit: Jos tiimisi on keskusteltava 10 muun tiimin kanssa toimittaakseen jotain asiakkaalle, ketterä kehitys ei toimi (vielä). Varmista, että sinulla on tiimejä, jotka voivat ottaa vastuun koko prosessista, tehdä päätöksiä itsenäisesti ja keskustella asiakkaiden kanssa.

On olemassa monia erilaisia ketteriä organisaatiomalleja, jotka voivat auttaa sinua toteuttamaan ketterää toimintaa omassa kontekstissasi. Seuraavassa on kaksi esimerkkiä suosituista malleista, joista voit ottaa oppia:

• Scrum: Tämä on ketterä kehys, joka auttaa tiimejä luomaan arvoa iteratiivisesti ja inkrementaalisesti.

  • Scrum määrittelee kolme roolia: Scrum Master, Product Owner ja Kehitystiimi.
  • Siinä määritellään myös neljä tapahtumaa: Sprint Planning, Daily Scrum, Sprint Review ja Sprint Retrospectives.
  • Siinä määritellään kolme artefaktia: Product Backlog, Sprint Backlog ja Increment.

Scrum sopii hyvin pienille tai keskisuurille tiimeille tai projekteille, joilla on selkeät ja vakaat vaatimukset ja tuotokset.

• Spotify-malli: Spotify-malli on ketterä organisaatiomalli, jonka on kehittänyt musiikin suoratoistopalveluyritys Spotify.
  Spotifyn mallissa joukkueet jaetaan Squadeihin, Chaptersiin, Tribesiin ja Guildsiin.

  • Ryhmä on pieni poikkitoiminnallinen tiimi, joka tuottaa tietyn toiminnon tai tuotteen.
  • Luku on ryhmä ihmisiä, joilla on samanlaisia taitoja tai tehtäviä, kuten kehittäjiä, testaajia, suunnittelijoita jne.
  • Heimo on ryhmä ryhmiä, jotka työskentelevät samankaltaisella alueella tai toimialueella.
  • Kilta on koko organisaation laajuinen etuyhteisö.

Spotify-malli sopii hyvin suurille organisaatioille tai ohjelmille, joilla on monimutkaisia ja dynaamisia vaatimuksia ja tuloksia.

Seuraavaksi haluan tuoda esiin klassisen johtamismenetelmän, jolla on tärkeä rooli myös ketterässä kontekstissa: kahdenkeskiset kokoukset.

Kuten seuraavasta taulukosta näkyy, työntekijät pitävät niitä erittäin tärkeinä.

Paras käytäntö: kahdenkeskiset tapaamiset kehittäjien kanssa

Ohjelmistokehittäjien johtaminen säännöllisissä kahdenkeskisissä tapaamisissa on ehdottoman keskeistä Agile:n toimitusjohtajille. Ne ovat ehkä tärkein tapaamisesi. Otatko ne vakavasti

Haluaisin käyttää tilaisuutta hyväkseni ja kiinnittää huomionne ilmaiseen kahdenkeskisiin kokouksiin tarkoitettuun ohjelmistoon, joka on kehitetty erityisesti ketteriä tiimejä varten. Tee 1:1-kokouksistasi jännittäviä, mittaa trendejä ja ennen kaikkea edisty työntekijöiden kehityksessä! 

Kokeile rohkeasti jotakin malleistamme, katso alta. Seuraava malli on vakiomalli esimerkiksi kahden viikon välein pidettäville kahdenkeskisille tapaamisille. Se sisältää myös mitattavan “tunnelmatarkistuksen” lopussa, jota voit tietysti muokata:

Jotta ketterä käyttöönotto onnistuisi, sinun on noudatettava joitakin parhaita käytäntöjä, jotka auttavat sinua optimoimaan käyttöönottoprosessin ja tulokset. Tässä on joitakin niistä:

• johtaa itseorganisoituvia ja itsenäisiä tiimejä: Agile-johtajana tai -päällikkönä sinun on annettava tiimillesi valtuudet tehdä päätöksiä, ottaa vastuuta ja puolustaa työtään. Sinun on luotettava siihen, että he tekevät parhaansa ilman holhoamista tai tarpeettomien sääntöjen tai rajoitusten asettamista. Sinun on myös tuettava heitä antamalla heille heidän tarvitsemansa resurssit, välineet, palautteen ja tunnustuksen.
• Suora asiakaskontakti: Ketterän tiimin jäsenenä tai tuoteomistajana sinun on oltava suoraan ja usein vuorovaikutuksessa asiakkaidesi kanssa. Sinun on ymmärrettävä heidän tarpeitaan, odotuksiaan ja mieltymyksiään ja tuotettava arvoa, joka täyttää tai ylittää ne. Sinun on myös kerättävä heiltä palautetta tuotteestasi tai palvelustasi ja käytettävä sitä tarjontasi parantamiseen ja mukauttamiseen.
• Ajattele jokaista uutta toimintoa kokeiluna, josta voit oppia: Ketterän tiimin jäsenenä tai tuotteen omistajana sinun on kohdeltava jokaista uutta ominaisuutta tai vaatimusta kokeiluna, jolla testataan oletuksia ja hypoteeseja siitä, mitä asiakkaat haluavat tai tarvitsevat. Sinun on suunniteltava kokeilut huolellisesti, mitattava tulokset objektiivisesti ja opittava tiedoista ja palautteesta. Sinun on myös oltava valmis harkitsemaan uudelleen tai siirtymään eteenpäin tulosten perusteella.

Siinä kaikki, mitä tarvitset yleiskatsaukseen. Toivottavasti tämä artikkeli auttaa sinua ymmärtämään enemmän ketterästä toimituksesta, sen perusteista, esimerkeistä ja parhaista käytännöistä. Jos sinulla on kysyttävää tai palautetta, kerro minulle 😊.