Innovation iteration

Join Shane and Blair as they chat amongst themselves on their experience running innovation iterations.

Read along you will

PODCAST INTRO: Welcome to the “AgileBI” podcast where we chat with guests or sometimes just to ourselves about being Agile with teams who are delivering data analytics and visualization.

Shane Gibson: Welcome to another AgileBI podcast. I’m Shane Gibson.

Blair Tempero: And I’m Blair Tempero.

Shane Gibson: 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 Hackathon, but which they called Innovation, they are sprint, so the whole process of giving the team some time to decide what they want to deliver, and letting them go wild.

Blair Tempero: So we sort of called it a mix between Dragon’s Den and a Hackathon. So bringing those two things together.

Shane Gibson: And Dragon’s Den, because?

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

Shane Gibson: 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 tried to effectively sell the value of what they wanted to do. So they could go and actually harden their code, or visualization, or data or whatever it wasn’t they did.

Blair Tempero: 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 because it wasn’t true cash being thrown at these things.

Shane Gibson: Do you find though that by setting up early with a team that there was this Dragon’s Den at the end of it, that they had to present to a group of people outside of the team. What they’re done and where they saw the value if they carry it on? Did I help them focus on being done by the end?

Blair Tempero: Absolutely. So we had an end goal. And we knew that we had a week to do it. And so there was no sort of flailing around. We’ve just had to get stuck in with the end goal. And the best part of it being presenting to the C-Suite plus yourself. So definitely think having that end goal of the presentation kicked us along.

Shane Gibson: And normally, Hackathons are normally a data so I’m going to talk about Phoenix where Hackathons are those kind of things, when we look at startup or companies that do that they normally only spend a day on it. We select a week because?

Blair Tempero: We thought about a day and going overnight, but we had some team members that had new babies and all sorts of we have BAU. So we kind of mixed it with BAU we had to write, we still had to keep the lights on. So it was important that we split time between your team concept and essentially keeping the lights on. So that’s why we came up with a week. We were thinking longer, but we just couldn’t tell that.

Shane Gibson: So in retrospect, was a week too long, too short?

Blair Tempero: I thought it was just right because we did keep the lights on. And we did come everyone did come up with a presentation. And it was a tough week don’t get me wrong. So we decided what members would go on to 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 bonus. So we formed the teams put them together to come up with a concept. So we had the first session was to report back just on the theme that you’re going to work on just to make sure there was no duplication. Make sure that everybody in the team was along for the ride.

Shane Gibson: And so one of the things we did was we said, how do we help the team through their ideation? How do we let them actually go through a bit of a process themselves to figure out all the ideas they have, which ones they think was the most valuable, the most achievable timeframe. And when we kind of use the innovation canvas, so we kind of took coming up. We took the lean or the business canvas and we use that. So each team really had to fill out the canvass at the beginning to help them form and collaborating and have a conversation about what they were actually going to work on. Did their work as a concept?

Blair Tempero: Absolutely. I think it was just a central point that we could put our goals and the purpose of the, of the sprint, 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.

Shane Gibson: So looking at saying if they’ve got approval to go forward, actually, what do we think? And do we so that estimation, was it done at the beginning of the of the innovation sprint, or at the end, or do we do the beginning and then kind of update at the end?

Blair Tempero: We did it at that sort of in between. So after we got our proof of concept and decided it would have been a useful exercise actually to go back and see which ones we put into production. Our estimates were right.

Shane Gibson: Well, how wrong were they? Estimates are never wrong. So one of the things I found interesting was the number of teams because you formed quite a large number of small teams. I can’t remember how many?

Blair Tempero: I think there were five teams of four and five.

Shane Gibson: So again, fairly small Scrum teams still get a good mix of key skills, but having five teams racing each other.

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

Shane Gibson: Actually, I forgot about that. Because at that stage, we’d only been one running one scrum team, that was seven or eight and the team wasn’t enough so and then the rest of the team were stuck in BAU Lane trying to manage the BAU bleed and do that. So 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 forgot about that.

