AgileData #11 - The value of agile ceremonies

Welcome to the Agile BI podcast, where we chat with guests, or sometimes just to ourselves, about being agile with teams who are delivering data analytics and visualizations.

Welcome to the Agile Bi podcast. I'm Shane Gibson.

I'm Blair Temporo.

And I'm Joe Shrigley.

Hey, Joe, thank you for joining us today. It's lovely to see you.

Thank you.

The way we tend to start off the podcast is asking people to come along to tell us a little bit of their background. So a little bit of a story about how you got into this world of Agile Bi.

Well, for the first.

12 years of my career, I worked in data analytics and I didn't use Agile. And then in 2015.

The place that I was working decided to implement Agile and I guess I was a little bit skeptical at first. It was just something I hadn't really heard of before, but. But I really, really quickly, I was really quickly bought into it. And the main reason for that was that the framework was just so natural to me. The fundamentals of what Agile was trying to achieve is everything that I had already been doing in my work. So working really collaboratively with my customer, taking them right along the journey and, and rather than showing them what I'd completed at the end of what I thought I'd completed, I've always been a person to.

You know, to show them, go and meet with them and, oh, this is it, half done. What do you think of this? This is it. Third, three quarters done. What do you think of this?

And so the implementation of the framework of Agile just kind of fitted into what I was already doing. So, yeah.

And the other thing, I guess that I had always tried to push in the jobs that I've been in is collaboration across the team. And so, you know, before being introduced to Agile, I was always a fan of meeting as a team on a regular basis and talking about what you were doing with the aim of.

Maximising the team's knowledge in order to create a smarter solution and also minimising reinventing of the wheel because there'd been times when I'd come into a team and different people within the team would be essentially doing exactly the same thing. I mean, in fact, in the current place that I work, when I, you know, right back when I first arrived, everybody, no one in the team knew what each, what each other were doing and each person in the team was essentially repeating what another person was doing in the team. And if they'd just been, if there was a forum where they could have been talking about what they were doing and Demoing what they were doing, then the outcome for the customer as well as the productivity for the team would have been way better. And I suppose through, through the move to Agile or the formal move to Agile in 2015 and our team.

All the benefits, all that smarter solutions that we're coming up with, the significant reduction of reinventing the wheel, the creating more holistic solutions that meet a whole bunch of customers needs instead of just, you know, head in the sand only meeting one customer's needs.

And also I guess a better customer service through.

The whole team, more collaboratively and more iteratively working with customers. All that's come to fruition. So yeah, so what's your role on.

The team that you're working with at the moment?

So the role that I'm doing right now is officially Scrum Master and BI consultant. So I sort of manage the daily stand up, I organize and manage the Scrum ceremonies. So the demo, the retro, the refinement meetings and sprint planning. And I also help remove the team to remove impediments. So if they are implying at a stand up that something's blocked because of such and such a person or something, then I will identify that and you know, and try and work with the team member to work out how we can get rid of that impediment. I also will at the stand up, if somebody's saying, right, I've now finished the dev work that I need to do and we can all see that the peer review is the next thing that needs to be done, then I will proactively say, right, okay, is there somebody in the team who's willing to take up that peer review or put their hand up in the stand up for the peer review just to keep things rolling?

Yep. So all good Scrum Master behavior. So I think what we're going to talk about today is to kind of topic you picked, which is one that again, another topic I love is this idea that when you start off with a new team, so you're going into an organisation or into a team that hasn't started their Agile journey and you're taking a Scrum approach and when you look at it, like you said, there's indentious ceremonies that we run because they have value. I think the word you used was investment when we talked about before. So they take time and for that investment of that time there are some benefits without investing time. We get the downside of those things not happening. But often the teams come into this agile way of working thinking. There is no documentation, there is no Meetings, the things that everybody advertises or that advertise so people focus on as some of the negatives sometimes. So when we say, hey, if you're running a three week iteration the morning of the first day we don't lose. So we invest time in planning and committing what we're going to deliver over the next three weeks. At the end we do a demo or approve it where we show in the value we've delivered and prove it's actually ready. In the middle, we want to refine what we're doing after this one so that our time on that first day is shorter. It's more of a commitment than a planning and, and estimating. We do daily stand up so the team can talk to themselves about where they're at. All those ceremonies take time and teams often turn around and go, I'm spending too much time in meetings, just let me code. Right. And so you've obviously found that issue or that problem or that behaviour when you started out.

Yeah, absolutely. So when I came back from having my son in April last year, I came back to our team. I think we were doing one refinement meeting if that per fortnight we weren't doing a demo.

And there were members of the team who were saying that they were finding that we were having too many meetings and they were all ready and they were reluctant, very, very reluctant to have any more meetings. And I guess.

