AgileData #7 - Innovation Iterations

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 another Agile BI podcast. I'm Shane Gibson, and I'm Blair Tempro, and today it's Blair and I having a little bit of a chat on our own, and we're going to cover off a little bit of work we did a couple of years ago at Blair's place where Blair and the team decided to have a bit of a go doing what I would have normally called a FedEx or a hackathon, but which they called Innovation Day, uh, Sprint. So, yeah, the whole process of giving the team some time to decide what they want to deliver and letting them go wild.

Yeah, so we sort of called it a mix between Dragon's Den and a hackathon, so bringing those two things together.

And Dragon's Den because?

Oh, because we had to sell our idea to a bunch of executives and yourself, Shane.

Yeah, so that's what I found really interesting was at the end of the process, the team actually had to effectively stand up on stage with a bunch of the senior executives from that organization and show what they had built and try to effectively sell the value of what they wanted to do. So they could go and actually harden that code or visualization or data or whatever it was that they did?

Yep. Yeah, definitely. So it was good to know that all of the ideas were endorsed, but jumping to that first, we didn't really doubt that that would happen, but 'cause there wasn't true cash being thrown at these things, but—

Do you find though that by setting up early with the team that there was this dragon's den at the end of it, right? That they had to present to— to a group of people outside of the team what they'd done and where they saw the value if they carried on. Did it help them focus on being done done by the end of it?

Oh, absolutely.

Yep.

Yeah, so we had an end goal and we knew that we had a week to do it, and so there was no sort of farting around. We just had to get stuck in with the end goal, and the best part of it being presenting to to the C-suite plus yourself. So, yeah, I definitely think having that end goal of the presentation kicked us along.

And normally hackathons are normally a day, right? So we talk about FedEx or hackathons or those kind of things when we look at startup or companies that do that, they normally only spend a day on it. We picked a week because?

Oh, we thought about a day and going overnight, but we had some team members that had new babies and all sorts, and we had BAU. So we, we kind of mixed it with BAU. We had to, right? We still had to keep the lights on, so it was important that we split time between, you know, your team concept and, yeah, essentially keeping the lights on. So that's why we came up with a week. We were thinking a longer, but we just couldn't sell that.

Yep, yep. And so, um, so in retrospect, was a week too Too long, too short, just right?

I thought it was just right because we did keep the lights on and we did come up— everyone did come up with a presentation. And it was a tough week, don't get me wrong. It was, um, yeah, so we decided what members would go into what team. It's a kind of social experiment. We wanted to see how certain members worked with others, so it was really sort of a Yeah, that was a bonus. Yep, so we formed the teams, put them together, said come up with a concept. So we had the first session was to report back just on the theme that you were going to work on, just to make sure there was no duplication. Yep. Make sure that everybody in the team was along for the ride.

And so one of the things we did was we said, well, how do we help the team through their ideation, right? How do we How do we let them actually go through a bit of a process themselves to figure out of all the ideas they have, which one do they think was the most valuable, the most achievable in that time frame. And we kind of used innovation canvas, so we kind of talk, I can't remember if we took the Lean or the Business Canvas.

It was the Lean Canvas that I used.

Yeah, and we use that, so each team really had to fill out the canvas at the beginning to help them form and collaborate and have that conversation about what they were actually going to work on. Did that work as a concept?

Oh, absolutely. I think it was just a central point that we could put our goals and the purpose of the sprint, you know, who are the people, what are the resources that we need, and we also got into the costs. Hypothetically, this would cost 3 sprints. We'd need a product owner, that sort of thing. So we actually started to formulate a plan.

Right, so looking to saying if it got approval to go forward, actually what do we think? And did we, so that estimation, was that done at the beginning of the innovation sprint or at the end, or did we do it at the beginning and then kind of update it at the end?

We did it at the sort of in between. Yeah, so after we'd got our proof of concept decided, It would have been a useful exercise actually to go back and see which ones we put into production. Were our estimates right?

Yeah, yeah, well, how wrong were they, right? Estimates are never right. So one of the things I found interesting was the number of teams, right? Because you formed quite a large number of small teams. I can't remember how many.

