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 Tempro.

And I'm Jo Shrigley.

Hey Jo, 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 who 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 sort of 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 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, you know, 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 show, "Oh, this is it half done. What do you think of this? This is it 3/4 done. What do you think of this?" And so, yeah, 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 maximizing the team's knowledge in order to create a smarter solution and also minimizing 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 my— the current place that I work, when I, you know, right back when I first arrived, No one in the team knew 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 in our team, all the benefits, you know, 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, you know, the whole team more collaboratively and more iteratively working with customers. All that's come to fruition.

Awesome.

Okay. So, yeah. Cool.

So what's your role on the team that you're working with at the moment?

So the, 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 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, you know, we can all see that the peer review is the next thing that needs to be done, then I will proactively say, right, okay, who, is there somebody in the team who's willing to take up that, you know, 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 want to talk about today is the kind of topic you picked, which is one that, which again, another topic I love, is this idea that when you start off with a new team, so you're going into an organization or into a team that hasn't started their Agile journey and you're taking a Scrum approach, and when you look at it, there's a, like you said, there's a bunch of ceremonies that we run because they have value, right? I think the word you used was investment when we talked about it before, and so they take time, and for that investment of that time, there are some benefits, and we're about investing time we get the downside of those things not happening. But often the teams come into this agile way of working thinking, you know, there is no documentation, there is no meetings, you know, the things that everybody advertises, or that advertise, so people focus on as some of the negatives sometimes. So when we say, hey, you know, if you're running a 3-week iteration, The morning of the first day, we invest time in planning and committing what we're going to deliver over the next 3 weeks. At the end, we do a demo or a prove-it where we show them 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 our planning and and estimating, you know, we do daily stand-ups 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 behavior for 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 already, 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 things things in a particular way. So I've never been 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 carrot and— or the, you know, is it stick approach?

Well, the dictatorial, the old shout.

Yeah, yeah, yeah. And people do that all the time because it takes longer to do it the way of getting people's buy-in to 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 2 hours and everybody would just be at their wit's end because who want, you know, how can you operate effectively in a tense 2-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 who wrote the story and put the story in would have to explain it to the rest of the group. And then it would be like, there'd be lots of questions about, so why would we want to do this story? And, but we've already done this before, or those kind of questions. And 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 fresher, yeah.

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 retrospective 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, 2 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.

Really? So you gave them the chance to opt out if they didn't see the value?

Yes. So I said, at least if we've got 4 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 certain people to, you know, 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 they opted out. But if they saw their colleagues, if they saw their team members going to it, seeing, 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, that refinement session, you're either going to slow the team down by, you know, 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 exactly And that's exactly 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 the 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 have you?

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 organizations with these digital teams, and they're inherently running from an agile point of view anyway. So they've got UX designers in there, 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, it was 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, you know, it can change, but it's that reinforcement, you know, visually we've agreed that you don't go to planning, you can't relitigate a lot of the questions and fill in.

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 held people to task if they actually showed traits of the negative. So that could build into a contract or not a contract.

So a team agreement is a form of contract, right? Yeah, 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, yeah, 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, right, 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, you know, all that complexity is all done in 2 to 4 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 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? Yeah.

Oh, sorry, the refinement ceremony. Where else have you seen it?

Oh, look, we run 3-week sprints and we have 2 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 you, 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, you know, 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 there was a good point there again that I hadn't picked up on. So you're running 2 iterations ahead, right, your time horizon for refinement.

S-1, S-2.

Yep, but what you're also doing is you're bringing the product owner in, if they haven't been a product owner before, in before the iteration starts.

Yeah.

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.

Yeah, 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 timebox what we're actually going to do for those next three weeks.

That's a good point.

We're saying, you know, if you're not sure what's next, You know, you've got 2 weeks to sort it out. So that's a bit of gold too.

Yeah, that's good. Because you're refinement, how many time horizons ahead are you? Are you still, are you planning the next iteration, or are you trying to refine a couple here?

Yeah, we are mostly still in the only planning for the next sprint. But, uh, 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 3 or 4 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 refinement 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 3 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 3 epics are just far too big for one sprint. So you're automatically moving into S-2.

