Combining agile and data five years on with Blair Tempero

Join Shane Gibson as he chats with Blair Tempero on that last five years since they started the AgileData Podcast together.

Read along you will

Shane: Welcome to the Agile Data Podcast. I’m Shane Gibson.

Blair: And I’m Blair Tempero.

Shane: Hey Blair, welcome back. So for the audience who don’t know we’ve been doing the Agile Data Podcast for almost five years now. This is episode number 50. It’s been a bit random, there’s been times where lots of podcasts came out and there’s been times where there wasn’t.

But the very first podcast range of podcasts was me and Blair co hosting it together. So it was in real life. We had a bunch of guests come into the office and Blair and I would sit in this little meeting room with a speaker or a microphone on the coffee table between the three or four of us, depending on how many people we were chatting to.

And we were talking to a bunch of people in the Wellington, New Zealand market who were combining Agile and Data together five years ago, so when I thought about what the hell could I do for episode number 15, I was like, let’s get Blair back and we can have a chat about What have we seen in the world of Agile and data for the last five years?

So Blair, before we rip into that coolness, why don’t you give a bit of a background for the people that haven’t gone through the back catalog and listen to the episode where we introduced ourselves.

Blair: Thanks Shane. So my name’s Blair Tempero. I’ve been working in the same organization in a government department for almost 11 years and I met Shane when we first went through a transformation from GitLine Chaos, disorganized, and we tried to find a way of working and we found that Agile was really the way to go.

I joined as the first Scrum Master in the organization and went through some training with Shane We combined two teams that were geographically in different buildings, and we brought them together. That was the first big change we made. And then I guess I learned the ways of being a scrum master and how an agile team works.

Recently I’ve moved out of being a scrum master and into more of a team lead position, so

at the moment I’ve got 15 staff reporting to me. That’s a mix of scrum masters and BAs of different levels. We lend out the scrum masters And BAs to different projects.

And they see me when things go wrong, or they see me when they want to apply for leave, or if there are any impediments that the scrum masters can’t get through, then I’ll pretty much sit down with him and we’ll go through different options on how we can break down those barriers. So pretty much, an agile coach.

That’s really from where we started to, to where I am now. I must say that those early days were really exciting and

I didn’t know what Agile was at the time, so I thought Scrum was obviously a rugby

Shane: Ammerse,

Blair: Agile was some sort of, of yoga move how to get Agile in a Scrum. But things fell pretty much into place and I’m still an evangelist for Agile and its way of working.

Shane: So from memory, before you moved into that scrum master role, you were a business

Blair: a data 

Shane: a data analyst.

That’s something I’ve seen a lot of. I have a joke that I’ve never really seen a project manager. Adopt the role or the skills of a scrum master and be successful.

But I’ve seen a shit ton of business analysts and data analysts do it. And it was something always about that idea of flexibility, that idea of facilitation of being able to talk to lots of people, understand what they need, and then help them be successful. Is that what you’ve found? Is that when you look at the scrum masters you’ve worked with, that people coming from an analyst background tend to adopt the right stance for that role.

Blair: Yes, I do , absolutely. We’ve got five scrummasters now on our team and they’ve come from mainly analyst roles. I’d say that four of them analysts. One of them is actually a product owner in the past. she’s found that. In a previous role that she was working as a product owner, they had a very ineffective scrum master, so she took over running the team and because she had the product ownership background, it was quite an easy transition over.

She was pretty quick to implement good. I can’t say I’ve come across a project manager that’s gone in. I think it’s a totally different mindset. Obviously You’re going into a servant leadership role where you’re actually having to sit back and actually let the team lead themselves.

Blair: And I know that the few I’ve worked with would find that incredibly hard. To release that control. So I haven’t been a traditional project manager, so I can’t imagine how that would be. I’ve found especially analysts that are used to solving problems, looking at issues, certainly fit the role perfectly.

Shane: We’ve seen the whole agile market change dynamically. Some good ways and some bad ways, depending on your opinion. And one of the things I’m seeing is people that have a scrum master role. Sometimes get moved from the focus of the role being supporting the team, looking at the team, looking at the way the team works, helping the team be better as a team.

So standing behind them to more of a delivery focus, not a project manager as such, but they’re more focused on the delivery of the work, not helping the team that are doing the work. What are you seeing? Are you seeing that happen 

Blair: I am actually, . I’m seeing firstly the role scrum master be replaced by agile delivery lead. I’ve seen that become more prominent and especially in our organization, We’ve made that change, where the focus is not only on the development of the team and helping the team improve, but it’s also a responsibility to reach the metrics that have been agreed between the product owner and the team.

Those further up the chain. We’ve committed to 80 points this sprint. The Agile delivery lead is responsible for making sure as best as possible that we reach that 80 