Blair Tempero: So it was interesting. And I’ll get into that a bit further. I thought the concept of me being in a team was really interesting for me. I wasn’t allowed to be Scrum Master. How did that go you might ask really?

Shane Gibson: Because you just back on the field.

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

Shane Gibson: Did you find that somebody else in your team jumped in and started to fill that similar leader role?

Blair Tempero: At the start, 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. We had to keep collecting ideas. So I had to step on the Scrum Master. No one had the experience of bouncing two ideas and coming up with a compromise, which we did. We came up with and we presented two ideas. We just could not break that.

Shane Gibson: That was interesting because two teams or 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.

Blair Tempero: It just the actual date BAU had for those two members for. They came from different areas.

Shane Gibson: And some of the other teams did you see somebody kind of step up as the Serbian leader as the as the quasi scrum master to help the team?

Blair Tempero: The limited time I got to see other teams actually interact, because I was part of part of our 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 result. Well, obviously the individuals that had been sort of in a leadership role in the scrums were the ones that came to the fore. It was really good experience to see how they did act in that scrum master role, because not the scrum master can always be at ceremonies. It’s good that he is there or she, but it just see how they would act if they had to just sort of be that person.

Shane Gibson: So do you think if you did it again from her to speak 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 we’re just helping the teams, they’ll 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, if you think they would have been helpful.

Blair Tempero: 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 struggling for this one was useful as well.

Shane Gibson: That was gonna experiment astoundingly. And then from memory, we didn’t really run the ceremonies. We did, I’m assuming each of the types of daily stand ups. But we didn’t really do any kind of play backlog grooming or sprint planning at the beginning was more of an ideation that throw 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. And no, one week with a couple of iterations. We kind of just gave them a week.

Blair Tempero: I guess that came down to time. We had a week. It’ll be useful to try it with all of the ceremonies, half an hour backlog grooming, rather than an hour. The daily standup would obviously keep going. It just came down to, this is going to be sprint with maximum BAU so let’s spend as much time developing as we could.

Shane Gibson: And again, it was an experiment. Experiment learn retrospective, change it a little and do it next time.

Blair Tempero: We did have demo days sort of where we go into a room each team and switch on a PC and go over what they’ve done. We certainly did. Open up SQL, run a module done, open a spreadsheet, that’s kind of things.

Shane Gibson: So I kind of preferred amongst the team gives you a check point where you’re at because again, you’re fronting to people outside your team.

Blair Tempero: So we started to talk about it really early on how we were going to do it. But it’s only the content came. Because we came up with the idea of two methods quite late. We had to rush it. The other thing is for a lot of work into the presentation as much as you couldn’t awake.

Shane Gibson: That definitely came across as polished. It was a lot of fun. It doesn’t seem anybody was standing up though for the first time.

Blair Tempero: No, because it was the internal pressure. So you didn’t want to be that team that failed, that’s the beauty of the competition.

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

Blair Tempero: Oh, they got to be safe. I just coming from a supporting background, and it was just great just trying to kick some ass.

Shane Gibson: If you think about it, if you’re doing it, where maybe the organization isn’t as safe as yours was, or the team’s not as safe for them, then there is a risk that actually could get bad behavior.

Blair Tempero: So the boss was an observation type role. In our innovation sprint planning, we had regular check-ins.

Shane Gibson: Okay, so there was somebody sitting outside of monitoring the process, keeping an eye on it from a pastoral point of view, making the first person key and point of view making sure that as the fact that you’re experimenting for the first time, it’s safe, and everybody’s okay that’s good.

Blair Tempero: And we call that a check-in. So it was just a visit from the boss. How’re you guys going? So we shared with myself on sort of running it, kind of behind the scenes, where people were at certain times for the ceremonies for the kind of a mix between a backlog grooming and wanting to stand up, so you might have it at three in the afternoon, and then we’ve turned up with lollies or sausage rolls just to keep the ball rolling.