Another good point about that, which just tweaked me thinking about it as well, is by refining early, we can find those stories that are 40s, right, because the team don't know how to decompose them, right, 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, you know, it becomes obvious, look, this big thing is too big and we don't know how to decompose poses. 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, yeah, so to take your point, I don't use a 5-minute time limit, but I unconsciously invoke one at some time when I find they're 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 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— yeah, we might be arguing to get it from a 5 to a 3, or we've just got this little pet peeve, or we're really interested and we just want to discuss it.

Yeah, yeah.

It's not— that's not the point of refinement. It's to get it down to a small enough chunk the way I work it is that, you know, in theory, that task can move in a day. It'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 They get on though. Yeah, I know, but they, 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 5 or a 7 or, is there a 7? No, a 5 or an 8, 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 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 going 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's 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, you know, but we're going to take a punt, right? But what we say is do the 40, the 20 first, right? Don't leave a 20 to the last part of the iteration because you'll fail. Bring it in early, right? You know, if it's below 20, if it's a 13, you know, and then 8, you know, so, you know, where we really want to get to is more of a Kanban approach where every card's a 5 and a 5 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 1 for a whole raft of reasons.

And with, if you have 2 refinement sessions during the 3-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 2 sprints because I use that opportunity to, with the product owner's agreement, and we found that this 20 is just massive and it's actually a 50 or whatever.

It's 100?

It's 100.

It's a question mark.

Then we're not shy of changing the whole, so it's the first or second, yeah, we've got 2 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 2 you know, 2 tens or whatever, and then bring in that— the bit that's left over will go into S-1, and then we say—

or not, right? Or not, because what you're saying is the 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. Yeah, 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?

Yeah, you're doing half or nothing. Yeah, there's choices. So if we go from there and we jump into So, refinement for me, yeah, solves a lot of problems. I think we've seen this. 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. 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. They can't, 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 prioritize 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—

Product owner.

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.

Hmm, how come?

And the re— I actually have made a specific decision not to do that because we're doing so So many different things for diff— 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 backend, what do you call it when you improve some code that you've written in the past. And so, yeah, so in any one sprint, we will have between 5 and 20 customers. So that's, I guess, direct and slightly 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 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 less, 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.

Okay.

So over the next week or so.

So you still demo?

Yeah, yeah, yeah.

So let's explore that a little bit. So for me, the demo has been really I call it a preview session, man. I call it a preview 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 we, if we're doing our first exploratory type of delivery, we're kind of data and code heavy and, you know, 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, that 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, um, 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, right? 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 what's running. The first person takes up all the time, everybody else, right? So they learn and they start adapting to doing a bit of a an agenda for themselves, right, 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 in this new way of working, and that investment in their ability to fail, actually helps. The other thing it does is is after 2 or 3 iterations, that stakeholder, if they're not at those prove-it 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 it's— people, for some reason, they have this natural 2 to 3 iterations, which for when I do it's 9 weeks, that's enough, right? We should be absolutely hard in the rock in it. As soon as they come to approve it, they can see which bits are hard in which bits are still risky. So they, their risk profile, you know, they'll back off a little bit. And it creates a really great value conversation around that. I like this idea of investment, it's so easy, 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 space, 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—

Yes.

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 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, ah, 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 one information, right? What that means is people don't know what exists. And yes, we're doing data cataloging.

That's true.

But often we'll hear the words, oh my God, I didn't realize we had that customer data already.

Yeah, yeah.

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 Oh, right, 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 will 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 that, 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 the 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, right? And that's really interesting dynamics, but they're both okay, right? If the product owner is comfortable with 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 grabbed the data and actually showed what 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, you know, it was quite a complex model and they were like bang, bang, bang and that. But yeah, so I think that's okay, is what you said, you adopt the behaviors of these agile approaches and patterns in a way that fits you. BI and data is a little bit different, so yeah, I don't know, I'd suggest maybe do it safely, right?

Definitely something to think about.

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

If it doesn't work, stop it, right?

If it works, carry on.

Yeah, yeah, but I really like that idea of— I completely agree about the fact that, yeah, a team will definitely, you know, couldn't leverage off what another team's 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—

And actually, sorry, that tweaked 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 pre-viz, the documentation. Like, documentation, sorry, before I— don't underestimate the value of showing a document that you've written.

I love that.

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

Yes, so the beginning could be all the changes to apps that we've made. First half or whatever. Second half is, you know, 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, so you won't get upset.

