Combining agile and data five years on with Blair Tempero - Episode #50

Welcome to the Agile Data Podcast, where we talk about the merging of agile and data ways of working in a simply magical way. Welcome to the Agile Data Podcast. I'm Shane Gibson.

And I'm Blair Tempro.

Hey Blair, welcome back. So for the audience who don't know, I've been doing the Agile Data Podcast for almost 5 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, and actually the first 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 3 or 4 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 5 years ago. So when I thought about what the hell could I do for episode number 50, 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 5 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 listened to the episode where we introduced ourselves.

Thanks, Shane. So my name's Blair Tempro. 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 basically 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 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 them 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 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. I thought Scrum was obviously a rugby analogy, Agile was some sort 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.

So from memory, before you moved into that Scrum Master role, you were a business analyst?

I was a data analyst.

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 and you've worked with that, people coming from an analyst background tend to adopt the right stance for that role?

Yes, I do. Absolutely. We've got 5 Scrum Masters now in our team, and they've come from mainly analyst roles. I'd say that 4 of them analysts, one of them is actually a product owner in the past. She's found that in her 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. 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.

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

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 those further up the chain. We've committed to 80 points this sprint. The Agile Delivery Leader's 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.

Sounds like an Andy Patton 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 in 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, 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-off 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 owner 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 does 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 1 to 3 iterations, they're looking at 6 or 12 months to 2 years to 3 years. So 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 are talking about. You are 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, you, 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 are 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.

Yeah. I mean, 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 3-week timebox. 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 it'll have marching ants around it on every report. And when that 80 is not met, it's inquisition as to why it didn't.

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

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 as much as is sensible across the different projects that they're working on. And part of that has 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 a 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 a continuous improvement project 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. Make sure that we have retro. I leave the retros up to each individual Agile Delivery Lead. I'm not going to standardized, that would be boring. Just working with those 5 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, we'll work, work through. Yeah, I'm not telling anyone the best way to do it. We'll work and we'll find the right solution as a team.

That's great, Pat. 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 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 5 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 has there been 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 5 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.

We went through a stage, probably around 3 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 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 100 days. There would have been a lot of organizations 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. We had the two teams, if you remember rightly. One of them was working building Qlik apps. And the other one on other initiatives. And with the 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 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 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 online by having that iter approach, not trying to swallow the elephant all at once.

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 tends 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 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? 'cause you had senior management change and you had this middle management change, and each of those would've impacted your ability to keep iterating on these agile practices.

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 been 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? Shh, shh, don't let the troops know. Otherwise, there's a possibility they might have tried it before really badly. So that was cool until I think we dropped it after we were well integrated.

I remember when I first started, she said, you can't use the A word. I was like, all right, what do we call it? She goes, iterative. And I went, I don't care. This is 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 it hadn't worked for them, so they were against it. Iterative for quite a while. And thinking back to that, so 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. Yeah. And 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 at 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, you know, when we change the way our 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 they'd go to Team A or Team B. I think we actually had a competition for names, didn't we? But anyway, they go to And what were the names? Can you remember?

It was, yeah, it was, it was Kelvin and Knights.

Yeah, that's right.

So Kelvin, this was really a warning sign. It should have been that they called themselves Kelvin, 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's that going to work when somebody's working on BAU? And we were quite intrusive with our standups. 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.

There's consequences to every decision. I think the fact that we made everything visible worked. I think if we had have put them in a different building as a secret project or hid them away so that nobody knew what was going on, that would've actually made it worse. I think that would've made 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. I think for us to actually build a new airplane with 25 people on board and stopping any other airplane flying exactly at the same time would have meant 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.

Yeah, no, that worked. It worked really well.

I've seen teams scale where they scale by skill. So there's kind of data engineering skills and analytics skills and visualization or BI skills. And it's not my preferred way of scaling, but I always say, try it. If it works 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 upskilling in 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 conch huge though, because it was top of mind for me right now because I had an ask me anything from somebody overseas and they were saying, how do you deal with BAU work versus 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 3 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, you know, 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-assed 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?

So we've got a better pattern now. It was tough because we had 100% dedication to the work in the sprint. So we had very few resources available for BAU stuff, 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 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 refer 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 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, we'll form a mini Scrum team. So the team leads will 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 How long would that temporary team survive for?

How long would they work together? Is it typically, is it a couple of weeks? Is it a couple of months?

It's usually a couple of weeks.

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

Absolutely. At first, I was a bit ho-hum about it. I thought maybe it's not the way that Agile should be used, as it's like a throwaway team. But it seems to work, and we've 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're a full multifunctional team that it really works.