Yeah, there was I think there were 5 teams of 4 and 5.

Right, so again fairly small scrum teams, still got a really good mix of T-skills, but yeah, having 5 teams racing each other.

Yeah, it was pretty intense. So we tried to mix it between the people that had done scrum before with those that hadn't and kind of leverage the experience of those that have been in a scrum team a sprint team to kind of take the lead.

Actually, I forgot about that because at that stage we'd only been running one Scrum team, right?

That's right.

I can't remember, it was like 7 or 8 in the team, wasn't it?

Yep.

And then the rest of the team was stuck in BAU land trying to manage the BAU bleed and do that. And yeah, so actually this was a great way of getting those team members to be able to come in and actually have a go, be part of this new way of working and see how they thought. Yeah, I forgot about that.

Yeah, so that was actually—

How'd that go?

It was interesting, and I'll get into that a bit further, but yeah, I thought that the concept of me being in a team was really interesting for me. And I wasn't allowed to be Scrum Master. How did that go, you might ask?

Really badly. Because you're back on the field, right?

I'm back on the field. It was really hard to take that hat off, especially where I saw situations where I'd normally jump in and mediate or facilitate. It was tough, man, just to stand back and go, we'll see what these guys come up with, especially when there was conflicting ideas.

Did you find that somebody else in your team jumped in and started to fill that Serbian leader role, or?

Yes, at the start, and our team was interesting. I don't know if you remember, but we came up with an idea of loading click incrementally rather than do the full load, full load. We had two conflicting ideas.

Yep. Ah, yep, I knew that.

Remember our one? So I had to step in as drum master. No one had the experience of bouncing two ideas and coming up with a compromise, which we did. We came up with, we presented two ideas. We just could not break that.

Yeah, that was interesting because your team split into two teams of two effectively and then had a race to see which idea— and both got to the finish line where both ideas were presented, both ideas were viable. Yeah. They were just different opinions on which was the best.

Yeah, just that the actual date BAU hats that those two members wore, they came from different areas.

Yeah. And some of the other teams, did you see somebody kind of step up as the servant leader, as the quasi-scrum master to help guide the team?

In the limited time I got to see other teams actually interact, because I was part of our one spending most of the week bouncing those two ideas around before we came up with the idea, hey, why don't we do both? That was the last resort sort of thing. Well, yeah, obviously the individuals that had been sort of in a leadership role in the scrums were the ones that came to the fore. Okay. It was a really good experience to see how they did act in that Scrum Master role, because the Scrum Master can't always be at ceremonies. It's good that he is there, or she, but just to see how they would act if they had to just sort of like be that person.

Yeah. And so do you think if you did it again, from a retrospective point of view, would you recommend that actually there still was a scrum master role across all the teams that sat outside off the field and were just helping the teams, you know, guide the teams, especially because you had new team members who'd never done it before coming in, mixing with people who had been part of the first core scrum team, and then just giving them that little bit of guidance in that week. Do you think that would have been helpful?

Yeah, absolutely. And now that we've got more and more experience in the Scrum Master roles, I think it would just come along a lot easier. But, you know, struggling for this one was useful as well.

Yeah, it was a good experiment to start early, right?

Absolutely.

And then, from memory, we didn't really run the ceremonies. I mean, we did the— I'm assuming each of the teams did daily stand-ups. Yeah. But we didn't really do any kind of play, you know, backlog grooming or sprint planning right at the beginning. It was more of an ideation That's right. No real estimation, and we didn't do retros every day. We didn't take the normal 3-week cycle and try and compress it down into 1 week with a couple of iterations. We kind of just gave them a week and let them go.

That's right. Yeah, I guess that came down to time. We had a week. It would be useful to try it with all of the ceremonies, you know, half an hour backlog grooming. Other than an hour. You know, the daily standup would obviously keep going. Yeah, it just came down to, you know, this is going to be sprint with a mix of BAU in it, so let's spend as much time developing as we could.

Yeah, and again, it was an experiment, right? So experiment, learn, retrospective, change how you do it next time. Yeah.

We did have demo days, sort of, well, where we'd go into a room, each team, and switch on a PC and go over what they've done.

