Tekijä: Juha Luotio

Ketterässä kehityksessä käytetään useasti käsitettä vauhti (velocity) tulevaisuuden ennustamiseen. Mikä tämä vauhti on ja voisiko sitä käyttää tiimin tehokkuuden mittarina? Lyhyesti sanottuna vauhti on ennustamisen työkalu ei tehokkuuden mittari. Tästä syystä vauhtia voi käyttää ainoastaan tulevaisuuden ennustamiseen eikä sitä voi käyttää kuvaamaan tehokkuutta millään asteella. Miksikö sitten? Jos kerran vauhti hidastuu niin eikös se ole paha asia?

Oleellista on ymmärtää ensin miten tiimin vauhti määräytyy. Ensimmäinen kysymys on tietysti, että mikä on vauhdin yksikkö? Onko se tuntia, päivää tai kenties ideaalipäivää? Vastaus on, että ei mitään näistä. Vauhdin yksikköä kutsutaan monesti tarinapisteeksi (story point), mutta yksinkertaisesti kyseessä on tiimin kehittäjien hihasta heittämä vertailuluku, joka kertoo minkä kokoisia vaatimukset ovat suhteessa toisiinsa.

Suunniteltu ja toteutunut vauhti

Sprintin suunnittelussa tiimi valitsee työjonosta toteutettavakseen vaatimuksia. Tiimi päättää täysin itsenäisesti paljonko se kykenee seuraavan kahden viikon aikana toteuttamaan. Tämän arvauksen pohjalta saadaan suunniteltu vauhti, eli paljonko tiimi arvioi kykenevänsä toteuttamaan seuraavan sprintin aikana. Valittaessa vaatimuksia työjonosta ei valittavien vaatimusten määrää perusteta aikaisempien sprinttien vauhtiin vaan kyseessä on aina uusi arvio sen hetkisen parhaan mahdollisen tiedon pohjalta. Monesti suunniteltu vauhti on hyvin lähellä laskennallista vauhtia.

Tiimin toteutunut vauhti määräytyy sen perusteella kuinka paljon vaatimuksia on saatu toteutettua valmiiksi asti. Valmiit ominaisuudet ovat oikeasti valmiita ja testattuja, sellaisia jotka voisi viedä tuotantoon vaikka heti. Toteutunut vauhti voi heitellä monista eri syistä. Näitä voivat olla esimerkiksi ulkoiset riippuvuudet, laatuvelka, sairastumiset tai toteutumisvaiheessa havaittu vaatimuksen mutkistuminen tai yksinkertaistuminen.

Ulkoiset riippuvuudet

Ulkoinen riippuvuus voi olla esimerkiksi kolmannen osapuolen järjestelmä, jota vasten ei päästä testaamaan heti. Tämä voi johtua esimerkiksi siitä, että järjestelmän toimittaja ei kykene tarjoamaan tarvittavaan testiympäristöä tai oikeuksia kahden viikon sprintin aikana. Tällöin vaatimus jää työjonoon auki, eikä sen pisteitä lueta mukaan tiimin vauhtiin. Kun testaamiseen tarvittavat ympäristöt ja oikeudet sitten lopulta saadaan kirjautuvat valmiit tarinapisteet siihen sprinttiin, jossa tarina lopulta saatiin valmiiksi. Toinen vaihtoehto on myös uudelleen arvioida seuraavan sprintin suunnittelussa jäljellä olevat pisteet vaatimuksista joita ei saatu valmiiksi. Tällöin pisteitä ”katoaa” koska osa työstä on jo tehty, mutta  seuraavassa sprintissä vauhtiin lasketaan vain jäljellä olleet pisteet.

Laatuvelka

