Jul 21, 2013

A common source of frustration occurs when people, especially Product Owners (PO), realize that what they can expect from a single sprint is nothing like what they need to release. They want it all. Anything less is useless.

What the business wants in order to ship the product is called Minimal Viable Product (MVP). The sum total of features that the PO has determined is worth presenting to our customers.

At the end of each sprint the team should have a Potentially Shippable Product Increment (PSPI).

The relationship between PSPI and MVP is that MVP is the sum of several sprints worth of work.

MVP = ∑ PSPI

The “potentially shippable” part is really important because that allows the PO to change direction at any sprint boundaries, or to release earlier if they choose. That phrase also drives the organization to break down the waste of hand-offs between silos, driving testing into the sprint. Sutherland reported the effort to test, even one sprint later, was 24x the effort to test during the sprint. He also pointed out that breaking down this barrier is probably the single best thing you can do to improve your organization.

Q: My business users don’t see any value in intermediate deliverables and in their eyes MVP is equal to a fully delivered product. Why bother with PSPI?

A: This is a common situation before PO understands (and trusts) the tech teams. Their mind is still in the contract game and they want to push responsibility not only for development but also prioritization and conflict resolution into the tech teams.

Even for deeply technical stories with no UI we have found ways to demo the work. Always try to pick a slice that goes as near end-to-end as you can. To the extent the scrum teams can deliver PSPI every sprint that have got working code much earlier and the integration effort is amortized over a longer time (big bang integration often leads to lots of OT and pain, as you probably know). Scrum teams should absolutely drive for PSPI even when the PO doesn’t seem to care, because the effect of that construct is good for the product and exposes weaknesses in the processes & tools in place.

Every situation is different, but demonstrating working code that is incrementally better every few weeks is a compelling draw for many people, so even if your PO is intransigent now we should hold the line and be agile because we see the benefits.

See Also: “Why Longer Sprints Probably Won’t Help“.

Jun 21, 2013

Virginia Satir was a psychologist. She studied (among other things) how groups interact under the stress of change. The picture above is a typical Satir Change Diagram.

When you give it a quick look, time is shown along the X-axis. You see the group/team/organization is operating at some level before some “foreign element” or “change agent” appears and changes the system, throwing the team into a state of chaos. The team flounders in chaos, but if they persist they can climb out the other side, presumably to some higher state.

What does this imply for adopting scrum?

There will be pain. It will get worse before it gets better.
Corollary – if you aren’t feeling the pain, you probably did something wrong (see Larman’s 2nd Law)
The state on the other side better be worth all this pain!
While in the “chaos” state, the desire to retreat is large. The longer you flounder in chaos, the stronger the desire to backpedal.
… therefore, cross the chaos gap as quickly as possible.
Adopting incremental bits & pieces guarantees maximizing the pain and minimizing the chances of getting across the painful chaos.
get help to pull your team(s) across

Viewed another way, this is a restatement of the Tuckman model (forming/storming/norming). Both are cyclical in the sense that this is a reoccurring pattern that teams will progress through as they grow in maturity.

Interestingly, Virginia Satir was noted for her work in family psychology.