The metrics are becoming certainly a lot more visible to upper management C suite, which is quite interesting. I’m not saying I agree with it

Shane: Sounds like an Andy pattern to me, but let’s explore that a little bit. So what we are seeing a little bit in the market is the idea of a product manager and an agile way of working. And this is where we go in product manager versus product owner, let me put a bit of framework around that for us to have the discussion.

If we think of a product owner as being a role in scrum and they sit between the team and the customer, the stakeholder, and we can argue about that later and the product owner in this case is typically a subject matter expert, but definitely somebody who has the relationship with the key stakeholders.

And they’re helping the team get the trade offs decisions of work that will and won’t be done. So they’re reducing the time between the team getting stuck on some alternatives or some questions or some scope and having a single person that can come back and go, A, not B, carry on, so that’s the role that’s looking at.

And then the product manager is more macro. So where a product donor would be typically bound to one scrum team. For an iteration or multiple iterations, depending on how your organization works. The product manager is normally across multiple scrum teams. It’s normally looking at a form of a product.

They’re then looking at what is value to the business look like? What are the metrics for a product, not the team? Where do we get funding? Often I’ve seen the data lead or the head of BI or the head of data actually form that, . Product manager role they’re figuring out where the money comes from.

Typically they are doing a little bit of moving of money around, depending on who’s got money to fund things and what the team needs to deliver. They’re looking at a longer time horizon. So rather than one to three iterations, they’re looking at six or 12. Months to two years to three years.

That’s a form of a product manager. And there’s a bunch of metrics around that what does it look like a success of data in your organization? But that’s not what you’re talking about, you’re talking about somebody looking at the metrics for the team. So rather than say to the team, you’ve got some problems there.

I can see them, they’re there in the retro, you raise them. You don’t seem to be operating as efficiently as you could. Go fix it. What you’re saying is there’s a bunch of metrics that this person, this agile delivery lead is held accountable for so they can manage them, and to me that sounds like an anti pattern.

Blair: yeah I mean that they’re not fully responsible. The product owner is obviously dictating to a certain degree what comes into the sprint. The team can scream and yell that it’s just too much for the three week time box. And generally they do come to an agreement. It’s not all dictatorship from the product owner who does report to the product manager.

So there is compromise there, once that target has been set, that target will trickle right up to senior management saying that, especially if it’s a high profile product that you’re working on. That 80 will be in NEON and that’ll have marching ants around it on every report and when that.

80 is not met, it’s a inquisition as to why it didn’t, 

Shane: so that sounds like weaponizing Of story points, and again, I’ve probably said this on many podcasts, but let me reiterate it again. My view as an Agile coach is when management starts weaponizing story points, we stop doing them. , obviously I have the ability to be an external Agile coach and I can take stances that people in an organization may struggle with, but story points are there for the team.

They’re not there for anybody else to monitor. We probably do need metrics to say we deliver value and that’s a coordination between product manager, product owner, and the team. For me that’s an anti pattern that idea of agile delivery lead or delivery focus rather than team focus is something that I’ve seen happen in the market you talk right now about your role is pastoral care. I call it for a team of people. Do you also work with them to improve their way of working? So do you work with the scrum masters to, , say let’s look at our practice, our way of working. How can we improve that? So if we think about the old chapter leads or guild leads Out of Spotify model, even though it’s not a model you’re doing that,

you’re looking after the health of the team, making sure that they’re good and their ways of working as a group of people, because they’re not working together that often.

Blair: that’s right, the BAs are a separate kettle of fish, we can talk about them a bit later, but with the scrum masters, we’ve been working on a way of standardizing them. As much as is sensible across the different projects that they’re working on and part of that is, actually been learning parts of Scrum, parts of Kanban that not all of the team have been exposed to.

For instance, PI planning most of the team haven’t come from A safe background or PI planning sort of methodology so we’ve had to get really close to learn how that’s done so we’ve formed a little working group to improve how we use PI planning.

We’ve got an continuous improvement projects that we’ve called Agile Ignite. The first stage of Agile Ignite was to make sure that we’re using those standards across each Agile delivery lead and the projects that they’re working on. We’re filling gaps in knowledge. So as I mentioned, the PI planning story points, making sure that we are consistent 

we’re not using time, we’re using effort. We’re looking for a midpoint. And we’ll look at stories that we’ve already used before, and if they’ve worked, then we’ll keep that score. Just little things to keep things. Consistent across all of the teams, making sure that we have retros.

I leave the retros up to each individual Agile delivery lead. I’m not going to standardize that would be boring. Just working with those five people to fill those gaps, but make sure that we’re a team within a team. We spend quite a bit of time. On Teams, we’ve got a Teams channel and if anyone has a problem then we’ll work as a team to solve it.

