These are my notes of the Agile Scrum process that was used to successfully migrate a client from Waterfall to Scrum.

Manifesto for Agile Software Development

• • Value
    • Individuals and interactions
    • Working software
    • Customer collaboration
    • Responding to change
  • Over
    • processes and tools
    • comprehensive documentation
    • contract negotiation
    • following a plan

Intro to Scrum

To understand Scrum, it helps to understand the original Waterfall Model.  The following section shows just some of the challenges with using Waterfall and then delves into the Scrum Model characteristics.

Waterfall Model

The old framework for developing software.  This is characterized by front loading all of the planning to the n-th degree.  Waterfall works for physical products, but is risky for software because of the constantly changing requirements.  As a result, the nature of software prevents knowing the entire plan up front.

• • Dr. Winston Royce - In 1970, wrote a paper that evolved into the Waterfall Model of Software Development.
    • Waterfall Phases
      1. Requirements Analysis
      2. Design
      3. Code
      4. Integration
      5. Test
      6. Deploy
    • Risky and invites failure
      • Rarely have perfect knowledge of what is needed at the beginning
      • Know less about our project when we start out than we will know in the future.
      • The first day is the dumbest day of the rest of our project.
      • Waterfall projects eventually descend into anarchy
        • Low quality
        • Too much overtime

Scrum Model

The new framework that leverages Agile for developing software.  Scrum takes advantage of Agile principles by creating a set of ceremonies (i.e. meetings) whereby time boxed Sprints continuously iterate through Planning, Prioritization, Feedback, Process Retrospection and Process Adjustment.

Roles in the Scrum Process

• • • Product Owner
      • Maximizes ROI
      • Constantly reprioritizes Product Backlog as more is learned.
      • Product Owner and Team should talk directly
    • Scrum Development Team
      • 4-9 people
      • Team room
        • Information Sharing Tool
      • Attempt to build a potentially shippable and properly tested product increment at every Sprint iteration.

        A team that has not yet learned how to do this should reduce the feature scope it commits to, or they will be hampered by technical debt.

    • ScrumMaster
      • no management authority
      • Doesn't have a project manager role
      • Facilitator
      • Protects the team from distractions
      • Helps people learn how to use scrum

Artifacts

Scrum Element

• • • Product Backlog Item
      • Prioritized list of customer centric features
      • Forced rank
        • Top most item has priority
      • Does NOT contain tasks
    • Sprint Backlog

      What we have agreed to do for the Sprint

      • What
        • Committed Backlog Items
      • How
        • Tasks
          • Not Started
          • In Progress
          • Completed

Meetings

Backlog Refinement Meeting (a.k.a Backlog Grooming)

• • • • 2 hours
      • 2nd Wednesday
      • Set item priorities
      • Team and Product owner
      • Determine which items get put into next couple of Sprints
      • break big product backlog items into smaller product backlog items... maybe user stories
      • Product owner gets feedback on
        • input on prioritizaion
        • Considered dependencies
      • Could be done in Sprint Planning Meeting
        • People find it preferable to have a separate meeting.

Sprint Planning Meeting

• • • • 4 hours
      • 1st Monday
      • Team and Product Owner negotiate which items will be committed to the Sprint
      • Pulls top priority items from the Product Backlog
      • Places items into the Sprint Backlog
      • Breaks into smaller tasks typically
      • Decides if it is the right amount of work they are going to do in the Sprint
      • Determines if they are clear on what they would do.

Daily Scrum

• • • • Report to each other
      • What I did
        • Yesterday
        • Today
        • Blockers

Sprint Review Meeting

Feedback loop about the product

• • • • 2 hours
      • 2nd Friday
      • Team demonstrates a potentially shippable product increment to
        • product owner
        • anyone else who is interested

          "Stakeholders"

      • Product Owner
        • will declare

          • which items are done

          • which items did not meet acceptance criteria
          • measure velocity
          • Get feedback from stakeholders

            • about how the team is doing with velocity.

            • Add items to product backlog
        • A lot of times, the feedback is
          • Guys, you did what you said you'd do but after seeing it, we realize we need something else.
          • Couldn't have known that until they saw the wrong product.
          • People sometimes need to see a piece of functioning product to react against before they can specify what they really want.

Sprint Retrospective Meeting

Feedback loop about the process

• • • • 2 hours
      • 2nd Friday
      • Team Inspects and Adapt own process
      • What went well
      • What could be improved
      • What we learned
      • What still puzzles us
      • Team gives feedback to each other
      • Team takes ownership of their own process

Demands

• • Keep the product in a constantly known state
    • increasing rigor in the definition of "done"
    • skilled use of TDD
    • refactoring
    • continuous integration
  • Build/Test more than once per day
  • New Scope discovery tends to outpace velocity
    • Scrum teams ship
      • the highest-value products they can within time constraints
      • accepting that some requests must be delayed until future releases
  • Role of Management Changes
    • from telling people what to do
    • to
      • leading
      • helping
  • To become more adaptable
    • development teams must learn engineering practices that reduce the cost of change, a kind of technical debt
    • Re-prioritization should affect the Product Backlog not a Sprint in progress (except in real emergencies).
  • Hold off decisions until the end of the meeting
    • Give everyone a chance to offer their view.

References

• Scrum Training Series: Free Scrum Master Training from Seattle
• CollabNet Agile E-Learning
• CollabNet Agile Training (Scrum) - 15 training videos on YouTube