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.
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 a rigorous public test session. 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 round 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 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.
This article was previously posted on DZone.