If they can’t remove an impediment, then as a collective will work it through. I’m not telling anyone the best way to do it. We’ll work through it and we’ll find the right solution as a team.

Shane: That’s a great patent. I see this idea of a coaching circle, even if you’re not being aligned with one person who’s got pastoral care. But this idea of a coaching circle where, you know, scrum masters or coaches get together on a regular basis, discuss the challenges they have and get help from their peers effectively.

And then, incrementally change the way they work as a team, even though it’s a, may not be a team in an organizational structure. It’s a team in terms of what they do. And on that, it’s been five years. Your organization has been through, as most government agencies have, multiple changes.

Your teams have been through multiple changes. That idea of iterating your way of working, how’s that gone? Has that been. Constant or is there being, spikes where you do it and then , something would happen and you stop iterating and then you go, okay, now it’s actually, we’ve got major problems.

Now we need to go into a cycle of iteration again. How have you managed that over the five years, given the massive amount of changes your organization has gone through, which most organizations go 

through, let’s be fair, it’s not just yours.

Blair: , we went through a stage probably around three years after we first got together and changed our way of working where there was a change of government and we had this 100 day plan thing and one of our initiatives was on the 100 day plan. So we had to basically drop everything. It became a like An organization wide initiative, and we tried to use Agile as much as possible, but it was really just a rush to the finish line to get that initiative ready

and then we filled the gaps in after the hundred days. There would have been a lot of organisations doing that. And we’ll probably get a little bit of that this year.

So that put us off our track. I no longer had the dedicated. Teams with the two teams. If you remember rightly, one of them was working building click apps and the other one on other initiatives and with 100 day plan, everyone basically got poached and I ended up just being that pastoral manager while these program and Project managers were brought in to help us get along to that finish line, and we went back into some of the anti patterns that we had prior to you coming in and helping us with our transformation.

So that went along for a little while until we had a few changes in personnel, and you can imagine all along I’ve been preaching. Agile in the background and getting limited support. So , I just had myself on auto, almost like an alarm clock every day. Are we going back to Agile?

Are we going back to Agile? And then with a few changes in personnel I’m happy to say that we’re. We’re back on track. We’ve had a few big initiatives that have tried and failed and then we’ve said, hey, why don’t we try this? We can’t. Do any worse than it was previously and we’ve had some success stories out of helping bring projects back on online by, having that iterative approach, not trying to swallow the elephant all at once.

Shane: Don’t boil the ocean, that idea of leadership change. There’s multiple levels of leadership change that often impact how an organization works. there’s the one where the top table gets changed new leader comes in, new chief executive or new senior leadership team, and they’ve either worked in an organization that’s adopted an agile way of working and had success or they’ve worked in an organization that tried to adopt it and had failure and that seems to bring a whole perspective to it.

And then secondly, as you said, you get this idea of a program and project managers coming in. And again, They sit between the senior leadership team and the people doing the work, and they bring their past practices with them. As we all do, as you said, you’ve got used to an agile way of working, so you’re just sitting there, on repeat going, work for me, work for us, can we do it again?

so have you found that? Because you had senior management change, and you had this middle management change, and each of those would have impacted your ability to keep iterating on these agile practices.

Blair: So certainly the senior leadership changes has helped us out. We’ve had somebody that’s come from, as you said they’ve seen the success of Agile being implemented we’ve had The go ahead to bring teams together across different disciplines we’ve also had changes at middle management level or team leader level, which have included some that have changed. Thank you. Been part of a successful agile change in the past as well, so everyone in the picture has seen what good looks like, and , we often reminisce, 

of, the successes of the past and how we can use those to help direct the future. I know that when we first adopted Agile, we weren’t allowed to say the A word and , so I did a bit of research and I remember going up to the manager at the time one day and saying, hey, this is agile, isn’t it? She said, don’t let the, Don’t let the troops know, otherwise they’ll, there’s a possibility they might’ve tried it before really badly. so that was cool until I think we dropped it, after we’re well integrated. 

Shane: I remember when I first started, she said, you can’t use the A word. I was like, alright, what do we call it? She goes, iterative. And I went, I don’t care. That’s good, I’ll call it anything you want, 

and that was because some of the senior leadership had been in organizations where, that approach had failed in their eyes. And then some of the team had worked in places where, hadn’t worked for them, so they were against it. Iterative for quite a while. And thinking back to that, it was quite a large team from memory. It was 20 or 25 people in the wider data team at the time that we started. One of the things that I thought we did really well in hindsight, and I do a lot of now, is saying actually to change the way we work with 25 people in once is great, but it’s actually dangerous.

