Avoimuus muutoksille on edellytys ketterälle siirtymiselle (kuva Julia Lingertatilta)

Kuinka tulla ketteräksi - viraston opas

Ihanteellisten olosuhteiden luominen ketterille asiakasprojekteille

Tämä artikkeli on saatavana myös saksaksi.

Viime vuosina ”ketterästä” on tullut yhä suositumpi sanasto agentuurimaailmassa. Tuskin on yhtä yritystä, joka ei tunnusta toimivan ketterästi. Mutta mitä se oikeastaan ​​tarkoittaa? Kuinka voidaan kertoa kuinka ketterä yritys todella on? Jos joku työskentelee sprintissä, tarkoittaako se jo ketteryyttä? (Vastaus: ei.)

Aperto Move -yrityksessä olemme jatkuvasti analysoineet ja paranneet työmenetelmiämme kahden ja puolen vuoden aikana työntämällä visioamme ketterästä työpaikalla eteenpäin. Yksi kiistattomimmista havainnoista on ollut, että siirtyminen ketterään vaatii sekä aikaa että kokemusta. Ei voi vain tehdä siirtymistä ketterään. Vaikka emme ole vielä siinä, missä haluaisimme olla, parannukset ovat selvästi havaittavissa.

Ketterien menetelmien soveltaminen virastoissa on kokonaan vaikeampaa kuin esimerkiksi tuotekehityksessä; kun luodaan tuotteita eri asiakkaille, joissa olosuhteet voivat vaihdella huomattavasti projektien välillä. Siksi on vaikea uskoa, että jokainen virasto näyttää yhtäkkiä ketterältä. Onneksi on tekijöitä, jotka voivat auttaa selvittämään helposti, kuinka pitkälle yritys on matkalla tulla ketteräksi.

Tässä artikkelissa esitetyt neuvot perustuvat useimmille virastoille yhteisiin skenaarioihin, jotka ovat syntyneet päivittäisessä työssämme ja ratkaistuiksi, kun olemme havainneet ne ongelmiksi. Ne eivät ole parantavia ratkaisuja, vaan pikemminkin kokoelma oppimista, jotka toimivat meille parhaiten.

1. Selvitä terminologia

Ketterän käyttöönoton yhteydessä on ensiarvoisen tärkeää, että kaikilla yrityksessä on sama käsitys termistä, muuten vaarana on väärän viestinnän riski. Olen tavannut ihmisiä, jotka erehtyvät ketterään lähestymistapaan luopuessaan kaikista konseptin vaiheista, suunnittelusta ja säännöllisistä tapaamisista mieluummin syöksyäkseen suoraan projektiin ja nähdäkseen mitä tapahtuu. Ei ole vaikea kuvitella, että tällainen projekti oli kaikkea muuta kuin helppoa.

Toiset ovat yksinkertaisesti kuulleet ”Scrumista” ja pitäneet sitä tietyn haluttomuuden suhteen, hylkääen sen “jotain kehittäjille”, joka tukahduttaa luovan prosessin. Suurimmaksi osaksi nämä lausunnot tulevat ihmisiltä, ​​jotka eivät itse ole tutkineet Scrumia tai ketteritä menetelmiä. Lisäksi ne, jotka eivät tunne sitä, eivät usein osaa kertoa ketterän ja Scrumin eroa ja luokitella heidät samaan.

Ruumi ja ketterä eivät ole samoja

Scrum on kehys, joka määrittelee erityiset säännöt, roolit ja työprosessit ohjelmistojen kehittämiseen. Yksi esimerkki on määritelmä aikaväleille, jolloin toimiva tuote toimitetaan (ns. Sprintit). Scrumin toteutus myötävaikuttaa ketterään ohjelmistokehitykseen, minkä vuoksi termejä pidetään usein synonyymeinä, mutta ne eivät ole.

Toisaalta ketterä on ajattelutapa tai kulttuuri, joka kapseloi paljon enemmän kuin pelkästään sen, mitä Scrum tekee. Ketterän kulttuurin määrittelevät periaatteet on esitetty ketterässä manifestissa ja kuvattu seuraavassa videossa:

Scrum on vain yksi mahdollinen lähestymistapa ketterien periaatteiden noudattamisessa. Yksi voi myös olla ketterä käyttämättä Scrumia. Toisaalta, vain siksi, että noudatetaan Scrumin sääntöjä, ei tarkoita, että joku todella toimii ketterästi.

