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