Your SlideShare is downloading. ×
Open Agile Romania 2011/Johan Lybaert - Agile Open Romania the Ventouris Case
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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


Published on

Published in: Technology, Business

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Agile Open Romaniathe Ventouris Case
  • 2. Close collaboration with the customer lead to asuccessful VENTOURIS project Johan Lybaert Program Manager Cegeka
  • 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. Overall Presentation Goal show how agile development practices can help you to build the application the customer really needs
  • 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. 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 • 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. 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. 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. Application Architecture overview
  • 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. 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 qualityapplications for its customers…
  • 16. …in the mostproductive way!
  • 17. Being able to changecourse quickly…
  • 18. …while staying on track toreach the goals.
  • 19. That is what we call anAgile vision on projectmanagement
  • 20. No waterfall approach…
  • 21. …but iterative and incremental Plan Develop Iteration features Product Adapt InspectPrioritizedfeature list
  • 22. Agile Manifesto ... have more value than ...Individuals & Processes & interactions tools Working Comprehensive software documentation Customer Contractcollaboration negotiationResponding to Following a change plan
  • 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. Development Metaphor Washing-machine
  • 25. Focus on the following practices
  • 26. An agile cross functional feature teamCan 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 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. 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 SprintEstimation 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 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. Contact info:Johan Lybaertjohan.lybaert@cegeka.beCegeka ICT diensten nvInterleuvenlaan 163001 Leuvenwww.cegeka.beInside SoftwareLaurentiu OpreaBucharest, RomaniaPhone: +40 21
  • 45. Place your betsMake a chance to win