BCS Elite - March 2014 - v3

Commercial in confidence
EQUIFAX UK
AGILE REVIEW

Commercial in confidence
British Computer Society
G.A. Green
Head of Agile Delivery
13th March 2014

WARNING
WARNING!!
This is what worked for us / me
This is how we adapted and the
lessons we learnt
3Commercial in confidence — Equifax UK Agile Review - 2014

A little about me
4
Head of Agile Delivery for Equifax UK
Career began in 1987 as a
Software Engineer
27 years IT Project and Programme
delivery experience
Adopter of RAD, RUP,
Scrum, XP and Kanban
Specialises in distributed
Agile delivery within
multinational organisations
Gary Green
Commercial in confidence — Equifax UK Agile Review - 2014

Equifax has global credibility. We help organisations make decisions about
their customers
7,000
EMPLOYEES
158bn
MONTHLY
CREDIT
SCORE
UPDATES
81m
BUSINESSES
600m
CONSUMERS
205m
EMPLOYEE
FILES

We operate successfully in 17 countries across the globe
UK&I
SOUTH
AMERICA
NORTH
AMERICA
EUROPE
ASIA

And have been helping people for over 110 years

What we do? We provide informed decisions and insights
WE HELP YOU
MAKE INFORMED
DECISIONS ABOUT
YOUR CUSTOMERS
OUR INSIGHT CAN
HELP YOUR
BUSINESS
PERFORM BETTER
Commercial in confidence — Equifax UK Agile Review - 2014 8

Our insight can help your business perform better
9
We deliver
insight to you
by identifying the
intricate
connections
The breadth
and depth of
the consumer
and commercial
data we hold
is extensive
We help protect
businesses by
reducing levels of
fraud and providing
tools that help meet
regulatory and
compliance needs.
We predict the
behaviour of new and
existing customers to
support managing
risk and decisions
making.

Why are we embracing Agile?
n Embrace Voice of the Customer
n Hit the market fast
n Fixed cost and dates
n Deliver often – higher release cadences
n One team
n Leverage global resources, knowledge and skill
n Make delivery FUN

29%
14%
57%
Failed
Successful
Challenged
9%
42%
49%
When compared against other methodology, results are outstanding
Waterfall
Source: The Standish Group 2012 - Data sampled from 2002 to 2010
Agile

Why did we chose Scrum?
12
Scrum adoption levels
Scrum based models account for
almost 2/3 of adoption patterns
Source: VersionOne’s annual
Agile development survey
Skill availability
The team preferred it
I really like it!
Source: State of Agile Survey: http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf
54%
11%
9%
7%
4%
4%
2% 2%
2%
5%
Scrum
Scrum / XP Hybrid
Custom Hybrid
Scrumban
Kanban
Don't Know
XP
FDD
Lean
Other
Agile adoption patterns

Leveraging global capabilities into Agile delivery capacity
“The most efficient and effective method of conveying
information to and within a development
team is face-to-face conversation”
Agile Manifesto

Some key challenges caused by Distributed Agile Teams?
n Time-zone
n Language / Culture
n Over reliance on written communication
and tools
n Offshore teams left out of decision making
n Offshore team lose context
n Delays in decisions / escalations
n Service hours
n Public Holidays

How can we minimise the impacts caused by time-zones?
n Time-zones are killers to Agility
and empowerment
n Context gap
n Block out overlapping time
and give priority to collaboration
with offshore partners
n Flexible / shift working for periods
n Onshore proxies
n Ask the right questions

Make the effort to build relationships with peers and do it Face-to-Face!
n Built 1:1 Peer to peer relationships
n Make relationships that make sense
n Delivery
n Engineering
n QA
n Product / Business Analysts
n Talk daily
n Leverage desktop video conferencing
n Empower

How do you keep remote attendees engaged?

Games can make a dull activity interesting

Tools
Use tools to support communication across distributed teams
Build Relationships
Regular travel
Desktop VC & Sharing
Daily calls
Instant Messaging
Wikis
eMail

[Technology allows risks to be assigned and tracked]

A little visualisation goes a long way
n Wiki pages
n Burn-downs
n Summarise goals, scope,
definition of done

n An Agile Gantt chart and burndown does not
tell you a lot
n Trust and empowerthe team
How do you know you are delivering?
n Agree key metrics
n Start and end dates
n Sprint Goals
n Velocity
n Quality (static analysis)
n Number and severity of bugs raised by QA
n Number of bugs re-opened
n Be warned… metrics drive behaviour
too – Hawthorne effect

Monday Tuesday Wednesday Thursday Friday
08:45
09:00 Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum
09:15
09:30
09:45
10:00
10:15
10:30
Monday Tuesday Wednesday Thursday Friday
08:45
09:00 Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum
09:15 Breakout
(if needed)
Breakout
(if needed)
Breakout
(if needed)
Breakout
(if needed)
Breakout
(if needed)
09:30
09:45
10:00
10:15
10:30
Bad habits – Ceremony creep

