Tommi Laitila ja Mikko Mustakallio 05.12.2012"

Pragmatic Agile

Pragmatic Agile"

•  Mikä se on?"•  Miten se toimii käytännössä?"•  Mitä asiakas siitä hyötyy?"

Mikä se on?"

Miksi ketterä kehitys? "

•  Perinteinen vesiputousmalli ja sen variantit eivät enää kyenneet vastaamaan vaatimuksiin"–  Järjestelmien koko ja monimutkaisuus teki etukäteen

konseptoinnin (Big Design Up Front) haastavaksi"–  Isoissa hankkeissa ennustettavuus perinteisillä

malleilla oli epätarkkaa"–  Aikatauluvaatimukset (Time-to-market) pakotti

aikaistamaan toteutusta hankkeissa"–  Työntekoa piti tehostaa, johon ratkaisun toi

itseohjautuvat tiimit ja jatkuva priorisointi"

Miksi Pragmatic Agile?"•  Työkalupakki liiketoimintajärjestelmien ketterään

kehittämiseen"

Mitä Pragmatic Agile tuo lisää ketterään kehitykseen "

•  Hyvä takaisinmaksuaika (ROI) "•  Ilman elinkaarikustannusten (TCO) nousua"

Laadukas syöte kehityssykliin"

•  Kehityssykli on kone, joka tuottaa ICT-järjestelmän"–  Ulos tulevan lopputuotteen laatu korreloi syötteen

laadun kanssa"

Tuote-backlog pitää valmistella ennen kuin sprint commitment voi tapahtua"

Tarkoituksenmukaisen arkkitehtuurin varmistaminen (lean)"

Toteutuksesta pienkehitykseen ja ylläpitoon"

Miten se toimii käytännössä?"

CASE"Responsiivinen

kuluttajaverkkopalvelu"

Asiakkaalle aivan uudenlainen sopimus"

•  Lähdettiin rakentamaan uudenlaista luottamussuhdetta välille tilaaja-toimittaja"

•  Puitesopimus pienen, ketterän toimijan kanssa, joka tarjoaa osaamisen liiketoimintakonseptista toteutukseen"

•  Ainoastaan laadullisia mittareita sopimuksessa"•  Asiakkaan ja toimittajan tekijät nivoutuvat yhdeksi tiimiksi"•  Kvartaaleittain hankintatilaus, jonka pohjana tiimien

tarvitsema optimaalinen roolitus tekemisen luonteeseen nähden"

Mitä luvattiin?"•  Oikea ketterän kehityksen malli, jota liiketoiminta voi

ohjata omien prioriteettiensa mukaan"•  Itseohjautuvat Hero-tiimit"•  Aivan uudenlaista näkyvyyttä ja ennustettavuutta

hankkeen etenemiseen"•  Automatisoida kaikki, mikä on järkevästi

automatisoitavissa"•  Laatu aivan uudelle tasolle"•  Kova asenne ja vahva vastuuntunto paikalle"•  Elinkaarikustannusten hallittavuus"

Resources  Infrastructure  Technology  

Solu%on  design   Architecture  

Scrum  Quality  &  

deployment  

Needs  &    Requirements  

Business  

Prod

uc;o

n  

IT  

Enterprise  Architecture  

Architecture  

Releases  

Pragmaattinen malli"

KAPO = Konseptointi, Arkkitehtuuri, Prototyypitys, Operatiivinen malli"

BUSINESS" Design" UI" Concept"Architecture"

Web dev"

Operational Process"

Proto" CMS dev"

Content"

Testing"

BUSINESS" CAPO" DEVELOPMENT" CONTENT" TESTING & UAT"

Hero Team –periaatteet"

I.  Arkkitehtuuri ja ratkaisukonseptointi yhdessä: Vahva arkkitehtuuri- ja ratkaisukonseptointiosaaminen tiimissä keskenään samassa tilassa. Liiketoimintatarpeet selkeytetään ja prosessoidaan tekniseksi ratkaisuksi ja tuotetaan Product backlog -itemit toteutustiimille. Operatiivinen optimointi suoritetaan osana ratkaisukonseptia."

II.  Prototyyppi: HTML5-ulkoasu, CSS-tyylitiedostot, Javascript, grafiikat"III.  Toteutettu ominaisuus: Hero Team tuottaa ratkaisukonsepteista suoraan

