I’m not sure how I feel about doing demos for the ‘higher ups’ in the company. It seems that when we do a demo, we end up with a carefully crafted environment, that perhaps has a few hard coded values in place. It runs on a local developer’s machine with code that has not yet been put up for review. We can run through aspects of the feature and show what it can do, which is good in that it allows for feedback on things.
But there is a downside too.
Have we got accessibility in place? Is the code fully localized? Do we have a bunch of edge cases that we didn’t demo to clean up? What about those hard coded variables we put in place to make the demo work? What happens when that code gets off the developer’s machine and out into the wild? How will it perform under real life loads and stresses? There can be a LOT of work left to do on something that was shown in a demo, but does that really come through?
It seems like what can happen sometimes is we put our best foot forward in a demo, but we don’t show the things that are broken. We might mention some of the additional work that we need to do, but at the end of the day a picture is worth a thousand words. When someone sees a ‘working’ demo, and then hears about a few bullet points of additional work, what will they walk away from the meeting feeling?
‘Oh this is almost done’
Is it though?
I think a lot of demos leave people with a false impression of the state of the feature, and this can lead to problems. It can lead to schedule pressures – after all it looked almost ready last week so why isn’t it released yet? This can really get bad if people start talking to customers or even just internally ‘bragging’ about the feature.
Solution
I wish I had a magic solution, but I don’t. Well, I guess I do have one – don’t do them – but perhaps that is a bit extreme. I was just struck by the thought that this can be a problem, and I still need to think more about what can be done about it. Any thoughts? Have you ever seen this problem on teams you’ve worked with?
offbeattesting 
This sounds so familiar that I wondered if we used to work together (I know we didn’t though). The solution I proposed to reduce the false expectations and facades was that only stories that net our definition of done could be demoed. This meant that the story had made it through dev and testing. As a further measure, demos were performed using a QA/Staging environment which required the code to go through our deployment process and was not propped up on a development machine. The main drawback of this approach was the lack of a blameless environment when management asked why the other stories were not complete and being demoed.
LikeLike
Thanks for your comment. I feel like the concern you raised would be part of the problem in my context as well. Teams would get compared and you would get questions (or at least implications) along the lines of ‘why don’t you have something to demo when these other teams all do?’
Refusing to hack together demos could be one way to help with this problem though. Thanks for sharing your experiences!
LikeLike
I tend to find the only useful thing about demos is that they can give you early feedback about the things that are currently demo-able. Did they think the flow was going to be different? Do they dislike some of the assets or text used? (yes, this somehow happens despite having sign-off on those exact things).
I’ll paraphrase a quote I can’t quite remember: “The last 20% takes 80% of the time/effort”. Polish is tough. As you say, I see honesty as the best policy here. We have these known crashes. This is still mocked. We have X outstanding bugs.
Perhaps management need educating to not use a demo as their progress update. Whoever’s reporting to them should be making development and testing progress clear. They should be happy that the app is up and running and looking good, but they should be basing their expectations off of progress updates.
LikeLike
yeah, I think this article (http://gregorytesting.ca/2018/10/demo-things-that-arent-done/) actually helped my understand what is going on in my context. In the second last paragraph he talks about vapour ware perceptions and that it come primarily from long wait times. The solution of course being to fix the long timeline. I think fundamentally that is were we need to get as a team. We need to shorten the time between ‘starting’ and ‘finishing’ a feature
LikeLiked by 1 person