It'S really important to understand those people's perspectives. It was kind of valid what they were saying about having too many meetings. And I think you can't just. I guess my philosophy around anything I really do, including Agile, is around the importance of getting buy in from the people to why you're wanting to do in a particular way. So I've never been like a carrot and stick. This is the way Agile is therefore like it or lump it, this is the meetings we're doing.

I've found that doing it that way just pushes people away and that you really have to. And it always of course takes longer the second way. Like it's quicker to do the keratin or the, you know, is it stick approach?

Well, the dictatorial. They'll shower. Yeah.

And people do that all the time.

Because it takes longer to do it the longer the way of getting people's buy into it. And I suppose the way I tackled refinement meetings was that what was happening was that I would get to. Well, we'd get to our Sprint planning meeting which was on the Tuesday at the end of the Sprint and obviously the beginning of the next sprint and the sprint planning meeting would go on for like two hours.

And everybody would just be at their wits end because who want, you know, how can you operate effectively in a tense two hour meeting where you're trying to rush through sizing and explaining stories that people had no idea what, you know, the sprint was lined up with these stories. The majority of the team didn't know what they were. And so you'd have to backtrack and the person who put wrote the story and put the story in would have to explain it to the, to the rest of the group. And then it'd be like there'd be lots of questions about so why would we want to do this story but we've already done this before or you know, those kind of questions. And you know, by the end of actually because the sprint planning was taking so much time and so difficult for the team, we actually switched the sprint planning with sprint with retro with the retrospective and had the sprint planning in the morning. So people had more energy for it.

So much pressure.

Yeah, yeah. And so in the.

I guess over a period of a few weeks, it wasn't just once that I brought it up, but I guess I got the team to start thinking in the retrospect perspectives about the fact that the planning wasn't going very well and everybody knew that and everybody was frustrated and what could we do to try and help improve it. And the team, you know, ended up. It was kind of a bit of a negotiation thing between some of the team who were really like more pro, you know, the, the investment than others who were like pro. I want to be coding. But it kind of got through kind of a negotiation amongst the team.

They were able to agree about the need for actually to begin with I said why don't we just trial.

A couple of. So a refinement meeting in that off week that we weren't doing a refinement meeting but just a trial for a couple of weeks for a whole sprint, sorry, two sprints.

And then at the retro beyond that I asked the team how they felt that things were going and even the people who were very anti meeting admitted that it was. Oh, actually the other thing that I did was I said not everybody has to come to every refinement meeting so.

You gave them the chance to opt out if they see the value.

So I said at least if we've got four out of the team there. So it was about 70 odd percent of the team were there on any one refinement meeting.

And that gave the opportunity to the people, certain people.

It was not about opting out every time, but kind of almost a bit of a rotation basis.

But that would be interesting because what in theory that would cause is you're giving them permission to opt out if they didn't see value. They may decide not to come to the first one or they had to come to the first one and then opt out. But if they saw their colleagues, if they saw their team members going to it, and then when they go to the planning session at the beginning of the duration, they're out of the loop. Right. The team have already refined it, they understand it, they're having, you know, three letter conversations because they're all on the same page and they've collaborated. And if you've opted out of that planning refinement session, you even gonna slow the team down by asking a lot.

Of questions that have already been done.

So you're gonna, if it's successful, if you have that mass, you're gonna opt back in. Right.

It's funny you should say that, because that's what happened is certain people who hadn't attended the refinement meeting would start bringing up things in the Sprint planning meeting. And so I then said that if you're not at a refinement meeting, you have to accept that we've already discussed stuff. And so there would be times in the Sprint planning where I would, and I guess that's where I did put my foot down a little bit more and I said, look guys, I'm sorry, but this has already been over in the refinement meeting and if you weren't there, you know, I ended up getting agreement that if you didn't come to a refinement that you had to accept whatever was decided by the rest of the team.

So do you actually, out of interest, do you run a teaming agreement? Do you have a team agreement that's documented where you would actually slide that in as a way of working or.

No, we don't have that. It's a good idea.

Yeah.

Look, what I find is we had it more informally, I suppose.

Yeah. What I find is one thing I think.

We do badly in Agile bi we're not as well as we could, is we don't tend to set our spaces up as cool collaboration spaces. So a lot of the teams I'm working with now.

We'Re working in organisations where these digital teams and they're inherently running from an agile point of view anyway, so they've got UX designers and that, and they always have really cool posters. They always have this great feel about their space. And so when I look at team agreements in the past, I thought, yeah, we know them intrinsically, but actually just writing an A3 piece of paper up, even though it's ugly with those teaming things where you can actually say, I think it gives a sense of reinforcement as well. Because what you can say is, okay, we've got a new agreement, I'm going to go stick that on the teaming agreement, it's now visible, it's now agreed it can change, but it's that reinforcement visually. We've agreed that you don't go to planning, you can't relitigate a lot of the questions in fluent.

