Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added Intro to Scrum paragraph.

...

    • 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

...

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

...

    • 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