We don’t have our way of working. It’s hard to coalesce 25 people together. We also stopped doing BAU or any work as we do change, and when we change the way a team works, the team are nowhere near as efficient at the beginning than they were before that change happens. So we split a small group off to experiment with this way of working from memory, and then when it looked like it had traction, then we went back and from memory we scaled by splitting the original squad pod team, whatever you want to call them, in half, and then co locating them with the other two.

And that way they could cross pollinate this way of working from being within the team. And then, I think from memory, we had two teams and they were split by product, not by function. So work came into the queue and it would go to team A or team B.

I think we actually had a competition for names, didn’t we? But anyway, they’d go to, what were the names? Can you 

remember? 

Blair: was. Yeah, it was it was Kelvin and Knights.

Shane: Yep. That’s right.

Blair: So Kelvin this was really a warning sign. It should have been that they called themselves. Calvin, somehow expecting the other team to call themselves Hobbs without talking to them. And then at the end it was like, how do you think that was going to work?

Just on that, it was really interesting when we did start that first team. And the interaction between those in the team and those that almost missed the team, missed out on the team and I think we’ve talked, about that previously about is that going to lead to bad behavior or how is that going to work when somebody’s working on BAU and we were quite intrusive with our stand up.

So I remember we were using a board at the back of the room. With a lot of the team that were working on BAU, so they weren’t in the initial squad. So that must have been quite brutal for them, I think, looking back

Shane: There’s consequences every decision. I think the fact that we made everything visible worked. I think if we had put them in a different building as a secret project or hid them away. So that nobody knew what was going on. That would have actually made it worse.

I think that would have made the people who weren’t able to participate. I still don’t think we could have changed 25 people. I use the term building the plane while flying it. That kind of came out of that first piece of work and I use it all the time, but I think for us to actually build a new airplane with 25 people on board and stopping any other airplane flying at exactly the same time would have meant we, we would have run out of runway.

Before the organization said, hey, stop, we need to go back to the old ways of working because nothing’s actually getting done. There would be no value or outcome for them yet.

Um, yeah, really well.

I’ve seen teams scale where they scale by skill, so there’s kind of data engineering skills and analytics skills and visualizational BI skills.

And it’s not my preferred way of scaling, but I always say try it for weeks for you carry on. Just focus on the handoffs. When we have self sufficient teams and we end up with multiple of them, we have to focus on a couple of things. We have to focus on the way the work comes in, the way it gets picked up.

When pre work happens outside the iteration, who does that? Because it could go to any team. Are the teams bound to a domain? Is there a certain amount of data or business processes, which makes sense for a team to focus on because upscaling and that subject matter is important how do we make sure they don’t work on the same object or thing or table or piece of code or server at the same time?

And what do they need to support? I seem to remember we actually ended up implementing a platform team, but I’ll get to that in a minute. Let’s go back to that CONTUGE though, because it was top of mind for me right now, because I had a asked me anything. From somebody overseas and they were saying, how do you deal with BAU work versus a project or new work?

And I remember. We did this concierge process where effectively it would come in, it would get triaged and then somebody would pass it out to a BAU team versus a new work team. And the new work team were effectively running scrum, iterations based on three weeks and the BAU team were effectively running flow.

Although, I didn’t realize at the time, because I hadn’t done a lot of work in Flow and Lean, . And that seemed to work, except the BAU team ended up getting the shitty work. And what we saw was the new work team would finish a piece of work, throw it over the fence, and then the BAU team would have to pick up all the technical debt, and that wasn’t fun for them

they never got any of the new build stuff. It really wasn’t a concept of DataOps, it wasn’t a concept of you build it, you deploy it, you maintain it, you break it, you fix it. You could actually build something that was half arsed and then go, not my problem. And I think we dropped that very quickly, but is that what you remember and what you saw?

And have you tried 

that 

pattern again lately or not?

Blair: So we’ve got a better pattern now. It was tough because we had 100 percent dedication to the work in the sprint. So we had very few resources available for BAU staff. And we didn’t have a team that was dedicated to BAU stuff. So both teams were actually working on initiatives.

, I don’t think we really had a very effective. Kanban type situation to deal with that stuff flowing through. Now we have, which is great and I’ll give you just a little overview of what we’ve come up with. We call it the commissioning process and this is very much a team effort.

Blair: Based on using ServiceNow as a tool. So this is a plug out to ServiceNow there’ll be the existing workflows. If something’s broken, if you need help with something, then that, it’s the concept of user groups. So those things will flow through to the existing user groups.

So we’ve created a channel which is I want something new or I want something changed to something existing, so that’s another channel through ServiceNow that the user will go through and that will come through to a commissioning triage group that’s made up Of level 3 so the Information Directorate, Leadership Team, as well as level 4, so the team leaders below them, so every fortnight we will look at all of the new items that have come through in that fortnight And we’ll go through each one.

