Product Development Using Agile and Lean Principles
•
16 recomendaciones•4,647 vistas
My workshop for #fintech startups at StartupBootcamp in Mumbai on Mar 16
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Product Development Using Agile and Lean Principles
Similar a Product Development Using Agile and Lean Principles (20)
Más de Tathagat Varma
Más de Tathagat Varma (20)
Último
Último (20)
Product Development Using Agile and Lean Principles
- 2. Welcome J
- 3. Agenda Schedule Topics 09:30 – 11:00 Agile and Lean 11:00 – 11:30 Tea break 11:30 – 13:00 Scrum Framework 13:00 – 13:45 Lunch 13:45 – 14:45 Scrum-based Product Development 14:45 – 15:00 Tea break 15:00 – 17:00 Scrum Simulation 17:00 – 17:30 Wrap-up / Q&A / Feedback
- 4. Waterfall Software Development http://damonpoole.blogspot.in/2009/07/traditional-development-game-of.html What are the key challenges with waterfall?
- 6. Waterfall challenges: Poor Risk Management http://www.agilenutshell.com/agile_vs_waterfall
- 8. Waterfall challenges: Poor Change Management http://www.agilenutshell.com/agile_vs_waterfall
- 9. Late learning sequence of product development http://alistair.cockburn.us/Disciplined+Learning
- 10. As a result, software is… Late Buggy Costly
- 12. But we want software to be…
- 13. The Myth of Faster, Better, Cheaper
- 14. The Myth of Faster, Better, Cheaper Good FastCheap Bad?
- 15. Let’s paint…
- 17. Incremental and Iterative Incremental Iterative Scheduling and staging strategy Rework scheduling strategy Parts of system are developed at different times and integrated as they are completed Review and improve part of the systems Doesn’t imply or require iterative development Doesn't presuppose incremental development Output is not necessarily subject to further refinement Output is examined for modifications in successive iterations
- 18. http://itsadeliverything.com/wordpress/images//iterative-incremental-mona- Incremental and Iterative
- 20. What is the most important part in these two machines? “The Brakes!!!” They let you go faster…
- 23. 12 Agile Principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self- organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- 25. Waterfall vs. Agile http://www.agilenutshell.com/agile_vs_waterfall By doing them continuously: • Quality improves because testing starts from day one. • Visibility improves because you are 1/2 way through the project when you have built 1/2 the features. • Risk is reduced because you are getting feedback early, and • Customers are happy because they can make changes without paying exorbitant costs.
- 29. Waterfall vs. Agile: Risk vs. Value Delivered http://www.testingthefuture.net/wp-content/uploads/2011/12/waterfall_versus_agile_development.png
- 33. Lean × maximize customer value while minimizing waste. × A lean organization understands customer value and focuses its key processes to continuously increase it. The ultimate goal is to provide perfect value to the customer through a perfect value creation process that has zero waste.
- 34. Lean Thinking × Lean thinking changes the focus of management from optimizing separate technologies, assets, and vertical departments to optimizing the flow of products and services through entire value streams that flow horizontally across technologies, assets, and departments to customers. × Eliminating waste along entire value streams, instead of at isolated points, creates processes that need less human effort, less space, less capital, and less time to make products and services at far less costs and with much fewer defects, compared with traditional business systems. Companies are able to respond to changing customer desires with high variety, high quality, low cost, and with very fast throughput times. Also, information management becomes much simpler and more accurate.
- 35. Pillars of Lean Thinking 1. Identify Value 2. Map the Value Stream 3. Create Flow 4. Establish Pull 5. Seek Perfection
- 36. Pillars of Lean Thinking 1. Identify Value Specify value from the standpoint of the end customer by product family. 2. Map the Value Stream Identify all the steps in the value stream for each product family, eliminating whenever possible those steps that do not create value. 3. Create Flow Make the value-creating steps occur in tight sequence so the product will flow smoothly toward the customer. 4. Establish Pull As flow is introduced, let customers pull value from the next upstream activity. 5. Seek Perfection As value is specified, value streams are identified, wasted steps are removed, and flow and pull are introduced, begin the process again and continue it until a state of perfection is reached in which perfect value is created with no waste.
- 39. Value Equation of a Smartphone http://www.jtklepp.com/2009/12/03/a-value-based-framework-for-the-smartphone-os-war/
- 40. Value Stream Map (VSM) × Special type of flow chart that uses symbols known as "the language of Lean" to depict and improve the flow of inventory and information × Purpose is to provide optimum value to the customer through a complete value creation process with minimum waste in × Design (concept to customer) × Build (order to delivery) × Sustain (in-use through life cycle to service)
- 41. Value Stream for Cola Cans Lean Thinking – Womack and Jones
- 43. Kent Beck’s Value Stream Map
- 44. Agile Value Stream Map Lean Software Development, An Agile Toolkit – Mary Poppendeick
- 45. Lean Principles in Software Development Eliminate waste Amplify Learning Decide as late as possible Deliver as fast as possible Empower Team Build integrity in See the Whole
- 49. Wastes in Software Development Lean Software Defects Defects in Software, (Requirements, Design, Code) Overproduction Extra features that remain unused Waiting Delays in getting information, reviews, approvals Talent Talent (motivation, engagement, relearning) Transportation Distributed teams, Component Teams Inventory Work in Progress, Partially done work, Motion Chasing information, Task switching Extra-processing Over-engineering, Over-documentation, Over- process steps, Relearning legacy code, Handoffs in production systems,
- 51. 5S in Software Development × Sort (Seiri): Sort through the stuff on the team workstations and servers, and find the old versions of software and old files and reports that will never be used any more. Back them up if you must, then delete them. × Systematize (Seiton): Desktop layouts and file structures are important. They should be crafted so that things are logically organized and easy to find. Any workspace that is used by more than one person should conform to a common team layout so people can find what they need every place they log in. × Shine (Seiso): Whew, that was a lot of work. Time to throw out the pop cans and coffee cups, clean the fingerprints off the monitor screens, and pick up all that paper. Clean up the whiteboards after taking pictures of the important designs that are sketched there. × Standardize (Seiketsu): Put some automation and standards in place to make sure that every workstation always has the latest version of the tools, backups occur regularly, and miscellaneous junk doesn't accumulate. × Sustain (Shitsuke): Now you just have to keep up the discipline. Implementing Lean Software Development from Concept to Cash – Mary Poppendeick
- 52. 5S in Java × Sort (Seiri): Reduce the size of the code base. Throw away all unneeded items immediately. Remove: × Dead code, Unused imports Unused variables, Unused methods, Unused classes, Refactor redundant code × Systematize (Seiton): Organize the projects and packages. Have a place for everything and everything in its place. × Resolve package dependency cycles, Minimize dependencies × Shine (Seiso): Clean up. Problems are more visible when everything is neat and clean. × Resolve unit test failures and errors ( passed == 100%), Improve unit test coverage ( > 80%), Improve unit test performance, Check AllTests performance, Resolve checkstyle warnings, Resolve PMD warnings, Resolve javadoc warnings, Resolve TODO’s × Standardize (Seiketsu): Once you get to a clean state, keep it that way. Reduce complexity over time to improve ease of maintenance. × Sustain (Shitsuke): Use and follow standard procedures. Implementing Lean Software Development from Concept to Cash – Mary Poppendeick
- 53. Time for break!
- 55. Scrum
- 56. Scrum Framework
- 58. So, what happens in each increment? Increment ≠ Mini-waterfall
- 60. Feedback Loops in Traditional Techniques vs. Agile Techniques
- 61. feedback loop in agile lifecycles
- 64. Roles, Ceremonies and Artifacts • Scrum Team is small (5-9), cross- functional team members from Dev, UX, QA (excluding Product Owner) to ship complete feature(s) end to end • Scrum Master is the servant leader responsible for supporting team • Product Owner owns Product Backlog and sets appropriate priority for team to act upon Roles Product Owner Scrum Master Scrum Team Ceremonies Sprint Planning Meeting Daily Stand- ups Backlog Grooming Product Demo Sprint Retrospective Artifacts Product Backlog Sprint Backlog Increment Release Burn- down Chart Sprint Burn- down Chart
- 65. Scrum Roles
- 67. So, how do we start?
- 68. What’s wrong?
- 72. How Apple does it? Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people. My favorite line of the day was when people kept raising their hand saying, "Does it do [x]?", "Do you plan to add [y]?". Finally Jobs said, "Wait wait — put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don't want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features.” http://www.oreillynet.com/onlamp/blog/2004/08/say_no_by_default.html
- 73. Kano Model
- 74. MoSCoW • Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.MUST • Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary. SHOULD • Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.COULD • Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.WON'T
- 75. Minimal Marketable Feature A Minimal Marketable Feature (MMF) is a feature that is minimal, because if it was any smaller, it would not be marketable. A MMF is marketable, because when it is released as part of a product, people would use (or buy) the feature. An MMF is different than a typical User Story in Scrum or Extreme Programming. Where multiple User Stories might be coalesced to form a single marketable feature, MMFs are a little bit bigger. Often, there is a release after each MMF is complete. An MMF doesn’t decompose down into smaller sub-feature, but it is big enough to launch on its own. A MMF can be represented as a User Story — a short, one-sentence description.
- 79. Product Backlog × The Product Backlog is a prioritized list of everything that might be included in a product. × The Product Owner creates, maintains, and regularly re- orders the Product Backlog. × The Product Owner uses the Product Backlog to adapt to emerging requirements, customer feedback, and market changes. https://felixgrayson.files.wordpress.com/2015/08/image4.png
- 83. Roadmap -> Release -> Sprint https://www.scrumalliance.org/scrum/files/42/421788e7-1ebb-468f-8404-ca4cb9d0be6d.jpg
- 84. From Product Backlog to Sprint Backlog https://kienlamcs100w.files.wordpress.com/2014/09/sprint-planning-meeting-outcome.jpg
- 85. Sprint Backlog × User Stories selected by The Team × Will be built in current Sprint × Fully Estimated × Divided into Tasks
- 86. User Stories × User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template: × As a <type of user>, I want <some goal> so that <some reason>. × User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
- 87. Epics and User Stories
- 88. Themes, Epics and Stories
- 92. Acceptance Criteria vs. Definition of Done
- 93. Technical Debt
- 94. Tech Debt
- 95. Potentially Shippable Increment × A Potentially Shippable Product is the sum of the Product Backlog Items delivered each Sprint. × Delivering Potentially Shippable Product each Sprint is fundamental to the Scrum because when work is divided into simple pieces it can be finished in a short iterations. × By accelerating the creative process and putting a functioning product in the hands of the user, the Team can gather feedback more quickly than it otherwise would have. To achieve this feedback loop on a Sprint-by-Sprint basis, Scrum Teams deliver Potentially Shippable Product at each Sprint Review. × The keys to creating working product at the end of each Sprint are: × A cross-functional Team with all the skills necessary to complete the Sprint Backlog. × Quality User Stories with explicit definitions of Ready and Done. × A Product Owner with the ability to prioritize backlog into vertical slices of functionality.
- 96. Sprint Planning × Happens on Day 1 of every Sprint. × Decide what user stories will be attempted based on dependencies, priority, resources, time × Define what Done means for this iteration. Checked in software, tested, documented and demonstrable. × Team plans iteration by decomposing user stories into estimated tasks describing the work that needs to be done to complete the story. × Task should be in the order of 1-16 Hrs × Everyone agrees on what to do and commits to completing the work. × Team signs up for tasks on Sprint backlog.
- 97. Estimation × “The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them.” – Steve McConell × Are any two projects same?
- 102. Story Points × Agile teams generally prefer to express estimates in units other than the time-honored "man-day" or "man-hour". Possibly the most widespread unit is "story points". × One of the chief reasons is the use of velocity for planning purposes. "Velocity", in the sense Agile teams use the term, has no preferred unit of measurement, it is a dimensionless quantity. Velocity allows teams to compute the expected remaining duration of the project, as a number of iterations, each iteration delivering some amount of features. × Another important reason has to do with the social and psychological aspects of estimation: using units such as story points, emphasizing relative difficulty over absolute duration, relieves some of the tensions that often arise between developers and managers around estimation: for instance, asking developers for an estimate then holding them accountable as if it had been a firm commitment. http://guide.agilealliance.org/guide/nuts.html
- 103. Estimation Mainly two forms of estimation × Analogous Estimation [T-Shirt Sizing - S,M,L,XL] × This Story is like another Story (maybe a little more difficult, maybe a little less) × Give this Story a comparable estimated value. × Estimate against multiple Stories of the same effort. × Analogous estimation is successful due to our inherent ability to better measure relative size than absolute size. × Planning Poker × Each estimator is given a deck of cards, each card contains a valid estimate. × Fib ––1,2,3,5,8,13,20,301,2,3,5,8,13,20,30 × Story is read and discussed briefly × Each estimator selects a card that reflects their estimate. × Cards are turned over for all to see. × Discussion takes place × Re-estimate to try to get convergence.
- 104. Planning Poker
- 106. Daily Standup × Daily meeting, 15 mins, team members answer 3 questions. × What did you do yesterday? Informs team on completed tasks, dependencies. × What will you do today? Informs team on possible upcoming dependencies, requests. × What is blocking you? Helps identify resources to help unblock tasks after the meeting. × Sprint backlog should be updated with yesterdays tasks prior to meeting × Not intended for problem solving, or as a status meeting. × Everyone is invited, but only team members
- 107. Scrum Task Board
- 110. Sprint Review × Held on the final day of every sprint × Team presents what it accomplished during the sprint in the form of a demo of new features or underlying architecture. × Team also explains what remains undone and why. × Should be a very informal meeting where non team members can see what has been accomplished and comment. × Demo should foster collaboration about what can and should be done next, providing valuable input into the subsequent sprint
- 111. Sprint Retrospective × Held on the final day of every sprint. × Scrum Team ONLY revises, their development process to make it more effective and enjoyable for the next Sprint × Inspect how the last Sprint went in regards to people, relationships, process and tools. × Identify and prioritize the major items that went well and those items that-if done differently-could make things even better. × Team takes 2-3 items and brainstorms solutions to most important issues × Team should agree on actionable improvement
- 112. Time for break!
- 114. Planning a Family Vacation Holiday Plan Map GPS Odometer Speedometer Eyes Strategic Direction Execution Alignment Vision Execution Feedback Goals
- 115. Planning in Agile Mission Vision Portfolio Product Release Sprint Daily Organizational Strategy Agile / Scrum- based Product Development
- 116. Product Runways Strategic Vision Set by the CEO / Board and consists of Strategic Direction, Solution Strategy, Technology Initiatives and Themes Reviewed annually as part of annual strategic planning and revised as needed Serves as a strategic input for product vision Product Vision High-level overview of product requirements owned by respective POs Acts as true north for the product in long term (3-5 years) Serves as the input for overall product roadmap in medium term (1-3 years) Product Roadmap Calls out the high-level themes and release timeline in next 1-3 years Consists of swimlanes (strategic priorities vs. lights on, client requests,vs. competitive intel, technical debt vs innovation ideas,, etc.) Reviewed each quarter by Product Council Product Backlog Prioritized list of features identified for the next 1-3 releases Owned and maintained by respective POs based on relative prioritization of each feature request Revised constantly based on evolving inputs and refined weekly in grooming sessions with scrum team Sprint Backlog Consists of highest-priority / highest-value features agreed upon for development in the current sprint (1-4 weeks) Product Owner responsible to prioritize the features, while scrum team responsible for planning, estimation, planning, execution and completion of those features in a sprint Once the sprint has started, any new requirements or change request must wait until the next sprint planning
- 117. Adaptive Planning ProductBacklog ProductRoadmap SprintBacklog ProductVision Futuristic picture of the product Based on technology evolution, market development, industry trends, etc. Reviewed annually, and revised as needed High-level wish list of themes and epics for a long-term Reviewed by Product Council on a quarterly basis Typically revised annually Prioritized list of Themes, Epics and User Stories Gets constantly revised and groomed on a weekly basis Well- groomed User Stories Can’t be changed once the sprint is underway Current Sprint 3-6 months 12-24 months 1-3 years SmallStories, FirmRequirements, LargeStories/Epics/Themes, Fuzzy/EvolvingRequirements
- 119. Product Vision Shared by All Desirable and Inspirational Clear and Tangible Broad and Engaging Short and Sweet
- 120. Product Vision – Elevator Pitch For (target customer) Who (statement of the need or opportunity) The (product name) is a (product category) That (key benefit, compelling reason to buy) Unlike (primary competitive alternative) Our product (statement of primary differentiation) http://www.joelonsoftware.com/articles/JimHighsmithonProductVisi.html
- 121. Product Vision Box × As the name suggests… × Describes the top 2-3 features of product
- 122. Press Release × Amazon’s “working backwards” × Write the launch press release!
- 123. http://blogs.salesforce.com/company/2012/06/agile-approach-to-talent-management.html Agile lifecycle – small picture
- 124. Backlog Grooming × Upto 5-10% of sprint time × Creating or refining new PBIs × Estimating PBIs × Prioritizing PBIs
- 126. Affinity Estimating Guidelines • If team is already Sprinting, find a small-ish one already completed that was a really good estimate; use that estimate • Or find a fully understandable story and fully task it out; call it either a 2 or a 3 • Smallest at the right and largest on the left compared to initial story • Anyone can move anyone else’s story position
- 128. Release Planning
- 129. Release Burndown Chart https://agilewarrior.files.wordpress.com/2013/06/burndown-3-details.png?w=540
- 131. Time for break!
- 132. Scrum Simulation
- 134. Activity Time Sprint Planning 10 min Sprint – Day 1 7 min Daily Scrum 3 min Sprint – Day 2 7 min Daily Scrum 3 min Sprint – Day 3 7 min Sprint Demo 5 min Sprint Retro 20 min
- 135. Product Backlog Product Backlog Item Order Create cover art, brand, and/or logo Define major topics for Martian tourism Describe “Art Interests in Europe” tour Describe a tour based on photosynthesis Outline a “7 Wonders of the World” expedition Set prices for the tours Outline warning messages (gravity, oxygen, fungi, etc.) Suggest clothing options Explain travel options to/from Mars Describe a “Human Sports” tour Outline refund policy Suggest related services Define advertisers Define a 12-month campaign Set-up how to get more information
- 136. Feedback
- 137. Q&A