Toinen yleinen tapaus joka aiheuttaa vauhdin laskemista väliaikaisesti on teknisen velan kertyminen. Ketterässä kehityksessä lähdetään siitä, että bugit korjataan välittömästi, eikä niitä jätetä työjonoon priorisoitavaksi. On kuitenkin melko yleistä varsinkin uudella tiimillä, että kaikki sprintiin otetut vaatimukset pyritään saamaan valmiiksi hinnalla millä hyvänsä. Saadakseen asiat nopeammin valmiiksi tiimi tinkii yleensä huomaamattaan laadusta, jolloin työjonoon kertyy bugeja eli tekemätöntä työtä. Tekemättömälle työlle ei koskaan anneta työmääräarviota, koska se pitää tehdä välittömästi pois alta, jotta se ei ala kertymään. Tällöin voi käydä esimerkiksi niin, että seuraavaan sprinttiin tulee valtava määrä bugeja edellisestä sprintistä ja näiden korjaaminen on pois uusien vaatimusten toteuttamiselta. Keskimäärin näiden kahden sprintin vauhti antaa siis kelvollisen ennusteen siitä paljonko tiimi saa aikaan suuressa määrässä tulevia sprinttejä.

Vaatimuksen mutkistuminen tai yksinkertaistuminen

Työmäärä arviointiin pyritään käyttämään kohtuullisen vähän aikaa, koska siihen käytetty aika on pois vaatimusten toteuttamiselta. Tästä syystä melko useastikkin käy niin, että yksinkertaiselta näyttänyt vaatimus mutkistuu huomattavasti kun sitä aletaan toteuttamaan. Tämä on erityisen yleistä  kun siirrytään uuteen vähän tuntemattomaan kokonaisuuteen. Tällöin vauhti putoaa verrattuna suunniteltuun kun asiat osoittautuvat monimutkaisemmiksi kun miltä ne ovat näyttäneet. Tämä kuitenkin tasoittuu seuraavissa sprinteissä kun tiimi oppii miten uuden kokonaisuuden kanssa tulee toimia ja uudelleen pisteyttää vaatimuksia uuden parhaan mahdollisen tietonsa pohjalta.

Voisiko vauhtia käyttää tehokkuuden mittarina?

Kiusaus käyttää vauhtia tehokkuuden mittarina on yleensä varsin suuri johtajilla, jotka eivät ymmärrä mikä vauhti on ja mitkä ovat sen rajoitteet. Vauhtia ei yksinkertaisesti voi käyttää tehokkuuden mittarina, koska se on itsestään mukautuva. Itsestään mukautuva tarkoittaa sitä, että jos tiimin tehokkuus kasvaa kun tiimi oppii alkaa se myös arvioimaan vaatimukset pienempinä. Tästä syystä äkillinen tehokkuuden kasvu saattaa näkyä toteutuneessa vauhdissa piikkinä, mutta tasoittuu nopeasti pois kun jäljellä olevat vaatimukset  uudelleen pisteytetään uuden tiedon valossa. Tällöin se mikä aikaisemmin oli kahdeksan saattaa nyt olla kolme verrattuna muihin vaatimuksiin. Lopputuloksena vauhti tasoittuu taas takaisin lähelle pitkäaikaista keskiarvoaan.

Voisiko vauhtia käyttää tulospalkkauksen perusteena?

Jos vauhdista itsestään tekee tavoitteen esimerkiksi tekemällä siitä osan tulospalkkausta ampuu helposti itseään jalkaan. Koska tiimi määrittää itse pisteet ja paljonko se kykenee sprintissä toteuttamaan, voi se kertoa ääritilanteessa kaikki pisteet vaikkapa kymmenellä. Tällöin pisteet ovat edelleen vertailukelpoisia keskenään, mutta ne ovat kärsineet vakavasti inflaatiosta. Lisäksi jos vauhdin asettaa tavoitteeksi kannustaa se tiimiä ottamaan laatuvelkaa ja toivomaan, että se ei ehdi alkaa näkyä projektin aikana.

Mihin vauhtia voi sitten käyttää?

