Kenneth S. Rubin - Essential Scrum. A Practical Guide to the Most Popular Agile Process (2012, Addison-Wesley Professional)..

0. Introduction

Claim: Scrum can be a way of making software engineering work more proficient.

Who deals with: rejects traditional, plan-driven, predictive development (waterfall style) approaches and Gannt charts, acknowledges that kanban framework is useful in contexts where scrum is not applicable.

Method: Narrative. Breaks Scrum framework into constituent parts: concepts (sprints, requirements and user stories, backlog, estimation and velocity, tehnical debt) and roles (product owner, scrum master, dev team, managers). Then gives introduction to agile principles and zooms in to planning and sprinting to discuss in more detail.

Why important: Rubin defines three key reasons: (1) deals well with situations where there's more unknown than known; (2) avoids big up-front architecture design; (3) teams are cross-functional.

Relevance to my research: describes the software engineering approach to work, which my research also deals with; explains how software rituals are applied in human behaviour.

Naysayer: scrum is not ideal for all situations; it's not good for chaotic contexts and in interrupt-driven workflow (eg, support tickets).

Technical debt

Avoiding long-term, low-certainty guessing

Example technical debt economic analysis

•Each month of development costs $100K.

•We cannot reasonably meet the target delivery date (at ten months) with all of the requested, must-have features.

•Dropping features is just not an option.

Post-launch development process: Scenario 1

•Team finishes up all the lag in the reasonable amount of time (before next update/release due)

•At point B, the total amount of work gets back to being equal to ongoing work

Post-launch development process: Scenario 2

Team makes sure the debt is not growing and covers the most critical issues, sealing the debt that cannot be addressed

At point B, the total amount of work equals ongoing work plus any servicing of debt that was left behind unaddressed

Post-launch development process: Scenario 3

Team discovers that technical debt is in fact growing quicker than can be addressed without further budgeting considerations

The total amount of work grows, adding up the ongoing work, servicing of debt and addressing the debt.

At point B maintenance costs exceed total cost of building entirely new website from scratch, making keeping of the old one questionable

Notes:

Found chapters on technical debt, sprints and product backlog quite informative. chapter 16 to 18 contain information which mostly reiterates previous claims and adds a bit more in terms of large-scale planning. The section about sprinting contains mainly stuff mentioned before.

Sprinting:

- come to sprint planning with already groomed backlog (336)
- formulate sprint goal
- break backlog items into smaller tasks (344)

Difference between sprint review and retrospective: review is for the work done in the sprint (with stakeholders). Retrospective is to analyse the working methods (for Scrum team).

Retrospective questions (377):

- What worked well this sprint that we want to continue doing?
- What didn’t work well this sprint that we should stop doing?
- What should we start doing or improve?

Tools for retrospective:

- Timeline with emotional seismograph to analyse team feelings about the sprint
- Things to keep doing/things to stop doing/things to try board