Okay.

Yeah, we certainly did.

Yeah, yeah.

You know, open up SQL, run what you've done, open a spreadsheet, that sort of thing, yeah.

Right, so kind of prove it amongst the team to give you a checkpoint of where you're at and so. And how much time did that take? Because again, you're fronting to people outside your team.

So we started to talk about it really early on how we were going to do it, but it was only the content came because we came up with the idea of two methods quite late. We had to rush it. Yep. But the other teams put a lot of work into the presentation as much as you can could in a week.

Yep.

Yeah.

Yeah, well, that definitely came across as polished.

Yeah, yeah, it was a lot of fun.

It didn't seem like anybody was standing up doing it for the first time.

No, because there was that internal pressure, right? So you didn't want to be that team that failed.

Yeah.

So that's the beauty of the competition.

Yep. And how did you manage that? Because now what you had is 5 teams competing in front of an audience. Yeah. That Dragon's Den thing brings in a natural sense of competition, but it's got to be safe.

Oh yeah, it was safe. I just, you know, coming from a sporting background, it was just great just trying to kick some ass.

Yeah, but I think, you know, if you think about it, if you're doing it where maybe, you know, the organisation isn't as safe as yours was, or the team's not as safe or well-formed, then there is a risk that actually could get bad behaviour. Yep. So—

But we did have a So the boss was in an observation-type role over the— and in our innovation sprint planning, we had regular check-ins.

OK, so there was somebody sitting outside of it monitoring the process, keeping an eye on it from a pastoral point of view, making a personal care point of view, making sure that as the fact that you're experimenting for the first time, it's safe and everybody's OK. Oh yeah, that's good. So I think that was one of the key things from our perspective, right? Absolutely.

And we called that a check-in.

Yeah.

So it was just a visit from the boss.

Yep.

How are you guys going?

Yep.

And we, yeah, so we shared with myself, I was sort of running it kind of behind the scenes.

Yep.

Where people were at certain times for their ceremonies, for their, kind of a mix between a backlog grooming and a morning stand-up, so you might have it at 3 in the afternoon. Right. Yep, and then, so we'd turn up with lollies or sausage rolls just to keep the ball rolling.

Yep, yep, but also just make sure that everybody's okay.

And I talk to every scrum master, in inverted commas, and just to keep a check on how things were going, because, you know, there's a potential for things to go wrong.

Also potential for people to overwork, right? Because it's a competition, you know, going to those silly 16-hour days just to try and get over the line where actually, you know, yes, there's some— the point is to produce something of value at the end of that week to show something that could work and what's left to be done. But it's also a bit of fun, you know, a bit of a letting steam off a little bit for the team that they're not in that constant sprint cycle of delivering to a product owner. And so on that, did somebody end up in the team becoming almost a quasi-product owner, did you find?

Yes, it was probably the person whose idea got chosen, or two ideas. Two product owners, we know how well that works.

Yeah, that's right. Well, I suppose, but in your case, you had two teams, you just had very small teams. So there was one product owner with one team, and again, that's a It was just a very small team of two.

So yes, just organically it went to the person whose idea was adopted. And I think in hindsight, we should have chosen ideas that involved the whole team because a few of them actually didn't embrace the whole team. So we didn't have everybody involved for that whole time.

Right.

Yeah.

Is that because they were doing BAU or because they—

No, it was because—

It wasn't their idea.

Well, it was something that only one person could do. They went away and wrote some code. We tried to get peer programming as much as we could. But yeah, I think the key next time would be come up with an idea that has everyone involved. So find a role for everybody at the start.

Or maybe you actually bring in product owners.

Yeah, yeah.

Although then the team don't get to choose, because one of the things I was really interested in was Some of the teams picked automation of the platform. They, they, how would I describe it, they looked at a problem they had, what they were doing in their process, and they chose to focus on fixing that. Yeah, yeah. Whereas some of the other teams went and said, well, we have this wealth of data and we have this really interesting idea on how this data could be used from an analytical point of view to make better business decisions. Decisions, but it's never been prioritized, you know, it's not coming from a product owner, it's our idea, so we can't work on it. So they made it more data analytics-centric content delivery. And so it was interesting that both of those kind of flavors came through. I suppose if we went and got external product owners to come in the team, it's always going to be kind of data and analytical focus, content focus, not automation of some of the processes that are frustrating the team. So, probably in hindsight, yeah, maybe bringing in an external Product Owner is not a good idea.