Vauhti on itsestään mukautuvuutensa ansiosta aivan loistava työkalu tulevaisuuden ennustamiseen. Käyttämällä sprinttien vauhdin keskiarvoa ennusteena siitä paljonko tiimi saa tehtyä vaikkapa seuraavan viiden sprintin aikana on varsin hyvä arvio. Koska vauhti saattaa heitellä paljonkin yksittäisten sprinttien välillä ei sitä voi käyttää kuin suuntaa antavasti seuraavan sprintin sisällön arvioimiseen. Viiden sprintin keskiarvo on kuitenkin heilahteluista huolimatta luultavasti hyvin lähellä historiallista keskiarvoa. Excel velhot voivat vauhtihistoriaa hyväksikäyttäen laskea melko hyvätkin tilastolliset ennusteet siitä millä todennäköisyydellä yhden sprintin suunniteltu laajuus saadaan toteutettua tai mitkä ovat todennäköisyydet viiden seuraavan sprintin tapauksessa.

Tulevaisuuden ennustamisessa melko yleinen keino on myös käyttää laskennallista vauhtia, joka ottaa huomioon arkipyhistä johtuvat työpäivien vaihtelut sprinteissä ja yksittäisten kehittäjien lomat. Laskennallisen vauhdin laskemisessa käytetään vauhtikerrointa (focus factor), joka on laskennallinen kerroin joka ottaa huomioon työpäivät ja tunnetut lomat. Kun vauhtikertoimella kertoo vauhdin keskiarvon saa vielä aavistuksen parempia ennusteita.

Esimerkki todelliselta tiimiltä

Yllä oleva kuva on todellisen tiimin vauhtikuvaaja. Tiimi oli tässä vaiheessa työskennellyt vähän yli vuoden yhdessä ja kaikki sprintit olivat olleet kahden viikon mittaisia. Harmaa palkki kertoo tiimin sprintin suunnittelussa suunnitteleman laajuuden. Keltainen palkki kertoo toteutuneen vauhdin. Harmaa alue ilmaisee laskennallisen vauhdin ja sininen viiva kertoo tiimityytyväisyydestä.

Kohdassa 1 nähdään kun tiimi aloitti ja luonnollisestikkaan sillä ei ollut vielä mitään käsitystä siitä mitä se saa aikaan sprintissä. Tämän jälkeen nähdää kuitenkin heti, että jo sprintissä 2 vauhti asettui aika lähelle sen tulevaa keskiarvoa. Kohdassa 2 nähdään uuden tiimin yritys ottaa laatuvelkaa. Kohdassa 3 tiimi vaihtoi uuteen kokonaisuuteen, jolloin vaatimukset osoittautuivat monimutkaisemmiksi kuin oli etukäteen odotettu. Kohdassa 4 nähdään kuinka laskennallinen vauhti reagoi kesälomiin.

Kohdassa 5 voidaan nähdä, että suunniteltu vauhti kurottaa sprintistä 22 eteenpäin aina korkeammalle kuin toteutunut. On varsin tavallista, että vauhdin pudotuksen jälkeen tiimi yliarvio oman toteuttamiskykynsä. Lisäksi nähdään, että toteutunut vauhti on välillä yli laskennallisen ja välillä alle. Tämän ei sinänsä pitäisi olla mitenkään tavatonta kun ottaa huomioon, että laskennallinen perustuu määritelmän mukaan toteutuneen vauhdin keskiarvolle.

Otsikon kysymys on kystty minulta useita kertoja ja vastaus on; ei mitenkään. Toisaalta myöskään kiinteissä toimitussopimuksissa sitä ei oikeasti voida taata. Tästä tunnettuna esimerkkinä HKL ja Siemensin metron automatisointiprojekti vuonna 2008. Eivät ne tiukat sopimukset ja lakimiehet vie sitä projektia eteenpäin vaan ainoastaan osaavat ihmiset, jotka kykenevät järjestelmän toimittamaan. Tiukka kiinteä sopimus ei auta, jos toimittajalla ei ole osaamista tai byrokratiaan menee enemmän aikaa kuin itse tekemiseen.

