Agile Open Romaniathe Ventouris Case
Close collaboration  with the customer lead to asuccessful VENTOURIS project        Johan Lybaert      Program Manager    ...
Cegeka, the company With about 1.600 people and atotal turnover of about 156 millioneuro, Cegeka undeniablypositions itse...
Overall Presentation Goal    show how agile  development practices can help you to build the application the customer     ...
Speaker’s QualificationsJohan is an experienced program/deliverymanager (> 30 years)Involved in J2EE projects for the last...
Working in close collaboration with  your customer is a key success       factor in IT projects.   In other words: the lac...
Customers: 8 social security funds
VENTOURIS                                                                                                       Bank      ...
Ventouris context Contract fixed price for 5 out of 8 customers Contract Time & Materials for 3 biggest customers = 77%...
Purpose of the renewalOnline ProcessingTechnology RenewalRicher Information ModelDocument GenerationRule Based EngineBusin...
Application Architecture overview
What were the biggest risks?1. Getting the requirements identified and agreed with   the 8 customers in concensus2. Respec...
The agile approach as risk mitigation ! building a product for 8 customers requires very close  collaboration to get it r...
Agile software development       Agile Software Development    XP Basics            Scrum Basics   XP Practices         Sc...
Committed to deliver high qualityapplications for its customers…
…in the mostproductive way!
Being able to changecourse quickly…
…while staying on track toreach the goals.
That is what we call anAgile vision on projectmanagement
No waterfall approach…
…but iterative and incremental               Plan                Develop                       Iteration                  ...
Agile Manifesto                        ... have more                        value than ...Individuals &                   ...
Open communication – no hidden agendaAgile Values:   Commitment – clear responsibilities,   empowerment to decide    Focus...
Development Metaphor  Washing-machine
Focus on the following practices
An agile cross functional            feature teamCan be distributed with developers from Romania & Belgium
Identificeren          proce          Busin            business                                                           ...
User stories                   Scope control? =>                       contract?!                  Use cases required ?   ...
on-site customer concept 8 companies?  proxy-customer  concept Proxy-customer can’t replace the on-  site customer beca...
Small releases                  Replace existing                   system requires major                   releases, but ...
Lessons learned on stand-up          meeting                    Organise scrum per team &                     scrum of sc...
Testing           Test-first            programming = not            a natural reflex           Regression Test         ...
Lessons learned on collective                ownership: it works! Technology diversity is a challenge The team respects ...
Lessons learned on continuous integration Goal is at least one successfull build  every day Build in 10’ is important D...
Lessons learned on refactoring             Not a natural reflex             Educate the team, use real smells as example...
Simple design                 Need for lead architect                 Assign a design coach                 Involve exp...
Lessons learned on pair programming                        Make teams of 6 dev + 1                         coach         ...
Scrum project approach                                                      Sprint of 2 weeks              Analysis       ...
Estimate backlog Backlog = list of all tasks  Product backlog = all backlog items  Release backlog = backlog items for ...
Planning of the next sprint Planning game  Prioritize the backlog (business value or technical   risk)  (Proxy) custome...
If you can only remember one      thing…“Real close collaboration   with the customer is      one of the most     importan...
Q&A
Cegeka ReferencesVentouris           30.000 md        4 years   60 expertsBMW                  1.000 md     9 months      ...
Contact info:Johan Lybaertjohan.lybaert@cegeka.beCegeka ICT diensten nvInterleuvenlaan 163001 Leuvenwww.cegeka.beInside So...
Place your betsMake a chance to win
Upcoming SlideShare
Loading in …5
×

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