tuotantokelpoisia ominaisuuksia (Java-toteutus + CMS-integraatio) "–  Yhteinen vastuu, yhteiset työkalut"

  Saumaton sykli: "–  Ratkaisukonseptoinnista prototyypin kautta operatiivisesti optimoituun

tuotantovalmiiseen järjestelmään" Saumaton toiminnallinen laatu:"

–  Konseptisuunnittelija vastaa lopputuotteen toiminnallisesta laadusta yhdessä kehittäjän kanssa (sign-off ennen hyväksyntätestausta)"

–  Hero Team vastaa testiautomaatiosta ja koodikatselmoinneista"

Vähemmän tekijöitä mutta laajemmissa rooleissa"

•  Pieni, tehokas tiimi tarkoittaa, ettei tarvita dedikoituja henkilöitä kapeisiin “laput silmillä” -rooleihin"

•  Laajemmat roolit tukevat kokonaisuuden ymmärtämistä ja vähentävät vastuurajojen epäselvyyttä"

•  Vähemmän rajapintoja ihmisten/roolien välillä varmistaa saumattoman kommunikaation"

Miten lupaus pidettiin?"

•  Asiakas vahvasti integroitu prosessiin"•  Konseptointi, arkkitehtuurin ohjaus ja protoilu

esisprintissä, joka syötteenä toteutussprinttiin"•  Itseohjautuvat moniosaajatiimit (Hero Team)"•  Testilähtöinen kehitys konseptista ylempiin ympäristöihin"•  Automatisointi kehitykseen, asennuksiin ja testaukseen"

BUSINESS" CAPO" DEVELOPMENT" CONTENT" TESTING & UAT"

Mitkä ovat asiakkaan hyödyt?"

Projektin tila nyt"

I.  Pienemmällä porukalla tehdään isompia asioita nopeammin ja laadukkaammin"

II.  Lopputuotos on täysin testaantuvaa ja design-velka minimoitu (vrt. perinteinen käsitys agile-malleista)"

III.  Velocity on tasaantunut ja ennustettavuus parantunut"IV.  Liiketoiminnan ketterä ohjaus toimii:

liiketoimintavaatimus sisään, toimiva ominaisuus ulos "

Hard Facts* 1/4 – tiimin koko, lähtötilanne vs. Nitor-TB haltuunotto"

0"

10"

20"

30"

40"

50"

60"

70"

Ennen" Nitor-TB"

Projektin pääluku yhteensä"Backlog-itemeita toteutettu"

•  Vaikka projektin pääluku (ml. konseptoijat, arkkitehdit, kehittäjät) on laskenut 1/3-osaan, ominaisuuksia toteutetaan jopa enemmän"

*Vertailun pohjana olevat luvut katsottu yhdessä asiakkaan kanssa kahdesta verrokkisprintistä. Ominaisuus tai backlog item pysynyt kutakuinkin saman kokoisena suureena muttei absoluuttinen luonnonvakio vaan pikemminkin suuntaa-antava yksikkö.

Hard Facts 2/4 - kehittäjän panos per sprintti"

•  Aika, jonka kehittäjät nyt pystyvät dedikoimaan itse kehitystyöhön, on kasvanut 15%"

4,0"

4,5"

5,0"

5,5"

6,0"

6,5"

7,0"

7,5"

8,0"

Ennen" Nitor-TB"

Kehittäjän kontribuutio sprinttiin (htp)"

Hard Facts 3/4 - kehittäjän käyttämä aika vs. toteutettu ominaisuus"

0,0"

1,0"

2,0"

3,0"

4,0"

5,0"

6,0"

7,0"

8,0"

Ennen" Nitor-TB"

HTP:tä / Backlog Item"

•  Hero-tiimin osana toimivilta kehittäjiltä menee nyt n. 60% vähemmän aikaa yhden liiketoiminnan tarvetta vastaavan ominaisuuden* toteuttamiseen"

*Ominaisuus tai backlog item pysynyt kutakuinkin saman kokoisena suureena muttei absoluuttinen luonnonvakio vaan pikemminkin suuntaa-antava yksikkö.

Hard Facts 4/4 - Tekniset parannukset (esimerkkejä)"

•  Käännös ja automaattinen testaus 1/10-osaan "