2. Jäähyväiset projektipäällikkörooliin (tervehdi ketterät roolit)

Scrumissa määritetään seuraavat roolit:

  • Tuotteen omistaja
  • Scrum Master
  • Kehitystiimi
  • Muut sidosryhmät, kuten loppukäyttäjä tai asiakkaan puolelta mukana olevat

Muita rooleja ei ole, eivätkä ne olekaan välttämättömiä. Klassista projektipäällikköä ei enää vaadita tässä asennuksessa. Hän vain estäisi prosessia, koska kaikki projektipäällikön aikaisemmin suorittamat tehtävät kuuluvat nyt edellä lueteltuihin tehtäviin. Vastuu projektin onnistumisesta ei enää kuulu yhdelle henkilölle, vaan koko joukkueelle.

Jokainen projektissa esiintyvä lisärooli, joka on Scrum-tiimin ja asiakkaan välillä, on este suoralle ja tehokkaalle viestinnälle ryhmän ja asiakkaan välillä.

Ota rooleja ja vastuita vakavasti

Jos joku ei tarvitse projektipäällikköä, eikö olisi järkevää käyttää aiempia projektipäälliköitä yhdessä Scrum Masterin ja tuotteen omistajan roolissa?

Ei. Toisaalta sekä Scrum-päällikön että tuotteen omistaja -roolit sisältävät tarpeeksi tehtäviä, joiden suorittaminen johtaisi yhden roolin laiminlyöntiin. Viime kädessä kahdella roolilla on ristiriitaiset intressit. Tuotteen omistaja on jatkuvassa yhteydessä kaikkiin sidosryhmiin ja varmistaa, että oikea tuote toimitetaan parasta laatua. Scrum-mestarin on muun muassa varmistettava, että joukkue ei ole ylityöllistetty tai keskeytetty. Siksi Scrum Master -laitteella ei ole mitään tekemistä itse tuotteen kanssa.

Vielä huonompi idea olisi jättää Scrum Master kokonaan pois. Ilman toimivaa Scrum-päällikköä ei ole roolia varmistaa, että ryhmä toimii tuottavasti, noudattaa määräaikoja tai oppii takautuvasti ja muuttuu tehokkaammaksi. Lyhyesti sanottuna he takaavat projektin ketterän toteutuksen. Kokemuksemme mukaan se on erityisen tärkeä rooli toimistoympäristössä, jossa muuttuvat asiakkaat, sidosryhmät ja olosuhteet, koska Scrum Master ottaa myös valmentajan roolin asiakkaalle.

Tässä artikkelissa selitetään Scrum Masterin ja klassisen projektipäällikön eri toiminnot helposti ymmärrettävän liikenteen analogian suhteen:

3. Ei enää resurssisuunnittelua (aseta pull-periaate sen sijaan)

Agenttitoimistoissa tehdään usein samanaikaisesti useita projekteja eri asiakkaille, jolloin työn tehokas jakaminen kaikkien työntekijöiden kesken on haaste.

Klassinen toimistotapa on resurssien suunnittelu: projektipäällikkö laatii suunnitelmat useiksi päiviksi tai viikoiksi eteenpäin ja osoittaa työntekijät projekteihin tai vastaaviin tehtäviin. Tämä vaatii paljon aikaa suunnitteluun ja koordinointiin ja johtaa joustamattomuuteen, koska se toimii olettaen, että kaikki allokoidun ajan ennusteet ja suunnitelmat täyttyvät.

Kokemus opettaa meille, että todellisuudessa tällaiset suunnitelmat eivät koskaan toteutu: tärkeä toimitus viivästyy, työntekijät sairastuvat tai syntyy muita odottamattomia olosuhteita, jotka johtavat siihen, että yksittäiset tehtävät vievät odotettua pidempää aikaa. Seurauksena on epätasainen työnjako kollegoiden kesken, lisää stressiä ja ylityötä.

Tämä ns. Push-periaate (koska työntekijöillä on yksittäisiä tehtäviä "työnnetty" heille) ei siksi ole optimaalinen. Joten miten työ jakautuu ilman projektipäällikköä ketterässä tähdistössä? Tämä kysymys vaatii erilaista lähestymistapaa:

Vedon periaate