We’ll go through a little bit of a process where , we’ll look at the size of it and the effort required. if It’s obvious what team that needs to go through, then that’s just a straight refers through to The appropriate resolver group. If it looks like it needs maybe some money or some external resources, then 

the manager talk to the senior leadership team about, hey, this has come up, and then they will talk to the business and see where that fits in terms of priority and it will either go or stay in, in the queue.

Where I think we’ve added the real value is, if it looks like something that’s not big enough to be a project, it’s an initiative what it requires is cross collaboration between different teams. So rather than have a ticket and then it will.

Be assigned to one team and then once they’ve done it, they will assign it. That sort of waterfall type pattern will form a mini scrum team.

So the team leads We’ll assess, hey, we need a developer. We need a tester. We need a BA. We need someone to help us with cloud integration.

I will go away and make sure that we’ve got a resource . From each of those required areas that we can put into a mini temporary scrum team. we’ll use all of the Agile methodologies to get that done and then we’ll disband. 

Shane: How long would that take? Temporary team survived for? How long would they work together? Is it, typically, is it a couple of weeks? Is it a couple of months?

Blair: it’s usually a couple of weeks, 

Shane: so you’re grabbing a bunch of people that typically haven’t formed together yet, you’re putting them together they’re going to form, do that work, and then just spend in a couple of weeks, and that’s working for you.

That’s a great pattern. It’s a hard pattern, right? Because You’re putting a bunch of people who haven’t really worked together long term together to get a piece of work done and then you’re disbanding them. So the startup and shutdown time is quite large

Blair: I absolutely at first I was a bit ho hum about it. I thought maybe it’s not the way that Agile should be used to as it’s like a throwaway team. But it seems to work and we got the right people. We’re doing morning stand ups. We’re planning.

It’s a pattern that’s working well. We haven’t used it a hell of a lot because it’s not often we find things that Aren’t going to require money and resources, but we’re finding heaps of times where one team can handle it on their own, but it’s where you need a full multifunctional team that it really works.

Shane: And it stops that problem with PI planning where, PI planning is a time horizon of three months, which actually means it’s nine months because everything’s already been pre prioritized for the next PI planning session. And probably. Penciled in for the one after that, so assuming everybody delivers in three months the massive release trains you’ve still got a massive delay to the organization for any new pieces of work, especially small pieces of work.

And that’s one of the problems with that type of working is small piece of work comes in and you go it’s nine, nine months before we can look at it. And the business person’s But it’s just a small piece of work and you you’re right, but from a prioritization we can’t do that. So this ability to spin off a small team, get them to deliver something quickly and then shut back down and then come up when they need to again is quite cool.

And so on that. Are there any other ways you’re looking at scaling teams, ? Is it still self sufficient the teams have enough skills to actually get the end to end job done? Is it still the way you’re working?

Blair: I might just go back to those small teams quickly that are forming and just forming that’s part of our Agile Ignite program is to make sure that nobody is coming in without an expectation of what that looks like. I know that most developers and BAs and testers have now got exposure to Agile and they know what it means.

It’s a lot different than when we started, where we had a lot of people that were like, Oh, OK, what’s this? I don’t do meetings. I like to put my headphones on and just develop code. We’re having a little bit of a a checklist that, hey, if we are bringing. These new people on board that they get a bit of training, so that’s where the guidebooks come in so that we can make sure that you know everyone that’s in a team or on the outskirts of a team knows the way that we work.

Shane: So on that, because there’s this idea of academies now, internal and to organizations, this idea of a way of training people in your way of working and Walmart had the idea of a dojo, which I loved, which was when new people turned up, they got moved to a separate building and that building was a dojo, but they actually did the work.

So they did the work while there were a bunch of coaches who were responsible for training with them. So they learnt by doing, but they were in a safe environment where they weren’t in a team that was, doing a full iteration. So they could learn the process by doing it, massive amount of support.

Focus on training and learning as much as on delivery and then once they had exited the dojo, they could go, back into their new team. And so this idea of guides, this idea of onboarding people, it sounds like you’re starting that journey towards an academy, towards a dojo.

Because you know it’s important that as people change, you know the new people coming in have to come up to the same speed as everybody’s been there for a while as soon as possible. Otherwise they’re left behind right there.

kind of sit outside the team for so long before they can be part of the team because they don’t have the same language.

They don’t have the same experience. They don’t have the same level of maturity in terms of agile patterns and ways of working.

just talk me through that. I turn up and I need to be accelerated into the teams. How does it work? Are they given a website to read? Are you sitting with them? What’s the actual process that you found successful for onboarding people increasing their 

Blair: we haven’t, 