Adapt, collaborate and adapt
n We got best results by adapting Scrum to fit us
n Called on a lot of advice and external and
internal sources
n Mike Cohn / Mountain Goat Software
n Agile 101
n Agile Alliance
n Scrum.org
n Books, books and more books
n Equifax Global
n And adapted to what worked and had value to us….
The team decided
n The same applied to the UK SDLC

Sprint Planning
n Takes up to three days but does not always
utilise the entire team
n Use Video Conferencing and desktop
sharing, then leave the team time to plan
and ask questions
n Product owner and tech leads on stand-by
to support planning
n The outputs were:
n Sprint commitment, definition of done per
Story as well as a Sprint Confluence pages
n Sub-tasks for all the candidate stories,
with estimates
n A standard set of sub-tasks are used as
a template

Be ready for Sprint
29
New Story
Nursery
Elementary Junior High
n New Story
logged
n Decompose into
Sprint-sized
Story candidates
n Story Estimate
(Shirt-Size)
n Prioritise
n Full description
n Tech. Design
approach
n Acceptance
criteria
n Compliance
criteria
n UI Design
High School
n Re-Estimate
n Re-Prioritise
n Review
n Sprint scheduling
Source:Nationwide Insurance 2009
Tech Lead
Team
Product

Backlog Grooming / Release Planning
n Based on a 3 week sprint
n Week 1 - Support the
team to plan
n Week 2 - Prep for next
Sprint
n Week 3 - Support the
team to close Sprint x close
Sprint x+1 kick-off
Sprint x+2+ Prep
Sprint x+1 close
Sprint x+1+ Prep

There are many Sprint Planning dangers and pitfalls
WARNING
DO NOT Over-Commit
Pace can be a killer – make it sustainable
Sprints should not be “sprints”, it’s a marathon
There’s always work the team can do, even if it is
not committed, just don’t pollute the code stream
Caution:
n Learn from past Sprints, try not to repeat mistakes
n The do’er is the estimator for the task –not to be imposed
Consider
planning
from Done
backwards
with QA
driving
planning
Test Driven Planning
Done

There are many Planning dangers and pitfalls
WARNING!
External
Dependencies
may cause scope
to be compromised or
committed too early

Planning – Change Happens
n Scrum Guide 2013
n No changes are made that will effect the Sprint Goal
n Scope may be clarified and re-negotiated
n Change still happens
n Welcome change
n Change still needs to be impacted and
renegotiated by the team
n The team should be in the driving seat

People not technology drive the process
n We still need leaders
n Not every wants to lead
n Leaders emerge
n Fully engaged product owner
n The tactical BA anti-pattern
n Team needs time to self-organise
n Sprint -1, 0
n Best lessons learnt from failure
n Celebrate failure
n BUT learn from it and do not repeat
n Four key lead roles
Product
Defines what is needed, supports
QA and Engineering
(Product Owner)
Delivery
Facilitates & communicates
progress
Removes impediments
(Scrum Master)
QA
Supports the Product
Owner and team
Tells us when we are done!
Engineering
Supports the Engineers - Ensures
that levels of technical debt are
acceptable and that we are aligned
to architectural governance.

QA Leadership
n Strong QA Leadership offshore was essential
n QA Lead acting as Scrum Master leads to a conflict of interest
n Drive delivery vs. remain impartial
Where there is no vision,
the people perish.
Proverbs 29:18
Engineering = Vanity
QA & Product= Sanity
Gary Green 2013

Achieving Done
n Ratio of 2 Eng : 1 QA worked best for us
n Working as Units of three
n Close Collaboration (Eng : QA : Product)
n Engineers can test too!
n Automation, Automation….
And more Automation
n But automation does cost… especially the
impact of change
n Manual regression can be a killer with multi-
Sprint / multi-Release Projects

What was the outcome?
Able to adapt quickly
Concept to delivery
time dramatically reduced
Delivered Under-Budget
Delivered What
the customer wanted!
Delivered On-Time

Key Success Factors
n People
n Product Leadership, vision, drive and support
n Technical Leadership
n Engineering and QA
n Dedication,commitment and collaboration
n Open and honestcommunication
n Take time to communicate,make it a priority… build
relationships
n Tools
n Leverage internal and external sources

Right People + Dedication + Resources + Empowerment
=

Summary
n Requires commitment, dedication and effort to make it work
n Everyone is part of the solution, no exceptions
n Does not guarantee outcomes
n Chose the right tools
n Watch for over-commitment
n Build strong relationships
n Empower
n Make it fun!!!

This presentation is confidential
Issued in 2013 by Equifax Ltd©
Capital House, 25 Chapel Street, London, NW1 5DS
Telephone: 020 7298 3000 Fax: 020 7723 7555
Registered in England No: 2425920
G.A. Green
gary.green@equifax.com
March 2014
Head of Agile Delivery

BCS Elite - March 2014 - v3

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to BCS Elite - March 2014 - v3

Similar to BCS Elite - March 2014 - v3 (20)

BCS Elite - March 2014 - v3