Well, that's something similar to what you ran with us, which is be that guy and don't be that guy. So at the very start of our agile journey, it's like what do we like about ourselves as people and.

What sort of characteristics don't we want in the sprint? So we had two very visual lists of things we don't want and we help people to task if they actually showed traits of the negative. So that could build into a contract.

Or not a contract. So a 10 minute agreement is a form of contract. You know, it's not as onerous as a contract. We don't sign it. I'm sorry, I've never had a team sign it. Kind of interesting. But yeah, it is a form of that. So yeah, that was off on a side thing. So yeah, I'm with you on the planning stuff. What I found with refinement is, yeah, that trigger point, that trigger point of our commitment ceremony or our planning ceremony at the beginning of the iteration gets too long and there's lots of anti patterns we see when we start doing that. So the ones I picked up that you mentioned, we're coming together with something to deliver a new IP information product. But the team haven't seen it before so they're trying to grapple with what's this thing, what's the outcome, what do we need to deliver? How do we now decompose it into its moving parts? Where are the risk areas that we have to score highly with large points because we're not sure which ones are safe? All that complexity is all done in two to four hours and people burn out. So I think that's a good one. The second one that I've experienced just lately, which I've never thought about is the way people absorb information. So when you work with people that really like to listen and hear and then they need time to distill or digest. They need to be able to stop, think about it and then come back. When we only have one ceremony, we don't give them that time because we're moving. Right. And the team's moving. So natural refinement, that refinement means they get a cut at it. Yeah. And then they can think about it and then they're not re litigating, but they're. They're becoming better at planning because they've got more time to absorb that information. And that's a personality style thing that I've never picked up on but just kind of stumbled across lately. So I think those. What do you think, Blair? Where else have you seen the planning ceremony being useful or worth the investment? I think. Oh, the planning ceremony, sorry, the refinement ceremony. Where else did you say, oh, look.

We run three week sprints and we have two.

Backlog grooming sessions, which is refining where we start to build the straw man of the next two sprints. Straw men. And I just find it so valuable going into the planning session already having an idea of what's next. And that's where I guess a product owner is really important as well, is giving you direction as to what their stakeholders say is important, what the value stream mapping says is important.

So that planning session's sharp. You're breaking down stories from epics or breaking epics into stories. You've already got an idea of what's next and there's no selling really. It's just breaking down into those manageable chunks and that's the goal.

So that was a good point there again, that I hadn't picked up on. So you're running.

Two iterations ahead. Right. Time horizon for S minus 1, S minus 2.

Yep.

But what you're also doing is you're bringing the product owner and if they haven't been a product owner before, the iteration starts, because you bring them into that refinement. So they're getting some engagement with the team. They're understanding how the team decompose things, the questions they're asking. You're actually slowly onboarding the product owner if they're new, rather than just landing them on day one to this whole new world of working, which must be bloody confusing when you're new.

And it also gets them two opportunities to go back to their customers or their stakeholders. Before we actually get into the planning session. And we time box what we're actually going to do for those next three weeks, we're saying, you know, if you're not sure what's next. You know, you've got two weeks to sort it out. So that's a bit of goal too.

Because your refinement, how many timer horizons ahead are you, Are you still. Are you planning the next iteration or are you trying to refine a couple of years?

Yeah, we are mostly still in the only planning for the next Sprint.

But.

I think we're slow through just incrementally improving things over time. I think when. So we're now like for example, when we.

I noticed about a week ago that when we got to Sprint planning meeting that not only had every single user story in that Sprint being refined and sized, but there were already three or four stories from the Sprint beyond that. So we are kind of slowly improving and we've come a massive way, I guess I'd say is what I'd say from a year ago. Another really cool thing that I've just started implementing recently, which I don't know what you guys think about, but is 5 minute time slots for the discussion of each story in the refinement meeting. So we get to the refinement meeting, what was happening was we were getting stuck on particular stories and we could be half an hour talking about one story. And so what would happen is because we'd done that, we actually weren't ready. We didn't have everything sized by the time we got to Sprint planning or we'd have to keep actually for a while I was incorporating extra refinement meetings. But even then like so we'd do a Thursday refinement meeting. We didn't. There was like half still not done. Then I'd be like, right guys, I think we're going to have to have an extra assignment meeting. So we'd do an extra one on the Monday with Sprint planning on the Tuesday. But even then, sometimes things would drag on and we'd still have stories not agreed.

