Transcript Slide 1
Introduction to Agile & Scrum Saket Bansal PMP, PMI-ACP , CSM , ITIL V3 F www.izenbridge.com 1 Essence of Agile Empirical Process Scrum Scrum Roles Scrum Ceremonies Scrum Artifacts www.izenbridge.com 2 In the struggle for survival, the fittest win out at the expense of their rivals because they succeed in adapting themselves best to their environment. —Charles Darwin www.izenbridge.com 3 The United States Department of Defense (DoD) and NASA have used iterative and incremental development (IID) since the 1950s In the 1960s, Evolutionary project management (Evo) was conceptualized by Thomas Gilb. Evo recommends one- to two-week iterations, delivery of product each iteration In 1986, “The NewNew Product Development Game,” a whitepaper published by Takeuchi and Nonaka Takeuchi and Nonaka discuss the “rugby approach” of dedicated, self-organizing teams www.izenbridge.com 4 “The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.” The New New Product Development Game Stop running the relay race and take up rugby www.izenbridge.com 5 Scrum Extreme Programming Clear Crystal IBM’s Rational Unified Process Dynamic Systems Development Method (DSDM) Many more… www.izenbridge.com 6 In 2001, a group of 17 “lightweight" methodologists met. The meeting also included the representatives of eXtreme Programming (XP) Scrum DSDM Adaptive Software Development Photo taken by Scott Catron The Salt Lake Valley, Snowbird, Utah The Agile Manifesto was written www.izenbridge.com 7 We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan This implies, while there is a value in the items on the right, we value the items on the left more. www.izenbridge.com 8 Focus on empowered, selfmanaging , cross functional teams Members collaborating in person to solve a mutual problem Tools support—not replace— Interactions www.izenbridge.com 9 Provide actual working product as a status report, “product review” Agile teams prefer face-to-face communication over documentation which is simpler, faster, and more reliable. Do not measure progress by percent completion of the functional milestones Design changes as the system is built, results in outdated documentation www.izenbridge.com 10 Customers become a part of the development process Writing specs down and throwing them over the fence is simply not effective Contract negotiation, Identify and define everything and spells out the payment and date www.izenbridge.com 11 It’s much easier to respond to change when the organization and the customer share a clear understanding of the project’s status Agile plans follow more of a rolling wave approach using top-down planning In plan-driven environments, all requirements are specified up front, broken down to the task level and estimated www.izenbridge.com 12 Poll 3 & 4 www.izenbridge.com 13 Agile Principles www.izenbridge.com 14 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. www.izenbridge.com 15 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. www.izenbridge.com 16 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. www.izenbridge.com 17 Agile and Traditional Development www.izenbridge.com 18 •Vision •Life cycle •Requirements •Schedule •Team •Communication mechanisms www.izenbridge.com 19 Incremental Delivery Over Big Bang Delivery Analysis Road Map Design Release Code Iteration Test Day Deploy www.izenbridge.com 20 www.izenbridge.com 21 Poll 5,6 & 7 www.izenbridge.com 22 Essence of Agile Empirical Process Scrum Scrum Roles Scrum Ceremonies Scrum Artifacts www.izenbridge.com 23 The empirical model of process control provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs www.izenbridge.com 24 Laying out a process that repeatable will produce acceptable quality output is called defined process control. www.izenbridge.com 25 Adopt the defined Modeling approach when the underlying mechanisms are reasonably well understood. Defined process gives cost advantage where product can be priced as commodity Adopt Empirical process when the process is too complicated for the defined approach If the commodity produced is of unacceptable quality , rework is high , higher costs of empirical process control is the only option www.izenbridge.com 26 Requirement Complexity Technology Complexity www.izenbridge.com 27 Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Three pillars uphold every implementation of empirical process control: • Transparency • Inspection • Adaptation www.izenbridge.com 28 Poll 8 www.izenbridge.com 29 Essence of Agile Empirical Process Scrum Scrum Roles Scrum Ceremonies Scrum Artifacts www.izenbridge.com 30 Scrum in 100 words • Scrum is an agile process that allows us to focus on • • • delivering the highest business value in the shortest time. It allows us to rapidly and repeatedly inspect actual working software. The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features. Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint. www.izenbridge.com 31 Self-organizing teams Product progresses in a series of month-long “sprints” Requirements are captured as items in a list of “product backlog” No specific engineering practices prescribed One of the “agile processes” www.izenbridge.com 32 24 hours Sprint 30 Days Sprint goal Return Return Cancel Sprint backlog Potentially shippable product increment Gift wrap Coupons Cancel Gift wrap Coupons Product backlog www.izenbridge.com 33 Scrum projects make progress in a series of “sprints” • Analogous to Extreme Programming iterations Typical duration is a calendar month at most A constant duration leads to a better rhythm Product is designed, coded, and tested during the sprint Sprint 30 Days www.izenbridge.com 34 Roles •Product Owner •Scrum Master •Team Ceremonies •Sprint review •Sprint planning •Sprint retrospective •Daily scrum meeting Artifacts •Product backlog •Sprint backlog •Increment www.izenbridge.com 35 Poll 9 , 10 & 11 www.izenbridge.com 36 Essence of Agile Empirical Process Scrum Scrum Roles Scrum Ceremonies Scrum Artifacts www.izenbridge.com 37 Define the features of the product Decide on release date and content Be responsible for the profitability of the product (ROI) Prioritize features according to market value Adjust features and priority every iteration, as needed Accept or reject work results www.izenbridge.com 38 Represents management to the project Responsible for enacting Scrum values and practices Removes impediments Ensure that the team is fully functional and productive Enable close cooperation across all roles and functions Shield the team from external interferences www.izenbridge.com 39 Typically 5-9 people Cross-functional: Programmers, testers, user experience designers, etc. Members should be full-time May be exceptions (e.g., database administrator) www.izenbridge.com 40 Teams are self-organizing • Ideally, no titles but rarely a possibility Membership should change only between sprints www.izenbridge.com 41 Poll 12 , 13,14 & 15 www.izenbridge.com 42 Essence of Agile Empirical Process Scrum Scrum Roles Scrum Ceremonies Scrum Artifacts www.izenbridge.com 43 Planning Sprint Planning Sprint Retrospect ive Process Check Act Sprint Review / Product Check Act Sprint / Doing Daily Standup /Collabor ation and Coordinati on www.izenbridge.com 44 Sprint Planning www.izenbridge.com 45 The Team and the Product Owner collaborate to help the Team determine how much Product Backlog it can turn into functionality during the upcoming Sprint. The Team create plans (Sprint Backlog) by identifying tasks for converting selected Product Backlog into functionality www.izenbridge.com 46 Sprint planning meeting Team capacity Sprint prioritization • Product backlog Business conditions Analyze and evaluate product backlog Select sprint goal • Sprint planning • Current product Sprint goal • • Decide how to achieve sprint goal (design) Create sprint backlog (tasks) from product backlog items (user stories / features) Estimate sprint backlog in hours Sprint backlog Technology www.izenbridge.com 47 Prioritized Product Backlog Sprint Backlog Facilitate www.izenbridge.com 48 Team selects items from the product backlog they can commit to completing Sprint backlog is created • Tasks are identified and each is estimated (1-16 hours) • Collaboratively, not done alone by the Scrum Master High-level design is considered As a vacation planner, I want to see photos of the hotels. Code the middle tier (8 hours) Code the user interface (4) Write test fixtures (4) Code the foo class (6) Update performance tests (4) www.izenbridge.com 49 The Daily Scrum Meeting www.izenbridge.com 50 Fine-grain coordination Daily commitment Raising impediments Peer pressure Access Progress towards sprint goal www.izenbridge.com 51 Parameters • Daily • 15-minutes • Stand-up Not for problem solving • Only team members, Scrum Master, Product Owner, can talk Helps avoid other unnecessary meetings Team is responsible of conducting this meeting www.izenbridge.com 52 Observe Facilitate What did you do yesterday? 1 What will you do today? 2 Is anything in your way? 3 These are not status for the Scrum Master • They are commitments in front of peers www.izenbridge.com 53 Sprint Review www.izenbridge.com 54 Team presents what it accomplished during the sprint Typically takes the form of a demo of new features or underlying architecture Informal • 2-hour prep time rule • No slides Whole team participates Invite the world www.izenbridge.com 55 Feedback on Product Demo Feedback on Product Facilitate www.izenbridge.com 56 Sprint Retrospective www.izenbridge.com 57 Periodically take a look at what is and is not working Done after every sprint Participants • Scrum Master • Team • Product owner (Optional) www.izenbridge.com 58 Observe Start doing Stop doing Continue doing Facilitate This is just one of many ways to do a sprint retrospective www.izenbridge.com 59 Poll 17 www.izenbridge.com 60 Essence of Agile Empirical Process Scrum Scrum Roles Scrum Ceremonies Scrum Artifacts www.izenbridge.com 61 Sprint Backlog Increment Product Backlog www.izenbridge.com 62 Product Backlog www.izenbridge.com 63 The requirements A list of all desired work (Product Backlog Item) on the project Ideally expressed such that each item has value to the users or customers of the product Prioritized by the product owner Reprioritized at the start of each sprint www.izenbridge.com 64 Sprint Review Team Input PO Research Product Backlog Sprint Planning Sprint Backlog www.izenbridge.com 65 Good product backlogs should be DEEP (Coined by Roman Pichler and Mike) Detailed appropriately Emergent Estimated Prioritized www.izenbridge.com 66 PBI Type Example Feature As a job seeker I want to search job using keywords so that I can find the suitable job Change As a job seeker I want default ordering od job search results to be by freshness rather than location so that its easier to see latest jobs first Defects Fix defect #245 so that special character in search wont crash the system Technical Improvement Move to the latest version of Internet Explorer Knowledge Acquisition Create prototype using two databases (RDMS and NO SQL) and run performance test to determine which would be better approach for our system. www.izenbridge.com 67 Backlog Item Estimate Allow a guest to make a reservation 3 As a guest, I want to cancel a reservation. 5 As a guest, I want to change the dates of a reservation. 3 As a hotel employee, I can run RevPAR reports (revenue-per-available-room) 8 Improve exception handling 8 ... 30 ... 50 www.izenbridge.com 68 Sprint Backlog www.izenbridge.com 69 The Sprint Backlog defines the work the Team will perform to turn Selected Product Backlog items into a “Done” Increment. The list emerges during the Sprint. Each ongoing task identifies those responsible for doing the work Each Tasks has information about estimated amount of work remaining on the task on any given day during the Sprint. www.izenbridge.com 70 A short statement of what the work will be focused on during the sprint Life Sciences Database Application Make the application run on SQL Server in addition to Oracle. Support features necessary for population genetics studies. Financial services Support more technical indicators than company ABC with real-time, streaming data. www.izenbridge.com 71 Individuals sign up for work of their own choosing • Work is never assigned Estimated work remaining is updated daily Any team member can add, delete or change the sprint backlog Work for the sprint emerges If work is unclear, define a sprint backlog item with a larger amount of time and break it down later Update work remaining as more becomes known www.izenbridge.com 72 Sprint Planning Sprint Backlog Maintain During the Day Daily Scrum www.izenbridge.com 73 Increment www.izenbridge.com 74 The Increment is the sum of all the Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” It must be in useable condition (Potentially shippable product) www.izenbridge.com 75 Everyone must understand what done means This varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency This guides Development Team in knowing how many Product Backlog items it can select during a Sprint Planning Meeting. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to Definition of “Done.” Definition of Done may change during the project www.izenbridge.com 76 Demo Increment Develop Increment www.izenbridge.com 77 Poll 18,19 & 20 www.izenbridge.com 78 This Presentation includes extract from Mike Cohn’s Presentation www.mountaingoatsoftware.com Includes Reference from Scrum Guide (www.scrum.org) Book : Agile Project Management with Scrum : Ken Schwaber www.izenbridge.com 79 www.izenbridge.com 80 On-demand Webinar/Google Hangouts Full Length Simulation exams Comprehensive E-learning Contents Post training support via email, social channels and phone call www.izenbridge.com 81 LinkedIn Community (PMI-ACP : Agile Certification Made Easy ) •http://www.linkedin.com/groups?gid=4673212 Facebook Page •http://www.facebook.com/izenbridge YouTube channel •http://www.youtube.com/izenbridge www.iZenBridge.com 82 Saket Bansal [email protected] M: 9910802561 Web: www.iZenBridge.com LinkedIn: www.linkedin.com/in/saketbansal iZenBridge.com 83