Or you could see what your ideas come up with and whether they warrant one and bring them in. I'm not sure. Or do they come with the idea? We'd have to think about it, how that would work.

Or do we actually say that, you know, you are forming a team and one of you has to adopt the Product Owner role. So if it's your idea, you that the team accepts as the one they want to work on, you're now the Product Owner, which actually means you're not on the field. So, the interesting thing there is that that team member will experience what it's like being a Product Owner, where you have to, you know, say what's important and encourage the team to deliver the bits of value. That would be quite interesting, wouldn't it, because now you're learning another role.

Absolutely, and you'd have to go away and talk to stakeholders and come back. It's quite a good time for us to be talking about that with having product ownership being on the focus. So yeah, it would be awesome.

Yeah, so maybe another innovation sprint, but this time each team have to allocate a product owner and then get a little bit of product owner coaching as part of that. As a way of feeling the pain of what a product owner goes through. Scrum Masters do —so yeah, that's right, good learning by doing. I suppose then you could actually, again, say each one of those teams have to select a Scrum Master who fills that role and again, you know, gets a little bit of cross-skilling on what it's like, but also get to feel the pain of being the person in the room standing behind everybody going, "Are you sure that's as easy as you say it is?" Exactly, that's not what it's easy is in the manual. That's right.

So in terms of Scrum Mastership, before the week started, I did a presentation on what role the Scrum Master has in it, in the development, sort of to give a tease to somebody that might think that that's a great idea. I had a couple people coming up to me after that saying, you know, in the Innovation Sprint, I really hope I get a chance to to be the Scrum Master, and they did. They realized how hard it was.

Yeah, so do you think that was because the people coming into the teams hadn't been involved before, so you had to give them some upskilling really early, just in time to say, well, when you hear these words, this is what it means. So it's kind of, you know, the Agile way of working 101 for your team. But if we had people that were experienced and being a team member, would we still do that? I think we would.

I think we would. I definitely think we would because most of them have been experienced developers, experienced BAs. They've seen us at work with Scrum Mastership and Product Ownership. But yeah, I think an overview would be perfect.

And it's really interesting, I was just kind of thinking about that. So I'm coaching two different teams from well, two different customer groups at the moment. And so one of the customers I've got one team, and with the other customer we've actually ended up with two squads, right? So again, challenge starting off from scratch with two squads at the same time rather than starting one and scaling out. And you remember when we kind of moved from, with yours, from one Scrum team to two, and we kind of split the team to see what would happen if we half-filled it with experience. We knew we'd lose velocity, but it was a way of onboarding the new team members safely, we thought. So I've got the same problem with these two customers in that as the team starts to rocket and we look at the product roadmap and the promises of what needs to be delivered over the next 6 to 12 months and the release promises over the next 3 to 6 months, There's a mountain of work there, right? Both of them are replatforming as well as re— so effectively replatforming the data analytics environments while trying to decommission the old environments while trying to build new for the new strategic, you know, high-priority information products. And so there's a mountain of work there that, you know, the team—

will they be sharing the duties, or is one team going to concentrate on a certain—