Yeah, we've come across that. So if you're spending 20 minutes on one story, it's probably too big, so it probably needs to be broken up. So what we found when we planned one sprint ahead, like three epics, let's say, that need to be broken down in the first refining session that automatically.

Moves into the next sprint because you know that you've sized it and those three epochs are just far too big for one sprint. So you're automatically moving into S minus 2.

And another good point about that, which tweaked me thinking about it as well, is by refining early we can find those stories that are 4 forties because the team don't know how to decompose them. There's some information missing or they haven't done it before and they're not quite sure how they're going to build this. And so that allows them to introduce the idea of a research spike in the next iteration before they get to it. If you're two horizons ahead, they can go. It becomes obvious, look, this big thing is too big and we don't know how to decompose. So why don't we spend some time or some points in the next iteration doing a research spike to understand how we do it? I think there's a balance there. So to take your point, I don't use a five minute time limit, but I unconsciously invoke one at some time when I find the deep diving because I think what I see is two behaviors. One is the story's too big and we're never going to be able to break it down right now because we just don't have enough information, information. So we need some way of breaking that. And that's where a research spike comes in. The second one is we're just deep diving on detail because people like to do it and it's not adding any value. Right. It's not, you know, we might be arguing to get it from a five to a three or we've just got this little pet peeve or we're really interested and we just want to discuss it.

Yeah, yeah.

That's not the point of refinement. It's to get it down to a small enough chunk. That. And the way I work it is that, you know, in theory that task can move in a day. That's really what we want to get down to. So there is that whole idea of no estimates where you don't actually point things.

I find that as teams get more and more experienced, they move away from poker pointing or they do it naturally. Right. They stop playing with the cards and they.

Yeah, I know, but because they've been working together for so long, they're kind of symbiotic.

Yeah. And you start to build up what we call a basis of estimates, which are things that we know that are a five or a seven or seven. No, a five or an eight. Because we do them every time we develop a product. So let's not spend time trying to decide.

I really like your idea, Shane, about how you mentioned about incorporating risk into your sizing because I think that's maybe something that we need to do more because quite often a story will end up ballooning out. And it's because there was. Yeah. Something that we were a little bit unsure about when we sized up it. And.

And that's okay because, you know, if you've got a big pointer. So I will naturally say to them there is a certain size you're not allowed to bring into an iteration. So Normally it's a 40, right. Or the.

Yeah.

And 20s we say are high risk. Right. We're saying we really think they're a lot of effort. They're about a week's effort, probably depending on how the team point. Right. But you know, they're multiple of. Multiples of days. You know, they're risky and we can't figure out how to break it down and we just don't want to. But we're going to take a punt. Right. But what we say is do the 40, the 21st. Right. Don't leave a 20 to the last part of the iteration because you'll fail. Bring in an early. Right. You know, if it's below a 20, if it's a 13, you know, and then 8. So where we really want to get to is more of a Kanban approach where Every card's A5 and A5 can move in half a day, you know, or a day, you know, we really want to be able to get to that level. But I don't know about you. When I start off with new teams, it's part of that journey to get to that level. We can't do it on day one for a whole raft of reasons. Yeah.

And with. If you have two refinement sessions during the three week sprint and you've identified that. That 20 that's sitting there and it's not moving, it can really change the whole shape of the. The next two sprints because I use that opportunity to. With the product owners agreement and we found that this 20 is just massive and it's actually 50 or whatever.

It's 100. It's a question mark.

Then we're not shy of changing the whole. So it's the first or. Yeah, we've got two more weeks. We can change the shape of the whole sprint with the agreement of the product owner and we'll break that 20 down into two, you know, two tens or whatever. And then bring. And that the bit that's left over will go into S minus one and.

Then we're not right or not. Because what you're saying is 20 sitting there is dangerous. We've had a go and we've realized that we're not Going to deliver all of it. So Mr. Or Mrs. Product Owner, you're not getting it. We can give you parts of it. That's the best we can do now you may, if you've got the right for the next iteration get the rest of it. You may not. But what do you want to do? It's your trade off decision.

Yeah. That's where you use the backlog as well. It's like we know that only half of this is really important for going forward.

Can we park the other half? Come back later when you've got a bit of a.

You're doing half of nothing. There's your choices. So if we go from there and we jump into the demo sessions. Right. So refinement for me. Yeah. Solves a lot of problems. I think we've seen that. Yeah. Good. Worth the investment. But hard probably the one meeting or session I think that people not argue with raise the most. Yeah.

I think it's because they're not working on it right now. So that planning early seems like an anti pattern for agile. Right. It seems like a waterfall behavior.