Ketterä työ perustuu "vetäytymiseen". Tämä tarkoittaa, että työntekijät päättävät ennakoivasti, mitkä tehtävät he haluavat suorittaa. Jotta tämä toimisi, tulevista tehtävistä ja niiden etenemisestä on tiedotettava avoimesti.

Ihanteellisessa tilanteessa tätä ei tapahdu vain projektitasolla, vaan kaikissa tulevissa yrityksessä tehtävissä. Tähän sisältyy laajuuden arviointi, esitysten luominen, työpajojen valmistelu, osallistuminen haastatteluihin tai jopa tämän artikkelin kirjoittaminen. Tämä voidaan suorittaa esimerkiksi Kanban-levyllä:

Vedon periaate varmistaa työn tasaisen jakautumisen työntekijöiden kesken, jolloin jokaisella on vapaus päättää itsenäisesti, kun he kykenevät työskentelemään tehtävissään. Tämä auttaa välttämään mahdollisuuden yliarvioida tiettyjä työntekijöitä.

Jotta vetoperiaate toimisi, seuraavien ehtojen on täytyttävä:

  • Jatkuva viestintä on ratkaisevan tärkeää. Projektin tilasta keskustellaan Aperto Movessa kolme kertaa viikossa hallituksessa
  • Se vaatii ihmisiä, jotka kykenevät tekemään aloitteen, sen sijaan että odottaisivat toisten kertovan heille mitä tehdä
  • Se suosii tasaisia ​​hierarkioita ja vaatii halukkuutta niiden toteuttamiseen
  • Yrityksen johdolla on oltava luottamus työntekijöihin, jotta he voivat ottaa enemmän vastuuta
  • Yksittäisten tehtävien ja hankkeiden välillä on oltava selvä ero. Projekteja ei vedä yksi henkilö, vaan joukkue. Tätä tutkitaan tarkemmin seuraavassa osassa.

4. Perusta vakaa joukkue

Agenttitoimistoille on tyypillistä työskennellä useiden asiakkaiden kanssa samanaikaisesti, ja kiireelliset tehtävät (kuten laajuuden arviointi, korjauspaikat tai virheenkorjaukset) ilmenevät usein lyhyellä varoitusajalla. Siksi projektiryhmät luodaan usein nykyisen saatavuuden mukaan. Tämän tyyppinen resurssisuunnittelu estää tehokkaasti ketterät projektit.

Ketterien joukkueiden tulisi olla vakaita ja löytää ihanteellisesti itsensä. Vain läheiset joukkueet voivat kehittyä optimaalisesti ja ylläpitää tai jopa kiihdyttää vauhtiaan oppimalla toisiltaan, koordinoimalla prosesseja ja viestintää sekä tunnistamalla ja ratkaisemalla ongelmia retrospektiivisen analyysin avulla.

Joukkueet voivat tunnistaa ja ratkaista ongelmia säännöllisillä retrospektiivillä (kuva Andreas Plath)

Jotta vältetään häiritsemästä tehokkaasti työskenteleviä työryhmiä, jotka toimivat hyvin yhdessä, ja siten eliminoidaan kaikki oppimis- ja rutiinivaikutukset, tulevia projekteja ei pitäisi suunnitella yksilöiden mielessä, vaan pikemminkin vakaiden ryhmien kanssa.

On kuitenkin epärealistista ajatella, että koko viraston muuttuminen kaikilla tieteenaloilla vakaiksi ja tasapainoisiksi joukkueiksi voi tapahtua yön yli. On ajateltavissa, että kaikki eivät halua työskennellä pysyvästi samassa joukkueessa. Siksi on ratkaisevan tärkeää löytää tasapaino, joka toimii kaikille hyvin.

5. Luo ketterät ehdotukset

Klassinen, yksinkertaistettu ehdotusvaihe asiakkaiden ja toimiston välillä tapahtuu yleensä seuraavassa muodossa: Asiakkaalla on erityinen idea tuotteesta ja aikataulu, jolloin se on valmis.

Sitten asiakas tiedottaa virastolle vaatimuksista (ehkä sävelkorkeudella) ja pyytää ehdotusta, jossa määritetään kiinteä hinta tämän tuotteen kehittämiselle. Molemmat osapuolet käyttävät itsensä suojelemiseksi huomattavasti työtä ehdotuksen laatimiseksi mahdollisen väärinkäytön välttämiseksi.