•  Järjestelmän rakennus ja asennus (kehitysympäristö) 1/20-osaan"•  Mahdollistettiin “build on commit”"

•  Muut ympäristöt olivat manuaalisia ja nyt automatisoitu"

0"

5"

10"

15"

20"

25"

30"

35"

40"

Ennen" Nitor-TB"

Minuuttia"

0"20"40"60"80"

100"120"140"160"180"

Ennen" Nitor-TB"

Minuuttia"

Tekniset parannukset (näkyvyys)"

•  Mitä mitataan näkyy kaikille"

Yhteenveto"

•  Kehityssyklin lopputuote on syötteestä riippuvainen, saumaton yhteistyö varmistaa tehokkuuden ja laadun "

•  Selkeät vastuut (DoD) ja saumattomat hand-overit varmistavat, että kehittäjät tekevät oikeita asioita eikä heidän työnsä keskeydy kesken sprintin "

•  Asiakkaiden ei enää tarvitse ostaa isoja projekteja ja useita erilaisia mutta kapeita rooleja, vaan keskittyä moniosaajiin, jotka tehokkaasti tuottavat liiketoimintavaatimuksista toimivan järjestelmän"

Asiakkaamme kertovat"

”Oikeasti, hyvät tyypit ja rutkasti asiantuntemusta”

“They have good working moral and always look for the best interest of the customer.” “Talent Base and NitorCreations’ people

stand out especially with subject matter expertise and mastering of their responsibility areas” “I personally would prefer a small

service provider like NitorCreations to a large service vendor with complicated hierarchy and processes”

“They stand out with their brilliant down-to-earth, humble and always helpful attitude”

“If something isn’t clear to myself or others in the business, your guys patiently take the time to explain or bring in others who can help”

“Easy to approach with any questions at any time, no matter what the issue”

THIS IS WHAT COUNTS:

☐ Team delivers working, tested software after each iteration ☐ Team delivers what the business needs most ☐ Team is continuously improving its practices

☐ Clearly defined product owner (PO) ☐ PO is dedicated to the project and easily available to the team ☐ PO is empowered and has knowledge to prioritize ☐ PO has direct contact with team ☐ PO has direct contact with stakeholders

☐ PO maintains a product backlog (PBL) ☐ PBL is prioritized by business value ☐ PBL is visible to the team

☐ Top PBL items are well understood and ready for development ☐ Grooming takes place before sprint planning ☐ Bizcases have been approved ☐ Architectural implications to other systems have been agreed ☐ UI mockups have been created an verified ☐ Items have been estimated by the team ☐ Items are small enough to fit in a sprint

☐ Team understands architecture and goals of surrounding systems ☐ Team receives architectural guidance when needed ☐ Team can bring up architectural issues and proposals ☐ Issues and proposals are managed transparently

☐ Team has sprint planning meetings ☐ PO brings an up-to-date PBL with well-understood items ☐ Whole team and PO participates ☐ Meeting is not longer than 4 hours ☐ Team decides what fits into the sprint ☐ Team has a visible sprint backlog and a burndown chart

☐ Team has a release burndown chart ☐ Teams estimate in story points rather than hours ☐ Team velocity is measured and used for release planning

POSITIVE INDICATORS:

☐ Team is having fun and is being trusted by stakeholders ☐ Work generally takes place within the limits of normal working hours ☐ The atmosphere is open for discussing, experimenting and criticizing

Pragmatic Agile check list v1.1

☐ Daily scrum (max 15 minutes) takes places daily at the same time ☐ Whole team participates ☐ Impediments surface and are dealt with

☐ Clearly defined scrum master (SCM) who is not PO ☐ Team knows top impediments ☐ SCM works actively to solve impediments ☐ Escalated to mgmt. when team cannot solve

☐ All code is automatically tested ☐ Continuous integration is used ☐ Unit tests are written and test coverage is followed ☐ Acceptance tests are automated and created based on user stories

☐ Demos are held after each sprint before the next one starts ☐ PO and the required stakeholders participate ☐ Useful feedback is received

☐ Retrospective takes place after each sprint ☐ The entire team including the PO participates ☐ Results in improvement proposals and some get implemented

☐ Sprints of max 4 weeks ☐ Thee sprints always end on time ☐ Team usually finished most items ☐ Team is not disrupted by other tasks ☐ Team possesses all skills required for completing items