Meten in een agile omgeving:Van denken in

oplossingen naar denken in eisen

Brian Teunissen

Nesma, 8 September 2015

© inspearit 1

Telt FPA nog wel mee?

© inspearit

Introductie

Brian Teunissen | Senior Agile Consultant

https://nl.linkedin.com/in/teunissen

Agile Master| SAFe Program Consultant

inspearit  Aligning for Customer Valuecibit academy  inspearit Brand for Training Services

Park Berg & Bosch | Professor Bronkhorstlaan 10/90 | 3723 MB Bilthoven | The Netherlands

T: +31 30 230 89 00 | M: + 31 6 215 30 209

Brian.Teunissen@inspearit.com

www.inspearit.nl | www.cibit.nl

Slide 2

Onderwerpen

© inspearit

Denken in eisen of oplossingen? De paradigma shiftBusiness waarde vs Functionaliteit? Wat te meten?Wanneer wel en geen FPA?

3

Denken in eisen of oplossingen?

De paradigma shift

© inspearit 5

6. Changing Requirements & Specifications

7. Lack of Planning8. Didn't Need It Any Longer9. Lack of IT Management10.Technology Illiteracy

1. Incomplete Requirements2. Lack of User Involvement3. Lack of Resources4. Unrealistic Expectations5. Lack of Executive Support

Standish Group: Top-10 reasons why to fail ICT projects

We never write down WHAT the customer wants, only HOW we are going to solve it!© inspearit 6

Paradigma shift: van denken in oplossingen naar denken in eisen

© inspearit

Geen BDUFInhoudelijke besluiten zo laat mogelijkOntwerp in de bouwsprint zelf, per storyUser story bevat detail gebruikers eis, geen ontwerpVoorkom overbodig werk:

Simplicity – the art of maximizing the amount of work not done – is essential

Real Options: Early decisions are likely to be wrong and cause rework, so defer to the last responsible moment

7

© inspearit 8

Ontwerp op laatste moment

© inspearit 9

O O OB B BT T TO O OB B BT T T

O O OB B BT T T

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

De paradigma shift werkt niet in klassieke demand supply omgevingen

© inspearit 10

FPA vaak gebruikt als inkoop / onderhandelings metriek, hetgeen vooraf meten impliceertFixed prices werken niet in een agile omgeving, impliceert tevens BDUFAdministratieve processen vaak ingericht op begrotingen en uitputting van budgetten per item, project, wijzigingsvoorstel

Financiële sturing ipv inhoudelijke

Business waarde vs Functionaliteit?

Wat te meten?

Business waarde <> Functionaliteit

Getting business value and complexity points

A common tool in Agile is PLANNING POKER

Weighted Shortest Job First

14

Absoluut vs relatief tellen

15

Hoe dan wel absoluut?Requirements points? RPA?

16

Use Case

Brief DescriptionTellen van flows en steps in Business en System Use cases?

Nadeel: Afhankelijkheid van documentatiewijze

Dus? Wanneer wel en geen FPA?

“Function points eliminated a number of the problems with

lines of code, but still requires a significant amount of work up-

front”

Jim Highsmith in voorwoord van boek‘Agile estimating and planning’ van Mike Cohn:

© inspearit 18

Mijn stellingen:

© inspearit 19

1. Gebruik FPA niet vooraf, dat werkt waterval denken en waterval werken in de hand.

2. Gebruik vooraf relatieve schattingen van business waarde en inspanning, ook om te kunnen prioriteren (koppeling aan economische waarde).

3. Gebruik FPA achteraf voor gehele releases (niet stories) waar er behoefte is aan benchmarking intern en extern. Deze combinatie kan elkaar versterken (Vooraf borgen dat er business waarde wordt gecreëerd, achteraf benchmarken van gerealiseerde functionaliteit die ook echt wordt gebruikt.

4. Laat bestaande administratieve processen en KPI’s niet een agile manier van werken belemmeren.

5. In Agile, en zeker scaling agile vormt een nieuwe set aan metrieken de basis voor het daadwerkelijk meten van het primaire IT proces (IT lifecycle). Bestaande metrieken zijn vaak basis voor een oude manier van besturen, gebaseerd op geschatte uren per item en uitputting van die uren. Dit is sturen op financiën en scope afspraken, en niet op je primaire proces en kort cyclisch leveren van business waarde!

© inspearit 20

Blogs:

© inspearit 21

Deel 1: Over volwassenheidsniveau 1: Agile/Scrum binnen het projectenparadigma / de projecten matrix organisatiehttp://www.cibit.nl/nl/nieuws/blogs/van-scrum-team-naar-agile-organisatie-24364/Deel 2: Over volwassenheidsniveau 2: Het samenstellen van virtuele vaste multi disciplinaire teams, het verlaten van het projecten paradigmahttp://www.cibit.nl/nl/nieuws/blogs/van-scrum-team-naar-agile-organisatie/Deel 3: Over volwassenheidsniveau 3: Het vormen (reorganiseren) van de structuur van de organisatie naar de value streams, eventueel al aangevuld met operations voor DevOpshttp://www.cibit.nl/nl/nieuws/blogs/van-scrum-team-naar-agile-organisatie-24702/Deel 4: Over volwassenheidsniveau 4: Het samenvoegen van Dev en Ops in de organisatiehttp://www.cibit.nl/nl/nieuws/blogs/van-scrum-team-naar-agile-organisatie-26213/Deel 5: Over volwassenheidsniveau 5: Het de-centraliseren van DevOps naar value streams/business producten, en continue organisatie structuur verbeteringhttp://www.cibit.nl/nl/nieuws/blogs/van-scrum-team-naar-agile-organisatie-28774/Over hoe velocity te meten in combinatie met structureel terugdringen van technische schuld en continue procesverbeteringhttp://www.cibit.nl/nl/nieuws/blogs/melk-produceren-of-poepscheppen/Over het toepassen van Scrum/agile en zelfs SAFe principes en practices voor het implementeren van agile frameworkshttp://www.cibit.nl/nl/nieuws/blogs/eet-je-eigen-hondenvoer/Over de grote besparingen in overhead die men kan realiseren door lean budgetteren bij scaling agilehttp://www.cibit.nl/nl/nieuws/blogs/pak-die-banaan/Vervolg op eet je eigen hondenvoer, ervaring met het opschalen met SAFe, scaling is een organisatieveranderinghttp://www.cibit.nl/nl/nieuws/blogs/de-taaie-kant-van-scaling-agile/

© inspearit

22