Agile Software development with Scrum
Mike Beedle, Ken Schwaber, 2001
Foreword Software development shall be controlled by an empirical process (p vi).
Preface Repeatable process vs. emergent process, but statistically predictable process (p viii).
Intro Scrum is a management and and control process on top of existing engineering practices (p 2).
"Whoever writes code owns it for ever" (p 5).
Chapter 1 - Introduction.
Architecture and Design should emerge rather than being done first (p 9).
Scrum teams are self-organized and autonomous (p 9).
Release Sprint to bring the product to release readiness (p 10).
Synchronous steps, component testing and refactoring (p 15).
eXtreme Programming to implement code delivered by Scrum organization (p 17).
Team (pair ?) programming, constant testing and refactoring were more difficult to introduce with C and C++ (p 17).
ADM (Adaptive Development Methodology ?): two cycles. Build functionality. Prepare it for release (p 18).
Scrum as a collection of organizational patterns (p 20).
Chapter 2 - Get Ready for Scrum!
Empirical model of process control: expect the unexpected ; frequent inspections and process adaptation (p 25).
Most people really understand Scrum when they begin to use it (p 25).
"The art of the possible" (p 27).
Chapter 3 - Scrum Practices.
Scrum master is focused and determined to succeed, comfortable being visible and taking initiatives (p 32).
Issue might be included in the backlog (living document) (p 33).
Product Owner manages and controls the product backlog (p 34).
PO works with Team to estimate. Estimating is an iterative process. Estimates can be revised (p 34).
Team commits estimated backlog items for the next sprint (p 34).
Team can reduce functionality in the current sprint (p 36).
Team size is between 3 to 8 - ideally (p 36).
Team is cross-functional and self-organized. Some teams include QA, otherwise engineers test their code (p 37).
Team has full authority to make any decision required to meet the sprint goal. Team can abort a sprint if it is not given enough autonomous (p38).
Open-space and Big Visible Charts.
Daily scrum in scrum room (p 40).
Chickens and pigs, pigs in circle, chickens outside of the circle (p42).
- what have you done since last scrum ?
- what will you do before the next scrum ?
- what got in the way of doing work ? The daily scrum is not a design session, not a working session (p 44).
Abort the sprint if too many impediments are not removed by the Scrum master or the organization (p 44).
Indecision can be an impediments (p 45). Scrum master is responsible for making the decision or having the team make it. Making decisions allows the team to gain control.
Sprint planning meeting (2 sessions)
- PO plus users, management and team to build the sprint backlog.
- Team discuss how to build this functionality.
Sprint goal: objective that will be met thru the implementation of the sprint backlog items (p 48).
Sprint backlog is a list of tasks (4 to 16 hours). The team owns the sprint backlog (p 49).
No interference, no intruders, not peddlers (p 52).
The team must attend daily scrum and update sprint backlog, update the test suite and follow each daily build with a smoke or regression test (p 53).
Management can cancel a sprint. Team can cancel a sprint when the goal is reached.
Sprint review: the Scrum master presents the actual sprint goal and backlog vs. the expected and explain the difference. The sprint review is informal (no PP) (p 55).
Chapter 4 - Applying Scrum.
Scrum empowers the team (p 57).
Is slide-ware dead ? or limited to 30 days ? (p 58).
http://www.extreme-modeling.com (http://www.extrememodeling.org).
Importance of the daily build (p 59).
Sprint fixes time, cost and quality ; and trades functionality. Team can change delivered functionality (p 52).
Slip is detected within a sprint (30 days including week-ends) (p 65).
Observe and listen people at daily scrum (p 69).
Design, models and use cases are only useful artefacts to guide the team. "You can't ship design. You can ship working code" (p 70).
Release backlog is a subset of the product backlog allowing to estimates release dates (p 71).
There are no mechanics in Scrum for tracking worked time. Scrum is result oriented, not process oriented (p 73).
Each product backlog item has its amount of estimated work remaining (p 83).
Defined process are repeatable, predictable. Complex process are not and shall be controlled empirically (p 94).
Estimation errors accumulate in PERT charts, sinking the project plan (p 96).
Chapter 5 - Why Scrum?
Process engineers failed to abstract or define process from scrum project experience. Each project is unique (p 102).
Chapter 6 - Why does Scrum work?
Software development is like new product development, not like manufacturing (p 106).
New product view of Scrum. CMM is inspired by MMM (Manufacturing Maturity Model), as exposed in Quality is free (Crosby) (p 107).
Onsite customer whenever possible (p 109).
Risk management and predictability view of Scrum (p 108).
- risk of not pleasing the customer
- risk of not completing all the functionality
- risk of poor estimating and planning
- risk of not resolving issues promptly
- risk of not being able to complete the development cycle
- risk of taking too much work and changing expectations
Yagni - You ain't gonna need it.
Chapter 7 - Advanced Scrum Applications.
One team for each application and one team for the shared resources (p 124).
Tracer bullet application to reuse shared resources (p 129).
Reusable assets need to be stable (p 130).
Hidden tasks are put in product backlog which makes them visible (p 138).
Chapter 8 - Scrum and the Organization.
The whole organization has to be committed to remove impediments. Organizations adapting Scrum should expect to reengineer themselves (p 143).
Chapter 9 - Scrum Values.
Values: commitment, respect, focus, openness, courage. "What's they got to do with the code ?" (p 150).