Shane Gibson: And also just make sure that everybody’s okay.

Blair Tempero: And I talked to every scrum master, and just to keep a check on how things were going, because there’s a potential for things to go wrong.

Shane Gibson: Also potential for people to overwork, because it’s a competition. Go into those silly 16 hour days just to try and get over the line where actually we use these some pointers to produce something of value at the end of that week to show something that could work and what’s left to be done. There’s also been a fun bit of a leading steam off a little bit for the team and that constant sprint cycle of delivering to a product owner. So did you have somebody ended up in the team becoming almost a quasi-product winner, did you find?

Blair Tempero: Yes, it was probably the person that idea got chosen. To product owners, we know how well that worked.

Shane Gibson: I suppose but in your case, you had two teams. There was one product owner for one team. And again, that’s okay. It was just a very small team.

Blair Tempero: So just organically, it went to the person whose idea was adopted. I think in hindsight, we should have chosen ideas that involve 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.

Shane Gibson: Is that because they were doing BAU or because of your idea?

Blair Tempero: What was something that only one person could do, they could went away and wrote some code. We tried to get pair programming as much as we could. 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.

Shane Gibson: Or maybe actually bring in product owners. Well, though, then the team they get to choose because one of the things I was really interested in was some of the teams packed automation of the platform, they held on to describe it. They looked at a problem they had of what they were doing in the 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 decision, but it’s never been prioritized. It’s not coming from a product owner. It’s our ideas, and we can’t work on it. So they made it the more data analytic 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 is not automation of some of the processes that are frustrating the team. So probably in hindsight. Maybe bringing in an external product owner is not a good idea.

Blair Tempero: Or you could see what your ideas come up with and whether they weren’t 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?

Shane Gibson: Or do we actually say that you are forming a team and one of you has to adopt the product owner role? If it’s your idea, the team except as the one they want to work, and 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 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 because now you’re learning another role.

Blair Tempero: Absolutely. And you’d have to go away and talk to stakeholders and come back. And that’s quite a good time for us to be talking about that with having product ownership being on the focus.

Shane Gibson: So maybe another innovation sprint, but this time, each, each team has 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 manager goes through.

Blair Tempero: Scrum Masters do so.

Shane Gibson: Good learning by doing. I suppose then you could actually gain, so each one of those teams have to select the scrum master. Who fills that role? And again, get some cross skilling and also get to feel the pain of being the person in the room standing behind everybody going to make sure that says easy, as you say.

Blair Tempero: So in terms of Scrum Master, before the week started, I did a presentation on what role the scrum master has, and 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 in the innovation sprint, I really hope I get a chance to be the scrum master and they did. They realized how hard it was.

Shane Gibson: So do you think there was because of the people coming into the teams hadn’t been involved before. So you had to give them some up skilling really early just in time to say, when you hear these words, this is what it means. So it’s the Agile way of working one on one for your team. But if we had people that were experienced, and being a team member, would we still do that?

Blair Tempero: I think we weren’t. I definitely think we weren’t because most of them have been experienced developers, experience BA’s. They’ve seen us at work with Scrum Mastership and Product Ownership. I think an overview would be perfect.

Shane Gibson: So it was really interesting, I just got to thinking about that. So I’m coaching two different teams from 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 squats. 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 move from viewers from one scrum team to two and we kind of split the team to see what happened if we have filled it with experience, we knew we’d lose a lots of it, but it was a way of onboarding the new team members safely we thought. So all the same problem, we’re with these two customers. And then as the team start to rock it and we and we look at the product roadmap and the promises of what needs to be delivered over the next six months and then release promises over the next three to six month, there’s a mountain of work there for the re-platforming as well as effectively re-platforming the data analytics environments. While I’m trying to decommission the old environments, while trying to build new for the new strategic high priority information product. And so is the amount of work is there.