So for the customer there, we have two squads. They're just going through that now. They're working through— we have enough of a product backlog that they can separate and focus without a lot of clash. However, because the platform hasn't been built, they have to incrementally build out the architecture and the platform and the DevOps stuff as they do it. So they are kind of codependent. But my thought goes, as they want to scale, you know, as we want to go from 2 squads to 3 squads, or from 1 Scrum Team to 2 Scrum Teams, how do we bring the new people on? Because we've been going on a journey where, you know, we've been learning the language, we've been learning the ways of working and defining that, and to bring new people in, they've got to get up to speed with that before they even start to kind of adopt that behavior. So thinking about it, actually running an innovation sprint, right, as a way of saying, actually, come in, we're gonna do it, we're gonna split the teams up, we're gonna run an innovation sprint for a week, so a bit of fun, but actually one of the outcomes we want is you start being immersed in the language and the behavior in a safe way. Yeah. We're not aiming for, you know, done done, out the door, value to a stakeholder with a product owner champion for that value, we've got a little bit more of a safety net for you to learn the process. To prove the concept. Well, it's a— I wouldn't call it a proof of concept. Well, you're not going to be proud with these things. No, so I wouldn't— yeah, we still have to say you have to produce something of value, right? You can't just spend a week mucking around and not prove anything. But I think the canvas and the Dragon's Den basically sets it up right in the beginning. You're going to plan and agree and and at the end you've got your demo day effectively where you're showing what you've done. So you have to show the value you've got to. But maybe it's a way of engaging, you know, scaling where you can safely bring new members on and quickly have them learn the way of working or start that journey in a safe environment.

Yeah, it could be just that.

Yeah. Yeah. Okay, I might, uh, you might do it. Oh, once we get to a stage where we're going to start. You've seen the canvas? Yeah, I've seen the canvas. And I think we We should be okay for maybe taking anything that mentions where you work out of that, but actually—

Oh, this is actually a blank one. I sent you a working one.

Yeah, so why don't we take the blank one and we'll upload it as part of the podcast and put it on the agilebi.guru website if somebody wants to download it and use it. Yeah, we found it really useful.

You know, the unique value proposition that you're aiming for, people, as I mentioned earlier, channels, you know, the path to customers. You're going to use Clicky, you're going to put it online. Key metrics, that was an interesting one. You know, with our innovation, we were going to hopefully speed up the load and put less pressure on the system each day. Things like that. You know, if you're putting it to a panel, they just want to see what you're going to get out of it, right? What value are you going to— Yeah, yeah. Why would we invest? So that was where the Dragon's Den thing really came in handy, actually putting some value on it.

So out of interest though, hard question, how many of those 5 products made it to another round of investment?

None so far. They were ideas from us, right, not the business, so we've been on the business business timetable ever since. Another idea was to stop, pause, and do some of our own stuff. We haven't had a chance to do that yet.

Yeah, so we've never really— you've never gone through any kind of technical debt sprint? No. And that's one of the challenges, right, as you start delivering that value out to the business stakeholders. Yeah. They want more. And yeah, so what I'm, you know, kind of retrospective of that for me was And I'm not sure I've got it right yet, but every new team I engage with, it's saying actually we need to set the cadence of that technical debt, that time where as a team you can focus on automating some of the things that you know you need to automate that have value for future iterations. But, you know, a product owner, if they have a choice between you automating a little bit more what you do or them getting another information information product out that helps answer business questions better, they're going to choose the information product every time, right?

Absolutely. But if we built into our timetable some of our own stuff, we could actually use the innovation sprint as a template for a bit technical debt sprint quite easily.

Yeah.

It would fit like a glove, really. You'd look at all of the same things, you know, costs and key metrics. What are you trying to get out of this? Product owner would be interesting. It might be the DBA.

Yeah, so you'd have to say that it can't be something that's data and analytical content out to a business stakeholder. That's right. So it can't be one of those. It's got to be something that makes the process or the platform or what the team does on an ongoing basis faster, safer, you know, less risk, all those kind of cool words. So yeah, it's got to be a way of adding value by making what you do a little bit easier, a little bit—

Yeah, and we've got a backlog of technical debt that we've left behind, so I've actually got it sitting there. We know what we've got to go back and fix, right? But it hasn't broken things, so it hasn't been fixed yet. Well, that—

and that's the other question, right?

If it's taking up resources but it hasn't broken anything, so where's the— where's the line there?

Yeah, but if those resources were freed up from those manual turks or those BAU bleeds, then in theory, yeah, they could deliver more to, to the business.

So yeah, it'll just be a case of maybe going through that backlog and doing some value mapping. What's going to add the most benefit by getting fixed or done, and then just prioritizing. Yeah. Would need an internal product owner to do that.

