And it can fail when all you want to do is give a great demo. I've seen many showcases which couldn't be further away from real projects. Use cases are constructed which are taylored to your features, a little deviation and it won't work anymore.
But still, it's a good exercise to see your project a bit more in the eyes of your user.
Demos should be inclusive of all he work it takes to build a real, functioning piece of software. That should include the reliability work, the scaling, the testing, and the refactoring necessary to do real software engineering. And it should include APIs and containerization. So I guess I'm intending this as a fairly technical demo, but talked about from a customer and business perspective.
I personally think it's important for your stakeholders to understand the necessity of this work, and this gives the team the chance to talk about it.
Thanks for bringing up the failure mode of this -- I'll consider adding that to the blog post.
One thing to be careful of is that the demos are inclusive of all the work required to build functional software. Prepare the team to demo all the parts of their work: the APIs, the infrastructure, the reliability work, and the testing. If you're in an environment where there is less trust, or the leadership doesn't understand how software should be built, you may need to use the demos to educate and give context on the team's work. It's also important for you to cheerlead the work that isn't customer facing.
And added davidkunz to the Thank you section.
And any time spent on the non-visible portions of the project (at least 50% of the value) are seen as "waster" because there's nothing to demo.
Everyone else is thinking about getting new customers, and mostly with new features.
They only love to get into the details when product market fit is not working and they need to buy some time and get the investors off their back by justifying some large technical rewrite.
- I could see what portion of the team's time is spent on tech debt issues, which gives me a sense of how well we're dealing with tech debt, the state of testing, and how good our technical decision making are.
- It also gives me an idea of how well the team is dealing with the real maintenance necessary for a production product. Are we improving response times for customers, how hard is it to make improvements.
- It helps me understand team dynamics. How collaborative is the team's work. Who is working with whom? How much support do team members give each other. How much knowledge silos do we have. How does the team treat each other? Do they cheer on this type of work? How do they feel about maintenance.
That's just a few things that come to mind. I have found these demos to be some of the most information rich activities I engage in, and I find it helps me support my teams.
But I get the sense it doesn't feel great to you. What sucks about it for you?
But it’s definitely one of those things that sounds good until you try it across a variety of teams and different projects.
Developers love showing off their work. But regular demos create expectations. Software always becomes primarily about expectation management.
Early on progress is rapid and there is lots to show and people like showing it.
Then things slow down and you refactor, fix bugs, and you’re left demoing tiny things or with nothing visible to demo.
But you’ve created expectations of consistent delivery of visible features, and non-technical people don’t get it. And the chain of EM and PM don’t want to tarnish their reputation so they will get teams to hack things for a demo. Code quality suffers, and you are piling on tech debt.
Better: let teams demo things when they are ready to demo. Don’t have a blocked out time for it either. Then it always becomes: “so who is ready to demo?”…and if you’re not you are failing and then it’s a competition with other teams.
Constant iteration and demos are good to make sure you are doing the right thing, but not on a public scheduled interval.
It’s scary how many management concepts that come naturally to new engineers are actually terrible ideas in team/political settings. I think we are too used to dealing unemotional machines…
So much important work is not really possible to demo in a way that most people understand or see the gain it gives either.
I think, from previous experience, that demo-driven development sort of works if you are a company or project in the start up phase, because there are a lot of stuff to demo and the development goup(s) can get quite a boost from the excitement it generates.
