Agile Project Management with Scrum by Ken Schwaber, the codeveloper of Scrum with Jeff Sutherland.
C1 Backdrop: The Science of Scrum
Defined/empirical process control: whether a process can repeatedly produce acceptable quality output
Elements of empirical process control: visibility, inspection, adaptation
Complexity in software development: requirements (ambiguous and changing), technology, people
- Product Owner: responsible for ROI, Product Backlog
- Team: self managing, self organization, do anything to meet Sprint goals
- ScrumMaster: process manager (NOT project manager)
C2 New Management Responsibilities
ScrumMaster: “M&S want quick responses to every opportunity that comes knocking. Developers need to focus on producing the product… Scrum strikes a balance between the two through the use of 30-day Sprints. The development organization will do whatever is needed every Sprint, addressing whatever is deemed to top priority for that Sprint. However, everyone else must leave the developers alone to work.”
C5 Product Owner
Sashimi practice: every slice of functionality created by the develoeprs be complete, in terms of requriements gathering and analysis, design, coding, testing, and documentation. At the end of each sprint, every functionality is potentially shippable.
C7 Project Reporting
Scrum reports at the end of each sprint:
- Product Backlog at the start of this sprint
- Product Backlog at the start of next sprint
- Changes report: differences between the two
- Product Backlog burndown report
C8 The Team
Estimate can never be accurate. The ultimate measure of project success should be high quality and on time release, not other things like the accuracy in estimate. So there’s no point in tracking progress task-by-task. Tracking progress by requirement does make sense, on the other hand.
Scrum’s essence is to inspect and adapt, using self-organization.
The first few sprints must address and setup infrastructure for functional and nonfunctional requirements. Product Backlog should have the following nonfunctional items:
- Decompose business architecture to support clean-interface multi-team development
- Decompose system architecture to support clean-interface multi-team development
- Define and implement a development environment to support multi-team collocated or distributed environments
Product Backlog will be hierarchical. Daily Scrum of Scrums can be used to synchronize and address cross-team dependency issues. An alternative based on self-organization is to send people as chicken to the other team working on the dependency, or add high-priority item to Product Backlog.