Scrum and Agile SDLC 101

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    4 Favorites

    Scrum and Agile SDLC 101 - Presentation Transcript

    1. Agile SW Development with SCRUM http://tiny.cc/RcgcB Aniruddha Ray
    2. Presumptions
      • Audience is (well) aware of traditional SDLC methods
      • Waterfall Model
      • V Model
      • Spiral Model
      • Iterative Development (RUP)
      • And concepts like:
      • Requirements Traceability
      • Use Cases
      • Unit testing
    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. 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
          • CMM focuses on process
      • Agile methods are considered
        • Lightweight
        • People-based rather than Plan-based
      • Several agile methods
        • No single agile method
        • XP most popular in Development
        • Scrum most popular in Project and Delivery Mgmt
      • No single definition -
      • Agile Manifesto closest to a definition
        • Set of principles
        • Developed by Agile Alliance
    5. 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
      • http://www.agilemanifesto.org
    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. Agile 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
        • Kanban for SW (Scrumban???)
        • Feature Driven Development (FDD)
        • Crystal Framework – Alistair Cockburn
        • IUP (and RUP done with Agile Principles) – IBM (Rational)
        • Agile Modeling (Agile Data) – Scott Ambler
    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. 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. 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 Extreme Programming
      • 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.
        • However with popularity there is criticism or frustration of failure in some cases (Scrum-But)
        • Successful appliance of Scrum in over 100 companies (BT, Sun, GE, Yahoo, Google, Siemens, Valtech etc)
    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. 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.  
    14. Basic Characteristics
      • “ 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. “MUST HAVE” Characteristics
      • Teams have a dedicated PO and SM
      • SM is co-located with team
      • Team have a Scrum/War room.
      • Timeboxing 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.
    16. “GOOD to have” Characteristics
      • Teams of sizes 5-7
      • Co-located teams and “war room”
      • Tie up with engg 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
    17. 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
    18. 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.
    19. 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 skilful 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
    20. 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
    21. 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
    22. 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)
    23. Sprint Planning Meeting
      • 1 st Part:
        • Creating/Refining Product Backlog (Edits, Reprioritization)
        • Determining the Sprint Goal.
        • Participants: Product Owner, Scrum Master, Scrum Team
      • 2 nd 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
      • 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.
      Spring Planning Meeting
    24. Spring Planning Meeting – Input Output Sprint Planning Meeting Sprint Backlog Product Owner Scrum Team Management (Opt) Customers (Opt) Sprint Goal Product Backlog Team Capabilities Business Conditions Technology Current Product
    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. 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. Sequential vs. Overlapping Dev. Requirements Design Code Test
    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:
        • What did you do yesterday
        • What will you do today?
        • 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. Scrum Meeting – What Is It (IS NOT)
      • 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.
    30. Scrum Meeting FUDs
      • 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
    31. 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 )
      • Informal
        • 2-hour prep time rule
        • 2 hour demo time
      • Participants – EVERYONE
      • Informal and Fun
    32. 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 4 th )
        • Start - What are worth trying
        • Stop – What are waste and should be stopped
        • Continue – What went well
        • Escalation/Risk List to Upper Mgmt
      • Don’t skip ever (Critical for the first 5-6 sprints!!!)
    33. 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)
    34. 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.
    35. Product Backlog
      • 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)
    36. 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)
    37. 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
    38. 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
    39. 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
    40. Scalability of Scrum
    41. Confused about Scrum?
      • How much Documentation : Scrum doesnot specify. Team decides (whats 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 overcommitment)
      • 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)
    42. Scrum EXPOSES Organization Impediments
      • Scrum 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 practices
        • 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 engineering practices
        • 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
      • Organizational issues
        • Software process organization enforce ineffective processes
        • Management assumes fixed-price, fixed-time, fixed-functionality delivery posture
        • Software test and/or system QA is separate organization and is not integrated with team
        • Organization rewards individual rather than team behavior.
        • Existing rules or software capitalization demand adherence to document-drive waterfall approaches
        • Team cannot make small, organizational space ad expense decisions needed to do their jobs.
      • Thank You !!!
    43. Sprint Burndown Chart
      • 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
    44. Release Burndown and Product Burndown
      • 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)
    45. Scalability of Scrum
    46. Does This Ring A Bell?
    47. Agile SW Development – XP and RUP
      • The Essence of XP – Extreme Programming
      • 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
      • RUP – The Rational Unified Process - process framework from IBM (Rational)
      • 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.
    48. Agile SW Development – DSDM and Lean
      • DSDM – Dynamic Systems Development Method
      • 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
      • Lean Software – a set of principles derived from a combination of Lean-manufacturing thinking.
      • 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

    + Aniruddha RayAniruddha Ray, 4 months ago

    custom

    642 views, 4 favs, 0 embeds more stats

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 642
      • 642 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 4
    • Downloads 5
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories