AgileData #8 - A new way of working

Welcome to the Agile BI Podcast, where we chat with guests or sometimes just to ourselves about being agile with teams who are delivering data analytics and visualizations. Welcome to another Agile BI podcast. I'm Shane Gibson.

I'm Blair Tempro.

And I'm Pete Tansey.

Hey Pete, well, welcome, thanks for joining us. For those who don't know you, you're typically called Agile Pete here in Wellington. It's one of probably what I think is one of the strongest Agile brands for an individual in Wellington for a long, long time. And I think I met you many, many years ago, probably 5 or 6 years ago when I started my beginning of my journey into the world of Agile, where we kind of, you remember, we engaged you into a consulting company that I founded and was running to really start off our journey of what the hell is this thing called Agile? Is it really a religion with a bunch of hairy, furry hippies going around? And you helped us kind of start off with the basics basics and grow into that. And for me, you know, kind of started off my career as moving into that coaching space for data and analytics teams to help them kind of adopt an agile mindset and patterns. What we tend to do when we have a chat to somebody on the show, we kind of say, look, give us a bit of background, tell us the story of where you started and how you got to where you are today.

Hey, thanks Shane. I think that engagement 5 or 6 years ago was one of my first exposures to BI and data and the specifics associated associated with that. And if I remember, it was quite an eventful training session. There was a lot of skeptics. You might have even been one yourself at that stage.

I think I was, yes.

Well, good change.

Yeah.

So we've come a long way, and I think once people start using these practices and these techniques and get that way of thinking, we start to see the value of it. My career, and I've been doing this for many, many years, started back in the mid-'90s doing this from a technical perspective. I didn't even know it was called Agile then. It was just a style of working that resulted from frustrations at the traditional ways of working, and we experimented with lots and lots of different things. Didn't even know that was an Agile technique at that particular point. So over the years though, as the different frameworks have come on board, we've adopted them, we've tried them, and we've found what works for us and what, what hasn't. So For the last probably 15, 18 years, I've been really, really fortunate and just working in the Agile space. I haven't worked on any traditional projects as such. So, went from doing development work and working with development team, working on vendor organizations, using Agile and RFP style projects, which were quite hard. To the extent, I remember on one of them what we were working on, we wanted to introduce some developers to the project early on so we could validate our architecture, and they said, "No, no." you can't charge us for programmers until we've got the architecture signed off. So, we actually charged them at architect rates, built a sample architecture, actually got the people that were coming in to QA us, and they were blown away that we could actually demonstrate a working version of our architecture. So, that was kind of some of the smoke and mirrors we had to use in the early days to actually use these techniques. I think one of the things we learned in those days was that one of the challenges is when you give someone the option to look at the product that you're building and give you feedback, they actually want to change your mind. And in those days, we didn't make a lot of money using these techniques because we didn't manage the expectation that if you want to change your mind, you've either got to drop something or you've got to pay more. So the big learning for me in my early years was trading scope is key in the space. One of the principles behind it, of course, is we want to deliver on time and on budget, so we don't actually have to go back and ask for more money until we've successfully delivered something. And it's that pulling that lever around trading scope. I digress a little bit anyway. A bit of background, probably for the last 8 or 10 years we've been running our own agile coaching and training company, and I thought one of the things we might talk about, having been based in the Wellington market for most of my career, is the change, some of the changes that I've seen and the adoption patterns that I've seen as we've worked our way through. I moved into the, or took on the role of coaching, probably in around about 2004, 2005, more by default. It just so happened I knew, seemed to know more than anyone else that was on the team, and I think there was a passion as well. So I think if you're going to move into the space, if anyone's listening that is looking to be a coach or a Scrum Master, you've got to have a passion for people and a passion for making their environment better. And often that will manifest through process, better process. But I think if you've got high empathy for people, and I see coaches at two ends of the spectrum, one's people coaches and the other's process coaches. And I think you need the combination of both to be successful, or in your team of coaches you need both those skills. Where was I going? Oh, so started off in this role, and when I first got engaged, I was more or less coming in to help a specific team and what we'd call perhaps a Scrum Master today. And as we, the team, became successful, I'd get involved in other teams in the organization. What I found though is I couldn't do everything, and it was a real struggle in those days because I had significant gaps in the areas that needed help. Like, I knew some stuff about technical, I knew some stuff about Product Ownership, I knew some stuff about Scrum Mastery. Pretty much had little empathy for management though, and almost thought that management were the problem. I think what I've seen is over the recent times is, or perhaps over the last 10 years, the need to have multiple coaches and do peer coaching when you go in. So that if you're gonna be successful helping a group of teams or an organization, you've gotta have a multiple set of skills that you cover. Any coach can go in and help and it will make a difference, but if we're gonna make it lasting, there's a whole lot of points that we've actually gotta tackle. So one of the areas that I looked at was, how can I do— I don't wanna be specialist in all these areas, and I've found that my passion has become moving up the chain into the leadership space, which is probably something we ignored in the earlier years, and helping leaders understand what's in it for them. I think moving to an Agile way of working is like any change initiative. It's painful for some people. Some people embrace change, some people resist it. Often people say, "I think it's a good idea. I hope they change soon. I'm not gonna change," basically, is the implication. So helping people find out what's in it for them And leaders are used to operating in a particular way. They've got to that position because they're capable and competent in doing those things. And what we're asking them to do is change some of those mechanisms that they use. So one of the keys I'm working with, and one of my mantras these days, is building trust between the teams that do the delivery and the leaders that are asking for these things. And we're now starting to do a lot of work in government over the last couple of years Government's discovered this thing called agile, and we've had some successes. I know there's been a bunch of them actually around town. I'm working on a fairly major project at the moment for Land Online, LINZ, and that's public record, so I'm not telling any tales out of school here. Basically, they've taken the opportunity to replace one of their core systems and The programme of work is going to run over 5 years, so they've set it up as a programme so they can manage the funding. It's broken up into 4 business cases, which they call single-stage business cases, and the whole thing is probably going to be over $100 million by the time they finish. Highly scrutinised, high lot of involvement from the senior government areas, and making sure that we're actually tracking this in a way that makes sense. So what we're doing is we're having the opportunity to actually use these techniques to do a major project. Now part of my job is helping create visibility of what our forecast is. Now you can imagine on a $100 million project trying to project over 5 years is pretty much a waste of time. Yep. But we've actually got to create some sort of forecasts. Now I have a little acronym, I call them SWAGs— Scientific Wild Ass Guesses.