Ketterässä menetelmässä lähdetään siitä lähtökohdasta, että kaikki tekijä osapuolet ovat ihmisiä, kaikkine inhimillisine vikoineen. Parhaatkaan ammattilaiset eivät kykene tekemään täydellistä vaatimusmäärittelyä etukäteen. Ihmisten aivokapasiteetti ei yksinkertaisesti riitä. Jos kerran vaatimusmäärittelyäkään ei pysty tekemään täydellisesti, niin miten sitten tämän päälle tehty valmis toteutussuunnitelma? Ketterässä tekemisessä lähdetään siitä, että vaatimusmäärittelyä ja suunnitelmaa ei voi tehdä etukäteen inhimillisten rajoitusten vuoksi.

Ketterässä menetelmässä tiukka vaatimusmäärittely ja suunnitelma korvataan kommunikaatiolla asiakkaan kanssa. Parhaat tulokset saadaan kun asiakkaan edustaja ja kehitystiimi istuvat koko kehitysprojektin samassa huoneessa ja vierekkäin. Tämä takaa sen, että kommunikaatio toimii pakostikin, eikä synny vastakkain asettelua, vaan ollaan yhdessä tekemässä yhteistä projektia. Lisäksi ketterässä menetelmässä tarjotaan asiakkaalle jatkuvalla syötöllä selkeitä ennusteita ja mahdollisuutta tarkastella miten muutokset laajuuteen (eli vaatimuksiin) vaikuttavat toteutusaikatauluun, eli suoraan kustannuksiin.

Ketterää projektia tehdään käytännössä aina tuntihintaisena tällöin on varsin suoraviivaista ennustaa paljonko tunteja halutulla budjetilla saa. Kun asiakkaalle lisäksi tarjotaan koko aika selkeät työkalut siihen, että hän näkee mihin jäljellä olevat rahat vielä riittävät, niin projekti ei oikein voi epäonnistua mitenkään. Käytännössä säädetään siis vaatimuksia niin, että budjetilla saadaan paras mahdollinen tuotos, mitä sillä on mahdollista saada. Alkuperäinen kysymys on itseasiassa asenteellinen ja väärä, koska se kysyy imperfektissä mitä on haluttu. Oikeampi kysymys on, että miten taataan, että tilaaja saa jäljellä olevalla budjetilla sen mitä halutaan tämän hetken parhaalla mahdollisella tiedolla?

Tämän lisäksi kehitystiimi toimittaa kahden viikon välein julkaisukelpoisen version järjestelmästä ja jos tilaaja ei ole tyytyväinen tiimin työskentelyyn niin hän voi päättää sopimuksen omalta puoleltaan milloin tahansa ja etsiä uuden kumppanin, tai palata vesiputouskehitysmalliin. Lisäksi hyväksymistestausta ei tehdä projektin lopussa vaan parasta olisi, että asiakkaalla olisi toimittaa henkilö hoitamaan hyväksymistestausta päivittäin tiimin kanssa, jolloin lopussa ei tule enää yllätyksiä.

Muokattu 4.3.2021: Korjattu kirjoitusvihreitä ja yksinkertaistettu lauserakenteita.

Lekmannin blogissa on melko hyvä sanasto scrum-terminologiasta suomeksi. Lekmannin blogissa oleva sanasto on sovittu yhdessä suomen merkittävimpien scrum-kouluttajien kanssa. En ole kuitenkaan löytänyt pätevää suomalaista sanastoa jossa olisi myös lean-sanasto mukana. Postauksen alussa on kopio suoraan Lekmannin blogista ja postauksen loppupuolella on Lean-sanastoa. Päivittelen omia listojani sitä mukaa kun törmään termeihin joille kaipaan käännöstä tai kun joku ehdottaa parempaa käännöstä.

Scrum

