1. Agile Open Romania
the Ventouris Case

2. Close collaboration
with the customer lead to a
successful VENTOURIS project
Johan Lybaert
Program Manager
Cegeka

3. Cegeka, the company
 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
OFFICES
 Cegeka is a unique and Hasselt
Leuven
complete supplier that covers all Antwerpen
the elements of the ICT value Waregem
Veenendaal
chain; from strategy over Gorinchem
development to ’full’ outsourcing Luik
Bucharest (inside)
Cegeka has a NOC and DATA CENTERS
Hasselt
software development team in Leuven
Romenia. Veenendaal

4. Overall Presentation Goal
show how agile
development practices
can help you to build the
application the customer
really needs

5. 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

6. 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.

7. Customers: 8 social security funds

8. VENTOURIS
Bank
• Self-employed activity
• Look up and process income data Payments
• Career data • receive Bailiff
• Continued insurance • reassign
• reimburse
Accountancy
Request remission / Debt administration
exemption • Reminder
• Summons
Modifications
FCP • Subpoena
• Discharge
• Pension
Calculation File • Decease
• Failure (insurance)
• Normal suspension: request
• equalization
Family allowance • continued insurance
NISS
E Self-employed
Affiliation
Suspension

9. 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

10. Purpose of the renewal
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

11. Application Architecture overview

12. What were the biggest risks?
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

13. The agile approach as risk mitigation !
 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

14. Agile software development
Agile Software Development
XP Basics Scrum Basics
XP Practices Scrum Practices
Agile@Software Factory

15. Committed to deliver high quality
applications for its customers…

16. …in the most
productive way!

17. Being able to change
course quickly…

18. …while staying on track to
reach the goals.

19. That is what we call an
Agile vision on project
management

20. No waterfall approach…

21. …but iterative and incremental
Plan Develop
Iteration
features Product
Adapt Inspect
Prioritized
feature list

22. Agile Manifesto
... have more
value than ...
Individuals & Processes &
interactions tools
Working Comprehensive
software documentation
Customer Contract
collaboration negotiation
Responding to Following a
change plan

23. Open communication – no hidden agenda
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

24. Development Metaphor
Washing-machine

25. Focus on the following practices

26. An agile cross functional
feature team
Can be distributed with developers from Romania & Belgium

27. Identificeren
proce
Busin
business Productie
processen
Analyse per
ssen
Opleiding
ess
Design
& Roll out
module
t
Acceptatietesten
Globale analyse
en
(alfa & beta)
ym
Ar
Procesflows
plo
Analyse Maquette Acceptatie
ch
<submodule> Schermen analyse
Domain &
De
Design
ite
Analysedocument
c
1. Brainstorm
tuu
2. Werksessie Systeemtesten
<submodule>
Daily
r
Scrum
Klant
UItwerken User story Exploratory
user stories
testen
Testontwikkeling
Product backlog
2-weekly
Sprint design Demo voor de
walkthrough Sprint klant
Legende
Development
Test driven development
Potentialy
Coding / Refactoring
Sprint backlog
2-weekly Shippable
Product
Unittesten (story based)
Sprint
Betrokkenheid Daily build (= integratietesten)
van de klant
klant Proxy testen en
Data migratie onsitecustomer
(exploratory)
cegeka Testen
Update
analyserapport
Agile development
<submodule>
Slide 27

28. User stories
Scope control? =>
contract?!
Use cases required ?
 slicing in stories not
easy?
 which preparation
required for a story?
 splitting stories in tasks

29. 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

30. 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

31. 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

32. Testing
 Test-first
programming = not
a natural reflex
 Regression Test
Automatisation is
essential
 Technically not easy
to apply on all code

33. 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

34. 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

35. 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

36. Simple design
 Need for lead architect
 Assign a design coach
 Involve experts in the first
technical implementations
 Courage

37. 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

38. Scrum project approach
Sprint of 2 weeks
Analysis
User Story
User Story
User Story Story
User
User Story
Product Sprint Product
Backlog Backlog Increment
Sprint Daily Sprint
Estimation
Planning Scrum Review
Meeting
Meeting Meeting Meeting

39. Estimate backlog
 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

40. Planning of the next sprint
 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. 450
Remaining effort team BMW (hours)
Metaphor of yesterday‟s weather
400
350
300
250
It1A It1B It2A It2B
200
150
story points 72,5 19,8 17,6 26 9,1
velocity 2,00 2,00 2,00 2,00 100
cumulative story points 19,8 37,4 63,4 72,5 50
remaining story points 72,5 52,7 35,1 9,1 0 0
kt
kt
kt
kt
kt
kt
al
t
t
t
t
ok
ok
ok
ok
it i
/o
/o
/o
/o
/o
/o
4/
5/
8/
9/
in
10
11
12
15
16
17
-50

41. 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”

42. Q&A

43. Cegeka References
Ventouris 30.000 md 4 years 60 experts
BMW 1.000 md 9 months 9 experts
Argenta BOAR + 2.000 md 1 year 12 experts
mutaties + 1.000 md + 9 months +8 experts
Argenta On-line 8.000 md 2 years 30 experts
kantoor (ongoing)
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

44. Contact info:
Johan Lybaert
johan.lybaert@cegeka.be
Cegeka ICT diensten nv
Interleuvenlaan 16
3001 Leuven
www.cegeka.be
Inside Software
Laurentiu Oprea
Bucharest, Romania
Phone: +40 21 3362065
Laurentiu.Oprea@insidesoftware.ro
www.insidesoftware.ro

45. Place your bets
Make a chance to win