4 ms·

Set the expectation that everyone will demo their work sometime around half way through the sprint. That way everyone knows they’ll be showing something and so

Set the expectation that everyone will demo their work sometime around half way through the sprint. That way everyone knows they’ll be showing something and so will have to think earlier about how ‘done’ they really are, what visible progress they’d like to be able to show, etc. But there’s no expectation anything will be more than half finished at demo time, reducing stress and giving early visibility.

stingraycharles 6y ago
Works only if the work is frontend though. With backend work, there’s usually not a lot to show unless you specifically optimize for making a demonstratable prototype a specific deliverable, which to me seems like just a distraction and missing the overall goal.
- tomcat27 6y ago
  Absolutely!
- capableweb 6y ago
  Why? If you're backend, show that things are working in the backend, not much different than frontend work. Or show your design work. Or video editing progress, or anything. If there is _no_ progress but in your head, at least what you can do is write it down. Then you end up with a document. Demo your document. And yeah, if it's missing the overall goal, then it's clear halfway through that we're missing the goal, so you can correct earlier.
- eatonphil 6y ago
  I see this argument a lot from folks who never worked in the frontend. Having worked in both it's much clearer there are always ways you can demo changes in a backend. You can show new docs made available or before/after performance numbers of simply just describe what would now be possible for clients. No matter what you work on there _has_ to be a way to show the impact you had unless you had no impact.
- darrylb42 6y ago
  Lots of ways to demo a backend. Are you doing REST? Postman to show the API functioning. Have tests, show the test suite. The person writing the backend needs some way to drive it to test their own work this should be demonstrable to a technical audience.
- Smaug123 6y ago
  I agree with the siblings that this isn't true. I've recently finished a big refactor of something entirely back-end with almost no user-visible changes at all (except ahem for a bug I wrote), and I could still present progress. The work was the migration of six or so different components: they used to conform to one API, and I moved them to a different API. I found a way to order the changes so that they could be done sequentially rather than big-bang. Bam: a clear progress marker. This kind of progress is pretty common, in my experience. I've already written about defunctionalising an algebra before (https://www.gresearch.co.uk/article/defunctionalisation/ https://www.gresearch.co.uk/article/defunctionalisation/), and that is another example of a task where the work can often divide itself into discrete chunks. You can show your progress to your team, all without the end-user being able to see anything.
throwawayincog 6y ago
This is a very good idea and fits with what immediately came to my mind; things need to be "proven" or "working" way before the end of the sprint so there is time to refactor, refine, and improve quality. To the OP, think spikes: https://en.wikipedia.org/wiki/Spike_(software_development) https://en.wikipedia.org/wiki/Spike_(software_development). Very important with a lot of unknowns. Doubly important for new engineers because.. Well, sounds like they are dealing with a lot of unknowns.

stingraycharles 6y ago

Works only if the work is frontend though. With backend work, there’s usually not a lot to show unless you specifically optimize for making a demonstratable prototype a specific deliverable, which to me seems like just a distraction and missing the overall goal.

tomcat27 6y ago
Absolutely!
capableweb 6y ago
Why? If you're backend, show that things are working in the backend, not much different than frontend work. Or show your design work. Or video editing progress, or anything. If there is _no_ progress but in your head, at least what you can do is write it down. Then you end up with a document. Demo your document. And yeah, if it's missing the overall goal, then it's clear halfway through that we're missing the goal, so you can correct earlier.
eatonphil 6y ago
I see this argument a lot from folks who never worked in the frontend. Having worked in both it's much clearer there are always ways you can demo changes in a backend. You can show new docs made available or before/after performance numbers of simply just describe what would now be possible for clients. No matter what you work on there _has_ to be a way to show the impact you had unless you had no impact.
darrylb42 6y ago
Lots of ways to demo a backend. Are you doing REST? Postman to show the API functioning. Have tests, show the test suite. The person writing the backend needs some way to drive it to test their own work this should be demonstrable to a technical audience.
Smaug123 6y ago
I agree with the siblings that this isn't true. I've recently finished a big refactor of something entirely back-end with almost no user-visible changes at all (except ahem for a bug I wrote), and I could still present progress. The work was the migration of six or so different components: they used to conform to one API, and I moved them to a different API. I found a way to order the changes so that they could be done sequentially rather than big-bang. Bam: a clear progress marker. This kind of progress is pretty common, in my experience. I've already written about defunctionalising an algebra before (https://www.gresearch.co.uk/article/defunctionalisation/ https://www.gresearch.co.uk/article/defunctionalisation/), and that is another example of a task where the work can often divide itself into discrete chunks. You can show your progress to your team, all without the end-user being able to see anything.

throwawayincog 6y ago

This is a very good idea and fits with what immediately came to my mind; things need to be "proven" or "working" way before the end of the sprint so there is time to refactor, refine, and improve quality. To the OP, think spikes: https://en.wikipedia.org/wiki/Spike_(software_development) https://en.wikipedia.org/wiki/Spike_(software_development). Very important with a lot of unknowns. Doubly important for new engineers because.. Well, sounds like they are dealing with a lot of unknowns.