Open Agile Romania 2011/Johan Lybaert - Agile Open Romania the Ventouris Case

Agile Open Romania

the Ventouris Case

Close collaboration

with the customer lead to a

successful VENTOURIS project

Johan Lybaert Program Manager

Cegeka

With about 1.600 people and a

total turnover of about 156 million

euro, Cegeka undeniably

positions itself within the top 10

of end-to-end solution providers

in the Benelux.

Cegeka is a unique and

complete supplier that covers all

the elements of the ICT value

chain; from strategy over

development to ’full’ outsourcing

Cegeka has a NOC and

software development team in

Romenia.

OFFICES

Hasselt

Leuven

Antwerpen

Waregem

Veenendaal

Gorinchem

Luik

Bucharest (inside)

DATA CENTERS

Hasselt

Leuven

Veenendaal

cegeka

Cegeka, the company

Overall Presentation Goal

show how agile development practices

can help you to build the application the customer

really needs

Speaker’s Qualifications

Johan is an experienced program/delivery manager (> 30 years)

Involved in J2EE projects for the last 7 years

His track of successful delivery is based on the continuous adaptation & application of relevant methodologies

Johan believes that the agile development approach is a step forward to the realization of successful projects

Chairman of the Belgium Chapter of the Agile Consortium

Working in close collaboration with

your customer is a key success

factor in IT projects.

In other words: the lack of

collaboration is one of the most

important causes of failure.

Customers: 8 social security funds

Accountancy

Bailiff

Bank

Payments

• receive

• reassign

• reimburse

Calculation

Family allowance

Self-employed

NISS

E

Suspension

Request remission /

exemption Debt administration

• Reminder

• Summons

• Subpoena

Affiliation

File

Modifications

• Self-employed activity

• Look up and process income data

• Career data

• Continued insurance

• Discharge

• Pension

• Decease

• Failure (insurance)

• Normal suspension: request

• equalization

• continued insurance

FCP

VENTOURIS

Ventouris context

Contract fixed price for 5 out of 8 customers Contract Time & Materials for 3 biggest customers = 77% Functional en Non Functional requirements document Decisions taken in workgroups on the basis of concensus Service level agreements for the exploitatie for 7 years Clear performance and availability SLA’s Clear Scope Change Management process agreed Includes also the migration from mainframe to the new platform Deployment & data cleaning activities in time & materials 6 weekly steering committee with the 3 biggest customers Timing was not a contractual goal Scope & Quality was more important than budget

Online Processing

Technology Renewal

Richer Information Model

Document Generation

Rule Based Engine

Business Process Engine

B2B data exchange with NISSE (RSVZ, INASTI)

Service Desk

Ease to integrate with legacy applications

Purpose of the renewal

Application Architecture overview

1. Getting the requirements identified and agreed with

the 8 customers in concensus

2. Respecting the budget

3. Integrate smoothly new (legal) requirements –

embrace change

4. Performance of the application -> clear SLA’s

upfront defined

5. Duration of the project – estimated at 3-4 years –

be able to cope with turn-over of teamplayers

6. Migration of the existing mainframe data towards

the new environment

What were the biggest risks?

building a product for 8 customers requires very close

collaboration to get it right

early feedback is a must for customer satisfaction

going for a detailed design phase does not guarantee the

customer will get what he wants. Most of the time he does not

know how he wants certain functionalities to be implemented.

only by demonstrating the functions, real discussions take

place

New requirements: 2-weekly iterations & change control

Migrate & perform Data Quality in parallel with the

develoment

Continuous integration – integrate performance tests

Collective ownership – reduce de busfactor

The agile approach as risk mitigation !

Agile software development

Agile Software Development

XP Basics

XP Practices

Scrum Basics

Scrum Practices

Agile@Software Factory

Committed to deliver high quality applications for its customers…

…in the most productive way!

Being able to change course quickly…

…while staying on track to reach the goals.

That is what we call an Agile vision on project management

No waterfall approach…

Prioritized feature list

Develop

Adapt

Plan

Inspect

Iteration features Product

…but iterative and incremental

Agile Manifesto

Individuals & interactions

Working software

Customer collaboration

Responding to change

Processes & tools

Comprehensive documentation

Contract negotiation

Following a plan

... have more

value than ...

Agile Values:

Commitment – clear responsibilities, empowerment to decide

Focus – well defined backlog, dedicated team

Openness – all issues on the table

Respect – for each other‟s expertise, for different ways of thinking

Courage – to solve the problems when they occur, no postponement, no concealment

Open communication – no hidden agenda

Development Metaphor

Washing-machine

Focus on the following practices

Can be distributed with developers from Romania & Belgium

An agile cross functional

feature team

Agile development

Product backlog

Daily

Scrum

Analyse per

module

User story

Testontwikkeling

Development2-weekly

Sprint

2-weekly

Sprint

Test driven development

Coding / Refactoring

Unittesten (story based)

Daily build (= integratietesten)

Arc

hite

ctu

ur

Productie

Bu

sin

ess

pro

cessen

Dep

loym

en

t

TestenUpdate

analyserapport

<submodule>

Data migratie

Sprint backlog

Sprint design

walkthrough

UItwerken

user stories

1. Brainstorm

2. Werksessie