But the demo one's really interesting. Right. The prove it again. I see teams drop it because. And in my view it's because it holds them accountable.

You can't show it it didn't happen. What do you think?

I don't. I haven't experienced that myself. I just think that people prioritise which is the critical meetings and a demo like you have to have planning because otherwise the team doesn't know what they're doing tomorrow. But people and I guess, I don't know, people tend to drop the demo rather than the retro part and.

Yeah, I mean so when I came back into my team they weren't doing a demo.

So how did the stakeholders feel about that? So how did the people outside of the team. Well, product owner above. Right. The people outside of the team who weren't involved.

Were they not attending anyway?

Well this is interesting because a year on having done demos for I guess a year now we still aren't actually including our customers in our demos.

How come?

And.

I actually have made a specific decision not to do that.

Because we're doing so many different things things for. Because I guess in the BI space and we've got a bunch of different. We've got about 10 key data apps so qlik and qlik sense and the requests that we get are quite varied. So it might be a change or an improvement to an app. It might be an investigation into some data that somebody thinks looks a Bit strange. It might be.

Doing some back end.

What do you call it when you improve some code that you've written in the, in the past.

And so, yeah, so in any one Sprint we will have between four, five and 20 customers.

So that's I guess direct and slightly like more indirect customers. But users of the change.

And for a few Sprints we did have some people coming along, but it was quite hard to, you know, say, to get. Well, there's a couple of issues for us. One is that a lot of our customers are based in different locations and actually getting a room that is suitable for the, for the demo and retro that's big enough and has a VTC is a challenge in itself. But also like the logistics of saying to a particular customer, okay, we only probably need you from 10 past 10 until, you know, 25 past 10, and then you probably don't need to stay after that because the next thing is a lot less relevant for you. I found that it was better for us to demo as a team in the demo and then have individual demos with customers after that. So over the next week.

So you still demo.

So you still demo. So let's explore that a little bit. So for me, the demo has been really, I call it a previous session and I call it a previous session because demoing came out of Scrum and it came out of the app dev environment and typically they've got lots of screens to show.

And when we're doing data and bi and analytics, sometimes if we're doing our first exploratory type of delivery, we're kind of data and code heavy and front end light.

So for me it's taking the demo concept and saying we're actually proving what we spent our time on. And I found by changing that it had a little bit of an impact on the behavior in a good way. I definitely find having that session for some reason makes the team focus.

On actually finishing. I don't know what it is, but if they don't know it's there, if it's not there, everything bleeds to the next iteration. If it's there for some reason, there's just that little bit more push to get it ready.

So if you have a Sprint full of research and documentation, you still have a demo.

Yeah, I still improve it. And the reason for that is.

The other thing I'll do is if I start with a new team, I'll go through a gradual process. So I'll start off and they will demo to themselves. We make it a very safe environment. There's nobody else allowed in, including their boss, if they're uncomfortable, really safe environment because they've got to learn how to present, right? And so what will happen is typically the first one will be a complete nightmare. It's completely ad hoc, no agenda, Nobody knows of the running. The first person takes up all the time, everybody else, right? So they learn and they start adapting to doing a bit of an agenda for themselves so they know who's next. Then you'll see them have a little bit of a practice so that it actually works.

And then what I'll typically do is allow their direct stakeholders in as a practice run next time where they've got that. An unexpected benefit of that is that those stakeholders have given the team permission to work in this new way. And they're not really often at the beginning, because we know the teams often fail at the beginning. They're seeing this investment and this failure and they start getting nervous. And when they come into the prove it session, they can actually see all the work the team's doing, so they get the sense of actually that investment, that investment in letting them take the risk and this new way of working and that investment in their ability to fail actually helps. The other thing it does is after two hours, three iterations, that stakeholder, if they're not at those private sessions, will start to want to accelerate the teams. They'll either want to add more people, get them to do more, or add more squads, because people, for some reason, they have this natural two to three iterations, which for when I do, it's nine weeks, that's enough. We should be absolutely hard in the rocking it. As soon as they come to approve it, they can see which bits are hard and which bits are still risky. So their risk profile, they'll back off a little bit.