Tämä on suoraan Lekmannin blogista. Hakasuluissa olevat ovat omia vaihtoehtoisia käännöksiäni, eivätkä siis edusta virallista käännöstä:

Lisäksi lisäisin tähän sanastoon vielä seuraavat omat käännökseni:

Lean

Nämä termit olen yrittänyt itse kerätä kasaan eri lähteistä. Näihin voi ehdottaa muutoksia ja päivittelen niitä tähän blogipostaukseen sitä mukaan kun joku keksii tai tietää parempia. Tavoitteena on välttää fingelskaa aina kun se on mahdollista ja tarkoituksenmukaista.

Laadi lista asioista joita järjestelmällä pitää voida tehdä

Vaikka ohjelmistoa tehdään ketterin menetelmin tarvitsee toimittajan saada jonkinasteinen kuva siitä miten laajasta projektista on kyse.  Kirjoita lista yksinkertaisia lauseita kuten: ”Kansalainen voi lähettää hakemuksen sähköisesti”, ”Käsittelijä voi tutustua kansalaisen hakemukseen tehdäkseen sen pohjalta päätöksen” tai ”Käsittelijä tekee päätöksen joka lähetetään tiedoksi kansalaiselle”. Listaa lisäksi projektin reunaehdot kuten: ”Kansalaisen on voitava käyttää hakemuksen täyttämiseen yleisimpiä nettiselaimia” tai ”Järjestelmän täytyy täyttää lain asettamat vaatimukset sähköisestä arkistoinnista”. Älä takerru yksityiskohtiin sillä ketterässä kehityksessä vaatimuslista voi muuttua lennossa projektin aikana. Järjestelmän toimittaja tarvitsee listan saadakseen karkean kuvan projektin koosta voidakseen tarjota oikean kokoista tiimiä. Listan pituuden pitäisi olla enintään sata vaatimusta.

Vaadi toimittajaa sitoutumaan ketterään kehitykseen

Vaadi, että toimittaja käyttää yleisesti tunnettua ketterää mallia kuten Scrumia. Vaadi tarjouksen liitteeksi projektiin sidottavien kehittäjien CV:t. Projektilla täytyy myös olla täysipäiväinen Scrum Master. Scrum Masterilla täytyy olla vähintään kaksi vuotta kokemusta Scrum Masterina toimimisesta. Certified Scrum Professional -sertifikaatti on tästä pätevä osoitus. Certified ScrumMaster tai Professional Scrum Master todistaa ainoastaan, että henkilö on käynyt kahden päivän kurssilla. Scrum Master on ketterän kehityksen erityisasiantuntija, joka hallitsee ketterän kehityksen koukerot ja pitää huolen siitä, että ketterät periaatteet eivät ole vain paperilla. Mikäli tulevan tiimin koko on alle neljä henkilöä saattaa olla perusteltua, että Scrum Master ei ole täysipäiväisenä projektissa.

Lisäksi vaadi, että toimittajan lupaamat henkilöt on sidottu vähintään 90%:sti vain sinun projektiisi koko projektin ajan. Mikäli toimittaja haluaa vaihtaa henkilöitä kesken projektin olet oikeutettu saamaan korvaavan henkilön työskenetelmään vähintään ensimmäiset kaksi viikkoa ilmaiseksi. Vaadi myös, että sinulla on oikeus haastatella ja hylätä projektiin siirtyvät henkilöt ilman selittelyjä.

Sitoudu itse ketterään kehitykseen

Varmista omasta organisaatiostasi, että teillä on yksi henkilö joka on vastuussa projektista. Tämän henkilön pitää tuntea ongelma jota ollaan lähdössä ratkaisemaan, sekä hänellä pitää olla päätäntävalta tehdä päivittäisiä linjauksia ilman ohjausryhmiä tai komissioita. Lisäksi tämän henkilön pitää olla valmis viettämään koko projektin aika toimittajan kehittäjien ja Scrum Masterin kanssa samassa tilassa. Jos projektista vastaavalla henkilöllä ei ole aiempaa kokemusta ketterästä kehityksestä on järkevää lähettää hänet Certified Scrum Product Owner-kurssille, jossa ketterän kehityksen perusteet, sekä häneltä vaadittavat asiat tulevat selväksi.