And it stops that problem with PI Planning where PI Planning's a time horizon of 3 months, which actually means it's 9 months because everything's already been pre-prioritized for the next planning session, probably penciled in for the one after that. So assuming everybody delivers in 3 months, the massive release trains, you 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 9 months before we can look at it. And the business person's, but it's just a small piece of work and 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, so the teams have enough skills to actually get the end-to-end job done, still the way you're working?

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, okay, 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 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 everyone that's in a team or on the outskirts of a team knows the way that we work.

So on that, because there's this idea of academies now internal into 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 learned 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'd 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 who's been there for a while as soon as possible. Otherwise, they're left behind, right? They 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. 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 processes you found successful for onboarding people and appreciating their skills?

So 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, the onboarding is basically you go into a team and the Scrum Master will look after you. You'll come on board at the organization and you've usually got a home on day 1. 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.

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. Things. It has to be an organization-wide kind of strategy that actually this is important, I think, to get 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 because 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?

My examples are they tend to stay Scrum Masters for life. I'll make an exception. One day I ended up not being a Scrum Master due to that sort of change in government that I mentioned. All of a sudden, I didn't have a team. To be Scrum Master too. I just had a team to be a team leader too. 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 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, 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 it's not the next step, it's rather a different step?

I think the term Agile Coach originally 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 in agile patterns. And then certification came out and you could do a 2-day certification, that's for a 10-question survey and all of a sudden you're a Scrum Master and that just enfranchised 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 if you go into a Scrum team and the way they work, there's 9 times out of 10, if not more, 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're, 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 5 teams and you're taking that coaching style, it's 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 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, has it got value for you?

So just a little caveat here, we haven't done that yet. We haven't done it across organization. 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 3-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 tribe 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.

Almost like a pre-demo day. So it's a way of 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 saying team trading where it's, we need some help over here and come and help us out, bruv.

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 gonna 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 7 different projects going on. If we give them less than 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, So when you say 7 big pieces of work, 7 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 7?

Okay, so the big one that I mentioned is in excess of 30 across 2 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 4 different work streams. And then we've got more like initiatives where it's continuous improvement, probably 3 or 4 in each team, keeping that development of ServiceNow going along.

So if we use the word product instead of project, if that's 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 there 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 to 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 a service that we can use rather than us having to do it ourselves in iterations? Is that what you mean about the split between information and technology, or is it slightly different?

It's more information being data. We're working on a new data platform moving into the cloud, but it's organizing the data very much less on the 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 teams. They're working closely, but they're very subjectively focused.

Any chance that the data architect's going down the Data Vault modeling paradigm by any chance? I think I tried 5 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.

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

Yeah, that's right, it's 5 years later, finally they've moved to the new world.

So, is that Data Vault being a A methodology or is that a product?

It's a pattern for structuring data. So no, it's not a product as such. But if you wanted 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 agile is 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.

It's just like economists.

So, it sounds like there's been constant iteration in almost everything over the last 5 years, even though you've been in the same organization. It sounds almost a bunch of new organizations every time without having to change who you turn up most days.

Oh, absolutely. There's just a few fossils 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 that kind of rollercoaster ride that we've done, and we've come out the back with good support or great support to keep Agile going. It's just that danger of getting too much into the story points. I think you picked that one up, using them as a sign of success or failure. Don't know how we can stop that.

Yeah, it's like I said, I 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. Technique. If it's been 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 they'll start using it against the agile way of working. Find what they're worried about, find some way of quashing that worry through some other mechanism, and then slowly move to swap it out as a groundswell.

Yep.

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

What about happy team, low turnover? There must be something on the human side that we can report.

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 is 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, that was a good point raised by somebody a while ago, actually, when I said that, was they're like, but 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 mean. That's not the behavioral 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 canceled 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 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 sprints. 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 hyperfocus 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 it's 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 is going to blow at some stage. How much time do how much money do you want us to spend making that safe? And then I'd visually give them two choices because that helps them decide. They 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 more focus on the organization on 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 debt is that. 9 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. Yeah, 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, uh, that'll be a great session.

Yeah. If I haven't retired, haha.

Thank you for coming on the podcast again and definitely a thank you for 5 years ago starting it with me. I enjoy 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 ones was fun, enjoyable, and yeah, something I remember really fondly. So thank you for that.

Awesome.

Excellent. Alright, we'll catch everybody later and hope they have a simply magical day. Data Magicians was another Agile Data podcast. If you'd like to learn more on applying an agile way of working to your data and analytics, head over to agiledata.io. Hiya!