Sopimuspohja Agile/Scrum-projekteihin

agile-scrum-sopimuskuva

Haluatko rahoillesi parhaan vastineen? Scrum lähtee siitä, että projekteissa on enemmän tuntemattomia kuin tunnettuja muuttujia. Tällöin on fiksua ostaa ja myydä vaatimusten sijaan työaikaa.

Ketterällä sopimuksella tilaaja ostaa etukäteen määrätyn sisällön sijasta työaikaa (sprinttejä tai päiviä). Tällöin on mielekästä priorisoida, katselmoida ja tarkentaa sisältöä jokaisessa sprintissä koko projektin ajan, joka johtaa parempaan lopputulokseen.

Projekti voidaan ostaa ja aloittaa ripeämmin, kun paksua ja nopeasti happanevaa vaatimusmäärittelyä ei tarvita. Edelleen on kuitenkin tärkeää, että sekä tilaaja että toimittaja ymmärtävät hankkeen liiketoiminnalliset lähtökohdat ja tavoitteet.

The best bang-per-buck risk mitigation strategy we know is incremental delivery. -Tom deMarco

Kokematon tilaaja saattaa aluksi jännittää, valmistuuko projekti ajoissa, kun sisältö voi muuttua projektin aikana. Pelko on kuitenkin aiheeton, koska tilaajan itse asettama tuoteomistaja päättää vaatimusten priorisoinnista, muutosten toteutuksesta  ja siten kehitystiimin ajankäytöstä. Joskus tietoinen myöhästyminen alkuperäisestä aikataulusta voi olla jopa hyvä liiketoimintapäätös, jos sillä saavutetaan suurempi markkinaosuus, liikevoitto tai sijoitetun pääoman tuotto. Joskus taas kannattaa karsia kaikki vähemmän kriittinen, jotta markkinoille päästään nopeammin.

Ketterä sopimus olettaa ja kannustaa siihen, että:

  • Tilaajalla on projektiin käytettävissä henkilö (tuoteomistaja), jolla on aikaa, mielenkiintoa ja ammattitaitoa määritellä ja priorisoida vaatimuksia, kommunikoida ne kehitystiimille ja vastata kehitystiimin tarkentaviin kysymyksiin jopa päivittäin. Jos tilaajalla ei ole tällaista henkilöä, voidaan käyttää toimittajan tai kolmannen osapuolen konsulttia.
  • Kehitystiimi työstää vain yhtä asiakasprojektia kerrallaan. Tällöin työ on tuottavinta ja tuoteomistaja voi olla jopa päivittäin luontevasti yhteydessä kehitystiimiin.
  • Jokainen kehitysjakso eli sprintti suunnitellaan ja priorisoidaan tuoteomistajan johdolla kehitystiimin kanssa.
  • Tuoteomistaja katselmoi jokaisen sprintin lopputuloksen (kehitystiimin demo) jonka lisäksi keskustellaan siitä, kuinka havainnot vaikuttavat seuraavaan sprinttiin, prioriteetteihin ja koko projektiin.
  • Kehitystiimi työskentelee fyysisesti yhdessä tilaajan tai toimittajan tiloissa.
  • Prosessin ja yhteistyön toimivuutta ja kehittämistä arvioidaan säännöllisesti retrospektiiveissä, joihin osallistuu tuoteomistaja, toimittajan kehitystiimi sekä kehitystiimissä toimiva Scrum Master, joka vastaa Scrum-prosessista.

Lataa sopimuspohja Agile/Scrum-projekteihin ja ota tarvittaessa yhteyttä niin autan mielelläni.

Julkishallinnon kilpailutusrajan (nyt 30.000 euroa) ylittävät hankkeet vaativat lisäksi hankintalain mukaisen tarjouskilpailun. Tutustu ketterän tarjouskilpailun ohjeisiin. Lisätietoja löytyy myös julkiset ohjelmistohankinnat -blogista ja Codenton Slidesharesta: Hanselin Outi Jousi ja Maanmittauslaitoksen Jani Kylmäaho.

2 Comments on “Sopimuspohja Agile/Scrum-projekteihin

  1. Kisko Labsin Lauri Jutila kommentoi sopimuspohjaa seuraavasti:

    Luin sopimuksen läpi ja se on varmasti hyvä pohja, jota monet osapuolet voivat käyttää sopimusneuvotteluissaan. Roolista (tilaaja, toimittaja) riippuen sopimuksessa oli kohtia, joissa ehkä kannattaa vaatia tai käyttää tiukempaa tai rajaavampaa kieltä, jotta sopimusta saa itselleen edullisemmaksi.

    Tilaaja voisi esim. vaatia muutamat tärkeimmät piirteet ehdottomasti toimitettavaksi projektin aikana, niin kuin olit jo oikeastaan laittanut. Tarkka ostaja antaa lisäksi ehkä vielä vähemmän löysää kuin sinä olit ehdottanut ja vaatii n+1 sprintin jälkeiset työt veloituksetta, jos toimitus viivästyy. Toinen vaihtoehto on myös tehdä ikään kuin puitesopimus sopimaan projektissa käytettävästä sopimus- ja kehitysmallista ja tehdä jokaisesta sprintistä oma toimitussopimus, johon on listattu sprintissä ne piirteet, joihin tiimi sitoutuu.

    Toimittaja voisi luovuttaa IPR:t vasta, kun kaikki laskut ovat maksettu. Ekslusiivisuus kannattaa jättää pois sopimuksesta, ellei siitä erikseen makseta lisää, tai se kannattaa rajata tarkemmin asiakkaan mahdollisiin liikesalaisuuksiin tai kilpailuetuihin. Lähtökohtaisesti kukaan ei toimita kilpailijoille vastaavia järjestelmiä, mutta voi tulla tilanteita, joissa tällaiset sopimusklausuulit voivat rajata liiaksi liiketoimintamahdollisuuksia, vaikka kyse ei olisi yhden asiakkaan liiketoimintasalaisuuksien paljastamisesta toiselle. Esim. CMS-järjestelmän toimitus verkkosivujen hallintaan kahdelle tuontiyritykselle.

    Kiitos Lauri!

  2. Päivitysilmoitus: Ketterän kehityksen ostajan opas julkaistu « larelekman.com

Kommentoi

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s