Continuous Deployment over Sprint Reviews

Waterfall required a big leap of faith (and often, a suicide leap) for business stakeholders: Open your wallet, wait a couple years and pray that you find the results useful. In Scrum, we make things more tangible: Every couple weeks,  stakeholders and developers gather and look at working software, discussing the good, bad and the ugly. The best part? Everything that is "Done" is already an asset, even long before the project's delivery date.

The value of Reviews

Truth be told, stakeholders often don't know what they really need unless they have something they can look at and fiddle with. Let's humour for one second the thought that a comprehensive specification and UML diagrams exist. 

Once the first couple lines of code are written, maybe just a GUI without any functionality - maybe just a few algorithms without a database connection ... the relevant users can take a look and decide whether that's workable, where the weak spots are and what could be done to make the construct more useful.

None of this is possible by looking at complex specification documents, because everything a document review does is add more levels of detail, not innovating new, efficient ways of doing things better.

What happens when you don't have Reviews

Or, alternatively, "What happens when stakeholders don't attend reviews, don't give feedback during reviews - or developers show funny powerpoint slides instead of working software".

In the Review, developers and business stakeholders re-sync mutual expectations and understanding. The next sprint can be planned more efficiently with the knowledge where the most value lies - from here.

Not having frequent, good reviews means that developers continue working with assumptions rather than with users. It also means that the most powerful Inspect+Adapt mechanism is taken from the team. Obvious faults in concepts will not be discovered until someone fiddles with the software or validates the system against their understanding of business.

Why having Reviews is bad

There is nothing intrinsically bad about Reviews. But there is something bad about having a set date, maybe once every 2 weeks, where Reviews are conducted.

Slow Feedback

Reviews are definitely an improvement towards simply "throwing stuff over the fence" because they enable feedback. Unfortunately, they encourage developers to move stories into "Done" without checking whether users actually like the result. Just asking you personally: Are you proud to call something "done" without knowing whether the person you're doing it for will like it? Ideally, we receive feedback even while developing the feature, ideally so fast that we can actually respond to change. Maybe there's no need to continue developing after a certain point, maybe we need to do things completely differently than we initially assumed.

Batch processing

The biggest problem of Reviews is the batch processing. If you got 5 Stories are on the sprint, 4 will be done long before the Review, and stakeholders can't see them until the timebox is over. This turns sour when these stories build upon one another and the first story already had a fundamental flaw: The entire sprint may need to be discarded.

Induced waste

This means we have an interval of a couple days where developers already start forgetting the "Why" and "How" before they have to recoup everything to produce a demo. Sometimes, they counter this by writing presentation notes upfront, which do not provide any value to the customer.

Worse than this - if different stakeholders attend in order to review different stories, their time is wasted. Marketing doesn't care about this fancy new form for sales - and sales doesn't care about the new campaign algorithm. But both patiently sit through the non-value adding time.

Lost value

The first item in the sprint backlog is the most valuable item of the sprint. So, it gets done first. That's common sense. However, many teams don't deploy to Production until the PO accepted the sprint's "Done" items in the Review. 

This means that from the time the most valuable item is done until the Sprint Review is completed, we have the most valuable deliverable rotting in the repo, producing zero value!

Summary

It is definitely good to have Reviews and a serious improvement over not having them. Reserving (half) an hour every 2 weeks to ensure you deliver high value, remain on the right track and have happy stakeholders is definitely a good idea.

But it is better to receive instant feedback on every work item completed. 

Continuous Deployment is a rigorous, highly disciplined approach to move completed features directly to where you receive this feedback - to the real users. You won't need to wait for a specific future date, you will instantly know how users respond. And from a business perspective: you don't keep the dollars on the shelf, you reap them!