Well, what I was— I kind of, yeah, just thinking about what you said there. If we take that Innovation Canvas and we focused on the metrics for what the team would deliver, and the metric has to be about more efficiency or safety for the team delivering in the future. So if that was the key metric, then actually having an iteration where the teams that they are going to get something production-ready, right? So it's not so much a week to have a quick go and then get investment for another round, it has to be done done. But the definition of success, the acceptance criteria, is you've set an expectation, a hypothesis, that this investment will make releases take 20% of the effort that they take now. And so you can measure that, right? And then by doing that, you can go back to your stakeholders and say, we invested, you know, 2 to 3 weeks, we whatever the iteration timeframe is, to deliver, you know, an 80% saving for this piece of effort going forward, and actually, here's the proof. Here's our releases.

A lot easier to prove than we're going to produce a product that will make it easier for our teams to make business decisions. Like, what does that mean?

But, damn, if you think about that, imagine having to quantify quantify the amount of time you would— so just use that release example. Imagine having to quantify how long it takes us to do a release and estimate or guesstimate how much time we'd save if we automated it. That would be— I mean, I'd struggle to do that.

Yeah, so we'll do a technical debt sprint after talking today.

Based on using the Innovation Canvas and key metrics of— and then by doing that, each team will still naturally compete, right? So they'll pick something that they know. So actually, if you think about that, what should happen, right? What we should see is the teams pick the cherries, right? The easy ones. They're gonna look at their processes and they're gonna say, you know, this thing over here takes us a long time in terms of effort and it shouldn't. And actually our ability to, 'create some automation to take a DataOps approach to that' is something we probably can do in 2 to 3 weeks. And actually, when we do it, we're going to knock off a massive amount of effort off that puppy going forward. So our metric, if we compete on the metric, will actually hit the low effort, high value things naturally. Because who's going to know where they are? It's the team that actually struggle with them or spend that time on an ongoing basis.

They know where those things live. Yeah, and that's why I think that a product owner within this, whether it's the DBA, whether it's, you know, the Chief Data Officer, whoever, working with a BA, doing the value mapping of what's going to add the most value, and we're going to go with that one within each team. So that's what we're learning at the moment. Value mapping.

So actually, yeah, bringing in value stream mapping for the core process that they do would then enable you to quantify the metric of effort at each one of them, or the latency at each one of those steps, which would then let you actually identify the high-value one. And then if you had a look at it and compared it to the effort to automate, you should be able to come out quickly with something that says, that one is the part of that value stream that we want to work to make next.

Absolutely. So technical debt has a purpose to speed things up, to improve. The innovation sprint had many, many, many reasons for that, passing over the skills that the Scrum team had learned across the whole team, seeing who works well together. Having a bit of fun, breaking it up, making people feel unsafe to a safe sort of level. It had all of those values. I think the innovation sprint has actually got a business purpose that's quantifiable, what's measurable, but they both work off the same canvas.

Yeah, so I think if we were going to put it into more of a pattern, so we have this concept concept of doing this 2 to 3 weeks— no, sorry, we have this concept of disrupting the way the team are working for a period of time for an outcome. But I think you've just described two different patterns. I think we have a 1-week innovation sprint, which is find something that you think has massive value to the business or part of the organization, to key stakeholders, and spend a week, you know, seeing how close you can get to delivering that and then asking for investment to finish it. I think that's one pattern. I think the second pattern is, you know, that technical debt sprint, but again using the same process and same templates where we say actually we're going to use the canvas, but this time we're going to focus on the metric around automation and we're going to value stream map the processes first to identify that, and then you're going to get given 2 to 3 weeks to actually deliver of it done, done in production. And again, same thing, Demo Day, all those same behaviors. When we do that, all the other benefits you talk about, about forming teams, bringing people on, all those things will happen. Yeah, we'll get those again. And I don't know, I'd be interested to see whether a technical debt sprint is seen as much fun as an innovation sprint. Yeah. I don't know till we try it.

Exactly. I mean, technical debt might be just as valuable to— yeah, as a brand new shiny product for some people.

Well, for the team members that are technical, right? That's right. People that like deep diving and solving complex problems and just nailing it and also make their life easier going forward. Yep. They're probably going to get excited. Yeah. So, yeah, who knows? Again, as with all things agile, experiment safely, have a retrospective at the end of it, and look at lessons learned.

