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

Kaikki puhuvat “Agile Delivery” -toimituksesta ja haluat siksi 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 arvonluontitapa, 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 tulevia kuukausia. Ja tätä kutsutaan usein “Agile Waterfall Deliveryksi”. Haluan kuitenkin tehdä selväksi, 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ä. Siksi tiimien tulisi aloittaa uusia töitä vasta, kun heidän aikaisempaa työtään käytetään asiakkaiden toimesta.
• 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, jonka avulla sinä ja tiimisi voitte saada palautetta todellisilta käyttäjiltä varhaisessa vaiheessa. Yleinen sudenkuoppa: Älä anna johtajien toimia käyttäjäpalautteen sijaisina. Tee johtajille selväksi, että heillä voi 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 mielellään yhtä malleistamme, katso alta. Seuraava malli on vakiomalli esimerkiksi kahden viikon välein pidettäviin kahdenkeskisiin tapaamisiin. Se sisältää myös mitattavan “tunnelmatarkastuksen” 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 😊.