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
- Value
Intro to Scrum
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
- Requirements Analysis
- Design
- Code
- Integration
- Test
- 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
- Waterfall Phases
- Dr. Winston Royce - In 1970, wrote a paper that evolved into the Waterfall Model of Software Development.
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
- Product Owner
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
- Tasks
- What
- Product Backlog Item
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.
- will declare
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
- Scrum teams ship
- 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.
- Keep the product in a constantly known state
References
- Scrum Training Series: Free Scrum Master Training from Seattle
- CollabNet Agile E-Learning
- CollabNet Agile Training (Scrum) - 15 training videos on YouTube