so we haven’t actually rolled out Agile Ignite as such. We’re still in the building stage of it, but at the moment that the onboarding is basically you go into a team and the scrum master will look after you. You’ll come on board at the organisation and you’ve usually got a home on day one you’ll go through all of the safety stuff and we’ll get you on board, we’ll Integrate you into the organization, but then it’s time to integrate into whatever project you’re working on, so it’s very much in the hands of the Agile delivery lead at the moment to make sure that you’re given a background, so any documentation that will help you get up to speed on the initiative or project that you’re working on. Obviously bring you onto as many of the ceremonies as is applicable and I’ve found that once you start to work as a team, then you become part of the mix. So it’s very organic at the moment. The Academy sounds great, but I can’t see it at our place just yet.

Shane: It’s a big level of investment, and then You’ve got to keep investing in it, so it’s not a one and done thing, it has to be an organization wide kind of strategy that actually this is important. I think to get the the ability for people to be dedicated and focus on all those areas. And so if we look at that area of growth, the theory used to be, you start off as a scrum master and you become an agile coach maybe. But what we see is there are a lot of people that go, I’m a scrum master. I’m a bloody good scrum master. I love being a scrum master. I don’t want to do anything else.

I want to get better as a scrum master. Cause I love helping teams. Fills my boat every day. What are you seeing in terms of. Growth of scrum masters in your organization. Do they tend to, start off as scrum masters and then become something else, go into a team lead role or pastoral care role, or do they tend to be scrum masters for life?

Blair: My examples are they tend to stay scrum masters for life. I make an exception, one day, I ended up not being a scrum master. Due to, that sort of changing in government that I mentioned, all of a sudden I didn’t have a team to be scrum master, to.

I just had a team to be a team leader to at that stage. I could have jumped and said, hey, I want to keep this going because I really love it. I still love what I’m doing here. So everyone is, that I’ve seen has, stayed Scrum Master. A few have got into Agile coachinG.

I don’t see Agile coaching as the next step in a sort of a career progression. I think it’s a totally different job in my views. I’ve seen scrum masters that actually hate teaching teams. They want to concentrate on their team and not have to jump around and coach other people.

They just love the thought of one team or two teams as long as they’re theirs and helping them improve. I don’t know what you think about the difference between coach and if, what have you seen in that space? That a coach 

doesn’t necessarily come from a scrum master or. not a, it’s not a, the next step. It’s rather a different step.

Shane: I think the term agile coach really started off as a dirty trick to the market. I think it was, and I’m opinionated on this, so it was a reaction to scrum certification. So my view is what happened was scrum masters were coaches. They taught, they mentored, they coached, they supported, they trained.

Their teams and agile patterns. And then certification came out and you could do a two day certification answer, a 10 question survey. And all of a sudden you’re a scrum master and that just enfranchise the people with experience. And so they changed the term to coach. That’s where it came from, in my opinion.

Where are we now? Agile coaches often coach more than just Scrum. I always crack up. You go into a scrum team and the way they work, there’s nine times out of 10, if not more, there’s a , a Kanban board, but that’s a Kanban board, not a scrum board. So that’s a pattern from a different, dojo or different art.

Which is great, it’s a valuable pattern. Coaches potentially have experience in Lean, Kanban, Flow, all these other different ways of working. These patterns that are valuable. Coaches often are more consultants, they, like you said, more temporary and they come in to help a team or an organization and then they get out, or they may be in an organization permanently, but help more than one team.

I have a maturity framework I use now for skills within a data team. So from, novice , through to a practitioner, through to an expert, through to a coach and the expert to coach is for me a big jump because as you said, it’s when somebody goes from being an expert in their job, being, the best they can be at doing that work to coaching somebody else, how to do that work the way they used to.

And that is a big change, that is a change in what you do every day, the way you work, the way you articulate things, because you’re no longer doing that work. So I think agile coaches often are that, they’re no longer doing the work, they’re helping other teams do it. But actually it doesn’t matter, 

If you’re a scrum master of five teams and you’re taking that coaching starts, good, call yourself a scrum master, call yourself whatever you want, but just intrigued of what you’re seeing in that market and in terms of that, in terms of being highly opinionated. You’ve used the word transformation, you’ve used the word program, and you’ve used the word PI planning. It’s fairly out there that I won’t work with any organizations that operate safe. Because I don’t believe in it, and I just don’t want to be there, and that’s my opinion. And that’s okay, because it’s about what I want to do. But as somebody who’s working in an organization that has PI planning, how do you find it?

Has it got value for you?

Blair: So just a little caveat here. We haven’t done that yet. We haven’t done it across organisation. We’ve got one project that’s doing it and they’ve done that. Ever since they were over in another building and the project had another name. They do three monthly PI planning across multiple streams.

But the thought now is that we will get all of the projects plus BAU initiatives that are running Kanban

