Introduction to product development flow
•Als PPTX, PDF herunterladen•
15 gefällt mir•5,199 views
This is the presentation for a pre-LSSC11 webinar on the topic of Lean Product Development flow. I’m going to introduce an approach to mixing Lean and Agile in order to achieve end to end agility. This is a major focus of my work in the recent 2 years with AgileSparks clients. Register for the Webinar which is on 16/3 at http://www.netobjectives.com/free-seminar-schedule/lssc11-session-4-intro-lean-product-development-flow-mar-2011-webinar This is also the topic I will talk about in my Agile Israel 2011 session “Techniques and experiences for managing end to end Releases/Projects/Programs using Kanban and Flow” http://agilesparks.com/KanbanandFlowLecture
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Introduction to product development flow
Ähnlich wie Introduction to product development flow (20)
Mehr von Yuval Yeret
Mehr von Yuval Yeret (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Introduction to product development flow
- 1. http://www.flickr.com/photos/yuvalyeret/265568342/in/set-72157594323037021/ Intro to product development flow Yuval Yeret
- 2. www.linkedin.com/in/yuvalyeret Blogging @ http://yuvalyeret.com Presentations at http://www.slideshare.net/yyeret/ Yuval Yeret yuval@agilesparks.com Http://lssc11.leanssc.org @yuvalyeret Agile Professionals in Israel - I'm there - Are you?
- 3. What we will cover in this webinar Why we need to think about flow – common dysfunctions of development processes Flow as part of a recipe for success How to enable flow How to see flow Common questions/concerns about flow Flow and Iterations/Scrum What to do tomorrow with flow
- 4. So how does an agile process look compared to traditional? www.slideshare.net/wnazzaro/agile-it-and-the-business-community/
- 5. The Waterfall approach Requirements Design Code Testing DONE Requirements Design Code Testing Requirements Design Code Testing Requirements Design Code Testing Requirements Design Code Testing Requirements Design Code Testing Time
- 6. Ideal world Feature-Driven DONE R D C T R D C T R D C T R D C T R D C T R D C T Time
- 7. But what we typically see is... Feature Freeze Coding Done DONE Hardening R D C T QA GAP R D C T R D C T R D C T R D C T R D C T Time
- 8. What this causes Feature Freeze Coding Done DONE QA GAP Time
- 9. Time to Complete Many features in parallel DONE R D C T R D C T Parallel - WIP R D C T R D C T R D C T R D C T DONE R D C T R D C T Requirements Design Code Testing DONE R D C T Time R D C T Requirements Design Code Testing R D C T Requirements Design Code Testing R D C T Time Requirements Design Code Testing Requirements Design Code Testing Ideal Flow Waterfall Requirements Design Code Testing Time
- 10. Scrumgate Feature Freeze DONE Hardening D C T Requirements D C T D C T D C T D C T D C T Time
- 11. And... DONE R D C T R D C T R D C T R D C T R D C T R D C T Time
- 12. Big Features DONE R D C T R D C T R D C T R D C T R D C T R D C T Time DONE R D C T R D C T R D C T Time
- 13. What about multiple teams? T1 Team1 Team2 Integration Team T2 Coding Done T R T1 T2 T R T1 T2 T DONE R T1 T2 T R T1 T2 T R T1 T2 T R T1 T2 T Time
- 14. A scrum example Features in progress? 3 versus 1
- 15. So now that we see the pain...
- 16. What do we do? DavidAnderson’s recipe for success: Focus on Quality Reduce Work-in-Progress, Deliver Often Balance Demand against Throughput Prioritize Reduce Variability and Improve the Process
- 17. First impediment to flow – big Features/Batches BIG Features 17
- 18. That are stuck for long in each stage 18
- 19. Move from rocks to pebbles 19
- 20. Moving to small units of work is NOT enough If our policy/behavior is early start of everything “Working on many things in parallel will ensure high utilization” “Everything is important” “Each engineer has his own baby feature, they don’t want to collaborate, and there is a high collaboration overhead” Batch size is still HIGH 20
- 21. How do we Visualize the work status in more depth? TODO Work in Process (WIP) Done 21
- 22. The Cumulative Flow Diagram Introduced in Lean Product Development by Don Reinertsen and David Anderson Visualize where the Features/Stories are in the workflow across time TODO Work in Process (WIP) Done 22
- 23. Mushon Inbar Inbar Elad Mushon Elad Inbar Elad Mushon How to do a CFD 23
- 24. How to do a CFD 24
- 25. What can teams learn from Cumulative Flow? Total Scope Dev Burnup Work in Process (WIP) Done Burnup Real Done Burnup 25 Average Cycle Time
- 26. Work in Process High Work-in-process leads to longest lead times to feedback and higher costs Low work-in-process greatly reduces lead times to feedback Results in more effective and safer projects
- 27. How can I take this to my context?
- 28. Visualize and manage the flow on your work tracking system HP QualityCenter Microsoft TFS IBM Lotus Notes JIRA Etc..
- 29. If you don’t currently have a work tracking system – you can use a kanban system AgileZen (RallyDev) LeanKit Kanban 29
- 30. A Kanban board – Not a Must for Flow But will SIGNIFICANTLY improve it
- 31. Common questions/concerns about flow
- 32. Isn’t this a waterfall?
- 33. But wouldn’t the bottleneck slow everything?
- 34. An example - focus on quality Feature Freeze Coding Done DONE Hardening R D C T R D C T R D C T R D C T R D C T R D C T Time
- 35. How do I commit?
- 36. How does flow relate to iterations/scrum?
- 37. How is this different than Scrum? Applicability? Scope? Prescription? The interesting question – how they can complement each other
- 38. Mashups DONE DONE DONE READY IterationsFlow IterationsFlow IterationsFlow 38
- 39. Project/Component Kanban Board Flow DONE READY! Opportunity Team & Project Manager Scrum Teams From my talk at #LSSC10... – Amdocs Case Study
- 41. Scrum/Kanban - The way WIP limits/PULL work Kanban board Scrum board Done :o) To do Ongoing Done :o) To do Ongoing 2 A A B B C C D D FLOW FLOW WIP limited per unit of time(iteration) WIP limited per workflow state Source: HenrikKniberg
- 42. approaches to change Evolution (Kanban) Performance Revolution (Scrum) (kanban the tool) Time 42
- 43. Recommendations for scrummers looking at flow If scrum works for you – don’t touch it! If you see dysfunctions consider how flow can help you Look at flow as a way to scale effectively
- 44. Main attractiveness of flow Finally, an agile-based approach that easily supports: Mainstream/pragmatic organizations – wanting to improve, avoiding a revolution Large/Complex environments where feature teams are not enough
- 45. Take aways Visualize YOUR workflow Limit work in process: Stop starting, start finishing Identify bottlenecks/constraints and think how to improve performance This applies to all LAYERS (including the META one) A pragmatic tip - Think how to introduce Flow to YOUR work tracking system
- 46. It is not crucial to nail down the accurate optimized WIP Limit / Batch Size / Sprint length ½ the WIP, ½ the batch size, can be a good start... Based on ReinertsenProduct Development Flow
- 47. Go do some reading...
- 48. Questions?
- 49. Summary Limit work in process: Stop starting, start finishing 49
- 50. www.linkedin.com/in/yuvalyeret Blogging @ http://yuvalyeret.com Presentations at http://www.slideshare.net/yyeret/ Yuval Yeret yuval@agilesparks.com Http://lssc11.leanssc.org @yuvalyeret Agile Professionals in Israel - I'm there - Are you?
- 51. Images Attribution http://www.flickr.com/photos/yuvalyeret/265568342/in/set-72157594323037021/ www.slideshare.net/wnazzaro/agile-it-and-the-business-community
Hinweis der Redaktion
- TraditionalLockup capital for a long time by having significant work in process before seeing any realization of business valueAgileBy releasing incrementally we open up the opportunity to obtain business value much earlier than would otherwise be possible and prior to the completion of the overall projectThis can be done by breaking the project into "feature chunks" that are delivered every few weeksIn this webinar, we will focus on FLOW and process, not so much on roles, responsibilities and other aspects of Lean/Agile
- Focus on feature release-level qualityNot just storyreduce features in progress at the release levelReducing stories/tasks in progress at a person/team level is not enoughDeliver features often (To internal consumers / to production )Delivering stories is not enough
- With big features everything is harder – time to define, to stabilize, to control variance, to test, to verify, to reproduce …Symptoms:Our features/user stories are too big to fit into one iteration – we need LONGER iterations..We need a long time to nail down the design for this. Our PSP for this iteration is a high-level design…Solution?Effective User Story Analysis to create Minimum Marketable Features (MMF)DesignEither do all design up frontOr have a growing evolutionary designEveryone works on highest priority – EVEN if outside comfort zoneNeed to improve collective code ownershipDevelopers need to feel safe to work everywhere in the team’s codebase
- Incease time until we can test, and complexity to InstallSymptoms:Our features/user stories are too big to fit into one iteration – we need LONGER iterations..We need a long time to nail down the design for this. Our PSP for this iteration is a high-level design…Solution?Effective User Story Analysis to create Minimum Marketable Features (MMF)DesignEither do all design up frontOr have a growing evolutionary designEveryone works on highest priority – EVEN if outside comfort zoneNeed to improve collective code ownershipDevelopers need to feel safe to work everywhere in the team’s codebase
- Also used to manage variability
- How
- More widely applicableLooks end to end – not just at the team levelTypically complementaryScrum at the team levelFlow at the e2e levelFlow to READY, iterate to DONE, FLOW to DONE DONE
- Limit wip – applicable to every layer