How Mandatory Demos Can Degrade Quality Culture

Today I want to talk about the widespread Scrum practice of demoing new user-facing features to key stakeholders after every Sprint. I consider it a dubious practice because it can prevent and degrade a culture of quality. Neither the Scrum guide nor common sense demands that you should strive to hold such a demo at regular intervals. The Agile 2 movement understands that turning teams into feature factories kills quiet reflection, adaptation, and true agility.

There’s a lot that people think the Scrum guide dictates which is in fact not in it. There are no story points, no poker planning sessions, and no Fibonacci ranges. Like religions accrue articles of faith that are in no holy book, so Scrum has given rise to received practices based on wrong assumptions. One belief is that you must hold a demo at the end of the Sprint. There is no such mandatory demo. There is a review, during which you inspect the outcome of the Sprint and determine future adaptations. [..] The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation. There you have it, straight from the horse’s mouth.

Driving for regular demos carries the risk that you create a mindset of rapid prototyping, which hurts quality and leads to more technical debt. This is the point I will argue. Scrum does not warn you that in the wrong team a steady cadence of releasing new features becomes an incentive to rush things. You can counter my argument and other warnings against the dangers of certain Agile practices by saying that there is no problem provided you play by the rules. By that token, no extreme sport is ever dangerous if you know what you’re doing. That is too simplistic. The problem is that we do know the rules to build quality software but are hampered by our own misguided interpretation of the Agile framework to carry them out well.

It makes sense to release often and gather constant feedback from key stakeholders on your new features. Whenever you have something useful and interesting to show, you should share it. But you must not require every chunk of work to be phrased ‘as an end-user I want to …”. Engineers have needs too. A feature is not always something tangible that can be demoed. Value and visibility in software are separate dimensions. Users see only the tip of the iceberg, but it’s the parts they don’t see or care about that keep it afloat. The release cadence in high-quality product development cannot be steady in terms of useful functionality. From a user’s perspective, progress will sometimes seem to stagnate. Use the review to educate stakeholders that this is all in the game and that you do have something to show for your work.

Despite all talk of sustainable pace, committing a team to showcase new functionality by two o’clock every second Tuesday is an open invitation to cut corners. An output-driven team that must get something tangible out the door like clockwork acquires a prototype mindset. Viewers of your demo cannot judge whether you have skimped on crucial non-functional requirements. It’s not their job. They will however tell you when a button is missing or misaligned. That’s what the demo is for. It’s great to keep the feedback loop with your users short if you have something to show. Feedback during these demos will focus on the fitness and correctness of the functionalities. They are not rigorous public test sessions. The serious bugs that you introduce because of your rushing won’t be part of that feedback loop.

All the work you should have done but didn’t get around to adds to the technical debt. It’s the gap between quality required minus quality delivered. Scrum certainly does not promote putting out half-baked features. If a feature is not done properly, it should not be demoed and not be released. Sure, that’s the theory, and Amsterdam City Council does not actively promote drunken stag nights – they just create the opportunity. If your team’s baseline of expectation is to deliver something tasty every two to three weeks, it’s hard not to let people down. You have effectively become a feature factory. You will shout “You ain’t gonna need it” (YAGNI) at every sensible suggestion to improve quality if it jeopardizes the upcoming demo. You call it sugar-coating when you know it’s futureproofing. Here are two sure signs that you are in murky waters: the hardening sprint and the definition of done-done.

The quality gap introduced with every new increment of technical debt becomes a chasm. Some companies let it happen, scrap the whole lot, cut their losses, and start again. Other teams introduce a hardening sprint, a concerted effort to pay back some of the debt and tackle the overdue maintenance of existing functionality. It’s like two reluctant weeks of sobriety and healthy eating after the Christmas holidays. A little embarrassing because you feel you shouldn’t have stuffed your face in the first place. Likewise, professional software teams wished they didn’t need hardening sprints. They feel it’s beneath them. If you need it, having it is better than not having it at all, is what I think. It’s a sign you at least know your weaknesses. You weren’t really done.

Are you done or done-done? When air traffic control gives clearance for take-off, the pilot doesn’t double-check if the tower really means cleared cleared. Rules to guarantee air space safety are not flexible. Rules for building software are malleable to non-existent in practice. That’s why we have the embarrassing concept of done-done. Done means being ready just in time for the demo, without sufficient unit test coverage and documentation, after which we rush on with the next feature. Done-done remains a Platonic perfection we never reach.

In my previous post on the artistic mindset to creativity, I illustrated my point with the late Stanley Kubrick, whose cadence of delivering new films grew longer and longer as he grew more perfectionist (over a decade between Full Metal Jacket and Eyes Wide Shut). Now here was a man who had no double standard about being done. We should be a little more like him, if only because having to settle for the bad quality in favor of churning out features degrades your sense of pride as a craftsperson. Mind you that bad quality can be a corporate strategy. Some outfits have a unicorn dream to grow fat asap and sell their ramshackle digital crown jewels to the first gullible investor. Get out while you can.