And it creates a really great value conversation around that. I like this idea of investment. I'm going to use it of the time and the permission and that. And then once you get it out to the wider audience, what tends to happen, in my experience, is you'll get a rush of people. For the first one, you've got to book a big room, right? The first one, you've got to book a big small because everybody's heard about this thing and they all come along and then after that, lots of people leave and never come back. Because what we say is, in the previous session, yes, you show the dashboard or the report or the data service, but actually you show the documentation. If you've had a gnarly problem with data you describe the process you took. You show a screen of code. You don't read the code out, but you go, I had this problem that we had customers coming in from two different source systems and we had to match them, but the actual customer IDs don't match. So I had to write code that looks at the names and the addresses and hey, here's a really interesting edge case. And everybody nods. They go, oh, yeah. The last part of it is by getting that mass is to your point about if it was built for one team, another team doesn't need to see it. What I found is often you'll hear the words, we have lots of data but no information. Right. What that means is people don't know what exists. And yes, we're doing data catalogs and that's true. But often we'll hear the words, oh my God, I didn't realize we had that customer data already I've been looking for that. Or even worse, oh my God, I didn't realize we had that customer data. I just paid a vendor a fortune to get it for me. So that cross pollination of what we have and what we can reuse is another piece of value that just intrinsically comes out of that audience.

That is a really interesting idea, actually. Yeah. One customer group are getting an idea almost from what another customer group's receiving. And even if that particular thing doesn't perfectly apply to them, it still may plant a seed.

Yeah, you often hear, oh, actually we could use that for.

They kind of morph and bounce off. Another use that nobody would have thought about because nobody understood their business problem. But they can see a mapping and then the other one, I suppose that happens is it starts, it's around that brand people who now go, oh, wow. So if we engage with you as a product owner and we give you our problems, you work through this process and give us help. Yeah, yeah. That's what we're here for. Wow. And again, it's a subtle sales message. What I used to. So when you look at demos, what's meant to happen, if you read the books is the product owner does the demo.

And I've always struggled with that one because it's not just a dashboard.

But what I found actually is it's also a great way of understanding maturity of your product owners. So I've now had teams where.

Sometimes the team will demo the product or the IP and in the next iteration the product owner will demo it. And that's really interesting dynamics, but they're both okay. If the product Owner is comfortable of showing what's being built. I've seen a product owner demo the data. There was no dashboard, no report, because they were quite a technical product owner. And so they grab the data and actually show what they. What model they built off it because they were a product owner that used the data to build the model and they rocked it. Right. Because it was quite a complex model when they were like, bang, bang, bang and that. But yeah, so I think that's okay. Like you said, you adopt the behaviors of these agile approaches and patterns in a way that fits you bi. And data's a little bit different. So, yeah, I don't know. I'd suggest maybe do it safely. Right.

Definitely something to think about.

One key stakeholder that you know is a forgiving, trusted key stakeholder. Bring them in and see what happens. Experiment with it.

Yeah, yeah.

If it doesn't work, stop it. Right. If it works, carry on.

Yeah, but I really like that idea of. I completely agree about.

The fact that, yeah, a team will definitely, you know, can leverage off what another teams received. Yeah, yeah. Because sometimes, you know, like, say you go to a conference and you're really keen on listening to a particular presentation and then you might end up sitting in on another one that you didn't expect that or didn't think you'd want to listen to, but suddenly it sparks this idea, doesn't it? And you're like, oh, like, yeah. And so that.

Tweet another thing. So sometimes what happens is the teams will decide to have a game of two halves. So they will spend the first half showing the sexy bits and the second half showing some more of the documentation. Like, documentation. Sorry, before I end it, don't underestimate the value of showing a document that you've written.

I love that.

So then you give them a. Give them permission to exit if they don't want to go through the more technical.

Yes. So the beginning could be that all the changes to apps that we've made, first half or whatever, second half is improvements to code.

And it's okay. You give them permission to exit the room if they want to go and invest their time somewhere else. Right. It's okay. The team won't get upset.

So you could also do gamma two halves with the product owner.

Sort of focusing on the. Why? Why are we doing this? What is the business problem? We've got a gap in data that is needed to make decisions.

And this is where we've got to head.

Yeah, no, I mean, I think you guys started that with me as well, is that the product owner standing up and actually saying what the business problem they had rather than what they wanted to solve?

Because I don't know if you find it, Blair, but what sometimes happens is somebody in the audience will go, but what about this? Did we do this? And you really want the product owner jumping in and saying, no, I made a trade off decision. Right. Didn't have time. We had a team to deliver that didn't think it was important. Deal with it a different way. You don't want the team answering the whys or the what's, you just want them answering the hows. So again, but it depends on your product owner.

Yeah. If you've got a mature product owner, that conversation should be happening anyway, away from the demo.

But we all know that product owner is the one we deal with after we've helped the team or that product.

Owner is the one that's got five different hats and product owner is one of them that they've been asked to do.

Might be their first chance to have a chat with stakeholders.

So we rip through the rest. I mean, daily stand ups.

Apart from when they start degrading and going too long. What have you found? Everybody tends to do them.

Yeah, that tends to be the first thing adopted. I think like even, even my other half's workplace that's attempting to go agile, they've adopted the, the daily stand up. But trying to get anything else done is.

