Successfully reported this slideshow.
Your SlideShare is downloading. ×

Scrum and Agile SDLC 101

Upcoming SlideShare
Agile Software Development
Agile Software Development
Loading in …3

Check these out next

1 of 45 Ad

More Related Content

Slideshows for you (20)

Viewers also liked (20)


Similar to Scrum and Agile SDLC 101 (20)

More from Aniruddha Ray (Ani) (19)


Recently uploaded (20)

Scrum and Agile SDLC 101

  1. 1. Agile SW Development with Scrum Aniruddha Ray
  2. 2. Presumptions Audience is (well) aware of traditional SDLC methods 1)Waterfall Model 2)V Model 3)Spiral Model 4)Iterative Development (RUP) And concepts like: 1)Requirements Traceability 2)Use Cases 3)Unit testing
  3. 3. Introduction Learning Driven Continuous Team Communication Deliver in Short, Business-Focused Phases, Typically 2 – 3 Months Develop in End-to-End Functional Slices Continuously Integrate Code Throughout (Daily Builds) Fully-Automated, Continuous Testing at Both Functional and Unit Level Low Cost of Change Plan Driven Infrequent Team Communication Deliver Once in “Big Bang” Fashion, Typically 9 – 12 Months Develop in Layers: Presentation, Persistence, Business, etc. Integration of Different Layers Occurs at End of Build Phase Testing as Separate Phase at End of Project, Emphasizing Functional Level High Cost of Change Waterfall Agile Attempts to Nail Down Requirements Expects, accommodates Changes to Requirements
  4. 4. What is Agile ? Agile proponents believe Current software development processes are too heavyweight or cumbersome (Too many things are done that are not directly related to software product being produced) Current software development is too rigid Difficulty with incomplete or changing requirements Short development cycles (Internet applications) More active customer involvement needed Agile methods are considered Lightweight People-based rather than Plan-based Several agile methods No single agile method or definition XP most popular in Development Scrum most popular in Project and Delivery Mgmt Agile Manifesto closest to a definition Set of principles Developed by Agile Alliance
  5. 5. The Agile Manifesto A Statement of Values 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 While there is value in the items on the right, we value the items on the left more. Key signatories: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
  6. 6. Agile Principles We follow these 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
  7. 7. Agile Methods Major Methods Scrum – Ken Schwaber and Jeff Sutherland Extreme Programming – Ron Jeffries and Kent Beck Adaptive Software Development (ASD) Dynamic System Development Method (DSDM) Lean Software Development – Mary Popendieck Other Methods Kanban for SW Development Feature Driven Development (FDD) Crystal Framework – Alistair Cockburn IUP (and RUP done with Agile Principles) – IBM (Rational) Agile Modeling (Agile Data) – Scott Ambler
  8. 8. Agile In Practice Focus on business value Work together closely as one team Work in short iterations Inspect and Adapt Remove waste ruthlessly (wasted effort, wasted time) Deliver working software early and often
  9. 9. 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 (every two weeks to one month). – INSPECT and ADAPT The business sets the priorities. Our teams self-manage to determine the best way to deliver the highest priority features. At every (pre-decided) frequency (two weeks to a month) anyone can see real working software and (decide to release it as is or) continue to enhance for another iteration. The iterations (Sprints) are Time-Boxed.
  10. 10. A Short History of Scrum 1995: - Design of a new method: Scrum by Jeff Sutherland & Ken Schwaber - Enhancement of Scrum by Mike Beedle & combination of Scrum with XP 1996: - Introduction of Scrum at OOPSLA conference 2001: - Publication “Agile Software Development with Scrum” by Ken Schwaber & Mike Beedle 2005: - Scrum and XP were the most popular Agile frameworks implemented (a lot of times Hand in hand) 2009: - Scrum is the single most popular Agile implementation. With popularity there is criticism or frustration of failure in some cases (Scrum- But)
  11. 11. The Power of Scrum More business value delivered sooner Better return-on-investment for projects Greater visibility – to team and customers (also – Management) Improved productivity – People, Process Less waste – Lean mindset Higher quality – Inspect and Adapt Frequently Stronger teams – focussed, decisive, self managing Better morale across the whole team - camaraderie Engineering processes improved significantly The critical features built at the quickest time at the minimal cost
  12. 12. The Dangers of Scrum It’s hard! It requires significant change It makes all dysfunction visible - Scrum doesn’t fix anything: the team has to do it - You may see things you don’t want to see It demands honesty and transparency Bad products will be delivered sooner, and doomed projects will fail faster Partial adoption may be worse than none at all Be forewarned: many Scrum adoptions fail
  13. 13. Scrum in a Page
  14. 14. The Operating Model “Self-managing or self-organizing” teams – no decision from anyone else. Product progresses in a series of month-long “sprints” – TimeBoxed Requirements are captured as features/stories in a “product backlog” – One version of truth Features are prioritized (by Business value or any other parameter) by single Owner At the end of every sprint team should demo a “potentially shippable product”. No specific engineering practices prescribed – team selects the necessary tools and practices (can select from other Agile FW) One of the many “agile” frameworks – TEAM takes best practices from others if they want BUT for the RIGHT reasons
  15. 15. Characteristics “MUST HAVE” Teams have a dedicated PO and SM SM is co-located with team Team have a Scrum/War room. Time Boxing of Sprints. Scope of Sprint Backlog can be changed ONLY by Team (not SM or PO or Management) Sprint Demo at the end of every sprint No one changed PBL except PO Team decides the scope of Sprints. “GOOD TO HAVE” Teams of sizes 5-7 Co-located teams and “war room” Tie up with Engineering specific from XP (Test Driven Development, Refactoring) Minimum Documentation (as per need) SM not the People Manager or Traditional Manager No management influence on team. Coaching from SM. PO co-located with Team
  16. 16. Scrum Framework Roles : Product Owner, ScrumMaster, Team Ceremonies : Sprint Planning, Sprint Review, Sprint Retrospective, & Daily Scrum Meeting Artifacts : Product Backlog, Sprint Backlog, Burndown Chart, Velocity Chart
  17. 17. Product Owner Responsible for maximizing the project’s ROI Creates high-level vision (MRD or PRD???) Creates a prioritized list of features (the Product Backlog) – decides on parameter of prioritization Final decision-maker on the Product Backlog – one version of truth!! Evolves the Product Backlog from Sprint to Sprint Helps the team be effective, by removing waste (like impediments and distractions) and supporting the team’s Scrum practices and efforts to improve. Can interact with customers, management or others to refine product vision. Single point of reference for team on ANY product related issue.
  18. 18. Scrum Master Serves the Team Helps the Team remove obstacles and problems (“blocks”) Facilitates interactions within the Team, and between the Team and Product Owner Protects the Team Protects the team from outside disruption or threats Coaches the Team Helps the Team and Product Owner improve the effectiveness of their practices Helps the Team and Product Owner face and resolve difficult or uncomfortable issues Guides the skillful use of Scrum Teaches Scrum to the Team, Product Owner, and company Ensures that all standard Scrum practices are followed Avoid having the team’s manager be ScrumMaster Try having full time ScrumMaster for best results
  19. 19. Scrum Team Typically 7 (+ or – 2) people Co-located 100% dedicated to sprint (minor exceptions – Sys-Admin etc) Cross-functional QA, Programmers, UI Designers, etc. Includes all the skills necessary to produce an increment of potentially shippable product Team takes on tasks based on skills, not just official “role” Teams are self-organizing and self managing What to do if a team self-organizes someone off the team?? Ideally, no titles but rarely a possibility Team decides how much to commit to in a sprint Team works together to manage and complete the work to achieve the goal Membership can change only between sprints
  20. 20. Ceremonies Project Kickoff Meeting Sprint Planning Meeting Product Backlog Refinement Meeting Sprint Review Meeting Daily Scrum (Scrum of Scrums) – for bigger teams Sprint Retrospective Meeting
  21. 21. Project Kickoff Meeting A special form of Sprint Planning Meeting – Optional. Meeting before the begin of the Project – 1 day of effort. Team (or a smaller core) may go through the product vision and entire backlog at higher level Helps in understanding the big picture – reviewing priorities and identifying dependencies/assumptions. May result in first cut of High Level estimates or minor refinements/changes in PBL (only PO will do it)
  22. 22. Sprint Planning Meeting 1st Part: Creating/Refining Product Backlog (Edits, Reprioritization) Determining the Sprint Goal. Participants: Product Owner, Scrum Master, Scrum Team 2nd Part: Participants: Scrum Master, Scrum Team Creating Sprint Backlog Discussing, Noting details on each scoped feature Dependencies/Assumptions (P.O available on call for discussion) Note: ScrumMaster facilitates the meeting and protects the team from pressure
  23. 23. Spring Planning Meeting Suggested Steps 1) Team calculates how much time it will have available during the Sprint 2) Team takes first item from Product Backlog and breaks it into tasks 3) Team estimates how long the tasks will take (take care of all planned activities, definition of DONE and buffer) 4) If there’s available time remaining, move to the next item on Product Backlog and repeat 1-3 5) Finalize the features which have clarity and estimates and decide on how many to be scoped for sprint.
  24. 24. Spring Planning Meeting – Input Output Sprint Planning Meeting Product Backlog Team Capabilities Business Conditions Technology Current Product Sprint Backlog Sprint Goal
  25. 25. Sprints Scrum projects make progress in a series of “sprints” Analogous to XP iterations Target duration is pre decided. Scrum suggests 2 weeks to one month a constant duration leads to a better rhythm Once decided Sprint duration MUST not change Product is designed, coded, and tested during EACH sprint EACH sprint should end in a potentially shippable code. Scope DOESNOT change within a sprint. Team may decide to push unfinished items to next sprint. PO can decide to CANCEL a sprint midway and restart (in special cases)
  26. 26. What is A Sprint A 2 - 4 week long iteration, during which team increments the product functionality NO outside influence can interfere with the Scrum team during the Sprint Each Sprint begins with the Kickoff meeting Daily Scrum Meeting conducted throughout the sprint. Each Sprint ends with a sprint demo and retrospective. Sprint duration or scope is immutable (unless critical business change happens) Sometimes teams may have intermediate Sprint review meetings (to discuss/pre-plan items of next sprint if it helps)
  27. 27. Sequential vs. Overlapping Dev. Requirements Design Code Test
  28. 28. Scrum Meeting Goal of the Scrum Meeting Keep team coordinated and up-to-date with each other Surface “blocks” or problems daily Key Parameters Daily (fixed time) 15-minutes or less (no more) Stand-up Not for problem solving Only SM and Team Three questions for everyone: 1. What did you do yesterday 2. What will you do today? 3. What obstacles are in your way? “Chickens” and “Pigs” – Only “Pigs” can talk Help avoid other unnecessary meetings No discussion until after meeting ends After meeting SM will help remove the blocks and find solutions to problems.
  29. 29. Scrum Meeting – FAQs Is NOT a problem solving session Is NOT a way to collect information about WHO is behind the schedule Is a meeting in which team members make commitments to each other and to the Scrum Master Is a good way for a Scrum Master to know (Track?) the progress of the Team Is THE meeting for a Scrum Master to know what is blocking the Team. • Why daily? – “How does a project get to be a year late?” • “One day at a time.” – Fred Brooks, The Mythical Man-Month. • What if all team members are not present – WHY are they not present (root cause?) – Burn Out, Low Team Morale or Over Pressure? • Can Scrum meetings be replaced by emailed status reports? – No • Entire team sees the whole picture every day • Create peer pressure to do what you say you’ll do
  30. 30. Sprint Review Meeting Goal Get hands on with what’s been built Inspect the quality Come up with ideas for improvements See whether the commitment was completed Team presents what it accomplished during the sprint Typically takes the form of a Demo of new features No PowerPoint Demo Informal 2-hour prep time rule 2 hour demo time Participants – EVERYONE Informal and Fun
  31. 31. Sprint Retrospective Meeting Goal Find ways to improve the team’s way of working in the next Sprint Participants: SM and Team only Product Owner and managers should join for part (but not all) of the Retrospective Team needs time to talk by itself Feedback within team and self correcting decisions – SM to check that there is no outside imposition. Three questions (optional 4th) Start - What are worth trying Stop – What are waste and should be stopped Continue – What went well Escalation/Risk List to Upper Management. Don’t skip ever (Critical for the first 5-6 sprints!!!)
  32. 32. Product Backlog Refinement – Optional Optional Meeting – Worked well in some cases Goal: During the Sprint, plan to spend ~5% of your available time doing Product Backlog Refinement (also known as Product Backlog Grooming) Team and Product Owner sit down and look ahead at Product Backlog Items for upcoming Sprints Team asks questions and clarifies requirements for upcoming items Team suggests items to add to the Product Backlog Team starts to think about how they’re going to implement the items (at a high-level)
  33. 33. Product Backlog A list of all desired work on the project Usually a combination of story-based work (“let user search and replace”) task-based work (“improve exception handling”) List is prioritized by the Product Owner Typically a Product Manager, Marketing, Internal Customer, etc. • Requirements for a system, expressed as a prioritized list of Backlog Items • Is managed and owned by a Product Owner • PO Can use MOSCOW tool to prioritize. • Can be a Spreadsheet (typically) or any other report • Usually is created during the first Sprint Planning Meeting or Project Kickoff Meeting • Should be changed/updated and re-prioritized before each Sprint Planning Meeting. • Product Backlog will have all features (including non- functional requirements)
  34. 34. From Sprint Goal to Sprint Backlog Scrum team takes the Sprint Goal and decides what tasks are necessary Team self-organizes around how they’ll meet the Sprint Goal Manager doesn’t assign tasks to individuals Managers don’t make decisions for the team Sprint Backlog is created Estimates are done by the team (best practice: Wideband Modified Delphi method)
  35. 35. Sprint Backlog A subset of Product Backlog Items, which define the work for a Sprint Is created ONLY by Team members Each Item has it’s own status Should be updated every day No more than 300 tasks in the list If a task requires more than 16 hours, it should be broken down Team can add or subtract items from the list. Product Owner is not allowed to do it
  36. 36. Sprint Backlog during the Sprint Changes Team adds new tasks whenever they need to in order to meet the Sprint Goal Team can remove unnecessary tasks But: Sprint Backlog can only be updated by the team Estimates are updated whenever there’s new information
  37. 37. Scalability of Scrum A typical Scrum team is 6-10 people Jeff Sutherland - up to over 800 people "Scrum of Scrums" or what called "Meta-Scrum“ Frequency of meetings is based on the degree of coupling between packets
  38. 38. Confused about Scrum? How much Documentation: Scrum does not specify. Team decides (what’s best for the project) What are user stories: short, plain-language description of the feature, in terms of customer value What are 3 C’s: Card, Confirmation and Conversation. It’s a common model for requirements/story analysis. How do we estimate in scrum: Scrum doesn’t specify. Only suggestion is to have 2 level of estimates – high level at PBL (may be Points) and low level at Sprint BL (may be Hours). Also, ONLY the team decided on estimates. Do we really need to release every sprint – 2 common approach - Release every sprint and multi sprint release. Do what gives maximum business benefit How can team scope the sprint – Team is COMMITING to delivery. So they should scope (Note: They may over or under-commit in initial sprints but with the right spirit and coaching they should stabilize in 5/8 sprints. A disturbing trend would continuous under or over-commitment) Why should we track Velocity: The team needs to find a Self-sustaining pace and confidence in commitment. Velocity provides the trend to them. (Note: Velocity IS NOT for management to track)
  39. 39. Scrum EXPOSES Organization Impediments Process People arrive late to daily scrum and do not support basic discipline Scrum meetings take too long – team is bred and considers the tie unproductive Scrum master dictates design decisions or micromanages Teams are too large for effective daily scrum and sprint planning Teams do not report task-remaining time for burn-down analysis People Individuals are interrupted and tasked to work outside the sprint Teams are isolated in cubicles and not in open scrum area Teams members are not accountable for personal sprint commitments Individuals are multiplexed across too many projects and teams. Product Cross-functional resources for definition, design, implementation, and test are not present on the team Sprints do not fully implement and test potentially deployable increments of customer-valued features. Product owner is not easily available or not integral to team System integration is not forced at each sprint Product owner won’t split up massive product backlog items to fit within a sprint Team have ineffective resources for automating builds and integrations Features are loaded into sprints after sprint begins
  40. 40. Thank You !!!
  41. 41. Burn Down Charts Sprint Burndown • Depicts the total Sprint Backlog hours remaining per day • Shows the estimated amount of time to release • Actually is not a straight line • Can bump UP and DOWN • Ideally should burn down to zero to the end of the Sprint Release Burndown • Will the release be done on right time? • X-axis: sprints • Y-axis: amount of hours remaining • The estimated work remaining can also burn up Product Burndown Is a “big picture” view of project’s progress (all the releases)
  42. 42. Agile SW Dev – XP and RUP Key characteristics of XP include A team of five to ten programmers, co-located with customer representation on site. Development with frequent builds and iterations, each of which is releasable and delivers incremental functionality. Requirements are specified as stories, each a chunk of new functionality the user requires. Programmer work in pairs, follow strict coding standards, and do their own unit testing. Requirements, architecture, and design emerge over the course of the project Key characteristics of RUP include (Modified to IUP) RUP provides a full lifecycle approach covering a series of product lifecycle phases called inception, elaboration, construction, and transition RUP provides a SW development method and a set of software engineering practices that cover the majority of SW development disciplines. RUP is iterative. Within each phase, the product undergoes multiple iterations; the nature of each is determined in part by the life cycle phase. RUP is incremental: Each iteration builds on the functionality of the prior iteration; the software application evolves in this fashion with the benefit of regular and continuous feedback.
  43. 43. Agile SW Dev – DSDM and Lean Key characteristics of DSDM include Active user involvement The team is empowered to make decisions The focus is on frequent delivery of products Fitness for business purpose is the essential criterion for acceptance of deliverables Iterative and incremental development is necessary to converge on an accurate business solution. All changes during development are reversible Requirements are base-lined at a high level. Testing is integrated throughout the life cycle. Collaboration and cooperation between all stakeholders is essential Key characteristics of Lean Software include Reduced work in process inventory – Reduced investment in elaborated requirements, documented designs Reduced Cycle time – Build all software in much smaller lots Cross-training and cell-based manufacturing – Increase cross-training with pair programming and shared code assets. Have developers write tests as part of their code Continuous Process Improvement – Continuous reflection and adaption
  44. 44. Scalability of Scrum
  45. 45. Does This Ring A Bell?