Richard Wilburn - Lean Truth

Lean Truth

Richard WilburnFiserv

Your pic

About me

Industry leader

Mission-critical solutions

Diversified client base

Award-winning innovation

Financial strength

Engaged associates

• $4.5 billion+ in revenue

• $1 trillion+ moved through Fiserv solutions annually

• 21,000+ employees

• 159+ acquisitions since 1984

• Auckland office growth

What we are

Growth

NZ Product team:

• Mobile banking

• 10 million+ users

• Number 1 in the US

• 12 scrum teams

What we do

ProductsCustomizations

Banking services

• Challenge

• What was the cause?

• Relevance of the problem

• The social challenges

• The solution & demo

• Results

Agenda

Survey

How many people:

• use word documents for writing specifications?

The challenge

• Months of unexpected documentation work

• Work surfacing in the last 6 weeks of the project

• Key team members leaving project

• Knock on effects for other projects

• Challenging/evolving stakeholders requirements

How common is this?Why projects are cancelled:

2014

Chaos

http://www.projectsmart.co.uk/docs/chaos-

report.pdf

Rank Reason Percentage %

1 Incomplete Requirements 13.1%2 Lack of User Involvement 12.4%3 Lack of Resources 10.6%4 Unrealistic Expectations 9.9%5 Lack of Executive Support 9.3%6 Changing Requirements &

Specifications8.7%

7 Lack of Planning 8.1%8 Didn’t Need it Any Longer 7.5%9 Lack of IT Management 6.2%

10 Technology Illiteracy 4.3%Other 9.9%

Identifying the cause

• Used retrospectives

• Post implementation reviews

• Stakeholder feedback

• Three amigos

Survey

How many people:

• have seen inconsistencies between specifications, test cases and code?

Multiple sources of truth are expensive to synchronize

• Test plans

• Code

• Product specifications

Test plan

CodeSpec

to build

The root of the problem

Test plan

CodeSpec

to build

The root of the problem

Test plan

CodeSpec

to buildAdditional

synchronization Pain!

The root of the problem

Frameworks

Product

Auto-matedServiceTests

Automated UI Testing

MarketingSpecification

ManualTests

ContractSpecification

CustomizationSpecification

SalesSpecification

UserGuide

OperationalInformation

Call-centreGuide

Multiple channels share common expectationsWe don’t share between channelsAt a spec levelAt a testing level

At a code/channel level we do share

Mobile WebMobile AppsTablet Apps

Web

Mobile

Tablet

The root of the problem

Multiple channels share common expectations

Web

Mobile

Tablet

Lets align our specification and testing practices to our code practices!

The root of the problem

Goals

• Single source of truth

• Automate to enforce consistency

Requirements

• Handwritten content must be preserved

• Specifications must update quickly

• Must scale to enterprise environment (consistency)

• Flexible (abstraction)

• Increase alignment of the three amigos

The solution

User storiesPrompts (Textual

data)

Technical diagrams

Mock test data

Wiki

The solution

Results

• Reduce time/cost

• Greater consistency

• Write less, say more

• Increased sharing of content

• Improved requirement context

Measured benefits

• Reduced rework

• Improved fix first time

• Reduced defect count

• Social change0

500

1000

1500

2000

2500

3000

3500

Total defects relative to resource

4 Teams

0.5 Years

7 Teams

1 Year

7 Teams

1 Year

Descending by finish date

Sprint behaviour evolution

Old pro-cess

Current pro-cess

Social evolution

• Positive early conflict

• Business Analyst held to account in sprint

• Team started blurring responsibilities and shifted focus to outcomes

• Cross skilling more common

• Strike teams formed on demand

• Challenge

• What was the cause?

• Relevance of the problem

• The social challenges

• The solution & demo

• Results

In Summary

Where to next?

• Product wide roll out

• Continuous improvement

• Creating a guild and three amigos buy-in

You could try customizing existing products

• Speclog

• Pro.Behave (Jira plugin)

• Fitness

Thanks for listening…Richard WilburnFiservFollow me @rhwilburn

Your pic

Resulting team attributes• Independent / Cross skilled

• Predictable velocity

• Better morale

• Greater connection with outcome

• Increased focus on getting to done

• Individual skill profiles evolved

Infrastructure change

Process difference

Business Requirement

• Epic PBI

Goal Driven Scoping

• PBIs

Spec by example

• Changed from word documents

Automation • Aligned to spec

Live documentati

on

• Updates every 5 minutes

Variety of options

TDD

•Mature•Code focused

BDD

•Mature•Business context focused

DDD

•Mature•Focus on domain logic

EDD

•Example focused

STDD

•Fail first•XP focused

ATDD

•Hybrid TDD / BDD

Why choose BDD?

DDD

BDDTDD Automa-tion test

first

Experimenta-tion Iterative

design

Collaboration Business fo-

cus

Priorities:

1. Automation

2. Business focused

Accountability vs Responsibility1. Team are responsible

2. BA is accountable (for specs)

• Challenge

• What was the cause?

• Relevance of the problem

• The social challenges

• The solution & demo

• Results

In Summary

Where to next?

• Product wide roll out

• Continuous improvement

• Creating a guild and three amigos buy-in

You could try customizing existing products

• Speclog

• Pro.Behave (Jira plugin)

• Fitness

Thanks for listening…Richard WilburnFiservFollow me @rhwilburn

Your pic