That's a good term.

The only scientific part about it is we put it in a spreadsheet. Yeah. What it does is we actually capture our assumptions and what we think might be the case based on the knowledge we've got right now as to what the future might look like. Now, we all know the future is going to change, but it gives our leaders an opportunity to have a conversation with our teams around the type of thinking that's going on. And then we use the inspect and adapt that comes out of the basics of Agile. So we make it transparent and inspect and adapt. And so as we find that the environment changes or some of our assumptions are wrong, We're having a conversation at a senior leadership level. Now, in case the LINZ one, we've actually got an external board involved and we're reporting up to them. We're providing them with visibility. We're in the very early stages of this, so it's quite experimental and we will be under a lot of scrutiny. So maybe in 6 months' time I can come back and tell you how we've got on.

Yeah, I'd love to hear when you go through your first major iteration of those future promises. You know, so when you've done your SWAG and you've presented it, and it'd be interesting to see whether the board move into traffic lighting, right? You know, are you green on the SWAG, are you orange, or are you red? And as you said, you know, you've had a big guess up front. And obviously it sounds like you've done that guess quickly, so you haven't over-invested in planning, you know, down to things that actually you can't plan for yet. But you obviously, at some stage, you're going to get a variation in terms of of what you guessed, you're going to get some of those assumptions validated or not, and you're going to have to go back and go, right, here's SWAG version 1, here's SWAG version 1.1, and it's different. And that conversation would be quite interesting at that level, wouldn't it? Because they're probably used to, like I said, traffic light reporting of what you said you would do.

So I think when we look at this, we need to look at the planning horizons that we've got. So So our planning horizons are daily for our daily standup, and for a sprint, we're operating 2-week sprints, completely team-related. And then we start to transition and we start looking at— on this program, we're using things called program increments, which are 3 months long. It starts to give us a governance or a management interest in that sort of forecasting What do you call them? Timeline. And then for us, we've got what we call a tranche, which will run somewhere around about a year, and then we've got the overall business case, or the total program that's being funded, of about 5 years. So we've got these different levels of granularity that we're using for our forecasting, and what we're trying to do is make sure that we don't try and get down to too much detail too early. So there's a lot of detail today on what we're doing today. There's a lot of detail for our current sprint for the next few days, there's not so much detail for our current increment, and there's not as much detail or level of detail, but we've lined up when we expect to deliver things to the business, so we can start managing expectations, and as that changes, we can start feeding back on that.

So when you look at those, I think you said there's 4 horizons that you're looking at, 4 different levels of horizon with obviously less and less detail as you get higher, as you should, How do you frame those up? So, you know, when we talk about today, it's what I'm working on today. When we talk about an iteration or a sprint, typically it's that, you know, a user story type of liberty, which is decomposed down. To the next horizon, are you at a feature or an epic? And are the epics told in the way of a user story? And then you get to a 1-year horizon, is that a product or an outcome?

The language isn't actually defined yet. Right. So this is part of what we're going through. So Our first increment that we're just going through has been what we call mobilization. It's actually building our muscle memory, getting our capability and our capacity on board, and building some stuff to prove our process, to prove our technology, our delivery technology from a developer and a test perspective. Then we've got to start thinking about what we're calling things. Are we calling them products? Are we calling them services? Basically, what we're doing is we're trying to use the language of the business in terms of what the business value is. Which might differ from business to business. So that's one of the little things that we're going through at the moment. So as we start to forecast, the further out we get, the more outcome or benefit-based is the view of what we're trying to deliver. So out at the last tranche, which is 3, 4 years out, what we're talking about is what sort of outcomes would we expect and what sort of benefits will we get from them. So that's very lightweight in terms of what sort of detail that you've got for that. And it's more intent than actual promise, or it's no promise. So they're the sorts of things that we're trying to do. Of course, there's a need today to be seen to be productive, and you're dead right, we get traffic lights. We're trying to get away from the traffic lights. So we've introduced some other concepts. Maybe if I just explore some of those, some of the things that are hot for us at the moment.

Yeah, yeah, that'd be great.

We're doing, we take advantage of burn charts, and I tend to use a burn chart if I'm looking at multiple time horizons so I can show things as they're moving over time and you can create that big picture. We're using things like burndown charts to focus on single time horizons, so we've got a particular date we've got to hit and it creates a focus. We're using concepts like story mapping to create visual pictures of what it is we're changing in the business. I've introduced a thing called a governance story map, which is a very high-level view of our end-to-end value stream that creates a conversation on a tabletop sort of thing. So people on our board can talk to team members and we all have the same conversation. But key to all this succeeding is that we stay in the business domain, we stay in the business language space.

Yeah, when I first started off, I was, I don't know if I was a fan of it, but again, what I typically started off was a big horrible iteration zero. You know, it was a large iteration to build the platform because typically we're going in greenfields to get muscle memory, I think you called it, for the team. So start getting the team to understand the processes, the ceremonies, the ways of working, that forming, norming, storming kind of behaviour, till we got to a stage that we could repeatedly execute as teams and start delivering on some of the promises and also understand how much we could deliver and what we should promise. But what I found was that that forced us into almost a waterfall way of thinking, right? Those iteration zeros were quite large, they were quite long. We never really proved that we were building the right thing. So, yeah, as we went into delivering with anger, we often found surprises of, ah, damn, I wish we had tried to build that with what we were doing in iteration zero. That would be useful. So more and more now, it's starting off working the way we should be working, but asking the senior people in the organization for permission at the beginning to fail often, right? That, you know, the team will not be as successful in the early iterations as they will be when they hit velocity and when they're formed and working in the right way. Is that how you think of it now in terms of this program that you've got where, as you said, you've got muscle memory? Are you building things out and getting the team kind of understanding how to work together incrementally, and then, you know, figuring out the promises you're going to make for what you can deliver when.

I guess it comes back to the level of uncertainty that you can handle within your organization. And so one of my roles is to try and create the impression of certainty where there is none. And it's just managing those expectations, and part of that In terms of what we've done is we mobilized, but we certainly weren't fully formed before we actually launched into our first bunch of work. But we were sufficiently fully formed that we were actually able to do meaningful stuff. We just didn't have all our team members on board, didn't have all our tooling in place. But when we created the forecast for what we could do over the next 6 weeks, we were able to just identify that this is what we know now and this is what we're forecasting now. And we're collecting empirical data as we go. But as our capacity and our capability builds, we'll be able to reflect on projecting better outcomes. And having that conversation with your leaders so that they understand what process that you're actually working through. And I think this is one of the surprises that people get. Working in an agile manner, a professional agile manner, is way more structured and disciplined than any sort of traditional work that I've done.

Yep, yep, I agree. We do a lot more planning and a lot more often. We just do planning at the right time, at the right level.

Yeah, yeah, and I think this comes back down to the fact if we can share that in some way that's easy to consume at a leadership level, What we can't do is give our leaders lots and lots of data. We've actually got to simplify the complex in a way that doesn't oversimplify it, and predominantly that's in their language so that they don't have to think about— other than if that we were reporting, "Hey, we've got an exception, now we need your help." And this is one of the challenges I think we see when we're moving into governance and leadership of major IT-type programs. There's a lot of traditionally hands-on management when the people are actually on a governance board because they don't trust the team to actually deliver. So if we can build this trust, then the people in those roles can move back to a governance layer, which is really, are we doing the right thing? Are we moving at the pace that we thought we would? Does it look like we're going to deliver this on time? And is the initiative aligned with the strategy and the vision that the organization has? Now, that's quite high-level goals. Governance should only get involved if we're reporting an exception and need some help. And so one of the key things I see is boards or steering groups, the value they add is setting the vision very clearly, linking it back to the organizational strategy for us so we understand, and then telling us what the boundaries are we have to work within. When we then find constraints in the way we have to work, that's when we want to dial them in. So governance board should be a Scrum Master's best friend, you know, in helping remove impediments. But the scale of things, often our Scrum Masters Scrum Masters today are working down at a team level, and that if we go back to, you know, Scrum, where Scrum Mastery came from, they talk about being a coach for the organization, but most of our Scrum Masters today are team-based and they don't often get the opportunity to go up through the organization.

Yeah, that's very much the Product Owner in our scenario. So do you have Product Owners, or do you report directly to the, to the board? Board? How does it work?

So I'm engaged at an SRO level, which is Senior Responsible Officer, in terms of the kind of, what are they, the PRINCE2 terminology, it's Managing Successful Programs, MSP. I think what we're trying to do, we've still got elements of traditional program structure, this is a big program, a lot of people involved, but we are having the concept of a product manager and product owners to help us scale, and that product manager more and more is owning that reporting.

Right, right.

We have multiple roles. I guess when I talk about Scrum Masters, I'm more looking at it from an impediment perspective and organizational things that are systemic in the organization that we need leaders to help us with, because as a program or project team, we can't change that. In terms of our product owner, we want them to own the direction and then interpretation of the strategy and be connected at that governance level, not have program or project managers between them and the governance.

Yeah, and look, I think that's what I struggle with at the moment as I move into more, more and more companies where I'm helping them where they're taking a transformational approach. So they want to change the way they work across the entire organization. So I'm not going in and helping, I'm typically going and helping an individual team to begin with, but that's part of a bigger organizational change. And so the conversation I have with them on a regular basis is, if we're going to change the way you work, then, and we're using Scrum, if that's the framework that you've decided, then Scrum Masters are a permanent role in your organization.

Couldn't agree more.

It's not a contract role, it's not a project, right? It's a way of working and we need to do that. And so often they won't, they don't hire in experienced Scrum Masters, they, you know, somebody who's interested in that role joins the team and learns with the team how to do that role, which is great because they're growing, they're engaged, they love it, and they build a capability within the organization. But those Scrum Masters aren't at a level that I would call a coach. You know, they're learning, they're not experienced. So then you've got the Agile Coach kind of role, and where does that sit? And so I struggle with that a little bit. And then if I think about transformational change to the organization, you know, we used to have a PMO when we were more PRINCE2 or PMP-based. And so what I'm kind of saying to the organizations is now what you need is more of a coaching circle, center of excellence for coaching, whatever you want to call it, but you need to build experienced coaches in your organization that when a new team wants to form, they can go in and help.

So who used to do that? In a traditional organization, whose responsibility was it for that?

Ah, HR?

Normally delegated to the PMO.

Oh yeah.

So what I'm saying to organizations these days, because I'm very skeptical of organizational transformations, and the ones you read about at the moment are Big Bang type, and you go, well, that doesn't seem too agile to me. There's going to be a lot of pain here.

And they're IT-driven, right? They're normally a system change that happens to be couched under a transformation project.

Potentially, yeah. There's some organizations that are succeeding, but they don't tend to do it as a big bang. Where I'm coming back to, though, is where should your coaches be based if you've got a traditional organization already? And I work with PMOs, and I say, you girls and guys should actually be be leading this charge, not the gatekeepers on the charge. You should actually be out there being proactive. You should be getting the coaches in to help the teams, and you should be understanding what it is that this way of working delivers in terms of reporting, because often the PMOs are the ones that are summarizing things up to a higher level. And so instead of the team having to translate it, we did a lot of work at ACCC where we trained, gave some basic training to the project coordinators, and the response that came back was amazing from them because all of a sudden they understood the way that the teams are working, and they were able to translate because project coordinators do a lot of that work and bring that information together. And so we put a lot of work in and a lot of emphasis around that. We also have done a lot of training with people like procurement and HR and legal, finance and policy, all around the way you support Agile initiatives because often they're seen as gatekeepers that stop rogue projects from inflicting harm on the organization. We have a little metaphor. We call them the sharks in the traditional world because they swim around our Agile Island. And if we try and venture off the island, they're there to inspect and adapt us or eat us. But what we want to do is turn them into dolphins. We actually, and this is one of the roles of the Scrum Masters, is actually get out and socialize with those people because if we can engage them early in the process, they can tell us their expectations. We just got to add the work that they need to our backlog to make sure it gets done. But often in working with us, they go, actually, we don't need that stuff anymore because you're mitigating those risks that we were trying to prevent by using this way of working, now that we understand how you're working. So it's kind of that old mandate, you know, keep your friends close and—

And that's where the trust that you're talking about comes in, I guess.

Totally, because we take them on the journey as opposed to keep them at arm's length. And delivering systems is not just about building features faster, it's about building value for the business and getting the whole group of people that actually have to transition that into the business on board with us.

Yeah, so it's a change of way of working rather than, you know, Agile is not a project in my view, right? It's not something we, we don't do an Agile project, we want to change the way the organization delivers or works and we use Agile techniques to make that successful. And often, I don't know about you, but often I see people treat Agile as a project. We want to implement Agile, not we want to deliver a safer product faster with, you know, the teams working together and having more control and fun, and we're going to use Agile techniques to achieve that. They tend to treat it as an Agile project.

So the one area listeners might like to look at then is the Agile Fluency Model. We've started to use you can use that now to actually work out how agile do you want to be. What is your agile compared to my agile? And they come up with different zones of agility that you might want to use to identify what sort of investment is involved, what sort of benefits are you looking for, and what sort of timeframe you like to take, take you through. So that's, now there's some newer sort of frameworks starting to appear that help us think about these things. So, in terms of going right back to the start though, what was the driver for Agile? If we look at the root cause, it was because IT was unreliable. We were always over time and over budget, and the business couldn't rely on us. The fact that we had all this change happening within our process and we didn't know how to handle it other than raise a change request, and I've never seen a change request make a project shorter. We've now—

Good point.

I've seen it make it more expensive, It's a valid way of extending a project from a governance perspective, but I bet you no one on a governance board actually likes that, and it's not normally a career-extending option for a project manager either. So one of the key things we've done is we've actually removed the IT group as being the roadblock to implementing things on time and within budget. So we now— but we acknowledge we pull the scope lever, so it's not like we deliver everything that they want, By cramming it into a smaller and smaller box. So, what we've actually done now is we're able to start exploring with the business. If you can rely on us to deliver, why don't you come and join us? Because you can actually now grab hold of the steering wheel. You can actually set this off in the direction and you've got an engine for delivering that's going to work closely with you. That'll give you what you want and you can change your mind on the way. We just got to be cognizant of the fact that our governance group have given us so much time and so much money, or we've agreed to those conditions. Constraints. We've just got to deliver something of value to the business in that timeframe.

