Richard Wilburn - Lean Truth
•Download as PPTX, PDF•
0 likes•1,464 views
Agile and looking to optimise your processes? Or tired of conflicting information within your project teams causing excessive development rework? Maybe you want to get a feel for the size of rework happening in your projects? In this session, we will look at how to detect inefficiencies in the software development process and, as we journey deeper, how to remove inefficiency through the adoption of a single source of truth. In our experience, a single source of truth is the goal of all companies, regardless of the company growth profile and at all levels of business, ranging from executive down to production level. We will elaborate on what a single source of truth is and how you can employ such a concept in your organisation with practical examples, based on commercially used best practices. No punches pulled!
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Richard Wilburn - Lean Truth
Similar to Richard Wilburn - Lean Truth (20)
More from AgileNZ Conference
More from AgileNZ Conference (20)
Recently uploaded
Recently uploaded (20)
Richard Wilburn - Lean Truth
- 1. Lean Truth Richard Wilburn Fiserv Your pic
- 2. About me
- 3. Industry leader Mission-critical solutions Diversified client base Award-winning innovation Financial strength Engaged associates
- 4. What we are • $4.5 billion+ in revenue • $1 trillion+ moved through Fiserv solutions annually • 21,000+ employees • 159+ acquisitions since 1984 • Auckland office growth
- 5. Growth NZ Product team: • Mobile banking • 10 million+ users • Number 1 in the US • 12 scrum teams
- 6. What we do Products Customizations Banking services
- 7. Agenda • Challenge • What was the cause? • Relevance of the problem • The social challenges • The solution & demo • Results
- 8. Survey How many people: • use word documents for writing specifications?
- 9. 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
- 10. How common is this? Why projects are cancelled: 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 & Specifications 8.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% http://www.projectsmart.co.uk/docs/chaos-report.pdf
- 11. Identifying the cause • Used retrospectives • Post implementation reviews • Stakeholder feedback • Three amigos
- 12. Survey How many people: • have seen inconsistencies between specifications, test cases and code?
- 13. Multiple sources of truth are expensive to synchronize • Test plans • Code • Product specifications Test plan Code Spec to build The root of the problem
- 14. Test plan Code Spec to build The root of the problem
- 15. The root of the problem Test plan Code Spec to build Additional synchronization Pain! Product Frameworks Automated Service Tests Automated UI Testing Marketing Specification Manual Tests Contract Specification Customization Specification Sales Specification User Guide Operational Information Call-centre Guide
- 16. Multiple channels share common expectations We don’t share between channels At a spec level At a testing level Web At a code/channel level we do share Mobile Web Mobile Apps Tablet Apps Mobile Tablet The root of the problem
- 17. The root of the problem Multiple channels share common expectations Web Mobile Tablet Lets align our specification and testing practices to our code practices!
- 18. Goals • Single source of truth • Automate to enforce consistency
- 19. Requirements • Handwritten content must be preserved • Specifications must update quickly • Must scale to enterprise environment (consistency) • Flexible (abstraction) • Increase alignment of the three amigos
- 20. The solution User stories Prompts (Textual data) Technical diagrams Mock test data Wiki
- 21. The solution
- 22. Results • Reduce time/cost • Greater consistency • Write less, say more • Increased sharing of content • Improved requirement context
- 23. Measured benefits • Reduced rework • Improved fix first time • Reduced defect count 3500 3000 2500 2000 1500 1000 500 • Social change 0 Total defects relative to resource 4 Teams 0.5 Years 7 Teams 1 Year 7 Teams 1 Year Descending by finish date
- 24. Sprint behaviour evolution Old process Current process
- 25. 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
- 26. In Summary • Challenge • What was the cause? • Relevance of the problem • The social challenges • The solution & demo • Results
- 27. 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
- 28. Thanks for listening… Richard Wilburn Fiserv Follow me @rhwilburn Your pic
- 29. Resulting team attributes • Independent / Cross skilled • Predictable velocity • Better morale • Greater connection with outcome • Increased focus on getting to done • Individual skill profiles evolved
- 31. Process difference Business Requirement • Epic PBI Goal Driven Scoping • PBIs Spec by example • Changed from word documents Automation • Aligned to spec Live documentation • Updates every 5 minutes
- 32. 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
- 33. Why choose BDD? DDD Experimentation Iterative design TDD BDD Automation test first Collaboration Business focus Priorities: 1. Automation 2. Business focused
- 34. Accountability vs Responsibility 1. Team are responsible 2. BA is accountable (for specs)
- 35. In Summary • Challenge • What was the cause? • Relevance of the problem • The social challenges • The solution & demo • Results
- 36. 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
- 37. Thanks for listening… Richard Wilburn Fiserv Follow me @rhwilburn Your pic
Editor's Notes
- Current role -------------------------------------- Dev (Mobile / Web / Backend) QA IT support (Call centre / consultancy / Change analyst)
- Number 1 in mobile banking. Auckland 1 trillion $ Asia, Europe, US Javelin research ranks us as Number 1 banking services provider Holding company -> Product company Growth opportunity
- Soft hand in acquisition Transition to a product company Growth: 2% of company making 25% ====================================================== Reference: http://newsroom.fiserv.com/fastFacts.cfm
- 3.5 years Product division only
- ------------------------------ Reference http://newsroom.fiserv.com/fastFacts.cfm
- Emphasise the spec, test plan and code iterating separately. Talk about amigos not talking together
- The standish group - http://www.projectsmart.co.uk/docs/chaos-report.pdf Give the context behind the stats on the slide. Context behind project. It was successful, but we can be better.
- QA raises issue Dev disagrees with the issue Test plan and spec are different Code is different again to both the test plan and the spec
- Story about QA / Dev / BA etc.
- Universal back behaviour. Describe once, and reference it in each channel.
- Example: Clients can sometimes hear multiple messages from big companies. Example: Rework can be expensive
- Spec: Login flow Gliffy: Conventions, Modularity, Less is more Explain nav,detail,validation vs basic, alternate, exception flow philosophy. Navigation: Define what it is. Detail: Define what it is. Validation: Show example table. Show dialog spec. Showing prompt keys Visual Studio - feature file Prompts: Where they come from. Why gliffy has prompt keys (branding). Mocks Link into platform specification; Why a separate for spec for platform UX section Show platform spec. Sequence diagram generation. Custom content. Show Back navigation spec (as cross product example). Release versioning
- Prompts. What are they? Context of why they are important. Example: error message etc. Link demo back to benefits Spec: Login flow Gliffy: Conventions, Modularity, Less is more REMOVE#############: Explain nav,detail,validation vs basic, alternate, exception flow philosophy. ###################Given/When/Then helps Bas go to a lower level. Navigation: Define what it is. Detail: Define what it is. Validation: Show example table. Show dialog spec. Showing prompt keys Visual Studio - feature file Prompts: Where they come from. Why gliffy has prompt keys (branding). Mocks Link into platform specification; Why a separate for spec for platform UX section Show platform spec. Sequence diagram generation. Custom content. Show Back navigation spec (as cross product example). Release versioning
- Modularity Conventions Context behind requirements Save $$$$$ Do not repeat yourself
- 99% fix first time Efficency Defect numbers
- QA Skin in the game Highlight. People and principles over tools and process. Helps people collaborate. Highlight. Instant spec turn around.
- QA Skin in the game
- Awesome results. Executive buy in.
- Skin in the game
- In the slides after the thanks slide, I am having as a back up area for extra content if time permits. I have done the presentation in public to ~80 people and I am confident in the timings, but its good to have a back up plan ;)
- http://www.slideshare.net/gojkoadzic/effective-specifications-for-agile-teams?next_slideshow=1
- ****** Make a matrix graph and put the options on.
- Diagram from Gojko Adzic, http://www.slideshare.net/skillsmatter/ddd-exchange-2010-gojko-adzic-on-ddd-tdd-bdd
- Skin in the game. ###############Consider removing