Pragmatic Agile: Mikä se on? Miten se toimii käytännössä? Mitä asiakas siitä hyötyy?

1. Pragmatic Agile
Tommi Laitila ja Mikko Mustakallio
05.12.2012"

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

3. Mikä se on?"

4. 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"

5. Miksi Pragmatic Agile?"
• Työkalupakki liiketoimintajärjestelmien ketterään
kehittämiseen"

6. Mitä Pragmatic Agile tuo lisää ketterään
kehitykseen "
• Hyvä takaisinmaksuaika (ROI) "
• Ilman elinkaarikustannusten (TCO) nousua"

7. Laadukas syöte kehityssykliin"
• Kehityssykli on kone, joka tuottaa ICT-järjestelmän"
– Ulos tulevan lopputuotteen laatu korreloi syötteen
laadun kanssa"

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

9. Tarkoituksenmukaisen arkkitehtuurin
varmistaminen (lean)"

10. Toteutuksesta pienkehitykseen ja ylläpitoon"

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

12. CASE"
Responsiivinen
kuluttajaverkkopalvelu"

13. 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"

14. 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"

15. Pragmaattinen malli"
Business
Needs
&
Requirements
Produc;on
Solu%on
Architecture
design
IT
Resources
Infrastructure
Releases
Technology
Quality
&
Scrum
deployment
Enterprise
Architecture
Architecture

16. KAPO = Konseptointi, Arkkitehtuuri,
Prototyypitys, Operatiivinen malli"
BUSINESS" Design" UI" Proto" Concept" Web dev" CMS dev" Testing"
Architecture"
Operational Process"
Content"
BUSINESS" CAPO" DEVELOPMENT" CONTENT" TESTING & UAT"

17. 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"

18. 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"

20. 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"

21. Mitkä ovat asiakkaan
hyödyt?"

22. 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 "

23. Hard Facts* 1/4 – tiimin koko,
lähtötilanne vs. Nitor-TB haltuunotto"
• Vaikka projektin pääluku
70"
(ml. konseptoijat,
arkkitehdit, kehittäjät) on 60"
laskenut 1/3-osaan, 50"
ominaisuuksia
40"
toteutetaan jopa Projektin pääluku
yhteensä"
Backlog-itemeita
enemmän" 30" toteutettu"
20"
10"
0"
Ennen" Nitor-TB"
*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ö.

24. Hard Facts 2/4 - kehittäjän panos per sprintti"
• Aika, jonka kehittäjät
8,0"
nyt pystyvät
7,5"
dedikoimaan itse
7,0"
kehitystyöhön, on
6,5"
kasvanut 15%" 6,0" Kehittäjän kontribuutio
sprinttiin (htp)"
5,5"
5,0"
4,5"
4,0"
Ennen" Nitor-TB"

25. Hard Facts 3/4 - kehittäjän käyttämä aika vs.
toteutettu ominaisuus"
• Hero-tiimin osana
toimivilta kehittäjiltä 8,0"
menee nyt n. 60% 7,0"
vähemmän aikaa 6,0"
yhden liiketoiminnan 5,0"
tarvetta vastaavan 4,0" HTP:tä / Backlog Item"
ominaisuuden* 3,0"
toteuttamiseen" 2,0"
1,0"
0,0"
Ennen" Nitor-TB"
*Ominaisuus tai backlog item pysynyt kutakuinkin saman kokoisena suureena muttei absoluuttinen luonnonvakio vaan
pikemminkin suuntaa-antava yksikkö.

26. Hard Facts 4/4 - Tekniset parannukset
(esimerkkejä)"
40"
35"
• Käännös ja automaattinen 30"
testaus 1/10-osaan " 25"
20" Minuuttia"
15"
10"
5"
0"
• Järjestelmän rakennus ja Ennen" Nitor-TB"
asennus (kehitysympäristö)
180"
1/20-osaan" 160"
140"
• Mahdollistettiin “build on commit”" 120"
100"
• Muut ympäristöt olivat 80"
Minuuttia"
manuaalisia ja nyt 60"
40"
automatisoitu" 20"
0"
Ennen" Nitor-TB"

27. Tekniset parannukset (näkyvyys)"
• Mitä mitataan näkyy kaikille"

28. 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"

29. Asiakkaamme kertovat"
”Oikeasti, hyvät tyypit ja rutkasti asiantuntemusta”
“They stand out with their brilliant down-to-
“They have good working moral earth, humble and always helpful attitude”
and always look for the best
“Talent Base and NitorCreations’ people
interest of the customer.”
stand out especially with subject matter
expertise and mastering of their
“I personally would prefer a small responsibility areas”
service provider like NitorCreations to
“Easy to approach with any
a large service vendor with
questions at any time, no matter
complicated hierarchy and processes”
what the issue”
“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”

30. ☐ 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 Pragmatic Agile check list v1.1
☐
PO has direct contact with stakeholders
☐
PO maintains a product backlog (PBL) ☐
Daily scrum (max 15 minutes) takes places daily at the same time
☐
PBL is prioritized by business value ☐
Whole team participates
☐
PBL is visible to the team ☐
Impediments surface and are dealt with
☐
Top PBL items are well understood and ready for development ☐
Clearly defined scrum master (SCM) who is not PO
☐
Grooming takes place before sprint planning ☐
Team knows top impediments
☐
Bizcases have been approved ☐
SCM works actively to solve impediments
☐
Architectural implications to other systems have been agreed ☐
Escalated to mgmt. when team cannot solve
☐
UI mockups have been created an verified
☐
Items have been estimated by the team ☐
All code is automatically tested
☐
Items are small enough to fit in a sprint ☐
Continuous integration is used
☐
Unit tests are written and test coverage is followed
☐
Team understands architecture and goals of surrounding systems ☐
Acceptance tests are automated and created based on user stories
☐
Team receives architectural guidance when needed
☐
Team can bring up architectural issues and proposals ☐
Demos are held after each sprint before the next one starts
☐
Issues and proposals are managed transparently ☐
PO and the required stakeholders participate
☐
Useful feedback is received
☐
Team has sprint planning meetings
☐
PO brings an up-to-date PBL with well-understood items ☐
Retrospective takes place after each sprint
☐
Whole team and PO participates ☐
The entire team including the PO participates
☐
Meeting is not longer than 4 hours ☐
Results in improvement proposals and some get implemented
☐
Team decides what fits into the sprint
☐
Team has a visible sprint backlog and a burndown chart ☐
Sprints of max 4 weeks
☐
Thee sprints always end on time
☐
Team has a release burndown chart ☐
Team usually finished most items
☐
Teams estimate in story points rather than hours ☐
Team is not disrupted by other tasks
☐
Team velocity is measured and used for release planning ☐
Team possesses all skills required for completing items
THIS IS WHAT COUNTS: POSITIVE INDICATORS:
☐
Team delivers working, tested software after each iteration ☐
Team is having fun and is being trusted by stakeholders
☐
Team delivers what the business needs most ☐
Work generally takes place within the limits of normal working hours
☐
Team is continuously improving its practices ☐
The atmosphere is open for discussing, experimenting and criticizing