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

Scrum roles

  • Product Owner: responsible for ROI, Product Backlog
  • Team: self managing, self organization, do anything to meet Sprint goals
  • ScrumMaster: process manager (NOT project manager)

Scrum flow and artifacts:

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:

  1. Product Backlog at the start of this sprint
  2. Product Backlog at the start of next sprint
  3. Changes report: differences between the two
  4. 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.

C9 Scaling

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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s