...

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

...

• • 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 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.

...

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

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

...

• People find it preferable to have a separate meeting.

Sprint Review Meeting

Feedback loop about the product

...

• • 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