Blair Tempero: Will be sharing the duties or just one team going to trade on a certain?

Shane Gibson: So for the customer there, we have two squads, they just go 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 stuff as they do it. So they are kind of codependent. But my thought goes, as I 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 new people on because we’ve been going on a journey where we have we’ve been learning the language, we’ve been learning the ways of working and finding that and to bring new people in, they’ve got to get up to speed with that before they even start to adopt that behavior. 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 team’s up, we’re going to run an innovation sprint for a week. So for the fun, but actually one of the outcomes we want as you start being immersed in the language and the behavior in a safe way. We’re not aiming for 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 concept. So we still have to say you have to produce something of value. 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 in the beginning, you had a plan and agree. And at the end, you got your demo data effectively, where you’re showing what you’ve done. So you have to show the venue you got to but maybe it’s a way of scaling, where you can safely bring new members on, and quickly have them learn the way of working start their journey in a safe environment.

Blair Tempero: Yeah, it could be just that.

Shane Gibson: I might do it. Once we get to a stage.

Blair Tempero: You see the canvas?

Shane Gibson: I think we should be okay for maybe taking anything that mentions where you work out of that.

Blair Tempero: Well, this was actually a blank one. I sent you are working on.

Shane Gibson: So what we take the blank one and we’ll load it as part of the podcast and put it on the edge of the agilebi.guru website if somebody wants to download it and use it.

Blair Tempero: We found it really useful, the unique value proposition that you’re aiming for. People as I mentioned, earlier channels, the path to customers. You’re going to use click it, you’re going to put it online key metrics. That was an interesting one. , with our, with our innovation, we were going to speak, hopefully speed up the load and put less pressure on the system each day things like that. If you’re putting it to the top panel, they just want to see what you’re going to get out of it. ? The value you can insert.

Shane Gibson: So why would we invest?

Blair Tempero: So that was where the Dragon’s Den thing really came in handy, actually putting some value on it?

Shane Gibson: Sounds interesting. How many of those five products made it to another round of investment?

Blair Tempero: None so far. They were out at ideas from us not the business. So we’ve been on the 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.

Shane Gibson: So you’ve never gone through any kind of technical desperate. And that’s one of the challenges as you start delivering that value out to the business stakeholders, they want more. So kind of retrospective that for me was, and I’m not sure I’ve got it yet. But every new team I engage with that saying, 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 need to automate that have value for future iterations. But a product owner, if they have a choice between you automating a little bit more of what you do, or even getting another information product out, that helps answer business questions better, they’re gonna choose the information product every time.

Blair Tempero: Absolutely. But if we built into our timetable some of their own stuff, we can actually use the innovation sprint as a template for a bit technical debt spread quite easily. It would fit a glove, you’re looking at all of the same things, costs and key metrics, what are you trying to get out of this product owner be interesting. It might be the DBA.

Shane Gibson: So you’d have to say that, it can’t be some of the data and analytical content out to a business stakeholder. So it can 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, all those kinds of cool words. So it’s got to be a way of adding value by making what you do a little bit easier.

Blair Tempero: 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. It hasn’t broken things, so it hasn’t been fixed yet.

Shane Gibson: Well, that’s another question.

Blair Tempero: Taking up resources, but it has hasn’t broken anything. So where’s the line there?

Shane Gibson: But are those resources were freed up from those manual tasks are those BAU bleeds in theory, it deliver more to the business.

Blair Tempero: Or just be a case of maybe going through their backlog and doing some value mapping? What’s going to get the most the most benefit by getting fixed or done? And then just prioritizing, we need an internal product owner to do that.

Shane Gibson: Well, what I kind of just thinking about what you said there, if we take that the 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 aren’t going to get something production ready. 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. But the definition of success, the acceptance criteria, as you’ve set an expectation or hypothesis that this investment will make releases take 20% of the effort they take now, so you can measure that. And then by doing that, and go back to your stakeholders and say, we invested, two to three weeks, whatever the duration timeframe is to deliver an 80% saving for this piece of effort going forward. And actually, here’s the proof.

