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

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 Sprint. So, yeah, the whole process of giving the team some time to decide what they want to deliver and let them go wild.

Yeah, so we sort of called it a mix between Dragons Den and a hackathon. So bringing those two things together and Dragons 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.

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 because there wasn't true cash being thrown at these things.

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 that, it helped them focus on being done. Done by the end of the year.

Oh, absolutely, 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 tooth 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 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, in retrospect, was a week 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. Yeah. So we decided what members would go into our team. It's kind of a 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 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, 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? 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 used 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, you know, of the sprint, you know, what the people, you know, who are the people, what are the resources that we need? And we also got into the costs. Hypothetically, this would cost three sprints. We'd need a product owner, that sort of thing. So we actually started to formulate a plan.

Right. So looking at 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 at the beginning and then kind of update 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. We're at estimates, right?

Yeah. 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 five teams of four and five.

Right. So again, fairly small Scrum team. Still got a really good mix of T skills, but, yeah, having five 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 leveraged the experience of those that have been in and 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 seven or eight and the team wasn't it. 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. 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?

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 serving and 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.

Yep. Remember our one? So I had to step in as Scrum Master. No one had the experience of, you know, 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. They were just different opinions on which was the best.

Yeah, just that the actual 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 servient 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 or the ones that came to the fore. Okay. It was 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 guide the team. Especially because you had new team members who had 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 hum 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, but we didn't really do any kind of 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 three week cycle and try and compress it down into one week with a couple of iterations. We kind of just gave them a week and let them.

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 stand up 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.

Where we go into a room, each team and switch on a PC and go over what they've done. Yeah, we certainly did. Open up SQL, run what you've done.

Open a spreadsheet, that sort of thing.

Right. So kind of prove it amongst the team.

Yeah.

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 an idea of two methods quite late, we had to rush it.

But the other teams put a lot of work into the presentation. As much as you can in a week.

Yep, yep. Yeah. Well, that definitely came across as polished.

Yeah. Yeah, it's 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.

Yeah. And. And how did you manage that? Because now what you had is five 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 behavior.

Yep.

So.

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

Okay. So there was somebody sitting outside of it, monitoring the process, keeping an eye on it from a pastoral point of view, making a person care point of view, making sure that as the fact that you're experimenting for the first time. It's safe and everybody's okay. Oh yeah, that's good. So I think that's. That was one of the.

Absolutely. And we called that a check in.

Yeah.

So it was just a visit from the boss. 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 where people were at certain times for their ceremonies, for their, for their kind of a mix between a backlog grooming and a morning stand up. So you might have it at three in the afternoon, right? Yep. And then so we turn up with lollies or sausage rolls just to keep the ball rolling.

Yep. Yeah, yeah. But also just make sure that everybody's okay.

And I talk to every scrum master or inverted commas and just, just to keep a check on how things were going because you know there's, 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 that's 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 three small teams. There was one product owner with one team and again that's okay. It was just a very small team of two.

So yes, you know, 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 your idea.

Well, it was. 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 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. 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. 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. But it's never been prioritized. It's not coming from a product owner. It's our idea, so we can't work on it. So they made it a more data analytics, centric content delivery. 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 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 are forming a team and one of you has to adopt the product owner role? So if it's your idea that the team accepts is the one they want to work on you, you're now the product owner, which actually means you're not on the field. So the interesting thing there is that team member will experience what it's like being a product owner, where you have to 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. Yeah, 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 too.

Yeah, that's right. Good learning by doing.

Yeah. Yeah.

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 and 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?

Exactly. That's not what it says 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 be the Scrum Master.

Okay.

And they did. Wow. 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 agile way of working 101 for your team. But if we had people that were experienced being a team member, would we still do that? I think we would.

I think we would. I definitely think we would because a lot of 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.

See what's really interesting. I 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.

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 start to rocket and we look at the product roadmap and the promises of what needs to be delivered over the next six to 12 months and the release promises over the next three to six months, there's a mountain of work there.

Right.

Both of them are re platforming as well as effectively re platforming. The data analytics environments while trying to decommission the old environments, while trying to build new for the new strategic, high priority information products. And so there's a mountain of work there that the team, will they be.

Sharing the duties or is this one team going to concentrate on a certain.

So for the customer that 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 data stuff as they do it. So they are kind of co dependent. But my thought goes is as they want to scale, as we want to go from two squads to three squads or from one scrum team to two scrum teams, how do we bring the new people on? Because we've been going on a journey where 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 adopt that behaviour. So thinking about it, actually running an innovation sprint as a way of saying actually come in, we're going to do it, we're going to split the teams up, going to 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. We're not aiming for.

Done, done out the door value to a stakeholder with a product owner champing for that value. We've got a little bit more of a safety net for you to learn.

The process of concept.

Well, it's a. I wouldn't call it.

Well, you're not going to prod 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, and, and not prove anything. But I think the canvas and the in 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 got to. But maybe it's a way of engage, 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.

You might do it once we get.

To a stage where we're going to start.

You've seen the canvas?

Yeah, I've seen the canvas through 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. Click. Are you going to put it online? Key metrics. That was an interesting one. You know, with our innovation, we were going to speed, 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, why would we invest?

So that was where the Dragon stand thing really came in handy, actually putting some value on it.

It's out of interest, though. Hard question. How many of those five 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, desperate.

No.

And that's one of the challenges. Right. As you start delivering that value out to the business stakeholders, they want more and. Yeah, yeah. So what I'm, you know, kind of retrospective 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 product out, 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, some of our own stuff, we could actually use the innovation Sprint as a template for. For a bit technical debt Sprint quite easily.

Yeah.

It would, it would fit like a glove really. You, 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?

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, less risk or all those kind of cool words. So, yeah, it's going 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 forth 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, if it's taking up resources, but it has. 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 they could deliver more to. To the business.

So yeah, it would just be a case of maybe going through that backlog and doing some value mapping. What's going to add the most.

The most benefit by getting fixed or done and then just prioritizing. 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 a 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 and then by doing that you can go back to your stakeholders and say we invested two to three weeks, whatever the iteration time frame is to deliver 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. What does that mean?

Think about that. Imagine having to quantify the amount of time you're. So you 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 automation 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 going to look at their processes and they're going to say, 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 data ops approach to that, is something we probably can do in two to three 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 lie.

Yep. 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 automate next.

Absolutely. So technical debt has a purpose to, you know, to speed things up to Improve. The Innovation Sprint had many, many, many reasons for that. Passing over the skills that the, you know, that the scrum team had learnt across the whole, 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 had this concept of doing this two to three weeks. No, sorry. We have this concept of, 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 one 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 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 send pattern is 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 two to three weeks to actually deliver 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, you know, 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 until we try it.

Exactly. I mean technical debt might be just as valuable 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, they're probably going to get excited. So who knows? Again, as with all things agile, experiment safely be respective 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 three months.

I think about it, 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 three, six 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.

Maybe on a six monthly basis because it's a week every six months.

Months.

And if you timed it for New Zealand time frames, if you did it for mid winter, Christmas and December, which is typical, more holiday downtime kind of behaviour. Well, mid winter because winter in Wellington is always grey and so it'd be a bit exciting. And then Christmas as we get that downtime. For me that seems like a natural cadence. But for a technical death sprint where we're going to take three 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 two scrum teams, one thought was that one of the teams would work on new products and the other one would work on technical dam. 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, no exposure.

It's kind of seen as dreary. Whereas the new products out to the business is seen as high profile. So we couldn't go down that road.

I think also the other one, if you did that, you get this risk of the. 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 technical debt.

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

When the pole 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 going to go and iterate and change my behaviour.

So in answering your question of when 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 wasn't a massive backlog of work for the team that had value to the business stakeholders. So I think we need to lock in a cadence where the, the team are saying actually a percentage of our time over a year needs to be dedicated to 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, 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 the business stakeholders are quite rightly going to say I need this next. This has massive business value. So I don't know, I mean.

Do.

You do it every six months on an off cycle? So if the innovation sprints are one week and you know, June, July and December, do we hit an iteration? Kind of 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, every three week cycle we're going to knock 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 originally when I started coaching we typically were pipelining, but micro pipelining. So there was still a handoff between the, 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 working with.

I've actively moved away from anything that looks like that and found that actually with the T skills and most of the teams I work with they naturally pick out the moving parts and actually there is no real downtime. So would it be useful? Probably. Would it work? I 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 we're always moving stories or tasks out as sitting in the iteration backlog. And if you nail the points and you want to bring something in, 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.

Yeah.

It'll be more of a Kanban type.

Yeah.

Thing. So. Yeah.

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.

Yeah.

Whereas, you know, a dedicated technical debt sprint using the innovation type canvas and competitive behavior across the teams in a safe way and focus on that metric of where's the value in terms of reduction in time or reduction of risk by automation. To me that feels like a pattern and process.

And I think the fun of having the dragonstand type panel. The panel will 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 plumbing. They picked plumbing.

Right.

But they still produce 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 puzzle is that without knowing if you know you're not going to have to front that your behavior probably will be slightly different.

And it's getting people on stage. Right. It's an another skill to your bow.

Yeah. It's the beginning of facilitation. Right.

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 gotta say, the entire, you know, that was what, 25 people involved when in your. When you did it. And they were 25 cool presentations from everybody.

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

Wow, eight teams. Yeah, that's, that's. Wow. That's a. Interesting idea.

We'll take some planning. Yeah.

Would it, would it be any different? The teams will be bigger now.

Right.

Because what we'd say is, you know, one person's got to be a product owner, one person's got to be a scrum master. So there's two roles.

Yeah.

And we probably still need four to five people in the. Each. Each squad. Yeah. So seven to eight. So you've probably got five teams of eight now. So still. And you've proven you can do it with five 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.

So when you're running your one.

Yeah. Well, yeah, at the moment those, those teams are still coming up to speed, so not at the stage yet where.

I think it's safe to experiment in that way yet. We're not trying to prove the things that you needed to prove and test at that time, but they will eventually. The question is, when can 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. Otherwise, if you're just trying to book time in people's calendars and you're put off by things like that, 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 and then if anybody's going to go and give it a go, 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. Months and see how it went.

Yeah, I'm, 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 keep pretending that Wellington's sunny Yep. 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.