Asiakkaan kannalta tämä näyttää yleensä toteuttamiskelpoiselta ratkaisulta: he tietävät mitä saavat milloin ja mihin hintaan.

Vaatimukset muuttuvat

Useimmat asiakkaat eivät tällä hetkellä tiedä, että he haluavat usein jotain hyvin erilaista projektin loppuun saakka, kuten he tekivät alussa.

Koska ehdotuksessa on kaikki määritelty konkreettisesti, on lähes mahdotonta muuttaa jotain myöhemmin hankkeessa ilman uudelleenneuvotteluja, kuten:

  • muut ominaisuudet tulivat tällä välin tärkeämmiksi
  • haluttu projekti ei ole enää teknisesti toteutettavissa
  • käyttäjätestit paljastivat, että tuotetta ymmärretään väärin tai että sillä ei ole mitään järkeä
  • kilpailija on luonut samanlaisen tuotteen, joka edellyttää strategista kääntöpistettä

Tässä tapauksessa priorisoinnin uudelleenjärjestys ei ole helppoa, jos vanha, tarkistettu soveltamisala määritetään ehdotuksessa.

Tämän tyyppiset ehdotukset heikentävät muita ketteryyden tärkeimpiä näkökohtia. Tuotteen jatkuva, yhteistyöllinen parantaminen on paljon vaikeampaa, koska tuote on määriteltävä alussa selvästi ehdotuksen viimeistelemiseksi. Tämä johtaa tyypilliseen vesiputouksen työnkulkuun. Sprintisuunnittelu, mukaan lukien pokerin suunnittelu, tulee yhtä turhaksi, koska lopullinen määräaika ja saavutettavuus on jo määritelty.

Jos soveltamisala, määräaika ja hinta on jo asetettu alussa, ei ole enää järkevää yrittää toteuttaa ketterää kehystä, kuten Scrum.

Tässä tapauksessa ketään toimituksen tärkeimpiä etuja ei voida enää käyttää, mutta silti ylimääräiset kulut Scrum-kokouksista, jotka eivät tarjoa todellista arvoa. Tätä prosessia kutsutaan myös nimellä "pseudo Scrum".

Tarvitaan toisenlainen ehdotus

On järkevämpää veloittaa suoritetusta työstä (ns. Aika- ja materiaalisopimukset) sen sijaan, että ehdotuksessa määritettäisiin tarkat suoritteet. Vasta sitten on mahdollista toteuttaa projekti ketterästi.

Se, kuinka paljon ja mitä asiakas saa rahoistaan, määrittelee hän itse projektin aikana pitämällä vaatimusluettelon ajan tasalla ja priorisoimalla yhdessä ryhmän kanssa.

