Downloaded 12 times
Uploaded bySudipta Lahiri
Upstream: Shifting-left towards organization agility
The document discusses the importance of lead time (LT) in agile methodologies and how to improve organizational agility by focusing on well-groomed user stories. It emphasizes the need for effective story mapping, prioritization of features, and accurate forecasting based on the cost of delay. The speaker, Sudipta Lahiri, presents strategies for enhancing collaboration and decision-making to satisfy customer needs more efficiently.
More Related Content
Similar to Upstream: Shifting-left towards organization agility
Upstream: Shifting-left towards organization agility
- 1.
- 2. Upstream Shifting-Left towards OrganizationAgility Sudipta Lahiri Head of Engineering, Digite 2
- 3. About Digité • Pioneerin Web-based Collaborative Products/ Solutions for Geographically Distributed Teams • Headquartered in Cupertino, CA • Products that cover Lean/ Kanban, Agile ALM, Project/ Portfolio Management 3
- 4. About myself • Headof Engineering and Products @ Digité • Passionate about Lean-Agile • Speaker, Conference and Meetup Organizer 4 Sudipta Lahiri (Sudi)
- 5.
- 6.
- 7. Setting the context… •The 1st Agile Principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • What would be a single KPI if you want to focus on this priority? • Lead time (LT): From the time when the customer gave you some idea of what he/she wanted, how long did it take him/her to get it? • Keeping focus on LT helps all teams come together to serve a common objective: customer/user 7
- 8. How do webring LT down? Ideation to Groomed Stories (including the front end) Specification to Dev Complete Dev Complete to Production Deployment Agile methods focus here DevOps extends the spectrum 8 This is well researched and we largely know what to do! Challenge is in adoption across the levels of the organization This is largely fuzzy… largely ignored and often, takes the bulk of LT Our focus today! DownstreamUpstream
- 9. Upstream: Shifting AgilityLeft Ideation to Groomed Stories (including the front end) Specification to Dev Complete Dev Complete to Production Deployment 9 DownstreamUpstream WorkOptions Commitment Point Discards AbortsMinimum Maximum Towards Increasing Agility!
- 10. Value Streaming Upstreamand Downstream Getting the right set of “groomed” stories 10
- 11.
- 12.
- 13.
- 14. Grooming “User Story”right… User Story != User Requirements 14
- 15. Conventional “Requirements” havefailed… 15
- 16. 16 If you goto a restaurant and see this: “Entree comes with soup or salad and bread” What would you interpret? (Soup or Salad) and Bread OR Soup or (Salad and Bread)?
- 17.
- 18.
- 19. What’s the mostcommon reaction to this? 19
- 20. Root cause issomewhere else: Nature of applications have changed! Back then… Now… 20
- 21. Common User Story“anti-patterns” • User Stories != User Requirements • A basis of conversation! • Do not follow the INVEST criteria • Small, independent, Testable • Ambiguous language in User Stories • Tasks wrapped as User Stories • No clear Acceptance Criteria • All business rules != Acceptance Criteria • Consider BDD • Agile welcomes changing requirement • You still need to give as much clarity that you have today! • Horizontal work items (vs) verticals slices of functionality • Estimation is classic waste; minimize it! 21 Badly Groomed User Stories will impede Organization’s Agility!
- 22. Story Maps: UserStories + Release Planning 22 ReleasePlanning Usage Sequence Activities/ Backbone S T O R I E S
- 23.
- 24. Story Maps vsProduct Backlogs • Unlike a product backlog, story maps: • Help generate Stories as per INVEST • Make visible the flow of work from one to another • Bring out how the hierarchy within different cards • Identify anything missing from the product backlog • Use as a basis for release prioritization 24
- 25. So, we knowhow to generate “Groomed” User Stories If Demand > Supply, how do we decide what Features or EPICs to take up next for grooming? 25
- 26. 1. Demand Shapingwith Risk Assessment 26
- 27. 2. Improve Agilityby knowing what to start! Are we working on the right thing “now”? Should we work on something else “now”? 27
- 28. Asking the rightquestion… From “When can I get it?” To “When do you need it” 28
- 29. Once you knowwhen do you need it… Static Alerts • Tools can track Due Dates - have the Board highlight it Dynamic predictions! • Get the Forecast Completion Date • If this is later than the Due Date, then highlight the RISK on the Board 29 Due Date 19-Feb-2019 Due Date Forecast Date
- 30. Don’t “waste” workingon the wrong things… • Demand > Supply, for most of us! • If your data shows that you will finish something much sooner than when you need it, then delay it! • Don’t spend bandwidth now on this; work on something else… maximize Opportunity potential! • Consider CoD/CoS when deciding how much risk you are willing to take for the “deferring” card • This decision making is part of the Upstream process – not downstream! 30 15–Oct-2018 Due Date Forecast Date
- 31. 3. Better Forecastingbased on Cost of Delay 31
- 32. Understanding Cost ofDelay (COD) • You know what’s an Expedite work items • Product Management should be able to help you define the “Fixed Date” or “Intangible” work items • You might struggle to define the curve for Standards but relative scaling might be easy 32
- 33. Cost of StartingDelay Cost of Starting Delay Cost of Finishing Delay Cost of Finishing Delay Cost of (Finishing) Delay + Lead Time distribution = Cost of (Starting) Delay
- 34. Let’s recap… • Characteristicsof Upstream… • Options vs Work, Maximum vs Minimum WIP Limits • Value Streaming Upstream and Downstream • Getting User Stories right… • Antipatterns of User Story Definition • Story Maps • Feature Prioritization • Demand Shaping • Forecasting based on LT Distribution • Cost of Starting Delay 34
- 35. • Reach meat: • @sudiptal • slahiri@digite.com • lahiri.sudipta@gmail.com THANK YOU! 35 “Absorb what is useful, discard what is useless and add what is specifically your own” Bruce Lee