And that kind of brings in the importance of that Product Owner role. So, you know, we've all struggled with having commitment from the business groups that are looking for the value to commit a person as the Product Owner to help drive those trade-off decisions, drive the priority, answer the questions quickly enough for the team to deliver. And what I found is If I'm joining a team and I'm coaching the team on delivery and say we're bringing in somebody new that we're kind of coaching as a Scrum Master, I have absolutely no capacity to go out and coach the Product Owners. I just, you know, I can't focus enough on one group to help them to the level that I need to and do that second group of people to help them. And then if we talk about the Executives, then I definitely don't have time to explain to them how their behavior needs to change, how, you know, they can't come in over the top on a Tuesday morning with an emergency thing for the whole team to do because the team just drop everything to do what the boss said and of course don't meet any of the commitments or promises. So they need to change their behavior over time, which is always a big challenge. So one of the things that I know that you've been working on for a long time is this idea of when you've got a large change happening into an organisation. So probably more of that programme level that you're talking about. How do you get more than one coach to come in and work as a team of coaches to help, you know, somebody being there at the right time to help the teams understand where they can improve and what they might be able to do to change and do things a little bit better. So how did you come to that model? What was kind of the trigger?

I think the Issue was, as we started to try and scale things within the organization and went outside just IT and realized that the value here is in engaging with our business that are requesting the service, you hit the nail on the head. Basically, the secret sauce at the team level is having good product ownership. That's a make or breaker in the Agile world. One of the very first projects I did for a big government department, we had a surrogate product owner, and we built an amazingly technically sound product that had no defects on release. The problem was the organization had been so used to having defects that they really didn't get involved until they started accepting it.

Using Tim's testing kit.

The cycle from when it was so purported to be done to when it actually got released could be 6 to 9 months after, and they'd get involved then. Now, it shocked them, and it turned out that what we'd built was actually not what they wanted wanted. But it worked. It worked perfectly. So to avoid that, we became very conscious. I then started working with a product ownership coach, and we started partnering up on doing things, and mine was team level and make sure the team was working a little bit like your own. And then as we got bigger engagements working, we realized that we— I started to have to move into a leadership role because now we were working with big programs of work, and we needed team-based coaches. So what we've done over a period of time is we've gone from focusing on helping small groups of people just to improve the IT component of the delivery of project to working now in a more holistic way. And we've built— we have something called the Agile CoLab where we're a bunch of self-selecting partners in this business. So we have a group of people with different skills. We've got people that are good at Kanban, Scrum, SAFe, DevOps, that sort of thing, so we can wheel them in, but they have their specialty and they have their generalist skills. And what we're finding is when we go into a site now, one of the key things we do is we go in, is we tend to go in as a peer for a start, understand the situation, and then we can draw other people that we need. Now we don't have all the skills, so what we're also doing is we're trying to stay well connected within the Wellington market in particular, so we can identify other people that we can recommend to our clients to come in and work with us as friends. What we're trying to do is is find people that have similar ways of thinking. And I think Agile Welly is a great place to start to actually find those sorts of things. And I think we're well served in Wellington for access to events where people can socialize.

And skills. I mean, you know, since we started doing this podcast, I've been amazed at how many really experienced, you know, people in the Agile domain we have in such a small town. It's amazing. And some of the innovation that, you know, they're coming up with. I suppose it's the Kiwi way, right? Number 8 wire and that, but it's just— it's amazed me how good we really are in this little town of ours.

And I think the bigger initiatives that we're now having on give people in the coaching space an opportunity to become more specialist or focused in the area that they want to contribute to and work as a team of coaches. We're seeing that at places like Westpac, where they now have multiple coaches going on. Spark, as they're trying to implement Agile as well. So the whole concept of a coach in the space is growing in popularity.

And that's got some danger to it as well, because, you know, I've seen it overseas and some of the podcasts I listen to and some of the blogs I read, you know, the concept of, you know, you can do a 2-day Scrum Master course and now you're a certified Scrum Master expert. And we all know that that's the beginning of the journey, right? You've got you've got now some of the terms and the frameworks, you can visualize how it should work, but it's not until you start working with your first team that you get the scars, you're on the field as such, well, Scrum Master, you're kind of on the side. But you know, it's not until you've done a few that really you have the experience to, in my view, to call yourself an experienced Scrum Master. Same with coaching, there's really limited training and certification for coaches And even then, you know, it requires a lot of experience in my view to be able to coach a team or coach a bunch of product owners.

I think the term coach is used pretty liberally in our environment. And we, just beginning of April, we were helping run the Agile on the Beach conference up in Tauranga. One of the themes there was around coaching, personal safety, and what that meant. And actually, as a coach, one of the key comments that came out of the conversations that were happening was, at worst, do no harm. And make sure that you're not trying to coach beyond your capacity. Because we looked at agile coaching as described by Lisa Adkins. She's written a great book on it. Talks about 3 areas. There's There's coaching or professional coaching where you believe that the person that you're working with has the answer and you're just trying to draw that out. There's mentoring where you're sharing your experiences, and then there's training when you're actually teaching. And be clear on which hat that you're wearing. And a lot of times when we come in as Scrum Masters, we're kind of the expert. We're seen as the expert on Scrum or Kanban or SAFe or Lean, whichever, whatever our thing is that we've come in, and people are looking for guidance and advice. Now you're in a teaching mode. So that's just one of the aspects of coaching though. And then when people have problems, how do you actually deal with that? And a lot of the success of teams is only a little bit to do with the frameworks that they're going to use. It's a lot to do with how they work together and building that team culture. And probably most of the people that call themselves coaches don't have a lot of exposure in actually doing that. But more and more as we're running conferences now and we're getting exposure, getting people coming in and talking, and talks for Agile Valley. Basically, we're looking at how do you actually relate to people as people and how comfortable they are actually engaging and being collaborative. How confident are we to be vulnerable to others? And how accepting are we of vulnerability? And this is the touchy-feely stuff of the people end of the coaching side. And when I started my career, it was all about the process. All about which framework were you going to use, that was the silver bullet. And we're becoming way more involved in actually optimizing the skills of the whole person that we've got on our team now and finding what makes them tick and how they best fit into a team. That's great.

