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
Recommended
