Product Increments. Sometimes just for show, with no pants on.
November 2020 saw the release of a new version of the Scrum Guide, an update that also coincides with Scrum’s anniversary of 25 years. This version introduced quite a few changes, but I want to briefly mention just a few of them:
- The guide now clearly mentions that you can deliver multiple Increments within a Sprint, not just one Increment at the end of the Sprint.
- It also says that the Review should never be considered a gate to release value.
- Another change is that some commitments were introduced; for the Increment, this comes in the form of the Definition of Done.
- If a Product Backlog Item does not meet the Definition of Done, it cannot be released (or even presented at the Review meeting for that matter).
- Another commitment is that of the Sprint Goal; the guide now states that the Sprint Goal is the single objective for the Sprint.
(The 2020 Scrum Guide also removed the software-specific terminology, making the Scrum framework available for a wider audience, but this article will be about software development)
These changes resonated with me and triggered a memory of a video I saw a while back: Reporter goes on air without pants and viewers notice.
So why this video? What relation is there between seeing a reporter doing a broadcast from home while wearing no pants and the things from the Scrum Guide I just mentioned?
I remembered it because that’s how your Reviews can end up looking when you don’t pay attention to the things stated in the bullet points above.
Misplaced attention
When Scrum Teams don’t choose good Sprint Goals, what often occurs is that the goal becomes to “Finish all the stories in the Sprint”. The work performed in the Sprint is obviously important. It’s work selected to achieve a result. But attention needs to be placed on the right thing, otherwise, the Sprint Goal moves from being outcome-oriented to being output-oriented. In short, the focus moves from the Sprint’s result to the work being performed in the Sprint.
Teams new to Scrum often fall into this trap of wanting to deliver all the work by the end of the Sprint. And truth be told, sometimes teams are pushed into this trap… by management. In a company where Agile values are not embraced — with things done differently but without truly changing — the team will most likely feel pressured to deliver the full scope of the Sprint. The approach remains that of the Waterfall model but applied in iterations. Sprints then transform into mini-projects with fixed scope, schedule, and deadline, instead of being a cadence or heartbeat for performing work to accomplish goals.
And as it often happens, any work planned in Sprint Planning can take more time to complete because you can’t perfectly predict what will happen during an entire Sprint. For example, fixing a bug takes longer than expected, a library upgrade goes wrong, a story is underestimated, etc. So now what options does the team have to deliver the Sprint if they feel pressured by management to have 100% Sprint completion, and maybe even having to keep up a high Velocity to prove it?
Can the team drop some stories from the Sprint? Not really, since the scope is fixed. That will also decrease Velocity. And what will stakeholders say?
Can everyone work overtime just for this Sprint? Maybe, but again, people look at Velocity as a KPI and want it high. If overtime is needed this Sprint to fix some problems and deliver some amount of Story Points, who says you won’t need to do the same next Sprint? Inevitably, a lot of teams in this situation start to inflate the estimates to gain enough time to work on everything. But even if they manage to obtain some breathing room, with time the work will expand to fill all of the time available for its completion and you go back to the same issue.
Or maybe just this once the team can skip on respecting the Definition of Done. Just this once! Maybe ignore the code review, maybe hard-code some configurations, or skip on some tests and verify just the happy execution path. A hack here, a shortcut there, just to get it “done” somehow. The reasoning is that these can be later fixed to be truly done, or “done-done”.
All of these things become possible especially in a combination with another issue: reasoning about software in the old fashion way, and not as Agile says you should.
What happens in many Scrum teams is that often releases are not just done less frequently, but they don’t even reach users. They stop somewhere in a testing or pre-prod environment. Releases in production, to the final user, are made in a less Agile way, only for milestones, or even performed according to the traditional model, towards the end of the project when a “V1 release candidate” is considered to have been built.
And now, that video perfectly describes a situation that I’ve often seen, one in which the Increment being demonstrated at the Review Meeting doesn’t — figuratively speaking — have pants on. An Increment is demonstrated at the Review, but it’s presented under a distorted image, one shown by placing the video camera at a certain angle to create just a specific view, not the full picture. The Increment becomes just for show. I’ve been there, I’ve done that, I know better now.
Product suffers
When the Increment stops on some testing or pre-prod environment, Scrum Teams can do all of these things — just this once — and think they can fix them later. But that doesn’t really happen. What happens instead is that a mess is carried along from Sprint to Sprint and then the team is forced to run a few hardening Sprints just before “an actual” launch, to bring the solution to a stage of truly “done”, or “done-done”. If things would be a news broadcast from home, once you’re off the air then everything ends there. But this is not a broadcast, it’s an Increment, as in “an addition to the product and also a base to build other stuff on top of” (i.e. other Increments). So the mess starts to pile up. There is then the risk of releasing the milestones or first version of the product with all sorts of issues in it.
Then transparency, one of the pillars of Scrum, is also affected. There is no longer a shared understanding of what work was completed as part of the Sprint. The progress and image presented at the Review are neither correct nor complete. From this then, you also embark on having incorrect decisions taken by stakeholders about the product and the business strategy going forward (since decisions are only as good as the information and understanding that supports them). Problems eventually (and inevitably) come to light and trust goes down the drain while management learns to no longer trust the Scrum Team. They may even rely on other traditional practices — such as micromanagement — to make sure this doesn’t happen again, unaware perhaps that a traditional mindset might have gotten them in this mess in the first place.
Not to mention that you don’t receive real feedback from users while the software sits on a testing server somewhere waiting for the next milestone or for another release candidate to be launched to users.
Appropriate attention
All of the bullet points mentioned at the beginning of the article, when properly paid attention to, contribute to getting a truly useful Increment.
The 2020 version of the Scrum Guide is less prescriptive than other versions before it, but I personally wish it would add another commitment to the Increment, a commitment to having a working, valuable Increment, just like the Manifesto for Agile Software Development mentions (for software). So not just any software — released throughout a Sprint or at the end of it, something that “works on my computer”, deployed in a testing environment, or software that someone hand waved at a Review Meeting after participating in a staged demonstration — but working, valuable software. Software that users receive and put to use to solve their problems. Working software is the true measure of progress. Working software, not partially working software rolled down the hill Sprint by Sprint and presented in a different light only by careful placement of the video camera.
To avoid having the Increment be “just for show”, a proper Sprint Goal needs to be selected, one that keeps the team focused on the outcome, not just on the output. Then the Review needs to be fully about transparency and shared understanding; it must be a collaboration and an opportunity to inspect and adapt the true product being built. And finally, the Definition of Done is very important too. The Increment needs to be complete and of quality, built in compliance with good guidelines and technical practices selected by the team, a Definition of Done designed to support the creation of a fully working, valuable Increment.
Pay careful attention to these things. Make sure they all — figuratively speaking — wear pants. Because only then does the camera angle not matter anymore. Only then are you showing the complete picture and a true measure of progress.
Do you want to write for Serious Scrum or seriously discuss Scrum?
