The document discusses a capacity transformation program between ThoughtWorks and Trainline to transfer ownership of services and infrastructure from a large team in Bangalore to a smaller team in London. Key elements included: - Restructuring teams along functional areas like booking, payments and advertising - Using agile methodologies like distributed pairing and workshops for knowledge transfer - Planning a 10 month process with metrics to track progress like reduced defects and increased velocity - Identifying risks like attrition, production issues, and motivation and mitigation strategies

1. Agile KT

2. Agenda
! Brief on the CTP between ThoughtWorks and Trainline
! Learnings from the Program
! Methodology
! Where can this be applied

3. The Capacity Transformation Program
How
Transfer Context and
Ownership on Services
and Channels
Lift and shift
Infrastructure
Bring in Product
Alignment
Restructure team to
suit a smaller (2/5
th size) team
Change processes
Why
Decrease
Capital
Expenditure
Enable
greater co-
location
In-sourcing
What
Transform the Trainline Program IDG
such that the platform can be enhanced
and supported by a team 2/5 the original
size. This entails, efficiency
improvements, mind shifts as well as
structural changes.

4. ! By Feature
! Booking, payment, adverts
! By Role
! BA, QA, Dev, PM
! By Code/Technical Area
! Distinct areas of code base, builds, deployment units and artefacts,..
! By Team
! Team mapped between London and Bangalore
! By Channel & Service
! Corporate/SME, Leisure, RS, TMC,
! By Process
! Regression, Release, Build and Environment etc...
Framework on How to KT

5. KT Execution Process – Techniques & Methods
Least
Effective
KT Unit
Pairing when
working on Small
Items/Defects
Workshopsclassrooms anddocumentation

6. BnE
Business. SME
Misc
Channel 2
Channel1
Service5
Services
A
R
C
H
I
T
E
C
T
U
R
E
Config Tool
BA
Automation
Bangalore
Infrastructure
Production
Support
UI
Plan and Milestones
February
May
June
August
September
October
December
April
March

7. Utilizing Agile Methodologies
Agile
KT
Distributed
Agile
Teams
Metrics
Ownership
Transfer
Continuous
Delivery

8. Agile Methodology – Distributed Team
! Single team - Mix of Bangalore and London members
• Blr members are Source of Knowledge and London – the
recipients
! All have one goal of delivering the project
! One Dev Mgr, for the team, and one BA for the project
! Devs and QAs are distributed
! Remote stand-ups, remote pairing and remote retros

9. What was the outcome?
Velocity
Increased
Team members changed their work
timings
No one bothered the remote
pair
Separate stories for KT – allowing
team to spend time on KT every
iteration
Velocity factored for KT
work
Budget got
distributed properly

10. Metrics
! The Budget was fixed
! The schedule was also rigid
! Identified the top 70% that needed to be KT’ed as
our MVP
! Factored for story points to deal with the KT
• Helped structure the iterations
• Helped plan Budget outlay for KT
• Created acceptance criteria for KT at iteration
levels
! Toyed with the idea of measuring number of regression
defects before and after
Scope
Schedule
Cost

11. Ownership Transfer
• Bangalore Team Takes ownership for first 3
iterations
• London members shadow pair

12. Continuous Delivery
! It’s a bit like changing pilots on a cruising
aircraft
• Commercial projects need to keep running
• Releases ought to continue
! Planned over 10 months given this context
• Actively identified functional projects for
KT
• Worked out modalities on Budgeting and
cost with commercial project PMs
• Created organization wide visibility on the
KT program

13. Risks Identified
Risks/Issues Comments
Difference of Opinion between teams, existing tech
debt, unacceptable processes
You got to plough through it. Senior developers ought to be
involved
Attrition on both ends More of it occurred in London. Delayed the ramp-down in
Bangalore
Production Issues Lean team from Bangalore continues to exist – as a last
resort if London cannot fix the production issue
Motivation Has been a major factor. Bangalore devs not interested
with the work. London devs not interested to pick up
additional responsibilities
Management. Large program – bound to hit unanticipated
issues
KT extended over time, but overall remained within
Budget
Measurement. We don’t know what good looks like Rather than numbers, went by comfort factor of receiving
teams
Processes – way of working, releases, builds, continuous
integration practices are all different across teams
Let London team choose what they are comfortable with.
They after all need to live with it

14. Learnings - Methodology
Understand
the real
scope
Create a
framework
Plan
Execute
Its not KT, Its OT
(Ownership Transfer)
Code is the center
piece
Automation scripts are
also code
Documentation will not
suffice
Engineering
Infrastructure
Process
Structure
It will take time
Learn by doing. Be realistic
Communication is key
Changing pilots on a running aircraft
Run with commercial projects
Factor for people issues
Don’t get hung up on measurements

15. Where applicable
! All systems involving Ownership Transfer between different units/
organization
Engineering
Process
Infrastructure
Structure
Scope

16. Engineering
! Are you going to pick up the code base as is – or do you envisage
improvements along the way?
• Are the build pipelines adequate?
• Is automation occurring at the right level?
• Are the deployment set-ups appropriate with the new set-up?
! Answer lies in the purpose of the KT

17. Process
! Ownership transfer always gets associated with process changes
• The new team will do things differently
! Discuss changes to project inceptions and executions?
! Changes to testing processes?
! Software release changes?
! Production Support?
! Project Costing and Governance
! Changes to team roles?

18. Infrastructure
! Relevant if the OT is across distributed environment
• Need to redistribute hardware
• Scale of application is changing
• Changes to networks
! The transition phase is key
• Replication between sites
• Handover/takeover of infrastructure
• IS team member involvement

19. Structure
Db
Website
Mobile Call
Center
Services CMS
Channel Team
Services Team
UI
DBA
Where do these go?
• Regression Team?
• Non Functional Testing?
• Release Team?
FeatureTeams
OR