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

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 five or six 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 fairy hippies going around? And you helped us kind of start off with the basics and grow into that. And for me, it 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 mice 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 five or six years ago was one of my first exposures to bi and data and the specifics associated with that. And if I remember, it was quite an eventful training session. There was a lot of skeptics. You might even have been one yourself at that stage.

I think I was, yes.

Wow. 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 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 into QAs and they were blown away that we could actually demonstrate a working version of our architecture. That was 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 this 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 eight or ten 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 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 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? 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 was a problem.

I think what I've seen is over the recent times, or perhaps over the last 10 years, the need to have multiple coaches and do peer coaching when you go in. So if you're going to be successful helping a group of teams or an organization, you've got to 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 going to make it lasting, there's a whole lot of points that we've actually got to tackle. So one of the areas that I looked at was how can I do? I don't want to 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 going to change, basically is the implication. So helping people find out what's in it for them. And, 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 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 Landonline 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 program of work is going to run over five years. So they've set it up as a program so they can manage the funding. It's broken up into four 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 five years is pretty much a waste of time. 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.

The only scientific part about it is we put in a spreadsheet.

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 lin's 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'll be under a lot of scrutiny. So maybe in six 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. 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 what you guessed, you're going to get some of those assumptions validated or, 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 our planning horizons are daily. For our daily stand up and for a sprint we're operating two 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 three months long, starts to give us a governance or a management interest in that sort of.

Forecasting, what I 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 five 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 four horizons that you're looking at four different levels of horizon with obviously less and less detail as you get higher, as you should. How do you frame those up so 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 a user story type of lever 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 one year horizon. Is that product or the outcome?

The language isn't actually defined yet. 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 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, 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 three, four years out, what we're talking about is what sort of outcomes would we expect and what sort of benefits would 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 words, no promise. So they're the sorts of things that we're trying to do. Of course, there's a need today to seem 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.

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 burn down 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 and introduced a thing called a Governance story map, which is a very high level view of our end to end value string 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.

When I first started off, I don't know if I was a fan of it, but again, what I typically started off was a big, horrible iteration zero.

It was a large iteration to build the platform because typically we're going in green fields 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 behavior 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 forced us into almost a waterful way of thinking. Those iteration zeros were quite large, they were quite long. We never really proved that we were building the right thing. So as we went into delivering with anger, we often found surprises of oh 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? 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 got muscle memory? Are you building things out and getting the team kind of understanding how to work together.

Incrementally and then 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 is 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 six 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 that capacity and that capability builds, will 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.

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. 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 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 organisation has now? They're 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 in helping remove impediments. But the scale of things, often our Scrum Masters today are working down at a team level. And that if we go back to Scrum where Scrum Mastery came from. They talk about being a coach for the organisation, but most of our Scrum Masters today are team based and they don't often get the opportunity to go up through the organisation.

Yeah, that's very much the product owner in our scenario. So do you have product owners or do you report directly to the board? How does it work?

So I'm engaged at an SRO level, which is Senior Responsible Officer in terms of kind of, what are they? The Prince 2 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. 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 a project team, we can't change that in terms of our product owner. We want them to own the direction and then put 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 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 don't hire in experienced Scrum Masters.

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. 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 Prince or PMP based. And so what I'm kind of saying to the organisations is now what you need is more of a coaching circle, centre of excellence for coaching, whatever you want to call it, but you need to build experienced coach in your organisation that when a new team wants to form they can go in and help, you know.

So who used to do that in a traditional organization? Whose responsibility was it for that.

HR.

Normally delegated to the PMO because they. So what I'm saying to organizations these days, if you. 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, 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 summarising things up to a higher level. And so instead of the team having to translate it, we did a lot of work at ACC 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 were 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. And 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. 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, keep your friends close.

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 changing way of working rather than Agile is not a project in my view. Right. It's not something we don't do an Agile project. We want to change the way the organisation 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 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 the 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 time frame you'd like to 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.

Good point. I've seen made 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. 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've 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 controls. We just got to deliver something of value to the business in that time.

Frame 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 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 behaviour needs to change, how 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 a organization. So probably more of that program 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 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 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 this service. You hit the nail on the head. Basically the secret sauce at the team level is having good product ownership that's a maker 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. The cycle from when it was so purported to be done to when it actually got released could be six to nine months after and they'd get involved then. Now it shocked them and it turned out that what we built was actually not what they 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 making sure the team was working a little bit like your own. And then as we got bigger engagements working, we realized that I started to have to move into a leadership role because now we were working with big programmes 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 have something called the Agile collab 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 work, 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 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 socialise and schools.

I mean, since we started doing this podcast, I've been amazed at how many really experienced people in the Agile domain we have in such a small town. It's amazing. And some of the innovation that they're coming up with, I suppose it's the Kiwi way, right? Number eight wire in that. But 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 I've seen it overseas and some of the podcasts I listen to and some of the blogs I read, the concept of you can do a two 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. You've got, you've got now some of the terms and the frameworks. You can visualise how it should work. But it's not until you start working with your first team you get the scars. You're on the field as such. Well, Scrum Master, you're kind of on the side, but it's not until you've done a few that really you have the experience, 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 it requires a lot of experience, in my view, to be able to coach a team or coach a bunch of product owners.

And I think the term coach is used pretty liberally in our environment. And 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 Aitkens, she's written a great book on it talks about three areas. 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 Saif or Lean, whatever our thing is that would 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. 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 are agile. Welly, 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.

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

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 two day kind of session where they did the demo day and, and did their retro and did their planning for a new product they're going to go 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, 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. It's not until we deep dive and we'll find a bit more about it, but we've got at least a boundary to discuss. At the beginning 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 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 help them through that process of identifying where they're looking for improvement. And that's where the experience of your patents comes in, to be able to suggest options for starting, because you've been there, done that before. I've seen this work in other organisations. It may or may not work for you, but it's probably a good place to start 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 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 that 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 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, okay, we want to try and adopting an agile mindset because we think that will help us deliver some of that value, but the team themselves haven't bought into it.

And so often what I find is they want the answer, they want to just be told, was it scrambled Kanban? And then. And the answer to them is, well, either they both have benefits and they both have downsides. So 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, they're used to being told what to do. Have you found that? Have you found that?

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 a 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 where they do have issues or even when you're doing a retrospective, propose some ideas that they might like to consider. But if I'm starting with a 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 bought 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 them 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're doing a change initiative, what would you expect the response to 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. The second zone for them to look at is how quickly do we want to be able to respond and innovate. 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. 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. That's where the fluency model helps a leader 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 patents 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 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 five plus 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 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 realise that that can potentially take longer in the first instance, but may pay bigger dividends in the longer term.

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, 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, the sales conversation.

But do you have it early? Because often people have this perception that this agile thing is going to, in the, in a couple weeks the team are going to be delivering twice as much with 100% quality on day one. And that's not true. In my experience, the team kind of break to begin with. They lose a lot of the, 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 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, 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 two or three 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. But in somewhere between our third, fourth and sixth, we will actually start to reach some of our potential. Now, if we're running scrum, for example, in our two week sprints, we're actually saying there's three 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, well, why would you want to disband this team after six months and now actually a really valuable engine? So we have that conversation. So instead 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 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 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.

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, 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 believe they've been through the process and it didn't work and therefore all the agile myths have come 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 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 our 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 performing 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 is 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'd 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 do. Right.

Coming from an IT background, the process stuff is you see a patent 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 and 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. But 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 just one of the things I picked up all the way through this conversation is we know that when we have a delivery team, we have to get them to form as a team.

What you're also saying, I think, is when we go into larger organisations, organisations that want to change the way they're working for more than just one team, actually, the coaches have to form a team and you have to trust the other coaches and you have to 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 my coaching colleague over there is a lot more experienced than 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 is going to create confusion. You can have differences of opinion, but you've got to 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 going to get teams with training, the 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 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 going to 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, 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 Babelfish. Right.

Striker's guide to the galaxy. You stick it in your ear and it's like, okay, I've been on the Agile Pete's collab course, Right.

Excellent. Yep.

Okay, these are the words I need to.

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're. 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, of customized training.

That's something that, yeah, I hadn't thought about. Definitely. Well, in the future. Excellent. All right, well look, I think we're about good on time. Thanks for coming along.

Well, lovely to share. Thank you very much.

Conversation. I think as I think we knew right at the beginning, we could go on for hours and we'll probably definitely get you back in six months, at least talk about how you manage those time horizons, but if not a bit earlier, around that governance, around that executive governance and 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.

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.

My challenge is actually to start working at a Treasury level and those guys are already thinking along these lines and just authorising 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 investments decisions, focus 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 organisation's funded on a 12 month project basis, there's a misalignment there between the way the organisation is starting to work and the way the funding and the response 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 organisation to the way we're doing processes and building teams.

So little steps at a time, build the trust all the way out 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, or there's a lot of good ideas overseas as well, so we, hopefully we can start embracing some of those and sharing worldwide as well.

Yeah, that'd be great. All right.

Hey, World domination.

Yeah, world domination. It's one of my taglines, actually. Oh, dear, oh, dear.

Excellent. All right.

Hey, thank you very much, Pete. We'll, 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.