3 ms·

My team has adopted a pretty bastardized version of this, and I think it’s a cautionary tale. We give demos after pretty much every sprint, which is absurd. Is

My team has adopted a pretty bastardized version of this, and I think it’s a cautionary tale. We give demos after pretty much every sprint, which is absurd. Is anyone really interested in seeing me flail around for a way to demo optimizations I’ve worked on for two weeks to improve request times by fractions of a second or resolve tech debt?

dllthomas 5y ago
I've never worked in a setting where demos were a durable feature of sprint planning, but in the transient attempts we've been generous with "demo" - walking through what changed in a refactor is very much in bounds (and probably should be - who is the customer of a refactor if not the other coders?).
jadeforrest 5y ago
I would be interested in that if I was leading your part of the org. Here's the value I would get out of it: - 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?

3 ms·

My team has adopted a pretty bastardized version of this, and I think it’s a cautionary tale. We give demos after pretty much every sprint, which is absurd. Is

by horns4lyfe 5y ago

dllthomas 5y ago
I've never worked in a setting where demos were a durable feature of sprint planning, but in the transient attempts we've been generous with "demo" - walking through what changed in a refactor is very much in bounds (and probably should be - who is the customer of a refactor if not the other coders?).
jadeforrest 5y ago
I would be interested in that if I was leading your part of the org. Here's the value I would get out of it: - 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?