Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Myths of Product Development


Published on

Describes and dispel some systemic fallacies about software product development.

Published in: Engineering
  • Be the first to comment

Myths of Product Development

  1. 1. De-mystify Product Development @shoaibshaukat Melbourne, 2015 Lean Thinking Agile Product Development
  2. 2. Purpose De-mystify some prevailing product development practices?
  3. 3. Practice #1 “High Utilisation of Resources will improve performance.”
  4. 4. Structures to meet unpredictable demand are different from the structures to meet linear demand. Team 1 Analyse Develop Test Operate Team 2 Analyse Develop Test Operate Team 3 Analyse Develop Test Operate Production Issue Production Issue QA Environment Issue
  5. 5. Practice #1
  6. 6. Little’s Law The average number of things in the system is the product of the average rate at which things leave the system and the average time each one spends in the system. WIP = Avg. Exit rate * Avg. Time Spent in System Avg. Time Spent in System (Cycle Time) = WIP / Avg. Exit Rate Example: A team (5 members) can complete a task in one day – If there are 5 tasks in a batch then Cycle time will become 5 days. Cycle Time = 5 / 1
  7. 7. High utilization of resources increases number of queues and their size. Queues affect economic performance Make WIP inventory visible Change the Management Control System from efficiency to response Selectively increase capacity Limit the number of active projects
  8. 8. Practice #2 “Processing work in large batches improves the economics of the development process.”
  9. 9. Holding Costs = High Transaction cost = Low Holding Costs = Low Transaction cost = High
  10. 10. COST BATCH SIZE Transaction Cost Holding Cost Total Cost Optimal Batch Size
  11. 11. Small batches allows to slash WIP and accelerate feedback -> improves cycle times, quality and efficiency. WORK WORK WORK WORK WORK WORK
  12. 12. Practice #3 “Our development plan is great; we just need to stick to it.”
  13. 13. Our development plan is great; we just need to stick to it. • Planning must respond to change to deliver the right customer value. • Every thing that customers said are not necessary is a product/need. • Customer needs can change during the project. • Lean Startup (or Lean UX) - Build-Measure-Learn (Eric Ries) • Plan based on business value, time criticality and effort. • User preferences or market needs can change abruptly requiring a rethink of the product specifications. • Don’t commit to a solution too early – Leave the decision to last responsible moment – (Mary Poppendieck) • Customers can’t accurately specify their needs for solutions that don’t exist yet. • Familiarity with existing product/process attributes can interfere with ability to express the novel product.
  14. 14. Practice #4 “The sooner the project is started, the sooner it will be finished.”
  15. 15. The sooner the project is started, the sooner it will be finished. Focus: Stop starting – Start Finishing. Value is only realised when delivered to customers. New projects, specially if they use shared resources will almost always create queues and slow down the delivery. Create WIP limits Don’t start a project until it’s value is clearly defined and provides the most benefits to organisation.
  16. 16. Business, IT, Customers, Partners Concept Evolve Deliver Harness Business Business Business IT IT IT Concept Evolve Deliver Harness Concept Evolve Deliver Harness Concept Evolve Deliver Harness LeanExperimentation
  17. 17. Practice #5 “The more features we put into a product, the more customers will like it.”
  18. 18. The more features we put into a product, the more customers will like it …
  19. 19. Less is More. How? MVP (Minimum Viable Product) – a product with a minimum feature set – high enough in value to customer to satisfy a particular need Focus on understanding user needs - understand how they use the products and their problems. Weighted Shortest Job First Bring developers closer to end user. Invest in building capacity to understand user environment.
  20. 20. Practice #6 “We will be more successful if we get it right the first time”!
  21. 21. “We will be more successful if we get it right the first time”! Requiring success on the first pass forces the teams towards the less risky. Innovation is risky by nature! Focus on shorter build times, early feedback, continuous learning! Software product development is complex and risky by nature! Promote experimentation. Embrace failure but celebrate recovering and learning from failure. Invest in automating the tools that help you deliver and learn faster.
  22. 22. Key Take Away Points Make queues and information flow visible Quantify the cost of delays and factor it into your decisions Introduce resource slack where utilisation is highest. Shift focus of control systems from efficiency to response time. Reduce transaction costs to enable smaller batch sizes and faster feedback. Experiment with smaller batches; you can easily revert to large batches if this doesn’t work. Treat the development plan as a hypothesis that will evolve as new information becomes available. Start projects only when you are ready to make a full commitment. Aim for simplicity; Ask what features can be deleted, not just what can be added. Experiment early, rapidly, and frequently, with computer models and physical prototypes, in controlled and real- life customer environments.