1. The Kiev Experiment Evolving Agile Partnerships

2. Who are we? Simon Sasha Peter

3. Where did we start? Existing Monolithic Mainframe Application Quarterly Deliveries 6 Week Testing Cycles Offshore Delivery teams Waterfall process Command and Control

4. What did we want to do? Belief there was a better way to deliver software Incremental development to deliver business value quickly Address the rapidly changing business landscape with flexibility in delivery Build quality into the solutions Deliver the software rapidly, but in a cost effective manner Put the fun back into software delivery

5. How did we start? Started with a single team in London Initially focused on building the tools, proving the processes and technologies Release 1.0 on Friday 13 th October 2006 Very soon we started to look how we could scale

6. Where are we now? 5 years into the delivery 2M trades per day 100 billions settling per day in all major currencies 40 exchanges across EMEA and APAC 15 scrum teams/120 people Teams in London, Kiev, Hyderabad, Hong Kong and New York 9 application components Production releases every 2 weeks

7. How did we get here? Inspect & Adapt Lots and lots of experiments Don’t accept the status quo But lets go back to the beginning…….

8. Evolving the Team

9. DD DD D D D 2006 small co-located team

10. D D D DD D DD DD D D D 2006 small co-located team 2007

11. DD DD D D D D D D DD D component teams 2006 2007 small co-located team

12. D D D D D DD D DD D D D AT AT AT D D D co-located feature teams dispersed feature teams component teams 2006 2007 small co-located team 20082009

13. DDD D D D DD D D DD D D D D AT AT AT DD AT first distributed feature team co-located feature teams dispersed feature teams component teams 2006 2007 small co-located team 200820092010

14. DDD D D D DD D D DD D D DD AT AT AT DD AT D DDDD AT D D DD AT many distributed feature teams first distributed feature team co-located feature teams dispersed feature teams component teams 2006 2007 small co-located team 2008200920102011

15. New YorkLondonKievHyderabadHong Kong

16. Evolving the Communication

17. Jan 2009 Small pieces of technical tasks May 2009 Complex technical tasks Dec 2009 User stories refined by SME May 2010 User stories refined in collaboration with end users Luxoft teams evolution 4 people 0 teams 6 people 1 team 21 people 3 teams 30 people 4 teams

18. Communication issue End users Analysts Architects Offshore team 1 Offshore team 2 Offshore team 3

19. Broadening Communication Bandwidth

20. Polycom experiment Communication flow PHOTO

21. Skype and projector

22. Interactive whiteboards + Skype

23. TelePresence?

24. Bridging The Communication Gap

25. Team intermediary Onshore team IntermediaryOffshore team

26. Bilateral rotation

27. Specification By Example

28. Dedicated architects group Architects Offshore team 1 Offshore team 2 Offshore team 3

29. Joint Architectural Workshops

31. Tackling technical challenges

32. Release Management trunk Release 1.0Release 2.0

33. But how do you scale? trunk Release 1.0Release 2.0 Multiple Teams Concurren t Projects

34. ISE CHIX TQ Release 2.0 Release 2.1 Let’s introduce a process

38. But what if this now becomes the highest priority? CI needed on each branch Manual and high coordinated Waste of delayed integration

39. How do you address changing feature priority? How do you allow incremental feature development? How can you have an agile release function?

40. trunk Release X (ISE) Release Y (CHIX) This is what we want ISE CHIX TQ

41. trunk Release X (ISE) Release Y (CHIX) Latent Code Patterns ISE CHIX TQ “One of the most powerful techniques I have used over the last three years is latent code patterns.” Chris Matts InfoQ – The Last Responsible Moment in Deployment

42. trunk Release X (ISE) Release Y (CHIX) Latent Code Patterns ISE CHIX TQ Event Driven Feature Bits or Configuration Modularity or Dependency Injection

43. 200 commits per day 1000 artefacts updated per day 1 commit every 5 minutes peak Keeping It Green

44. A Single Bad Commit…..

45. 13 hours elapsed time wasted 500 hours of effort wasted A Wasted Day

46. Coaching

47. Fast Visible Feedback 24 Build Targets37 Test Targets