into a room after they’ve done their planning to do a summary, to the rest of the ID. Directorate on what’s coming up next. I guess, the planning side of it, and this is where you pick up your collisions who’s needing different environments at different times it’s really for that sort of risk mitigation side of it but it’s also somewhere that Senior management can sit down and see exactly where every initiative is, it’s a way that management can package everything up and say, look, we know everything that’s going on at a big scale in the information directorate 

Shane: Almost like a pre demo day so it’s a wave. Communicating and collaborating what everybody’s working on so it’s like a demo day for work you plan to do, not a demo day for work you’ve done. And we know that demo days have value, we know that actually showing the work was done is a great way for everybody else to be able to actually see who did what and maybe they can leverage it.

So if you do that the other way around, then everybody gets a sense of what everybody’s working on and then they can go away and Do that. And when you said wall sale, I was thinking you meant, the amount of wall you need to be able to do that thing where you put dots on the wall and trace wall between the dependencies

across all the teams.

But No.

you’re, you’re saying team trading, where it’s we need some help over here and, come and help us out, bruv. 

Blair: But I think once we get a little bit more comfortable with it, that might happen. Don’t see that as being a bad thing. It’ll be interesting. The first one’s going to be a little bit chaotic, I would imagine, and there’ll be a lot of things to learn and we’ll hopefully take it down a notch from a day to maybe half a day.

We’ll see how the first one goes. So we’ve got approximately seven different projects going on. If we give them a lesson an hour each to let us know what they did previous sprint and what they’re doing for the next iteration at an epic level or at a feature level.

Shane: So when you say seven big pieces of work, seven projects how big are they? I don’t need to know exactly how many story points they’ve committed to and that the agile leads are holding them accountable. But how many people is typical for what you call a project for each one of those 

seven on average? 

Blair: okay, so the big one that I mentioned is an excessive 30 across two streams. So we’ve got an information stream and a technology stream. That will make up the bulk of it. We’ve got another project it’s dwindling down and that’s probably about 20 across four different work streams, and then we’ve got more like initiatives where it’s continuous improvement initiatives where there’s probably three or four in each team keeping the development of service now, going along, 

Shane: so if we use the word product instead of project, it fits right? We can say that you’ve got a product which has, 20 to 30 people. It’s a large product. there’s multiple teams within it delivering that product and then they are. Other products where it’s smaller. With that, that large one, when you talk about information technology, is that back to that pattern that I talked about that we got to right at the beginning when we started the scale where, we had a team that started building out the.

Data platform, because back then we needed to invest some time and effort into building out some new technical capability for the delivery teams. And then there were delivery teams that became the customers. They asked we need this kind of capability going forward. Can you build that for us as a product or service that we can use rather than us having to do it ourselves in iteration?

Is that what you mean about the split between information technology or is it slightly different?

Blair: It’s more information being data, we’re working on a new data platform, moving into the cloud but it’s organizing the data, so very much less on the data side. Technology and more on how we’re going to structure the data. So you’ve got, the data architect and data analysts involved with that more so than cloud stack developers, which are in the other team.

They’re working closely, but they’re very, subjectively focused, 

Shane: any chance that the data architect’s going down the data vault modeling paradigm by any chance? I think I tried five years ago to get the team to Approach that one and you were firmly embedded in the dimensional modeling at the time and it made sense not to change that because we don’t want too much uncertainty.

Blair: I’m not close enough to know that one, but I can find out for you.

Shane: Yeah, that’s right. It’s five years later finally they’ve moved to the new world.

Blair: So is that Datavolt being a or is that a product? 

Shane: It’s a pattern for structuring data. So no, it’s not a product as such. But if you want to buy a product, I know a really good one, because we build it. It’s just a way of data architects always argue about the right, like Agilis, arguing about which patterns work and which don’t, and having strong opinions on things like SAFE, data architects are just like that, and that there’s flavors that they love and flavors they don’t like.

So I’m a bit bigoted on that one as always. 

Blair: Just like economists, 

Shane: So it sounds like, there’s been constant iteration in almost everything over the last five years, even though you’ve been in the same organization. It sounds almost a bunch of new organizations every time without having to change

you turn up 

most days.

Blair: Oh, absolutely. There’s just a few fossils of like myself , or cockroaches that have survived a few nuclear wars , within the organization. But it’s amazing just seeing how we’ve moved from. Going through the kind of roller coaster ride that we’ve done and we’ve come out the back with, with good support or great support to keep Agile going, it’s just that danger of getting things.

Too much into the story points. I think you picked that one up using them as a sign of success or failure. know how we can stop that.