And getting it into a pattern is the challenge as well. We've run one, we haven't managed to do it again. Or do you do it on a case-by-case when you need it, when you feel you need it? Or do we set a timetable for these things and have it every 3 months?

I think, um, I think I think if I had to have an opinion right now, my opinion would be an innovation sprint should be booked at a cadence where, you know, the team is starting to get stale. Yeah, it needs to be a bit of fun. So that for me feels like a 3-6 month type of thing. But I think one thing we learned from this was it was fun when we did it once, but we haven't done it again. So I think you do need to get permission to book it in, yeah, maybe on a 6-monthly basis, you know, because it's a week every 6 months. And if you timed it, you know, for New Zealand time frames, if you did it for like midwinter, Christmas, and December, which, you know, is typical more holiday downtime kind of behavior. Well, midwinter because winter in Wellington is always grey, and so people bit of exciting, and then Christmas is where you get that downtime. For me, that seems like a natural cadence. Yeah. But for a technical dev sprint, where we're going to take 3 weeks, so we're going to take an entire cycle of all the squads, all the teams, because it is a competitive type behaviour. What's your feeling on that? How often would we get— once?

Well, when we split up into the 2 Scrum teams, one thought was that one One of the teams would work on new products and the other one would work on technical debt. We decided that wasn't going to work, the reason being I think that you don't get recognized for technical debt and it would get boring doing all of that all the time. No exposure. It's kind of seen as dreary. Whereas the new products out to the business is seen as high profile. So we didn't go down that road.

I think also the other one, if you did that, you get this risk of the new build team will never be done done, but they'll flick it over the fence because they know there's a safety net there of the— Just leave technical debt. Technical debt. It'll get picked up by those guys. You know, it's like when I was a kid, right? My clothes were always on the floor at home because I knew my mum would come and pick them up. The day she stopped coming and picking them up, and I wore the consequences, I started picking my own clothes up when I ran out of clothes. Yeah, when the pile got too big to get into your room. Well, I just climbed over it, but when I kind of had, you know, didn't have clean clothes and I started to smell, it's like, okay, there's a consequence to my behaviour, so I'm gonna go and iterate and change my behaviour.

So, um, in answering your question of when, um, or how often, Yeah, that's a good question. I think constant monitoring of the backlog is probably important. I've just got a pile of cards that say, "Do this, we'll do this later, we'll do this later." We need to value prop— value map them, see if anything—

Yeah, look, I mean, with all the teams I've coached, I've yet to get to a situation where there was resulted in a massive backlog of work for the team that had value to the business stakeholders. Yeah. So I think we need to lock in a cadence where the team are saying, actually, a percentage of our time over a year needs to be dedicated to, you know, tidying up our own room and doing that kind of work. I'm assuming that as the technical debt sprints using the canvas and the metrics happen, then the value, you know, that those metrics, those time savings or automation will become more visible and therefore more of a value-based discussion. But I think you actually have to lock in permission to do them on some form of cadence. Otherwise, you know, the business stakeholders are quite rightly going to say, you know, I need this next, this has massive business value. So I don't know, I mean, I'm, I don't know, do you do it every 6 months on an off-cycle? So if the innovation sprints are 1 week in, you know, June, July, and December, do we hit an iteration going to March, April, and September, October for the technical debt iteration, I think?

Yeah, I don't know. I mean, you'll probably poo-poo this, but do you add innovation into an existing sprint and just say, look, every 3-week cycle we're going to knock a certain number of points off the technical debt? The trouble being that they might not be associated with the widget that you're building, or the website, or the app that you're building in that sprint?

I think I think originally when I started coaching, you know, we typically were pipelining but micro-pipelining, so there was still a handoff between, you know, the analysis to the engineering to the data to the visualization and the testing. There was a natural handoff and therefore there was natural downtime across team members where that might have worked. But I've got to say that with the later teams that I've been working with, I've actively moved away from anything that looks like that and found that actually with the T-skills of most of the teams I work with, they naturally pick out the moving parts and actually there is no real downtime. Yeah. So would it be useful? Probably. Would it work? I'm gonna guess that it wouldn't because it wouldn't be a focus. It'd be a secondary. You could say that if the team have delivered the iteration early, they could pick up some of those backlog technical debts things, but most times, you know, we're always moving stories or tasks out as sitting in the in the iteration backlog, and if you nail the points and you want to bring something in, the Product Owner's got a whole raft of additional features.

