BCS Elite - March 2014 - v3

Commercial in confidence

EQUIFAX UK AGILE REVIEW


British Computer Society

G.A. GreenHead 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,000EMPLOYEES

158bnMONTHLY

CREDITSCORE

UPDATES

81mBUSINESSES

600mCONSUMERS

205mEMPLOYEE

FILES

We operate successfully in 17 countries across the globe


UK&I

SOUTHAMERICA

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 ABOUTYOUR 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%ScrumScrum / XP HybridCustom HybridScrumbanKanbanDon't KnowXPFDDLeanOther

Agile adoption patterns

Leveraging global capabilities into Agile delivery capacity

“The most efficient and effective method of conveyinginformation 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 sensen Deliveryn Engineeringn QAn 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


ToolsUse tools to support communication across distributed teams

Build Relationships

Regular travel

Desktop VC & Sharing

Daily calls

Instant Messaging

Wikis

eMail


Use tools to support communication across distributed teams






[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 empower the 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)




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 sourcesn Mike Cohn / Mountain Goat Softwaren Agile 101n Agile Alliancen Scrum.orgn Books, books and more booksn 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 pagesn Sub-tasks for all the candidate stories,

with estimatesn A standard set of sub-tasks are used as

a template


Be ready for Sprint

29

New StoryNursery

Elementary Junior High

n New Story logged

n Decompose into Sprint-sized Story candidates

n Story Estimate (Shirt-Size)

n Prioritise

n Full descriptionn Tech. Design

approachn Acceptance

criterian Compliance

criterian UI Design

High School

n Re-Estimaten Re-Prioritisen Reviewn Sprint scheduling


Source: Nationwide Insurance 2009

Tech LeadTeam

Product

Backlog Grooming / Release Planning

n Based on a 3 week sprintn Week 1 - Support the

team to plann Week 2 - Prep for next

Sprintn 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

WARNINGDO NOT Over-Commit

Pace can be a killer – make it sustainableSprints 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 streamCaution:n Learn from past Sprints, try not to repeat mistakesn 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!

ExternalDependencies

may cause scope to be compromised or committed too early


Planning – Change Happens

n Scrum Guide 2013n No changes are made that will effect the Sprint Goaln 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 leadersn Not every wants to leadn Leaders emerge

n Fully engaged product ownern The tactical BA anti-pattern

n Team needs time to self-organisen Sprint -1, 0

n Best lessons learnt from failuren Celebrate failuren BUT learn from it and do not repeat

n Four key lead roles

ProductDefines what is needed, supports

QA and Engineering (Product Owner)

DeliveryFacilitates & communicates

progress Removes impediments

(Scrum Master)

QASupports the Product

Owner and teamTells us when we are done!

EngineeringSupports 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 interestn Drive delivery vs. remain impartial

Where there is no vision, the people perish.

Proverbs 29:18

Engineering = VanityQA & 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 deliverytime dramatically reduced

Delivered Under-Budget

Delivered What the customer wanted!

Delivered On-Time

Key Success Factors

n Peoplen Product Leadership, vision, drive and supportn Technical Leadershipn Engineering and QA

n Dedication, commitment and collaboration

n Open and honest communication

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!!!


Thank you, any questions?

This presentation is confidentialIssued in 2013 by Equifax Ltd© Capital House, 25 Chapel Street, London, NW1 5DS

Telephone: 020 7298 3000 Fax: 020 7723 7555Registered in England No: 2425920

G.A. Green

[email protected]

March 2014

Head of Agile Delivery


EQUIFAX UK AGILE REVIEW

Documents

BCS Elite - March 2014 - v3