Blair Tempero: It’s lot easier to prove than we’re going to produce a product that will make it easier for teams to make business decisions, what does that mean?

Shane Gibson: Think about that, imagine have been to quantify the amount of time, so just use that release example. Imagine having to quantify how long it takes us to do a release and estimate so we’ll get estimate how much time we’d save if we automated that? There would be an odd struggle to do that.

Blair Tempero: So we’ll do a technical debt sprint after talking today.

Shane Gibson: Based on using the integration canvas and key metrics. And then by doing that, each team will stall naturally compete. So they’ll pick somebody that they know. So actually, if you think about that, what should happen? What we should see is the teams pick the cherries, the easy ones, they gotta look at the 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 automations, or 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. Well, if we compete on the metric, we’ll actually hit the low effort high value things naturally, because who’s gonna know where they are as the team that actually struggle with them or spend their time on an ongoing basis, they know where those things live.

Blair Tempero: And that’s why I think that product owner within us, whether it’s the DBA, whether it’s 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, very mapping.

Shane Gibson: 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 and each one of them or the latency at each one of those steps, which will 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 or something says that one is the part of that value stream that we want to automate next.

Blair Tempero: 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 learnt 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. That had all of those values. I think the innovation sprint has actually got a business purpose that’s quantifiable, what measurable. But they both work off the same canvas.

Shane Gibson: So if we were going to put it into more of a pattern. So 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 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 to get it, see how close you can get to delivering that and then asking for investment to finish it. I think there’s one pattern, the same pattern is the 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 a value stream map the processes first, to identify there, and then you’re going to get given two to three weeks to actually deliver it done in production. And again, same thing on Demo Day, all those same behaviors. When we do that, all the other benefits you talked about forming teams bringing people on, all those things. We’ll get those out again. And I’d be interested the weather or technical debts from as seen as much fun as an innovation sprint. I don’t know till we try it.

Blair Tempero: Technical debt might be just as valuable to as a brand new shiny product for some people.

Shane Gibson: Well, for the team member’s technical people, they deep diving and solving complex problems and just nailing it and also make their life easier going forward. They’re probably got to get excited so who knows? Again, as with all things Agile experiment safely respective at the end of it and look at lessons learned.

Blair Tempero: And getting it into a pattern as 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? What do we set a timetable for these things and have it every three months?

Shane Gibson: I think if I had to have an opinion now, my opinion would be an innovation sprint should be booked at a cadence where the team is starting to get stale needs to be a bit of fun so that for me feels a three, six month type of thing but I think one thing we learned from this was that was number 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. And if you told him that for New Zealand timeframes, if you did it for midwinter, Christmas and December, which is typical more holiday, downtime kind of behavior. Because winter, Wellington’s always gray and so people are exciting, and then Christmas as we get their downtime. For me, it seems a natural cadence. But for a technical debt sprint, when 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 behavior. What’s your feeling on there? What how would we get once?

Blair Tempero: Well, when we split up into the two Scrum teams, 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 will 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 didn’t go down that road.

Shane Gibson: 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.

Blair Tempero: So picked up by those guys?

Shane Gibson: When I was a kid, my clothes were always on the floor at home, because I knew my mom would come and pick them up. The day she stopped coming and picking them up all the consequences, I started picking my clothes up, when I ran out of clothes.

Blair Tempero: Was the closet was too big to get into your room.

Shane Gibson: I just got over it. But when I got ahead, you didn’t have clean clothes and I started to smell, I was like “Okay, there’s a consequence to my behavior. So I’m gonna go and around change my behavior”.

Blair Tempero: In answering your question of when or how often? 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 probably met them.

