Download to read offline
Uploaded byIIBA UK Chapter
Untangling Stories
Slides from a presentation given by Daniel Marlow and Miles Austin to the South West branch of IIBA UK on 10 March 2016.
Editor's Notes
- #2 SLIDE 1 [INTRODUCTION] [THANK YOU] – Invited to talk [HONOURED] – to be given the opportunity with share our ideas at this event [WHO WE ARE] – Software Engineering Consultants at Ordnance Survey Mentoring, software development and testing Working with customers and stakeholders in agile teams Providing consultancy on engineering improvement across the organisation
- #3 SLIDE 2 [DISCLAIMER] [PERSPECTIVE] Software engineer’s perspective [INSIGHTS] How business analysis can profoundly affect software delivery and outcomes Business analysis can directly influence what software is built AND how it is built [NATURE OF AGILE DEVELOPMENT] Identifying needs vs. building to requirements can have a significant effect Difficult to identify customer needs. Easy to build software that diverts from those needs Software engineering practices can help us to identify value Business analysts should work with teams iteratively to discover value and deliver iteratively
- #4 SLIDE 3 [THE IMPORTANCE OF BUSINESS ANALYSIS] [SUCCESS] Ongoing business analysis provides the team with a direction to steer towards customer value. Costs and time minimised Software can cope with changing requirements or priorities [DANGER] Business analysis diverts the team away from truly valuable software Increase costs and time building the wrong thing Divert the customer away from building the next more important thing – opportunity cost Upfront business analysis does not cope with changing priorities and value discovery Software cannot cope with changing requirements and priorities
- #5 SLIDE 4 [DELIVERY TEAM AS STAKEHOLDERS] [PROXY] Business analyst acts as a proxy for many conflicting interests and priorities Delivery teams want to build high quality software with real value [COLLABORATION] Continuous prioritisation and collaboration with the team is crucial Customer NEEDS will change constantly [TWO-WAY INFLUENCE] Legacy software, systems and interfaces can influence analysis HOW needs are described can influence how software gets built
- #6 SLIDE 5 [VALUABLE SOFTWARE vs. WHAT’S ASKED FOR] [NEEDS] Hard to discover What is truly valuable? How do we know what is valuable? Can we measure value? [WHAT IS ASKED FOR] Typically has some overlap with what is valuable [WASTE AND LOST OPPORTUNITIES] If needs (value) and what is asked for don’t align we get waste and lost opportunities [ALIGNMENT] Constantly moving target to align needs with what is asked for Alignment requires continuous prioritisation and delivery
- #7 SLIDE 6 [INVEST] [CHARACTERISTICS OF A GOOD USER STORY] MNEMONIC created by Bill Wake. Many people know about INVEST for user stories. Takes real discipline to apply. I – Independent – Stories should not overlap or depend on each other. They should lead to independently deliverable features N – Negotiable Should exist purely in the problem space and can always be rewritten and changed V – Valuable Should deliver REAL value to the end user. Not necessarily what is initially asked for E – Estimable Is there enough supporting information so that it can be estimated to provide predictability S – Small Small stories complement an iterative approach. Discover value by describing needs in small pieces. T – Testable - How does a development team know they have met the customer’s NEEDS?
- #8 SLIDE 7 [TANGLED STORIES] [COMPLICATED] [STORIES] Stories that overlap, depend on each other or exist in an artificial hierarchy Mixture of large and small stories Mixture of valuable and low value stories Stories that are hard to test due to poor understanding and dependencies [SOFTWARE] Complicated software usually results due to poor overall understanding of NEEDS Software delivered in order with late integration and high technical risk Projects usually start fast and get slower over time High cost to change
- #9 SLIDE 8 [UNTANGLED STORIES] [SIMPLE] [STORIES] Stories that can be delivered independently Stories that are small so that they can be delivered frequently Stories that can be tested simply so they can be released early Stories that have been identified as valuable [SOFTWARE] Small components relating to isolated, identified needs Loose coupling with evolving interfaces Software that is easy to change based on changing needs
- #10 SLIDE 9 [HOW DO STORIES BECOME TANGLED?] How might business analysis take us along the path to tangled stories and unnecessarily complicated software?
- #11 SLIDE 10 [ABSTRACTION IN TO COMPONENT TEAMS] [ORGANISATIONAL ANTIPATTERN] Stories are immediately divided by component team Each team has an independent backlog and set of priorities Teams have lost the original purpose Organise people into feature teams and have everyone necessary to do the work
- #12 SLIDE 11 [ABSTARCTION IN TO COMPONENT TEAMS] [ORGANISATIONAL ANTIPATTERN] [FEATURE TEAMS] Feature teams understand the whole problem and sense of urgency More likely to deliver simple solutions [COMPONENT TEAMS] Component teams divide the work Customer become disengaged – work focuses on the organisational design and alignment Separate backlogs and sense of urgency
- #13 SLIDE 12 [ABSTARCTION IN TO COMPONENT TEAMS] [ORGANISATIONAL ANTIPATTERN] Component teams reinforce architectural patterns Conway’s Law – more likely to design software to reflect our organisational structure Constant problem of alignment and integration Complication increases Testing becomes harder as more functionality is handled in fewer components
- #14 SLIDE 13 [ABSTARCTION IN TO COMPONENT TEAMS] [ORGANISATIONAL ANTIPATTERN] [FEATURE TEAMS] Aligned with sense of urgency More likely to design the simplest solution to the problem Not aligned with the organisational structure –write software without organisational constraints Have everyone in the team necessary to solve the problem More likely to deliver early and often
- #15 SLIDE 14 [ABSTRACTION IN TO DESIGN] [EARLY ABSTRACTION IN TO DESIGN/SOLUTION SPACE] Can occur during analysis [EXAMPLE] Three customers independently NEED to compare data Could be described with independent stories and delivered early Early abstraction in analysis introduces a dependency between all the stories “Central comparer” – now describes a lower value need and has increased complication
- #16 SLIDE 15 [ABSTRACTION IN TO DESIGN] [EARLY ABSTRACTION IN TO DESIGN/SOLUTION SPACE] Treating needs simply and iteratively – more likely to design simple software Early abstraction in analysis to design – likely to introduce premature generalisation Increases difficulty in testing and development Causes late integration of many components
- #17 SLIDE 16 [ABSTRACTION IN TO DESIGN] [EARLY ABSTRACTION IN TO DESIGN/SOLUTION SPACE] Tester begins to focus on testing the consequences of the design rather than the need Typically becomes driven by integrated tests Project dominated by integration and logic problems Original customer need has been reduced in significance [T] - Harder to test, getting harder [I] - Three customers may have to wait for the comparer to be completed - dependency [E] - Difficult to estimate when all the work will be done [N] – Customers have less ability to negotiate their original need [V] – “Comparer” has lower value [S] – Comparer may have increased the size of the development effort
- #18 SLIDE 17 [ABSTRACTION IN TO DESIGN] [EXAMPLE] [BUSINESS ANALYSIS] Customer has a NEED to know the currency of their data Business analysis constrained by existing contract/interface – output in blocks Increased complication for customer – based on a legacy system Need expressed through requirement expressed through design/architecture Customer reluctantly agrees
- #19 SLIDE 18 [ABSTRACTION IN TO DESIGN] [EXAMPLE] [SOFTWARE DELIVERY] Development concentrates on delivering to the design Less effort spent delivering the need in a simple manner Testing concentrates on the contract/interface – based on functionality rather than customer value Effort spent testing compliance with the design
- #20 SLIDE 19 [ABSTRACTION IN TO DESIGN] [EXAMPLE] [SOFTWARE DELIVERY] Testing becomes focused on the contract/interface Delivery team has lost its understanding of customer value Tangled stories -- Increasing development costs on low-value tests
- #21 SLIDE 20 [ABSTRACTION IN TO DESIGN] [EXAMPLE] [SOFTWARE DELIVERY] Testing really should be concentrating on the customer need Currency of the data Untangled stories – tests for customer value
- #22 SLIDE 21 [ACCIDENTAL COMPLICATION] [INTRODUCING UNNECESSARY COMPLICATION] Original customer need/value converted into a requirement converted in to a design Contracts/interfaces are 2nd class requirements Delivery team was excluded from an initial understanding of the problem Development to contracts reinforces the life of those contracts – software increasingly harder to change [ESSENTIAL COMPLICATION] Derive value through test-driven development Base acceptance criteria on stories and deliver first-class requirements
- #23 SLIDE 22 [ACCIDENTAL COMPLICATION] [INTRODUCING UNNECESSARY COMPLICATION] Needs immediately converted to requirements representing the current contract/interface Probably because an interface was created early Current contract offers the delivery team no chance to offer improvements/changes based on problem Less opportunity to find a quick, simple, small, testable, independent solution to the customer’s problem Introduces unnecessary complication and work based on the design or interface or silo
- #24 SLIDE 23 [ACCIDENTAL COMPLICATION] [INTRODUCING UNNECESSARY COMPLICATION] [HOW SHOULD IT HAVE BEEN DONE?] Discover true customer needs with ‘5 Why’s’
- #25 SLIDE 24 [WHEN SHOULD WE ABSRACT OUR ANALYSIS IN TO DESIGN?] - Deliver software components with a single responsibility to address an isolated need - Abstract software design when these needs have been fulfilled - Independent software components express the true need by this point
- #26 SLIDE 26 [TAKEAWAY] [SPOTTING TANGLED STORIES] Focus concentrates on understanding the design rather than the customer need Stories are organised by component team Stories are organised by legacy software system or contract/interface Stories mix the problem space with the solution space Abstracted designs accumulate functionality – becomes harder to test over time Customer doesn’t recognise the work – unengaged – only understands business need
- #27 SLIDE 27 [TAKEAWAY] [SPOTTING UNTANGLED STORIES] Discover value through 5 Whys? Keep backlogs small – requirements ROT – more likely to deliver backlog vs need Stories should describe the original problem Ensure the team is fully engaged with the problem – discover simple solutions Small, independent, testable stories that can released easily Customer is more likely to remain engaged
- #28 SLIDE 28 [THANK YOU] Thank you Hope you have found our talk interesting and useful Any questions?