Yeah, yeah, I agree with you. I mean, for me, it's about being there at the right time to make some suggestions that may help that team get better. And, you know, again, early on it was, I had the theory, I suppose most people when they start out, which is there's a bunch of patterns that you can apply repeatedly with any team at any time. And for me now it's about, there's a bunch of patterns that may, that team might decide to adopt that might help them get there a little bit faster or a little bit safer. But not every team will adopt those patterns for the right, you know, for the right reasons, they'll go and they'll come up with their own patterns or they'll try it and that pattern just doesn't work for them. And that's okay. You're just there to accelerate them a little bit more than if you weren't there. For me, that's what it's about. But it took a long time to back off from the command of, well, this has worked every other time I've seen a team try it, to, hey, I've seen other teams do this and it seemed to work. And this is kind of what they did, and this is how I can describe it to you, and this is kind of how we would use it. What do you think? Should we have a go?

Seems like it.

Seems like it. Seems like it. Seems like it.

Seems like it.

Yeah, and then, for me, the buzz is, I had one yesterday. I've been away overseas for a couple of weeks, and so one of the teams I'm coaching ran their first 2-day kind of session where they did the demo day, and did their retro and did their planning for a new product they're going to deliver. And so they sent me the kind of deck for the scope of the new product, and they picked some of those patterns up, and it's great, because now I can just read it, and I'm like, cool, I get what the vision and the scope of this next couple of iterations are. It's worked for them, but that was their choice to adopt it. It was like, again, you know, this seems to work, 'do you want to have a go?' And they went, 'Yeah, let's give it a go.' And then they went, 'Oh, good, let's solve that problem, right? We can engage you with the product owner, have an idea of what the scope might be over the next couple of iterations.' You know, it's not till we deep dive and we'll find, you know, a bit more about it, but we've got at least a boundary to discuss at the beginning, and it's been valuable.

And I think one of the things when you join a team as a coach is understanding what they want from you. Sometimes when you go in with your trainer hat on, you might be having to propose a process or a structure, and that's always highly risky, and there has to be quite a bit of uncertainty around what's actually happening for that to be successful. In other words, the team's not performing in some way, but I always find it's way easier to go in and get them to explain to you what they do, how they do it, and then let them help, help them through that process of identifying where they're looking for improvement. And that's where the experience of your patterns comes in, you know, to be able to suggest options for starting because you've been there, done that before. I've seen this work in other organizations. It may or may not work for you, but it's probably a good place to start. Yeah. If you don't have a better idea.

And if it doesn't work, then what's your idea for the thing that might with your organization, with of what you're trying to achieve. So do you find though that sometimes you start working with a team where often Agile's been given to them, shall we call it that? So somebody at a high level in the organization has said, look, it's not working right, we're not keeping our promises, we're not delivering what we said we would when we said we would, everybody's busy, but you know, we're not seeing the value out of that effort that we would want to. So their answer is, look, either based on experience in other companies or from beers at the pub or whatever, they're, okay, we want to try and adopting an Agile mindset because we think that'll help us deliver some of that value. But the team themselves haven't bought into it, you know. And so often what I find is they want the answer. They want to just be told, you know, was it Scrum or Kanban? And the answer to them is, well, either. They both have benefits and they both have downsides. So, you know, which one would you like to try first? Which one do you think, if I describe them in this way, which one do you think fits naturally to the way you think you want to work? And then how are we going to know that you're successful at it or not? But often teams, you know, they're used to being told what to do. Have you found that? Have you found Yeah, yeah, totally.

But on the counter side also, you get teams that are very strongly opinionated about what they want to do. So my normal mode of operation is if I go into a team that's already operating, I'll use a more Kanban style approach where I'll get them to visualize their work so that they can start to see where the challenges might be. And we can evolve that. And as you're saying about the patterns, There's techniques that are out there that will help them when they find an issue, but if they don't see it as an issue, trying to inject that technique into the team is just going to get resistance. I always find if it's my idea and I get to do the job, I'm way more embrace it and way more own it. So pretty much it's actually just trying to make those sort of things, create awareness around whether they do have issues, or even, you know, when you're doing a retrospective, propose some ideas that they might like to consider. Consider. But if I'm starting with the team from scratch, I might go for a more framework-based approach like Scrum or Lean Startup type stuff, or depending on what the problem is that we're trying to solve, especially if I've been brought in right at the start and you're actually building a team around you. So that's kind of the— if there's no process there, I'll grab a particular framework to get started. If there is a process already, I'll try and understand what that process is and help the and just evolve it.

So is that where the how agile are we going to be sort of spectrum kicks in?