Ketterien ehdotusten laatiminen vaatii harjoittelua (Lähde: https://unsplash.com/?photo=OQMZwNd3ThU)

Jotta asiakas saa käsityksen siitä, mitä hän voi odottaa, voidaan antaa karkea arvio siitä, kuinka paljon on saavutettavissa tietyssä ajassa tai kuinka kauan kestää, kunnes tietty vaatimus toteutetaan. Mitä kauemmin joukkue on työskennellyt yhdessä, sitä tarkempi tämä arvio tulee, koska on helpompaa mitata joukkueen yleistä vauhtia tai ”nopeutta”. Tämä on toinen syy, miksi on parempi työskennellä vakaiden ryhmien kanssa.

Ehdotuksen laatiminen on edelleen yksi vaikeimmista osista ketterässä siirtymisessä. Tuskin yksittäinen asiakas, joka ei ole vielä kerännyt kokemusta ketterästä ympäristöstä, haluaa allekirjoittaa toistaiseksi voimassa olevan sopimuksen. Heidän vakuuttamiseksi sen ansioista on ensiarvoisen tärkeää osoittaa taito ja rakentaa luottamusta asiakkaan kanssa.

Kokemuksemme mukaan tämä haaste selviytyy helposti heti, kun ketterä projekti on saatu päätökseen yhdessä. Silloin projektiprosessi puhuu puolestaan; tuottaa nopeita ja konkreettisia tuloksia iteratiivisella työllä, tiiviillä yhteistyöllä ja lyhyemmillä palautussyklillä, jotka ovat paljon lähempänä asiakkaan suunnitelmaa kuin mitä ne olisivat tyypillisissä vesiputousprojekteissa.

Ketteristä ehdotuksista, kuten tämä kirja, on saatavilla paljon hyödyllistä kirjallisuutta:

6. Ota projektiryhmä mukaan hankintavaiheeseen mahdollisimman aikaisin

Virastoissa hankinta- ja ehdotusvaihe on usein erillinen hankkeen toteutuksesta. Uusi liiketoimintaryhmä vastaa uusista hankkeista, ja projektiryhmä ei ole yksityiskohtiensa edessä ennen toteutusvaihetta, mikä lisää konfliktien todennäköisyyttä.

Ehdotusvaihe voi jo olla ratkaiseva sen määrittämisessä, onko projekti onnistunut vai ei. Siksi on välttämätöntä, että ketterä joukkue otetaan mukaan viestintään mahdollisimman varhaisessa vaiheessa.

Tämän seurauksena voidaan arvioida suhteellisen varhain, onko ketterä toteutus mahdollista ja kuinka paljon aikaa siihen voidaan odottaa. Aikakustannukset, esim. Tarvittavien sprintien määrän scrum-projektissa voi arvioida vain ryhmä itse, jos se tietää projektista niin paljon kuin mahdollista.

Toisinaan hankepyyntöjä on enemmän kuin kykyä käsitellä niitä. Vetotaidon periaatteen toteuttamiseksi ja sopivimman projektin valitsemiseksi ryhmän on tiedettävä mahdollisimman paljon kaikista vireillä olevista hankkeista. Vasta sitten he voivat tehdä tietoisen päätöksen ja sisällyttää tarkoituksenmukaisesti uudet projektit nykyisten tulosteisiin.

Uuden projektin alkaessa ryhmän tulisi tuntea kaikki sidosryhmät ja heidän vaatimuksensa mahdollisimman varhaisessa vaiheessa, jotta saataisiin oikea tuote parasta mahdollista laatua. Yksi tehokas toimenpide tämän saavuttamiseksi on työpajan järjestäminen ryhmän ja asiakaspuolen sidosryhmien kanssa.

Lisäksi on tärkeää kommunikoida ketterät arvot asiakkaalle, tunnistaa ensisijainen yhteyshenkilö ja selittää yksityiskohtaisesti yhteistyömenettely.

7. Unohda palveluntarjoajan rooli (ja työskentele ryhmänä asiakkaasi kanssa)

Asiakas / palveluntarjoaja -suhde on haitallista, koska se perustuu aina oletukseen, että asiakas on tehnyt sopimuksen ja odottaa tiettyä tulosta. Projektin onnistunut tulos, joka tyydyttää kaikki osapuolet, vaatii yleensä työtä kaikilta osapuolilta, etenkin säännöllistä kommunikointia toistensa kanssa.

Olennainen edellytys menestyvälle ketterälle projektille on samalla tasolla tapahtuva viestintä. Tämä tarkoittaa, että asiakas ja toimisto pitävät toisiaan yhtenä ryhmänä, työskentelevät yhdessä projektin parissa ja tunnistavat ja arvostavat toistensa vahvuuksia. Virasto on yleensä strategian, käyttäjäkokemuksen, suunnittelun ja teknisen toteutuksen asiantuntija; asiakas puolestaan ​​tuntee omat sisäiset prosessinsa ja vaatimuksensa sekä kohderyhmänsä. Vasta kun näitä tietoja jaetaan, voidaan luoda todella käyttäjälähtöinen tuote, joka tyydyttää kaikki sidosryhmät.

Tämä edellyttää, että asiakaspuolella on nimetty yhteyshenkilö, joka voi vastata projektiin liittyviin kysymyksiin tai voi toimittaa virastolle puuttuvan materiaalin. Kaikki asiakkaat eivät voi tai halua sijoittaa niin paljon aikaa yhteen projektiin, koska heidän omat sisäiset työprosessinsa eivät salli sitä.

Kokemuksemme mukaan asiakkaat huomaavat yleensä jo varhaisessa vaiheessa, kuinka nopeasti he saavat korkealaatuisia tuloksia ketterän yhteistyön avulla. Tämä vastaa heidän odotuksiaan ja he ovat valmiita sijoittamaan aikaa.

8. Jätä tilaa ryhmätyölle

Ketteryys tarkoittaa työskentelemistä monitieteisesti ja jatkuvan viestinnän avulla. Tämä toimii parhaiten, jos ketterä joukkue istuu yhdessä, mikä auttaa heidän työtä helposti koordinoimaan. Ihannetapauksessa jokaisella joukkueella tulisi olla oma tila, jossa he voivat työskennellä häiriöttömästi minimoimalla muiden häiriöt, esim. kun suunnittelusta tai ominaisuuksista keskustellaan.

Ketterien joukkueiden tulisi voida työskennellä ilman häiriöitä (Lähde: https://unsplash.com/photos/5T6lSk2uI1A)

Virastot maalaavat usein erilaisen kuvan: työntekijöiden ryhmittely omien alojensa mukaan. Tämä tarkoittaa, että kaikki suunnittelijat istuvat yhdessä toimiston nurkassa, kehittäjät toisessa nurkassa ja testaajat ja tilinhoitajat usein eri huoneissa. Vaikka tällä saattaa olla järkeä kurinalaisuuteen liittyvässä vaihdossa, se vaikeuttaa viestintää projektitiimin sisällä. Toistensa kirjoittaminen on mahdollista, mutta se vie paljon kauemmin kuin suoraan toisilleen puhuminen.

Se on entistä vaikeampaa, kun kaikki joukkueen jäsenet eivät ole samassa paikassa. Kaikki tietävät, kuinka huonot puhelin- tai videoneuvottelut ovat, ja jos et ole joutunut kärsimään heistä aiemmin, tätä videota suositellaan:

9. Harkitse jokaista kuria ja koko projektiprosessia

Koska Scrum syntyi ohjelmistokehityksestä, voi tuntua kätevältä toteuttaa vain projektin tekninen osa ketterästi, jättäen luovan vaiheen koskematta. Tämä saavutetaan kuitenkin suhteellisen vähän, koska vesiputousrakenne ratkaistaan ​​vasta projektin lopussa.

Klassinen vesiputousprosessi perustuu tiettyjen suoritteiden hyväksymiseen

Oletetaan, että ketterä tiimi koostuu puhtaasti kehittäjistä; asiakassivuston konsepti ja suunnittelu on jo valmis, mutta kehityksen keskellä käy ilmi, että tärkeitä valtioita ei ole määritelty tai suunniteltu ja luova joukkue on jo mukana seuraavassa projektissa. Mitä nyt? Pitäisikö ihmisten ottaa pois muista hankkeista? Jatkako epätäydellisen tuotteen kehittämistä? Ei ole muuta helppoa vastausta kuin kaikkien asiaankuuluvien tieteiden sisällyttäminen ketterään työnkulkuun alusta alkaen.

Säännöllinen vaihto projektiryhmässä parantaa tuotteen laatua (Lähde: https://unsplash.com/photos/gN_nIUnjYJI)

Palaute, palaute, palaute

Valtava vahvuus ja tärkeä syy siihen, miksi ketterästi kehitettyjen ohjelmistojen laatu on parempi kuin klassisen projektinhallinnan vesiputoushankkeissa, on monitieteinen yhteistyö ja tuotteiden toistuva parantaminen kaikkien sidosryhmien varhaisen ja säännöllisen palautteen perusteella.

Yksinkertaisesti sanottuna, tämä tarkoittaa: kaikki tarkistavat kaiken projektin kaikissa vaiheissa.

  • Asiakas ja koko joukkue antavat tuotteen omistajalle palautetta käyttäjän tarinoihin
  • UI-suunnittelijat antavat palautetta kehyskehyksistä ja teknisestä toteutuksesta
  • UX-suunnittelijat antavat palautetta käyttöliittymäsuunnitteluun ja tekniseen toteutukseen
  • Käyttöliittymäkehittäjät antavat palautetta kehyskehyksille, käyttöliittymäsuunnitteluille, taustan käyttöliittymille ja tarvittaessa taustan toteutukselle.
  • Taustakehittäjät antavat palautetta kehyskehyksistä, käyttöliittymäsuunnittelusta ja käyttöliittymän toteutuksesta
  • Laadunvarmistus (QA) antaa palautetta kehyskehyksistä, käyttöliittymäsuunnittelusta ja teknisestä toteutuksesta
  • Käyttäjät antavat palautetta käytettävyystesteillä projektin kaikissa vaiheissa (kehysrakenteet, suunnitteluprototyypit, napsautussukut, käyttöliittymä)
  • Asiakas antaa palautetta tuotteen lisäyksistä sprintin tarkistuskokouksissa
Ketterässä kokoonpanossa joukkue toimii yhdessä eikä peräkkäin

Säännöllinen palaute on ketterän kehityksen tärkein voimavara, ja sillä varmistetaan, että tuote kehitetään kaikille sidosryhmille tyydyttävällä tasolla. Luonnollisesti tämä toimii vain, kun kaikki ovat mukana jokaisessa projektivaiheessa.

10. Älä odota, että kaikki toimii heti (tee virheitä ja opi niistä)

Toivottavasti edelliset osiot kertoivat, että useilla tasoilla on käytettävä erilaisia ​​lähestymistapoja niihin, joita on todennäköisesti kehitetty ja vahvistettu vuosien varrella. Tämän vuoksi on entistä tärkeämpää ymmärtää, että siirtyminen ketteryyteen on prosessi, ei välttämättä helppo, eikä sellainen, jolla on määritelty päämäärä.

Edellä käsiteltyjen toimenpiteiden toteuttaminen ei automaattisesti takaa muutosta ketteryyteen. Samoin ei riitä, että toteutetaan vain "teknisiä" näkökohtia, kuten Scrumin käyttöönotto. On paljon tärkeämpää muuttaa yrityskulttuuria ja luoda yhteinen, ketterä arvojärjestelmä kaikilla hierarkkisilla tasoilla.

Olisi naiivia odottaa, että tällaiset perustavanlaatuiset muutokset voidaan toteuttaa heti ja ilman esteitä. Yhtiöprosessien muutoksia voidaan myös pitää ketteränä projektina ja toteuttaa iteratiivisesti.

Viime kädessä tämä tarkoittaa, että ei pitäisi yrittää muuttaa kaikkea kerralla, vaan pikemminkin toteuttaa yksi toimenpide kerrallaan. Tällä tavalla oppii, mikä toimii, mikä ei ja mitä voidaan parantaa. Olisi väärin pitää kiinni yhdestä mittarista, joka ei tunnu oikealta, vain siksi, että kirja tai blogi on suositellut sitä.

Ulkoisesta valmennuksesta voi olla apua oikeiden ajatusprosessien käynnistämisessä, mutta ei kuitenkaan voi toivoa löytävänsä pikakorjattavaa korjausta, joka tekee siitä yhtäkkiä ketterän.

Yhtä tärkeää on luoda sisäinen tietojen ja kokemusten vaihto ja sopia yhteisestä lähestymistavasta. Tämän saavuttamiseksi on hyödyllistä tarkastella säännöllisesti ketterän manifestin taustalla olevia 12 periaatetta ja arvioida, missä määrin yrityksen yritys on jo ottanut ne käyttöön:

Ryhmässämme Scrum-kehyksen ohjeiden tiukka noudattaminen on osoittautunut parhaaksi ratkaisuksi. Joka kerta kun näistä prosesseista poikettiin, se johti komplikaatioihin ja lisäponnisteluihin. Sen ei kuitenkaan tarvitse olla kaikkien tapaus. Jokaisen yrityksen on löydettävä itse, mikä toimii parhaiten.

johtopäätös

Jo ennen asiakasprojektin alkamista tietyt tavanomaiset toimisto-olosuhteet voivat vaarantaa tai jopa tehdä ketterien projektien onnistumisen mahdottomaksi. Täällä tarvitaan uusi ajattelutapa kaikilla tasoilla ja kaikilla tieteenaloilla, mikä merkitsee muutoksia, joita ei voida toteuttaa yön yli.

Tässä artikkelissa esitetyt näkökohdat voivat toimia ohjeena, jonka avulla voidaan tunnistaa ja keskustella tilanteista ja ongelmista ketterien hankkeiden suunnittelussa, ennen kuin ne alkavat.

Mitkä ovat kokemuksesi tästä aiheesta? Tiesitkö muita olosuhteita, jotka tekevät ketteristä prosesseista vaikeita? Kerro meille tämän artikkelin kommenttiosassa.

Lisälukema

Aperto Move - IBM-yritys on Berliinissä toimiva digitaalisten ja matkapuhelinpalveluiden toimisto, jolla on noin 30 työntekijää. Entä sinä?

Seuraa meitä: apertomove.com / Facebook / Twitter