Address Discovery and not just delivery

When will you do the video of pt.3 Time between sprint?

Hi Ed, I wasn't planning on making one, but now that you mention it, I'm thinking "why not"! This would be great topic to address in more details - watch this space 😁

Time between Sprints seems like an interesting concept

The whole point is to address discovery/validation and not just delivery. One way could be to take more time after delivery to validate things... BUT, we also want a continuous (sustainable) pace of development. Best IMO would be to integrate that within the sprint itself

Sustainability is a great and important topic. There might be a video on this in the future. Watch this space!

The whole idea of sprinting is to release at every sprint at a minimum... So yes!

Making more videos on how to run meetings is great idea, thank you 👍

For the PO running the review, I wouldn't just impose this... I would probably bring it up at a retrospective and suggest it. The whole team should be on board with the idea. The point is to move away from the sprint review being just a demo... A demo doesn't really foster collaboration or feedback. It's too easy to just nod and wait for the next big release... The PO might well be reluctant to accept this. They might say "hey, I cannot do this, I don't know how the feature works since I haven't seen it yet"... But that's the whole point. The feedback then would be much more relevant. The team can also just observe how the PO struggles.. that tends to reveal a lot of interesting points!

@@TheAgileBroadcast Thank you for the reply. I really love your videos!!!

Thanks for the kind words!! Much appreciated 😁

Making you feel like you're in the classroom is the intension! It takes a little bit of setup to accomplish, but it's basically just a plexiglass screen in front of me.

@@TheAgileBroadcast Thank you for your quick reply. One more question please where is your camera positioned? in front of you or behind?

Camera is in front me. Screen is between me and the camera.

Hey, apologies for the late response! Somehow missed your comment before... I think it's more a matter of understanding the need to validate what you build rather than having a sustainable pace. Having said that, who is to say that sprints are only for delivery and not for discovery or validation...

Yeah, it's not something I do nor recommend... These can be useful input for the team itself, maybe for a retro for example (especially with the metrics for flow like velocity, throughput, etc.) Showing tasks completed/not completed is also not the right thing to do at a sprint review IMO. When people do that, it shows a mindset based on output rather than outcome (I have another video on that if you want to check it out?) The review is about the product, not about the management of the "project".

@@TheAgileBroadcast I completely agree with you! The value is the goal of Scrum. So if there is no "demo" (even if it is bad to call it this way) do the team proceed by showing Jira tasks (something I have seen from others) or what? Any thoughts? Your content is amazing!

@@NERIDA82 thanks for the kind words! When you say "no demo", is that because the sprint goal is not reached for instance and no value can actually be demonstrated? If that's the case, then why have a review? The sprint has failed, right? Let's not waste the stakeholders time. People are reluctant to do this because "it looks bad"... it's tough because people might say "well, it's not like we didn't do anything!" and they would probably be right! But the point is not being busy, and showing jira tickets progress via ppt and no valueable stuff to demo only demonstrates the busyness... ... which in turns points at the culture of the organisation. If there is such a pressure (external from managers as well as internal from people's own mindset) to basically beg for forgiveness i.e. "believe us, we know we failed this sprint, but it's not because we are lazy"... then we have another problem, much bigger than agile!

@@TheAgileBroadcast no David, "no demo" is because remote team is working on data (no software to show). They choose to show a pp with screenshot of the tickets from Jira (done work, remaining work, what planned for the next sprint, and what they plan to do). On the contrary, I am the one who prefers to focus on what value a feature has brought, which challenges the team has solved. I want their feedback to improve. Do you think my approach is correct? In this case, do you show Jira tickets or what? How do you plan your sprint review in terms of tools? Thanks for your kindness in claryfing. I always ask myself questions.

@@NERIDA82 Yes I think you have the right approach. Focusing on value, challenges and getting feedback is the most important thing. How to plan the review in terms of tools? Not sure what you mean by tools... There is no need for tools IMO. I might use a ppt to show a couple of slides to show the sprint goal and user data (e.g. if we've released a feature in previous sprints, then it's to show data about the usage of that feature - are people using it at all? Or for instance, if the goal of the feature was to get users to do something, well, let's check that they actually do). And you can also show an outlook of what's coming next (not in the form of Jira tickets, but in the form of a customer-centric sprint goal) Your team is working on data you say? So perhaps, they don't deliver features to users directly, which makes things trickier. But... they still have a customer - maybe other teams, who are going to use that data. The review is for them. And if the data is used by other software development teams that build feature... why not combine the sprint review is those other teams once the feature that uses the data is complete? And final thought... having a data team sounds like a bad idea to begin with to be honest. Scrum promotes the idea of cross-functional team, i.e. a team that has all the skills necessary to bring value. But data is often just a piece of the puzzle, right? If they deliver just a piece and you need lots of other pieces before you see user value, then it's going hard to be agile with a such a team setup. Hope this helps?

Magic 😃

It's called a lightboard. You simply write on a glass screen placed in front of you. That means the text is back to front of course... So you then need to flip the image with a video editing software, and that's that

Thanks for your feedback! Though I think what you present is a bit of a strawman. Maybe you think the entire concept of a PO role could/should be removed (and I wouldn't necessarily disagree there 😜) but a PO is by definition a single person and is meant to, quite literally, own the product. I see too many teams presenting the output of what they've done and the PO passively listening... In those cases, I want the PO to be in the driver seat (and yes, even better if they do that together with the rest of the team). Being in the driver seat doesn't mean you're the only one talking, or presenting... Just use your imagination when trying to get a passive PO into being more actively engaged with reviewing the product. Making the PO the driver is, I found, a good way to radically change the dynamic of the review from output to outcome. Now, do we want this original imbalance to be simply reversed (so now the Devs are passive)? Of course not. So I agree with you, even better to build a team with no barrier product/business/developer... That's a far away dream for most teams... Which is why this is just a "tip", not a recipe of "how to do things".

Sorry to hear you feel so strongly about how I look... Do you have feedback related to the actual content?

@@TheAgileBroadcast excellent production you just look ssooo tired! Then I get feeling the same way….so it’s hard. Will comment when I watch. So I have to mention this…But related to UX. UX produce red videos go on an on about usability then don’t us e UX principles in video, like one the content is perfect but the portraits shots with shiny skin reflecting light, then really bad hair, I almost felt sick.With Krug of Rocket Surgery fame video on UX was so bad I think I told him he needed a Razzy award. What happens you look so tired you can’t even focus on the content.it’s such a distraction. But the lighting, and production values is high. Bad UX on videos can render the video unusable.

Excellent video. And you worked so hard on the content so applause for you. Work is more important than looks .....

@h.t.7310 i think we r here for content not looks..... do u agree