So that goes back at a leadership level and saying, when we introduce this concept of agile, in the early days, the leaders that I was dealing with will go, Pete, how hard can it be? It's just agile, isn't it? And I go, well, if you were doing a change initiative, what would you expect the response to do you want your people to be? And for most people, it is, "I don't want to do it." So you've got to take people on that journey. So one of the things for leaders to be clear about is how far they want to go on the journey. And we talk about changing our focus from being really good technically and being able to actually look at things from a business perspective. And that's the first step in the journey. And if we do that, it allows business people to get huge visibility of what we're building and change their mind as we go. And the second zone for them to look at is how quickly do we want to be able to respond and innovate. And if we want to do that, we've actually got to get into a lot of the technology that allows this continuous deployment. There's a whole bunch more training that I've got to do, a whole bunch more tools. And if we really want to be market leaders in what we're doing, we've actually got to start bringing our business people and our technical people together and starting to focus on product-based thinking. So that's where the, the Fluency model helps a leader to decide. Then once we've got the leadership aspirations in place, we can start to talk to teams about where the organization wants to go, some of the techniques at a framework level, sort of it's raising up your patterns up into the framework because they're just patterns in their own right, and say, hey, do you think this would be a good starting point if we want to move more quickly? Should we actually start looking at this given the leadership direction that we've got? But most organizations I've worked with previously, they just say, we want to be agile. The intent of the leadership is we want to be product-based, want to be all those great things that we read in the media and, you know, McKinsey tell us about and Gartner and those sorts of guys. But it takes time, and to become good in that space probably takes you 5+ years. And that's an awareness that most leaders aren't aware of. So the landscape becomes murky for the teams, but if the landscape can become clear for the teams, they can start making the selection one of those frameworks for themselves, or just picking parts of those frameworks. I normally like a team, if they're starting from scratch, to pick a framework and at least get some mastery of that before we start trying to twiddle the knobs. Otherwise, you're starting to make decisions to tweak things without really understanding the implications, which can be dangerous. But having said that, if the team's really resistant, we take them on the journey. From a leadership perspective, we've got to realize that that can potentially take longer in the first instance, but may pay bigger dividends in the longer term.

So, I mean, again, do you find that when you get engaged in a customer for the first time, one of the first conversations you have with the executives are, this, you know, the team will become slower and deliver less at the beginning than they ever have right now?

I try not to have that conversation on my first conversation. Okay.

The sales conversation.

But do you have it early? Because, you know, often people have, you know, they have this perception that, you know, this Agile thing's gonna, you know, in a couple weeks the team are going to be delivering twice as much with, you know, 100% quality on day one, and that's not true. In my experience, you know, the team kind of break to begin with. They lose a lot of the, you know, we're changing the way they behave, so the stuff they were used to, they have to unlearn, and therefore what they deliver in the at the beginning is less than they've ever delivered, and then they build up to delivering more than they've ever delivered in a better way.

So I think if we look at the concept of forming and storming, you know, when we bring in change, it takes people time to actually hit their straps. And I just have a very gentle warning that for the first 2 or 3 times, whatever process that we're going to follow, whether it's a homemade one or a patterned one, you're going to find that our productivity is going to be lower because we're not operating in a fluent manner, we're not operating naturally. So, but in somewhere between our third, fourth, fifth, sixth, we will actually start to reach up some of our potential. Now, if we're running Scrum, for example, in our 2-week sprints, we're actually saying there's 3 months before you're actually starting to get significant reliable productivity coming out of a team, or forecastable productivity. If you're running projects and they're quite short projects, you've got to ask the question, is this a good investment? So then I go back and have a talk at a leadership level and say, why would you want to disband this team after 6 months and now actually a really valuable engine? So we have that conversation. So instead of kind of coming from the point of view of, hey, it's going to be a big hit, I say there's a change program in place here. It's actually our IT group that are being changed, as opposed to the change we often do to the business when we put out new systems, there is going to be some learning involved. And you're actually going to have to pay some money to get some people on some training, give them some books to read, let them go to some conferences, give them some coaching if you don't want this to take forever. So where's your benefit horizon that you're looking for as a leader in terms of your return on that investment? Teams that we don't provide the coaching for or the training, we know they just wander all over the place. Mm-hmm. And they always disappoint, not only from a leadership perspective But as a team member, you get frustrated, and in most cases you go back to what you've done.

Well, it's even worse than that in my experience, because you go back to what you've done and then you use those famous words, "Oh, we tried Agile, we did stand-ups, and it didn't work." So, you know, it's even worse than not trying because, you know, they've now— they believe they've been through the process and it didn't work, and therefore all the Agile myths have come to to roost, and they're even less open to doing or starting that Agile journey in the future.

Yeah, I'd be like that as well if you dealt to me like that. So, and I deal with teams that have been in that situation, and it then becomes a case of forget the frameworks and the patterns, you just got to build some trust within the team and actually understand where they're coming from. And I think this is the value of coaching, and where a lot of our coaches are going now, the focus on the people side of it. Someone called them soft skills versus hard skills at a conference and there was a big, "They're not soft skills, they're actually important skills, you're undermining them," and I go, "You're dead right." These are the skills now that we're actually trying to get our coaches more cognizant of, more skilled in, and the framework stuff, it's pretty well known now. We've got lots of people that can do that. Now if we want to get hyper-performers forming teams, we've got to find ways of actually creating teams of people. And the fluency model that we talk about, the Agile fluency model that we use for a lot of this framing of the thinking about the investment of moving into the Agile space, focuses on team-based fluency. That Agile's a team game, a little bit like sports teams, and to play the game at pace, the people have actually got to be cross-functional, they've got to be able to cover each other, and they've got to know what each other's doing. We've got to be able to respond without thinking. In a positive way.

Yeah, and that just takes time. I mean, I don't know, if I had to do it soft versus hard, I'd say that actually those are the hard skills.

They are the hard skills, you're dead right.

