agile kt presentation
TRANSCRIPT
Agile KT
Agenda
! Brief on the CTP between ThoughtWorks and Trainline ! Learnings from the Program ! Methodology ! Where can this be applied
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.
! 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
KT Execution Process – Techniques & Methods
Least Effective
KT Unit
Pairing when
working on Small
Items/Defects Workshops classrooms and documentation
BnE Business. SME
Misc
Channel 2
Channel1 Se
rvice
5
Serv
ices
ARCHITECTURE
Config Tool
BA
Automation
Bangalore Infrastructure
Production Support
UI
Plan and Milestones
Febr
uary
May
June
Augu
st
Septem
ber
Oct
ober
Dece
mber
April
March
Utilizing Agile Methodologies
Agile KT
Distributed Agile Teams
Metrics
Ownership Transfer
Continuous Delivery
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
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
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
Ownership Transfer • Bangalore Team Takes ownership for first 3
iterations • London members shadow pair
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
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
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
Where applicable ! All systems involving Ownership Transfer between different units/
organization
Engineering
Process Infrastructure
Structure
Scope
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
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?
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
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?
Feature Teams
OR