Järjestä kehitystiimille tilat omalta toimistoltanne

Kun halutaan toimia ketterästi tällöin päätöksiä on tehtävä nopeasti ja läheskään kaikkea ei ole dokumentoitu paperille. Tällöin on äärimmäisen tärkeää, että projektista vastaava henkilö istuu kehitystiimin kanssa samassa tilassa. Tämä vähentää merkittävästi kehittäjien kynnystä kysyä epäselvissä tilanteissa, sekä parantaa tiedonkulua omaan organisaationne. Parasta on jos voitte järjestää kehitystiimille oman huoneen omalta toimistoltanne. Tällöin kehitystiimi on lähellä niitä ihmisiä joiden ongelmaa ratkotaan. Tämä helpottaa kysymistä ja kommunikaatiota silloin kun täytyy selvittää jotain niiltä ihmisiltä, jotka järjestelmää oikeasti tulevat käyttämään ja tuntevat nykyiset prosessit. Vaadi myös, että tiimin on myös työskenneltävä tarjoamassanne tilassa, eikä etätöitä sallita. Tiimitilasta ei ole hyötyä, jos kehitystiimi istuu kotona tai omalla toimistollaan.

Suojaa selustasi vaatimalla yksipuolinen irtisanomisoikeus

Vaadi toimittajilta yksipuolinen irtisanomisoikeus ilman perusteita ja sanktioita. Mikäli sinä haluat irtisanoa sopimuksen milloin tahansa koska sinusta tuntuu, että et ole tyyväinen, sinulla on siihen oikeus. Toimittajalla on ketterien menetelmien puolesta velvollisuus esitellä sinulle toimivaa järjestelmää vähintään kerran kuukaudessa. Vaikka tiimi ei voikkaan esitellä sinulle koko järjestelmää ensimmäisen kuukauden jälkeen, voi se esitellä ne ominaisuudet mitä on siihen mennessä saatu aikaan. Mikäli tiimi ei pysty esittelemään toimivaa järjestelmää vähintään kerran kuukaudessa tai yrittää selitellä, että järjestelmää ei voi esitellä ennenkuin se on kokonaan valmis on aika vaihtaa toimittajaa. Myös mikäli tuntuu siltä, että tiimi piilottelee sinulta jotain tai esitellyt versiot ovat toistuvasti niin bugisia, että niitä ei voi käyttää niin tällöinkin on tullut aika vaihtaa toimittajaa.

Älä vaadi tyhmiä asioita

Älä vaadi toimittajalta 10 vuoden kokemusta juuri sellaisten järjestelmien tekemisestä kuin mitä olette tarvitsemassa. Varsinkin jos toimittaja on iso talo niin se voi listata kymmeniä projekteja jotka vastaavat sitä mitä olette haluamassa, mutta kehitystiimissä ei välttämättä ole yhtään henkilöä joka olisi ollut näitä tekemässä. Toisinsanoen ihmiset osaavat asioita eivät yritykset. Älä myöskään vaadi kohtuuttomia liikevaihto vaatimuksia yrityksiltä. Mitä pienempiä yrityksiä olet valmis huolimaan toimittajaksi sitä parempia tarjouksia luultavasti saat. Suuret talot joutuvat pyörittämään suurta koneistoa vaikka sinun näkökulmastasi ainoa oleellinen asia on ne henkilöt joita projektissa tulee työskentelmään.

Kilpailuta tiimin tuntihinta