<submodule>

Analyse

<submodule>

Globale analyse

Design

Identificeren

business

processen

Opleiding

& Roll out

Acceptatietesten

(alfa & beta)

Acceptatie

analyse

Systeemtesten

Klant

Exploratory

testen

Demo voor de

klant

Potentialy

Shippable

Product

Proxy testen en

onsitecustomer

(exploratory)

Update

analyserapport

<submodule>

klantklant

Legende

Betrokkenheid

van de klant

Analysedocument

Procesflows

Maquette

Schermen

Domain &

Design

Slide 27

cegeka

User stories Scope control? =>

contract?!

Use cases required ?

slicing in stories not easy?

which preparation required for a story?

splitting stories in tasks

on-site customer concept

8 companies? proxy-customer

concept

Proxy-customer can’t replace the on-

site customer because he doesn’t

has the daily experience of the real

user

Try to get a real on-site customer

Only demo’s is not providing enough

real customer feedback

Introduction of exploratory, tests

after each sprint helps in getting

early feedback

Small releases

Replace existing system requires major releases, but made by small incrementals (sprints)

Daily follow-up of ETC per story is essential

Burndown sheets visable for the team motivates

Lessons learned on stand-up

meeting Organise scrum per team &

scrum of scrums

Avoid having multiple status meetings

Always same time, same place

Presence is required!

Start the day with a scrum

Avoid reporting to the leader

Avoid problem solving

Testing Test-first

programming = not a natural reflex

Regression Test Automatisation is essential

Technically not easy to apply on all code

Lessons learned on collective

ownership: it works!

Technology diversity is a challenge

The team respects the code standards

Extra education & information sessions required, invest in it, it will pays off

Keep the project WIKI up to date

Assign owners for each technical component to act as coach for the others

Not everybody can master all technical aspects from day-one

pair programming

Lessons learned on continuous integration

Goal is at least one successfull build every day

Build in 10’ is important

Dedicated build manager is a must in a large team

Make multiple build environments

main build

migration build

...

Use of synchronisation token

Lessons learned on refactoring

Not a natural reflex

Educate the team, use real smells as example

Give them courage, it will pay-off

Refactor if you don’t understand the code

Refactor only the code you are working on

But only refactor when it hurts

Late refactorings costs a lot

Is often perceived as conflicting with

finishing the agreed scope of an

iteration

Simple design

Need for lead architect

Assign a design coach

Involve experts in the first technical implementations

Courage

Lessons learned on pair programming

Make teams of 6 dev + 1 coach

Change pairs every half a day

Combine experienced & starter developers

Exchange people each sprint

Pair under the following circumstances:

during the start phase of a project to get a common understanding

as newcommer

new technology

difficult business

Scrum project approach

Analysis

Product

Backlog

Sprint

Planning

Meeting

Sprint

Backlog

Product

Increment

Sprint

Review

Meeting

Estimation

Meeting

Daily

Scrum

Meeting

User Story User Story

User Story User Story

User Story

Sprint of 2 weeks

Backlog = list of all tasks

Product backlog = all backlog items

Release backlog = backlog items for a release

Sprint backlog = backlog items for a sprint

Estimation meeting

Estimations through story points (0,25 ;0,5 ;1 ;1,5 ;2 ; 2,5)

Proxy customer & business expert explain the task to be

developed

Developer makes a binding estimate of the delivery effort

Estimate backlog

Planning game

Prioritize the backlog (business value or technical

risk)

(Proxy) customer chooses the stories for the next

release/iteration

Capacity of the team is calculated on the basis of

metrics.

Load Factor („velocity‟) is the ratio of story points

expressed in mandays.

Metaphor of yesterday‟s weather

Planning of the next sprint

Remaining effort team BMW (hours)

-50

0

50

100

150

200

250

300

350

400

450

initial

4/ok

t

5/ok

t

8/ok

t

9/ok

t

10/okt

11/okt

12/okt

15/okt

16/okt

17/okt

It1A It1B It2A It2B

story points 72,5 19,8 17,6 26 9,1

velocity 2,00 2,00 2,00 2,00

cumulative story points 19,8 37,4 63,4 72,5

remaining story points 72,5 52,7 35,1 9,1 0

If you can only remember one thing…

“Real close collaboration

with the customer is

one of the most

important critical

success factors for a

project.

The agile development

approach enables this

collaboration model”

Q&A

Cegeka References

Ventouris 30.000 md 4 years 60 experts

BMW 1.000 md 9 months 9 experts

Argenta BOAR + mutaties

2.000 md + 1.000 md

1 year + 9 months

12 experts +8 experts

Argenta On-line kantoor (ongoing)

8.000 md 2 years 30 experts

Argenta STPLeven 900 md 9 months 8 experts

VDAB 3.000 md 1 year 20 experts

Eurocross 500 md 6 months 5 experts

RKW 10.000 md 24 months 25 experts

Contact info:

Johan Lybaert

[email protected]

Cegeka ICT diensten nv Interleuvenlaan 16

3001 Leuven

www.cegeka.be

Inside Software

Laurentiu Oprea

Bucharest, Romania

Phone: +40 21 3362065

[email protected]

www.insidesoftware.ro

Place your bets

Make a chance to win