Yeah. And so, I mean I try not to be derogatory and we, we often do. What I say is you're being ad hoc and that's okay. Please don't say you're doing or being agile. But what you've done is adopted an agile pattern that helps us collaborate on a daily basis. And that's good. Right? Not having a one hour team meeting every week is the only way you talk to each other. Talking on a daily basis is great. That's a good pattern. But don't think you're attempting to be agile. Right. You need to invest in all the other behaviors before you do it justice.

But it is kind of cool. We're starting to see the same thing with groups that you'd never imagine adopting any agile disciplines. Having morning stand ups, HR finance, It's like, holy shit, this is great.

Yeah, yeah. And we're seeing more and more people around our floor with post its on whiteboards, moving them around.

I just see them as an audience that.

We could help. And they're making the first step on.

Their own because they're collaborating on a daily basis. They're visualizing who's working on what and having a conversation around those things and how they're going to move them and make them better. They're all good patent behaviours. But yeah, I think you're right. I think that means they're open to an agile mindset.

We can at least have a chat about what fluency they want to get to. They might just want that stand up a little bit more. It's like how far do you want to go?

Yeah, and that fluency model. But I think taking your point, getting across to them, that is an investment. It's an investment of time, investment in risk.

You have to invest into these ways of working to make them work. It doesn't just happen by magic.

Absolutely.

So don't understand it for me. I think the one for me is when the daily stand ups degrade, right. When they become half an hour or 45 minutes because people are deep diving, you know, all those behaviours. I think that's when that investment of time starts to get challenged.

Yeah, I think it's the, you know, as a scrum master, it's the impediment stuff that's really I find important there. It's like why didn't you get to what you had to do yesterday? It's because so and so came up and had a BAU issue that I have to deal with. Okay. I might just have a little side conversation with that person and just say look, we're on an important time frame here. You know, come and see me first and then I can manage it with so and so.

Yeah, I think our team are really good at stand ups and I guess it's the one thing that we've.

In addition to the retro which has been, you know, consistent across the whole five years and so yeah, we're quite good at identifying. Oh, let's take that.

Out of the stand up and talk about that separately. We'd say that most stand up somebody would say that and most. Yeah, everyone's pretty good at just keeping it reasonably short. So. So very rarely would we go over 15 minutes.

Just. Shane, what have you seen as the, you know, like the ceremony that's the most likely to drop off if people start waning, you know, sort of moving away.

It's definitely grooming. Grooming, grooming. Either we don't get there or we lose it. Then what I see is the planning sessions on the beginning get loose. So the cards are massive, they're not refined, there are no good acceptance criteria on them. Yeah, we kind of we actually do waste the time, we don't get the investment out of it because it doesn't help us execute better as a team. Retros.

Yeah, I was going to say retros for us, the first ones that dropped off really.

So for me, I don't think I've ever. I think I've become dictatorial. Retros are a given. Right. If you. If you're not doing retros then we just stop.

I've just never allowed.

But regular retros.

I've never gone back in to see if the squads are still going. So when you're away on leave, you're saying the team actually ran their retros without you and that was the one ceremony, apart from stand ups that they retained.

Oh no, sorry.

They did stand up Sprint planning retro and I think they were mostly doing one refinement meeting a fortnight. Yeah, yeah. So the only things that got dropped were not enough refinement meetings and demoing. Yeah, yeah, yeah, yeah.

I mean I've seen a lot of podcasts and reading I've done actually talks about when the team are really good at continuously improving what they're doing anyway, you can drop the retro because. Because with Scrum, what we're doing is putting unnatural constraints in. If the team are really great at continuously refining the way they work, you don't need a force me a forced time slot to do it. We put that constraint in of you have to turn up on this time to do it because we want to encourage that behavior and get better at it. So I don't know.

I'd like to say that was the reason why we got a bit slack with retros, but it was really because it was out of the whole ceremony suite that was the one that the team thought could be put back into coding and put back into.

Interesting.

Yeah. But we've soon realised that no, you have to have that self reflection, that continuous improvement.

I tell you what we do sometimes to try and switch it up. Cause I'm big on like keeping it interesting for the team.

Sometimes we do the kudos session where we might only spend 20 minutes rather than like a hot. Or actually maybe like last time we did 20 minutes of kudos and then like a half hour specific topic that everybody felt that we needed to talk about. But with kudos, I. I printed off, you know, the thanks. There's these little things that you can find online that have got thanks and you're awesome and well done and congratulations and it's just. It's just an opportunity to reflect, to get the team to reflect positively on each other.