So you could also do Gamma 2 halves with the Product Owner. 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 hear.

Yeah, 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 was and what they wanted to solve. Because I don't know if you find it, Blair, but what sometimes happens is 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. Didn't have time, we have 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 whats. 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, 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 5 different hats, and product owner is one of them that they've been asked to do.

Yeah.

Yeah. It might be their first chance to have a chat with stakeholders.

So we ripped 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 my other half's workplace that's attempting to go agile, they've adopted the daily stand-up, but trying to get anything else done is—

Yeah, and so I've tried, I mean, I'm I try not to be derogatory, and we often do. What I say is, 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 1-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. 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.

Absolutely. Yeah, yeah. 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.

Yeah.

And they're making the first step on their own.

Yeah, 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 pattern behaviors, but yeah, I think you're right. I think that means they're open to an agile mindset.

Well, 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 it is an investment. It's an investment of time, investment in risk. You have to invest into these ways of working. Working to make them work. It doesn't just happen by magic.

Absolutely.

So daily standups for me, I think the one for me is when the daily standups degrade, right? When they become half an hour or 45 minutes because people are deep diving, you know, all those behaviors. 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? Oh, it's because so-and-so came up and had a BAU issue that I had to deal with. OK, 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 That's the one thing that we've, in addition to the retro, which has been consistent across the whole 5 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-ups, somebody would I would say that. And most, yeah, everyone's pretty good at just keeping it reasonably short. So very rarely would we go over 15 minutes.

Just Shane, what have you seen as the ceremony that's the most likely to drop off if people start waning, 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, they're the first ones that dropped off.

Really? So for me, I'm I don't think I've ever— I think I've become dictatorial. Retros are a given, right? If you're not doing retros, then we just stop. I've just never allowed—

Regular retros?

I've never gone back in to see if the squads are still going. So when you're away, you know, on leave, you're saying the team actually ran their retros without you, and that was the one ceremony apart from stand-ups 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 Some of the 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 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 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— Wow.

Interesting.

Yeah, but we've soon realized that no, you you have to have that self-reflection, that continuous improvement.

I tell you what we do sometimes to try and switch it up, because I'm big on keeping it interesting for the team. Sometimes we do the Kudos session where we might only spend 20 minutes rather than like a whole— 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 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 can— 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 etc. But more often than not, the retro will turn more into, 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 their process, and what are they going to do to action that. 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 colours. And so it's— I can't remember what they call it, whether they call it a team health check or anything, but you look at it and you go, 'I'm 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, 'OK, how are we feeling?' To get a sense in the room about, 'Yeah, no, this is a nice safe one,' Yeah, this one's going to be gnarly. So yeah, I think if the team are calling out the retro doesn't have value, it's like everything. It's going back to, OK, is it the way we're running the process that's not working? 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, a financial constraint to put it in place? Or 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.

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

Yeah.

It was 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 that 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're kind of reinforcing the the benefit or the reason why you have a retro.

Yeah, no, it's good. It becomes your parking lot, right? 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 find bringing food helps.

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

Oh, okay.

If we get a consensus 3 times, so everyone says 8 for the story, 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 I've got code for hard equals 20, easy equals 2.

I tell you what I did the other day was, so new team and they, 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 at it, you're full. Oh no, we can do some more. No, you can't. No, we can. So I just said, okay, we'll leave that on the iteration backlog. If you complete all those other things and you bring those in and complete them, I'll shout sausage rolls and cake and that. Now what happened was I didn't write an write the acceptance criteria down. So I thought I was very clear on what the acceptance criteria was. When they finished the iteration, they delivered some of the— they delivered one IP. They had committed to multiple information products. They delivered one information product and said, "I owe them sausage rolls and cake." And I went, "No, you had to deliver all of them that were in the IP." So you were safe, you were never going to deliver on your— Ah, 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, alright, well it looks like it's 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 heaps guys.

No, no, no, thank you.

Some really good tips to take away as well.

Excellent, so did I. Yeah, and for those that weren't here when we were recording, which is all of the rest of you, yeah, Joe came up with a really good idea about creating almost a bit of a coaching circle where we can get guests together and cover as 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 or myself if you want to come along and have a chat with us. Right, we'll catch you all later.

Right, see ya.

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.