Koska vaatimusmäärittelyyn ei tuhlata aikaa etukäteen, ei toimittajaa voi vaatia sitoutumaan kiinteisiin hintoihin missään projektin osissa. Ketterässä projektissa sinä kannat käytännössä riskin, jolloin toimittaja voi myös tarjota huomattavasti tiukemman tuntihinnan kuin kiinteähintaisessa projektissa. Tiimi laskuttaa käytänössä tehtyjen tuntien mukaan kaikesta mahdollisesta mitä projektin tekemiseen tarvitaan. Vaadi toimittajalta arviota myös tarvittavista lisenssikustannuksista. Jos projektissa käytetään valmisjärjestelmää tai komponentteja pohjana voivat nämä kustannukset olla merkittäviä. Yleensä lisenssikustannukset tulevat maksettavaksi vasta kun järjestelmä otetaan tuotantokäyttöön. Kehittäjien työkalujen lisenssikustannukset sisältyvät tuntihintaan.

Vältä toimittajaloukku

Vaadi toimittajalta, että projektissa käytetään ainoastaan komponentteja ja valmisjärjestelmiä joihin kaikilla toimittajailla on tasapuolinen pääsy. Toimittajan oma järjestelmä jota käytetään pohjana saattaa kuulostaa houkuttelevalta, mutta aiheuttaa suuria ongelmia mikäli toimittajaa joutuu vaihtamaan. Vaadi siis, että järjestelmässä käytetään ainoastaan kolmannen osapuolen valmiskomponentteja. Jos toimittajan komponentteja kuitenkin käytetään varmista, että sinulla on niiden lähdekoodiin täydet oikeudet, jotta voit siirtää projektin uudelle toimittajalle tarvittaessa.

Pisteytä tarjoukset järkevin perustein

Pisteytä tarjoukset ensisijaisesti CV:iden ja toissijaisesti hinnan perusteella. Kiinnitä erityisesti huomiota kehittäjien kokemukseen ja osaamisen laaja-alaisuuteen. Kokeneet kehittäjät tulevat nopeasti halvemmaksi kuin halvat ja kokemattomat. Älä kuitenkaan anna lisäpisteitä yli viiden vuoden kokemuksesta. Se mitä kehittäjä on tehnyt yli viisi vuotta sitten on jo jokatapauksessa vanhentunutta. Anna sen jälkeen miinus pisteitä tarjouksille mikäli niistä ilmenee seuraavaa:

1. Toimittaja tarjoaa jotain osakomponenttia kiinteähintaisena
2. Toimittaja yrittää myydä projektiin mukaan erikseen projektipäällikön
3. Toimittaja tarjoaa projektiin erikseen vastuullista arkkitehtiä
4. Tiimin kokoonpano vaihtelee toimittajan suunnitelmissa projektin aikana
5. Tarjottu Scrum Master on kokematon
6. Toimittaja esittää vaihtelevan pituisia sprinttejä
7. Toimittaja ei halua lähettää kehittäjiään sinun toimitiloihisi
8. Tarjouksessa mainitaan erillinen hyväksymistestausvaihe
9. Tarjouksessa määritellään sanktioita tai ehtoja toimitussopimuksen purkamiseksi

Hanki osaavaa apua ja varo lakimiehiä

Osta osaamista ketterältä valmentajalta, Agile Coachilta, tai muulta kokeneelta henkilöltä tai yritykseltä, joka ei ole mukana tarjouskilpailussa. Maksamalla muutaman tonnin etukäteen konsultaatiosta säästät helposti paljonkin aikaa ja rahaa projektin myöhemmissä vaiheissa. Mikäli tarvitset lakiosaston apua varmista, että heillä on erityisosaamista ketterästä kehityksestä. Jos organisaation oma lakimies yrittää tehdä vesitiivistä sopimusta hän luultavasti päätyy vaatimaan perinteistä koko projektin kilpailutusta kiinteällä tai tavoite hinnalla, sekä tarkempaa vaatimusmäärittelyä. Etsi tässä tapauksessa toinen lakimies joka ymmärtää ketterän kehityksen päälle eikä vain yritä tehdä asioita niin kuin on aina ennenkin tehty.