Coming from an IT background, the process stuff is, you know, you see a pattern for a process, you can apply it. The engagement with the people and the nurturing is often the hard part because it's something that we're often not taught.

And we're doing a lot more work now with business-related activities where there is no awareness of some of the hard type of practices that we use in IT. What does technical debt mean? What's continuous integration and deployment mean if you're in a business type world where those tools aren't relevant? You can draw parallels, but you've now got to start thinking in terms of how people are working together and what their products are, or what's the stuff that they're producing as part of this. All the skills that we've got, we can transfer, but we've just got to take a different mindset about it.

And I think, you know, just one of the things I picked up all the way through this conversation is, you know, we know that when we have a delivery team, we have to get them to form as a team. You know, what you're also saying, I think, is when we go into larger organizations, organizations that want to change the way they're working for more than just one team, actually the coaches have to form a team. And then, you know, you have to trust the other coaches and you have to have, typically I'm assuming, have worked together before to understand how each of you work and where your specialty is and what your T-skills are. And when, you know, it's like, actually, you know, my coaching colleague over there has a lot more experience in coaching product owners, so let's get them engaged because they're going to give you a much better answer or helping hand than I will right now. And so therefore, the coaches have to become a team.

Totally. And you have to be on the same page as coaches, because if you're giving a different message, it's gonna create confusion. You can have differences of opinion, but you've gotta have consistent messaging of what actually goes out so that the team, until they become confident and capable, are being supported in a way that doesn't cause any more confusion than the change that they're going through right now. And something to think about there is if you're gonna get teams with training, the team people that do the training, whoever the coaches are, it either should be them or those coaches should be on that training. Now you say, why would your coaches need to go on training? To hear the messaging. To make sure that if you're using professional trainers to deliver your training, the messaging that they're using is the same as the coaches are gonna use. And those coaches should be talking to those trainers before they deliver because there may be some personalization of the language that's required. Not the frameworks or that sort of stuff, but what does it mean within that organization? And I don't mean customizing courses, but just the way we actually talk about it. Is there something from the organization that we're working in that we want to overlay into the training such that we've got consistency of values or purpose or something along those lines?

That's a good point. That's one that I hadn't thought about before.

Well, I've often found I've come in after the organization's done the training because it's good to have people trained, it creates awareness. But if it's going to be more than just knowledge acquisition and we want to be able to apply it, then what we've got to make sure is when we come back into the workplace, the people that are supporting the application of that knowledge that you just got are on the same wavelength. Because if we're talking a whole bunch of language on one side and the coach comes back and is talking with different words meaning the same thing, The poor old team members have to try and translate that.

Yeah, we need an Agile Babble Fish, right? Yeah, like, it's like in Guardians of the Galaxy, you stick it in your ear and it's like, okay, I've been on the Agile Pete's CoLab course, right, excellent, yep, okay, these are the words I need to use.

Exactly, and one of the things we do is try and make Scrum Masters or whoever the leaders are, tech leads if that's what they are, even if they know the Agile stuff, we get them to come on our courses and the idea is we say, 'Come on the course for free and be the champion. Help us with the delivery of the training course to make sure that your team members that you're going to be working with tomorrow when you go back and work are tuned in so they can go back and apply this stuff straight away.' And this is getting context-based training without having to go the expense of customized training.

That's something that, yeah, I hadn't thought about, but definitely will in the future.

Excellent.

All right, well, look, I think we're, yeah, we're about good on time. Thanks for coming along.

It's lovely to share. Thank you very much.

Conversation, I think. Yeah, as I think we knew right at the beginning, we could go on for hours and we'll probably definitely get you back in 6 months at least to talk about how you manage those time horizons. But if not, a bit earlier around that governance, around that executive governance and, you know, how do we apply governance across scaling the agile stuff without moving into more of a waterfall project management and over-the-top reporting structures that I typically see. So, yeah, if you're up to it, we'd love to get you in.

I'd love to, and I have a passion to change the way we fund things out of government and change the value that we deliver in government-based projects, which is beneficial for all of us. And my challenge is actually to start working at a Treasury level, and those guys are already thinking along these lines and, you know, just authorizing the projects that we've been working on. But it's actually getting them to start driving it. It's a little bit like putting the coaches back into the PMO. These people that are driving the investment decisions, getting those investment decisions focused around agility. And a lot of the thinking is already there, we've just got to translate it down through some of the legislative restrictions that we've got.

That'd be great, because again, one of the struggles I have is, as we start introducing an agile way of working when the organization's funded on a 12-month project basis, there's a misalignment there between the way the organization's starting to work and the way the funding and the resourcing is allocated, and that just causes chaos. So changing that would be great because it means, again, we're starting to get alignment between the culture and the funding of the organization to the the way we're doing processes and building teams.

So little steps at a time, build the trust all the way up the pipeline, and hopefully we'll start to see changes coming down in terms of the freedom we're given.

Yeah, and then hopefully New Zealand can become one of the first in the world and show the rest of the world how to do it.

Or there's a lot of good ideas overseas as well, so hopefully we can start embracing some of those and sharing worldwide as well.

Yeah, that'd be great.

World domination.

Yeah, world domination. It's one of my taglines, actually. Oh dear. Excellent. Alright, hey, thank you very much, Shagility Pete. We'll catch you later. Cheers.

Thanks, Pete.

You've been listening to another podcast from Blair and Shane where we discuss all things agile BI. For more podcasts and resources, please go to agilebi.guru.