Well, that's one thing, the Product Owner's not, hasn't brought the story in, you won't be able to use the canvas, probably. It'll be more of a Kanban type thing.

So naturally, yeah, we've come up with no. Well, not a poo-poo, it's have a go. but naturally it doesn't feel like a pattern that would succeed. Whereas, you know, a dedicated technical debt sprint using the Innovation Top Canvas and a competitive behavior across the teams in a safe way and focus on that metric of where's the value in terms of production and time or reduction of risk by automation. To me, that feels like a pattern and process.

And I think the fun of having the Dragon's Den type panel, the panel obviously be a lot more technical than the one we use for innovation.

I don't agree. I think it would be exactly the same panel, but the presentation will be, here's a bunch of technical stuff, but actually here's the time or value that we save And the reason I say that is because half your teams did that. Half your teams actually did. They picked plumbing, right? But they still presented a compelling story. You know, even the two that your team did, both of those were compelling, just two different approaches to solving the same problem. So no, I think that Dragon's Den at the end is one of the high-value pieces of the competition. Of the puzzle is that without knowing, you know, if you know you're not going to have to front that, your behavior probably will be slightly different. Yeah.

And it's getting people on stage, right? It's another skill to your bow.

Yeah, it's the beginning of facilitation, right? Yeah, yeah. And T-skills? T-skills, yeah. It's something that a lot of the development teams are uncomfortable with. But again, you know, like I got to say, the entire, you know, that was what, 25 people involved involved in your one when you did it. Yeah. And they were 25. We're up to— Cool presentations from everybody.

So we're up to over 40 now. So that'll be an interesting one.

Wow, 8 teams. Yeah. Hmm, that's a— wow, that's an interesting idea. We'll take some planning.

Yeah. Would it be any different?

The teams will be bigger now, right? Because what we I would say is, one person's got to be a product owner, one person's got to be a Scrum Master, so there's two roles. And we probably still need 4 to 5 people in each squad. So 7 to 8, so you've probably got 5 teams of 8 now. So still, and you've proven you can do it with 5 teams, so I don't see that as, I think you had a scaling pattern from day one, which was great. I'm pretty happy about that. I'm gonna—

yeah, that's, uh, so when you're running your one—

yeah, well, yeah, at the moment those, those teams are still coming up to speed, so we're not at the stage yet where, um, where I think it's safe to experiment in that way yet. Yeah, um, we're not trying to prove the things that you needed to prove and test at that time, but, but they will eventually. Um, the question is, yeah, when can you How do you get permission to do your technical debt one?

Yeah, well, with the innovation one, it was just a case of I was lucky to have a really good change manager that helped me out. And we just made it happen. We just said, look, we're going to set some dates, not going to let anything get in the way, and we're just going to do it. And you have to take that approach. Yeah. Otherwise, if you're just trying to book time in people's calendars and you're put off by things like that, you just, you'll never get around to it.

As we know, if you're not focused on it, it becomes a secondary task and it never quite gets done done. So yeah, excellent. All right, well, I think, I think I'm pretty happy with that one. I'm kind of excited again. So we'll put the template up on the website where we publish the podcast. Yeah. And then if anybody's going to go and give it a go, give it a try, give us some feedback via Twitter. Absolutely. How you went. And then as soon as Blair figures out when he's going to book in the technical debt one, we'll do a follow-up podcast in a couple of months and see how it went.

Yeah, I'm pretty excited now. Just got to find some dates.

Excellent. Yeah. All right. Well, I think that's us done. We'll catch you all later from sunny Wellington, New Zealand. Is it? Well, not at the moment, but it has been up until now. So we'll just pretending that Wellington's sunny. Yeah, catch you all later.

Okay, cheers, bye. 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.