Rather, because normally in a retro, it's how come? Oh, well, actually, you can combine a bit of, you know, like, what do we want to keep, what do we want to do more of? And et cetera. But more often than not, the retro will turn more into a, oh, this isn't working well. And that isn't working well. And so this is just an opportunity to switch it up and be really positive.

Yeah, look, I agree.

I think as Scrum masters or coaches, we have to mix the retros up over time. We have to introduce different ways of doing it. It's there to focus on what does the team want to do better next time in the process and what are they going to do to action there. One of the customers I'm working with at the moment, they did quite an interesting one where they found a sheet somewhere that has kind of.

Emotive words on it and colors and so it's. I can't remember whether they call it a team health check or anything, but you look at it and you go feeling, you know, excited or, you know, I'm feeling concerned. And so they actually do that at Sprint planning at the end of it, as a part of the closing out, the commitment to, okay, how are we feeling to get a sense in the room about, yeah, now this is a nice, safe one, or, yeah, this one's going to be gnarly. So, yeah, I think if the retro, if the team are calling out the retro doesn't have value. It's like everything that's going back to, okay, is it the way we're running the process that's not working? You know, it's degraded and not getting that benefit? Are they now mature enough that they're just behaving that way and we don't need an investment, an unintentional constraint to put it in place or, you know, do we need to change the way we're running it? Because we're not getting the benefit out of that time investment that we should be in that.

And once we started the backup, it was like, shit, why did we stop doing this? It's great.

It's probably the Scrum Master's fault.

Yeah, you let stuff ride sometimes. Right. And I think coming back to your point, Joe is saying to them, I want you to give me permission to run it for a little while. And if at the end of that we do a retro on there and you say it's not adding value, then, okay, we're going to have a conversation about how we get those benefits in another way. But often when they give you that permission and you run it, they come back to. Yeah, that's actually helping.

Actually, one thing I've found with people who do question the retros is that often things are always coming up on a day to day basis in the daily stand up. And that's an opportunity. Like, you know, like issues that crop up, somebody will bring them up at the daily stand up. And that's the perfect opportunity I've found to then say back to the team. Well, the retro is the perfect opportunity to discuss this further. And then you kind of reinforcing.

The benefit or the reason why you have a retro.

Yeah, no, it's good. It becomes your parking lot. Right?

Yeah.

As long as they do bring it to that session and they do raise it and then they do work on a plan to resolve it also. Fine. Bringing food helps.

Yeah, well, we use cake for the, for the, when we do the scoring of the stories.

Oh, okay.

If we get a consensus three times, so everyone says eight for the story set, you know, 13. I have to buy the cake as Scrum Master.

Oh, wow. I don't want to do that one. I'll be buying cake all the time.

Well, that's good.

I can't game it. Yeah, no.

You see some gaming coming in, like they'll reach over the table and say, so is this easy or hard?

And they've got code for hard equals 20. Easy equals 2.

I do know what I did the other day was so new team and as new teams do over committing to what they could deliver. And so I was applying a little bit of the Scrum Master role where I was going, are you sure you can deliver that? That looks like a lot, right? Are you sure? And they're like, yeah. And they keep wanting to bring more in. And I had to close it and say, look, in terms of the way we point it, you're full. Oh, we can do some more. No, you can't. No, we can. So I just said, okay, leave that on the iteration backlog. If you complete all those other things and you bring those in and complete them, I'll show sausage rolls and cake.

Now what happened was I didn't write an acceptance criteria down. So I thought I was very clear on what the acceptance criteria was. When they finished the iteration.

They deliver one IP they had committed to multiple information products. They delivered one information product and said I owed them sausage rolls and cake. And I went, no, you had to deliver all of them that were in there.

So you were safe you were never.

Going to deliver on your. Oh, yeah, that's what they said, actually. So I went, okay, retro for me, write the acceptance criteria down very, very clearly. So I half paid out, so it's always okay. Excellent. All right, well, it looks like a good session. I'm pretty excited about that. Again, it's all things I think we've known, but we've never really talked about. So I think there's some good learnings out of there and some good ways of explaining to new teams or stakeholders or product owners around why we spend this time and invest to get that value.

Yeah, thanks, tips, guys. Some really good tips to take away as well.

And for those that weren't here when we weren't recording, which is all of the rest of you. Yeah, Joe came up a really good idea about creating almost a bit of a coaching circle where we can get guests together and cover a subject that's concerning one of us. So we might see how we can lock that in. So if you're based in Wellington and you're in the world of agile and data, get hold of Blair and myself if you want to come along and have a chat with us. Right. We'll catch you all later.

Right. See you.

See ya.

You've been listening to another podcast from Blair and Shane where we discuss all things agile bi. For more podcasts and resources, please go to agilebi guru.