Shane Gibson: We’re 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 we’re the team are saying, actually a percentage of our time over a year needs to be dedicated tightening up our own room and doing that kind of work. I’m assuming that as the technical debt sprints using the canvas and the matrix happen, then the value of those metrics, those time savings automation will become more visible and therefore, more 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 quietly going to say, I need this next and says Mr. Businessman. Do you do it every six months on an off cycle? So if the innovation Sprint’s one week in June, July and December? Do we have an aeration going to March, April and September, October for the technical debt?

Blair Tempero: I don’t know. You probably poo-poo this but do you add innovation into existing sprint and just say, every three weeks cycle, we’re gonna knock set number of points of the technical debt. The trouble being that there might not be associated with the widget that you’re building or that the website or the app that you’re building in that sprint?

Shane Gibson: I think originally when I started coaching, we typically were pipelining but micro pipelining. So there was still a handoff between the analysis to the engineer during 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. I’ve got to say that with the later teams that I’ve working with, have actively moved away from anything that looks 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, that’d be a secondary. You could say there, if the team have delivered the iteration early, they could pick up some of these 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 owners got a whole raft of additional feature.

Blair Tempero: That’s one thing the product owner hasn’t brought the story in. You won’t be able to use the Canvas probably, it’ll be more of a Kanban type of thing.

Shane Gibson: It doesn’t feel a pattern that would succeed. Where it is 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 please the value production on time or reduction on risk by automation.

Blair Tempero: I think that’s fun of having the Dragon’s Den type panel, the panel, obviously be a lot more technical than the one we use for innovation.

Shane Gibson: I don’t agree, I think it would be exactly the same panel. Here’s a bunch of technical stuff, but actually he is the time or value that we say. And the reason I say that is because half your team is actually did. They pick plumbing. They still presented a compelling story. Even the two that your team did both of those were compelling, just two different approaches to solving the same problem. So that Dragon’s Den at the end is one of the high value pieces of the puzzle was that without knowing, you’re not going to have to front that your behavior probably will be slightly different.

Blair Tempero: And it’s getting people on stage, that’s another skill to your bow.

Shane Gibson: Yes, the beginning of facilitation. It’s something that a lot of the development teams are uncomfortable with. Again, I gotta say what 25 people are involved with and you’re one when you did it and they were 25 cold presentations from everybody.

Blair Tempero: So we’re up to over 14 hours, that’ll never be an interesting one.

Shane Gibson: Wow, that’s interesting idea. Would have been different. The teams will be bigger now, because what we’d say is, one person is gonna be a product owner, one person is going to be a scrum master. So these two roles. And we’ve probably seen still need four to five people in each squad. So you’ve probably got five teams of eight now. So you’ve proven you can do a fun team. 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.

Blair Tempero: So when you’re running?

Shane Gibson: Well, at the moment, those teams are still coming out to speak. So we’re not at the stage yet where it’s safe to experiment in that way yet. We’re not trying to prove the things that you needed to prove and tested their time, but they will eventually. The question is, when can you get permission to do your technical debt one?

Blair Tempero: Well, the innovation one that 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 gonna 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 on people’s calendars and you put off by things like that, you’ll never get around to it.

Shane Gibson: We know if you’re not focused on it, it becomes a secondary task and then even quite gets done, done. Well, 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 when we publish the podcast. And then if anybody’s gonna go and give it a go, give us some feedback via Twitter, how you went? And then as soon as Blair figures out when he’s going to book the technical debt one, we’ll do a follow up podcast in a couple of months and see how we win.

Blair Tempero: Yeah, I’m pretty excited now. Just get over phantom date.

Shane Gibson: Well, I think that sounds done. We’ll catch y’all later from Sunny Wellington, New Zealand. Not at the moment, but it has been up until now. So we’re just keep pretending that Wellington Sunny. Catch you later.

Blair Tempero: Cheers, bye.

PODCAST OUTRO: You’ve been listening to another podcast from Blair and Shane, where we discuss all things AgileBI