719 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
719
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

  1. 1. Agile Open Romaniathe Ventouris Case
  2. 2. Close collaboration with the customer lead to asuccessful VENTOURIS project Johan Lybaert Program Manager Cegeka
  3. 3. Cegeka, the company With about 1.600 people and atotal turnover of about 156 millioneuro, Cegeka undeniablypositions itself within the top 10of end-to-end solution providersin the Benelux. cegeka OFFICES Cegeka is a unique and Hasselt Leuvencomplete supplier that covers all Antwerpenthe elements of the ICT value Waregem Veenendaalchain; from strategy over Gorinchemdevelopment to ’full’ outsourcing Luik Bucharest (inside)Cegeka has a NOC and DATA CENTERS Hasseltsoftware development team in LeuvenRomenia. Veenendaal
  4. 4. Overall Presentation Goal show how agile development practices can help you to build the application the customer really needs
  5. 5. Speaker’s QualificationsJohan is an experienced program/deliverymanager (> 30 years)Involved in J2EE projects for the last 7 yearsHis track of successful delivery is based on thecontinuous adaptation & application of relevantmethodologiesJohan believes that the agile developmentapproach is a step forward to the realization ofsuccessful projectsChairman of the Belgium Chapter of the AgileConsortium
  6. 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. 7. Customers: 8 social security funds
  8. 8. VENTOURIS Bank • Self-employed activity • Look up and process income data Payments • Career data • receive Bailiff • Continued insurance • reassign • reimburseAccountancy 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. 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 newplatform 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. 10. Purpose of the renewalOnline ProcessingTechnology RenewalRicher Information ModelDocument GenerationRule Based EngineBusiness Process EngineB2B data exchange with NISSE (RSVZ,INASTI)Service DeskEase to integrate with legacyapplications
  11. 11. Application Architecture overview
  12. 12. What were the biggest risks?1. Getting the requirements identified and agreed with the 8 customers in concensus2. Respecting the budget3. Integrate smoothly new (legal) requirements – embrace change4. Performance of the application -> clear SLA’s upfront defined5. Duration of the project – estimated at 3-4 years – be able to cope with turn-over of teamplayers6. Migration of the existing mainframe data towards the new environment
  13. 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. 14. Agile software development Agile Software Development XP Basics Scrum Basics XP Practices Scrum Practices Agile@Software Factory
  15. 15. Committed to deliver high qualityapplications for its customers…
  16. 16. …in the mostproductive way!
  17. 17. Being able to changecourse quickly…
  18. 18. …while staying on track toreach the goals.
  19. 19. That is what we call anAgile vision on projectmanagement
  20. 20. No waterfall approach…
  21. 21. …but iterative and incremental Plan Develop Iteration features Product Adapt InspectPrioritizedfeature list
  22. 22. Agile Manifesto ... have more value than ...Individuals & Processes & interactions tools Working Comprehensive software documentation Customer Contractcollaboration negotiationResponding to Following a change plan
  23. 23. Open communication – no hidden agendaAgile 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. 24. Development Metaphor Washing-machine
  25. 25. Focus on the following practices
  26. 26. An agile cross functional feature teamCan be distributed with developers from Romania & Belgium
  27. 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 klantLegende 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. 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. 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. 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. 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. 32. Testing  Test-first programming = not a natural reflex  Regression Test Automatisation is essential  Technically not easy to apply on all code
  33. 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. 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. 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. 36. Simple design  Need for lead architect  Assign a design coach  Involve experts in the first technical implementations  Courage
  37. 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. 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 SprintEstimation Planning Scrum Review Meeting Meeting Meeting Meeting
  39. 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. 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. 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. 42. Q&A
  43. 43. Cegeka ReferencesVentouris 30.000 md 4 years 60 expertsBMW 1.000 md 9 months 9 expertsArgenta BOAR + 2.000 md 1 year 12 expertsmutaties + 1.000 md + 9 months +8 expertsArgenta On-line 8.000 md 2 years 30 expertskantoor (ongoing)Argenta STPLeven 900 md 9 months 8 expertsVDAB 3.000 md 1 year 20 expertsEurocross 500 md 6 months 5 expertsRKW 10.000 md 24 months 25 experts
  44. 44. Contact info:Johan Lybaertjohan.lybaert@cegeka.beCegeka ICT diensten nvInterleuvenlaan 163001 Leuvenwww.cegeka.beInside SoftwareLaurentiu OpreaBucharest, RomaniaPhone: +40 21 3362065Laurentiu.Oprea@insidesoftware.rowww.insidesoftware.ro
  45. 45. Place your betsMake a chance to win

×