Shane: Yeah it’s like I said, I’ll use the nuclear option, which is we no longer do them, but that’s only because I tend to come in a position of privilege where I can try that technique. If it’s being used throughout the organization, then you’ve got a problem and. We just chip away at it you know what I would do, I would try and find other metrics of success then I would start reporting those alongside the story point reporting and then I would work with leaders in the organization that have influences that can become subservient leaders for the organization and help them influence other leaders to say actually that’s a better metric. So they’d work in the background with their peers going, yeah, those story points are great, but actually this metric over here is what I use because it gives me a better sight of success. And that’ll take you a while, but going head on is asking for a hiding and, yeah, people will start saying what you’re trying to hide from delivery.

So we’ll start using it against this agile way of working. Fine. What I worried about, find some way of, Quashing that worry through some

other mechanism and then slowly move to swap it out as the grounds will.

Blair: yep, 

Shane: But that leaves you with the problem, which is what’s the metrics that can show success and not make them worry

Blair: what about happy team, low turnover, there must be something on the 

human side that we can report, 

Shane: If we put our business leader hat on and we sit as a senior leader. They have a bunch of things they’ve promised to their stakeholders, and they want confidence it’s going to be delivered. So therefore they’re just looking for ways of going, like your PI planning.

How are we going? Are we going to make it or not? How do I get early warning? How do I know if there’s a problem? And, looking at the amount of work being done as a natural. Thing everybody goes to, people are busy. It’s good, they’re probably working on the wrong thing.

They’re hiding all the complexity. They’re doing the easy tasks. They’re gaming the story points. There’s a whole lot of things that humans will do when they’re held accountable to the amount of effort. Not the amount of value, but it’s hard, how do you then say what’s the definition of success?

How can we measure thaT? The other one I’d watch out for is rework. I’d be hyper focused on rework.

Because we know that rework’s a thing that reduces our ability to deliver. Now, there was a good point raised by somebody a while ago, actually when I said that, was that like, there is some good rework, 

there is the ability to experiment early, do small bits of work, and then rework it when we learn more. So we’ve got to be careful even with reworks that can turn into a weapon, no rework! Okay, so now we need big design up front. Big requirements because I can’t touch it again. And I’m 

like, Oh shit, that’s not what I meant.

That’s not the behavior of the pattern that I was after. So yeah, everything can be a pattern or an anti pattern given your context.

I’d look at your organizational culture, and so if you tell me that people are hyper focused on the story points,

having a technical debt sprint will get cancelled very quickly because it’s points being spent not adding value. What I’d do, make visible a register of technical debt stories.

So I would enable the team to record every technical debt story they see and put a points estimate on it. I wouldn’t even worry about any kind of curation of those estimates, just tell them not to be dicks.

And Then what you’re going to be doing is surfacing this cost, this asset that’s degrading, and then the senior leadership team can have a decision about when they want to pay that debt. Treat it like debt, give it interest. My natural reaction normally is let the team do technical debt work in sprint, let them carve out some points to do that work because that’s the best way, they solve the problems that are The highest value to solve because they know what they are.

But if there’s a hyper focus on points, then somebody’s going to see you doing that and then it’s going to go badly. I’d call out technical debt as a cost to the organization. I’d give it story points. I’d register it and then a prioritization for the leaders. We can work on new things, but remember that pile of aging missiles is degrading over there and going rusty.

One of them’s going to blow at some stage. How much time do you want us to spend making that safe? And then, I’d visually give them two choices because that helps them decide, they don’t know which bucket they’re pulling the work out of when they prioritize. Anything you can do to put a financial cost or an actual cost of that debt sitting there tends to get better.

More focus on the organization and prioritizing it. Otherwise it’s just stuff we don’t like as technologists or data people that, we felt like we could have done it slightly better. And sometimes that technical deal is that, but nine times out of 10, it’s the team saying, you’ve made me cheat,

you’ve given me a trade off decision that I don’t agree with because I know it’s going to bite us in the bum and that’s okay, that’s your job to prioritize and make those decisions. But I want to call it out that actually we need to go and deal with that at 

some stage. 

Give that a go and see what happens. Let me know. Come back on the podcast at episode 100 and we can say, How’s your PI planning going? And how’s your technical debt management going? And have you managed to change the core metric from a team from being story points to value delivered?

And then that’d be a great session.

Blair: Yeah. If I haven’t retired, haha.

Shane: Thank you for coming on the podcast again. Definitely a thank you for five years ago, starting it

with me. , I enjoyed doing things with people and I think if I had to do it on my own, it wouldn’t have lasted as long as it did.

And , definitely you working with me right at the beginning to do those in person as well was fun,

enjoyable. And yeah, something 

I. remember 

Really fondly. So thank you for that.

Awesome.

Shane: Excellent. Alright, we’ll catch everybody later and hope they have a simply magical day.