doesn't matter what method you go through, if you've never done something before and nobody in the team has ever encountered it, you've got no point of reference. It's not really a method problem, it's an experience problem.
Malcom:CTIO 1 O 1. Business Technology. Simplified and Shared Sponsored by Fairmont Recruitment, Hiring Technology Professionals Across the UK Europe Don't forget to subscribe!
Jon:so Dave, thank you very much for, uh, for joining me, um, on this. Um, I dunno if it's raining where you are. It's cats and dogs up in Yorkshire on a Friday afternoon after a long week. Um, really, really appreciate it. And we're gonna be talking about Agile. There's lots and lots of things talked about Agile, but actually you and I were discussing this earlier in the week and we thought, actually what would be interesting was to say, is there something different or special about Agile when it's done in the UK public sector? So that's kind of, you know, that that's what I thought was be great for us to talk about. Um, before we kind of tee that off and get stuck in, it'd be great to get just a bit about your, uh, background, your experience, um, you know, what, what is your public sector Agile experience, you know, how, how, how did you find yourself kind of in there, uh, and, and doing that. So just a bit about your background really.
Dave:Well first of all, thanks for having me, John. It's good to be here. It was about seven or eight years ago, uh, I started working for myself, uh, and kind of ended up in the public sector. And it wasn't necessarily intentional. The last couple of projects I'd worked on in the outsourcing provider were in the public sector. Uh, I enjoyed it. Uh, when I started working for myself, it kind of just lent itself to, to that kind of work. So, uh, yeah. And that, that's brought me to where I am today.
Jon:Do you remember your first Agile project, or do you remember Agile kind of coming in and being a thing and kind of getting your head around it or, you know what? Yeah. So what was your, you know, how did you kind of, uh, get introduced to Agile or kind of how did it get on your radar?
Dave:It, it must have been around 10 years ago when I was still working, uh, for the outsourcing provider. And I remember, uh, kind of being one of the, the kind of team leads in a department and somebody was coming along saying, We're going, We're gonna try and move Agile. We're gonna try and be a little bit more Agile. Uh, so they took the leadership team away and said, Right, this is Agile. This is what we're gonna need to do. Well, we'll, we'll try doing this. And at the time, uh, in my early Agile naive days, I was like, This isn't that difficult. You know, we, we can do this, You know, you only have to do this and, and do that, and it's okay. Uh, and looking back, like say it was very naive, Uh, it's the sort of thing, you know, 10 years later I could wish I could travel back in time and give myself a bit of a slap round ahead, uh, and say, actually, you know, you didn't. You didn't really get it, You weren't really bought into it. Uh, and whilst we did a few Agile bits, it really, really didn't sink in until probably about a year or so after, after doing these sorts of things. And then engaging with the, the kind of coach that was leading us on the journey. Uh, cuz each time they'd be like, Well what about this? And what about that? And have you tried this? And what about doing this? This might help. And it was only, I suppose years later occurred to me that it was a bit of a journey, a bit of a learning exercise to realize that actually what he was doing was actually quite good for the environment we were working in, which could afford to be a little bit flexible. You know, we had the flexibility in what we were doing. Uh, we could try different things and if it didn't work, we could tweak it and move things around a little bit. Uh, yeah, it was on after, uh, like I say, many, many moons to realize that that flexibility is in built.
Jon:David, it made me think, uh, when you talked about, you know, the first time you used or adopted it and the mistakes you made, and can you travel back in time? Um, do you think actually that that's still happening? I think with folks, everyone goes through that sort of phase when they first encount. Agile. So even though for you it was 10 years ago, but do you see that at all? Do, I mean, do you still encounter folks who haven't really used Agile before there's a resistance to it? Uh, Or do you think actually now that's kind of done and everyone's, everyone's sort of on the other side of the fence.
Dave:Yeah, I think, I think it's still there to an extent. I mean, I enjoy working with teams and one of the things I found recently working in, certainly in government is there's a lot broader acceptance of it as a kinda mindset and. I think with that, people that kind of move into this space want to understand a little bit more about the roles. So inherently you find people that are actually open and interested in learning a bit more about what it means to be Agile and, and what's behind it. So certainly in the areas I've been working in, for the most part, I think people are a much more bought into it. Um, which is a fantastic start for Agile. Cause you know, you've got to have that openness and, and like I say, I go back 10 years and I realize I probably wasn't as open as I thought I, uh, I was back then. Uh, so certainly in, in the spaces I've been working in around public sector, it's like I say, it's been a lot more acceptable. Uh, but from my experience, yeah.
Jon:Does Agile replace project management or planning? So if you're doing Agile, do you still have to plan.
Dave:we do, Yeah, we, we still do a lot of planning. Uh, we, like I said, Agile is a mindset and there are various flavors of, of frameworks that you could adopt, uh, to be Agile and, uh, a common one is Scrum, for example. And, and essentially you work in cycles. Uh, we, we work in two week cycles. Uh, and what that enables us to do is, is size work on a two week basis. Uh, and on a grand scheme of things, you talking about planning in particular, we're able to plan those cycles. So what we'll say is actually let's do that piece of work, but we'll do that in three cycles time, uh, the sprints as we call it. So we, we will say, actually, you know, let's do that piece of work in three sprints time. Uh, now I think that the thing with that is you're actually planning three sprints ahead is, is not unusual. Uh, but the further out your plan, the more, uh, flexibility you might require down the line. So planning is still a kind of core part of, of what we do and how we do it. Um, you know, I think people still, when. Kinda have an expectation of some, something being built, something being done, something being enhanced. They still have an expectation or would like some idea of, of what the, the kind of timelines might be. So yeah, planning is still very much part of what we do.
Jon:And, and David, that reminds me of, um, something they say about planning. Yeah. So the first thing is, is that sort of statement sort of suggests that it says, you know, if you do Agile, do you have no certainty? You know, that's really what it's saying, isn't it? But actually, when you put a plan together, I mean, it's this, it's the old saying, isn't it? The plan is out of date, the second you've written it, but the value you get is planning. It's the process of planning that gives you the value. If you think you're gonna put a plan together and Exactly. It's, you know, everything you've written, you've confused a plan with a really detailed prediction of the future. Yeah. So, so, so, so for me it's like, you know, in any, anything you do, you're gonna do planning as a process. Um, it's just you've got a framework around it. I dunno what your thoughts are on that.
Dave:Yeah, no, it is. I, I think a good example, and, and it's kind of a, a fundamental part of, of how we work in Agile, how I've been working with some of the teams is when you are working with a really good team and an experienced team, which is the same for however you decide you wanna develop something, uh, in, in the it digital space, uh, having a really good team is, is is a key success factor, isn't it? It's critical that you've got a team you can trust. And something that happened to me a couple of years back was we were working with a really good team, uh, and somebody came along and said, Well, actually we wanna do this with this particular product. How long do you think it'll take? And it, it wasn't a small piece of work. And one of the things I was able to go back to, our lead developers say, Well look, you know, we've been asked how much this is. And he was like, Oh, that's really. And so immediately it was like, well, how big is it compared to this other piece of work we did? I was like, uh, probably not quite as big as that. And it was like, well, okay, then what I what? A lot smaller or just a bit smaller? Probably a bit smaller, but, and we had this discussion about how big it was compared to this thing we'd done. And I was able to say to him, Well, that thing took us two months. And he was like, No. Yeah, it's, you know, and, and actually that was, that was good. That was actually, that was great. Cause what it enabled me to do was kind of give an indicative look, you've asked me for an indicative kind of idea. It isn't a plan, but what I can say is, based on this previous piece of work, it, it's about the same and it's gonna be about two months. And I think that's the core part when we talk about planning in Agile, um, you know, being able to do that, having the experience in a team to say that, uh, is a big plus. But then you, then you start talking about, well, okay then how experienced is the team? And, and that's a whole of the chapter.
Jon:You know what? I, I completely agree with you because if you think about it, it, it, uh, and actually it kind of gets us a little bit into the next question, which is around, um, Agile being a silver bullet. Um, but it doesn't matter what method you go through, if you've never done something before and nobody in the team has ever encountered it, you've got no point of reference. It's not really a method problem, it's an experience problem. Um, you know, so, so, so actually, you know, if you, if you really do understand the space well, um, you know, uh, you, you, you. You can make those estimates, um, because that's so, so, so I suppose what we're saying is Agile is absolutely no substitute for experience, but in this instance, the, the example you were giving is, it's a really good framework if you have experience because it's a much faster way of maybe sort of getting an idea of the problem space, this size, the sort of the risks, et cetera.
Dave:Exactly.
Jon:brilliant. brilliant. Okay. Well, okay, well, I suppose we, that does lead us into that, uh, that next statement. So, and, and I think this, uh, silver bullet point, um, I've, I've not met anyone who seriously said it's Agile and it does everything as in the silver bullet. So I think this question is more addressing people who are, who are hearing about Agile sort of at the side of, of activities. They're not quite drawn into exactly what it's about, but they've heard a lot about it. And, and I think if you want to adopt something as a team, you do have to sort of shout about it a bit more than maybe. You need to just to get the change, and therefore you get a perception that, you know, Oh, so it's just Agile now, this sort of silver bullet. So, um, would you say, I suppose, so if we do the very strictly, the silver bullet analogy is the kind of, is it right, Would you use Agile in absolutely every scenario that you're faced?
Dave:Uh, definitely not. Definitely not. And again, from experience, it's, it, it's, you have to take a step back sometimes. Uh, I worked in a department a few years ago and there was a particular piece of work that was asked to get involved in, uh, and it was a migration piece of work. It was a data migration piece of work. We had a project manager, uh, looking at it, and he, he was trying to work in, he was trying to work in Scrum and do cycles. Uh, he had a big, long list. And actually we had a discussion and we sat down and I said, So what you have here is a kinda linear, you know, you have to do a certain set of things in a certain sequence. Yeah. And it agreed that. I was like, So why are you using Agile? And it it, it went straight to the, Well, it's two week cycles. It delivers value. Uh, I said, Well, maybe so. But in your example, the project you are involved in, the activity you are trying to do is a very linear one. And actually we said, I, I think you probably need to drop Agile in this. This is very much a waterfall project. You have a linear set of requirements. You know exactly what they are. Um, you know, and you can get timelines from everybody in the link in the chain, uh, and, and develop it that way. Uh, and, and, and it was really interesting to have that discussion, but it was that kind of step back. It's just cause we are working in an Agile space doesn't mean to say you have to adopt a kind of Agile approach for something and make it fit, you know, make it really work for that piece of work you're doing when actually, you know, your requirements. You know, it's a linear piece of work that's it's classic waterfall. That's probably the best way to get, get that piece delivered. And, and so we kind of scrapped the Agile, uh, kind of methodology or mindset in that particular example. Adopted a bit of waterfall. Uh, and, and, and yeah, it kind of went through, uh, as you would
Jon:You know, it's very obvious that it's not a silver bullet. I think though, when folks who are doing something maybe should be very well suited to Waterfall, but they're turning to Agile, aren't they? Sort of trying to innovate a little bit, even the waterfall approach. That discussion you were having with that project manager about, and you said actually this is Waterfall, the fact that the project manager was looking at taking elements of Agile and using it, you know, maybe he was, he or she was really interested in the, the two week, the, the, the fortnightly cycle or, or elements that they wanted to use. Um, you know, is that, is that legitimate? Is that allowed, you know, he's trying to innovate the way he's doing waterfall. I mean, I've heard it described as Wagile uh, Waterfall and Agile. Um, not, you know, so I've heard that term before. I dunno, it'd be interesting in your thoughts on it, but do, do you see what I mean? So they're not doing. Just doing Agile for the sake of Agile, but maybe they've, There's bits of Agile that really chime with anyone who does delivery and it's like, I'd like to, I'd like to pinch that and use it in the waterfall context. Do you think there's any transferable parts?
Dave:a absolutely. I think, you know, there's lots of tools and it goes back to, you know, Agile as a mindset. You know, it really is a. And I think this is, this is the one thing I've learned over the years since that very first moment, somebody, you know, came in and, and threw Agile letters. Uh, it really is a mindset. Therefore, uh, you know, for me it's about, you know, it's about being pragmatic. It's about being kind of nimble, but, but with a structure. And I think in that example that there, I would certainly promoted any of the things that, uh, that project manager, in fact we did at the time, any of the things he'd seen that was happening in other teams that were, you know, kind of applying some Agile uh, flavors. Uh, you know, he, he took along. One of the best examples is, is we have this thing called retrospective is where we reflect back on, on what's happened in the previous couple of weeks. Uh, we looked to see if there's anything we could improve. Is there. You know, might not wanna learn from in terms of going forward. Now That's, so that's,
Jon:that was an example of something that he took actually, so he could still, you know, play that back in his team, even though it was kind of, you know, from a project management sector or a project point of view, it was still a waterfall.
Dave:But actually things like that, retrospective was something he could play in with his team to reflect and improve things when they were moving forward. Yeah.
Jon:And I, and I dare say cuz it's a really interesting topic, it kind of excites folks. Uh, sometimes it exercises folks, you know about methods, and there's probably someone shouting at the screen, Well, we've got a version of a retrospective that's in Prince two. Or it's a stage review or something, you know, But the, but you're right. It's just, you know, you, you construct it yourself. I think, I mean, ultimately, I think where we've got to really quickly in this conversation is if anyone wants to put their hand up and say, This is what Agile is, that's just a folly. Because you can't say exactly what it is. If it's a mindset, you can, you know, you can probably look at something and go, Yeah, that's, that's Agile. But it's not the, there's so many different versions of it. It's not like one single uh, flavor. Would you.
Dave:right. That's absolutely right. You know, there are several flavors and it's, you know, the word word Agile itself came, you know, came from, you know, agility and being about being Agile, being, being nimble, being flexible. Uh, and because of that, like say you can see how it is a mindset and, and things like Scrum came along where you can work in cycles and work in a certain way, help you be more Agile, help you be Agile, uh, and kind of, yeah, that's just one flavor of, of that mindset.
Jon:In that, uh, kind of, there are different flavors. Uh, obviously one of the things we're looking at and, uh, you've got a lot of experience of is, is using, uh, adopting or, uh, taking on the Agile mindset within the UK public sector. Um, so, uh, you know, if, again, I think folks maybe who have, have heard about it, who are more on the edges than, than are in the center of it, they might say, you know, is Agile. Uh, just a fad, you know, we'll be back to Waterfall. Or even actually they might not say that cause they might not know Waterfall either, but they might hear Agile and just think small a just agility, but not really know that it's a capital A and it's got a few more things to it. So is Agile in the public sector here to stay? And, and, and what's the sort of, in your experience, if you had to sort of say that mindset of Agile, you know, what makes that distinct perhaps from, from other interpretations.
Dave:So, so, so your first question around is, is it a fad? I'd like to think it's not, but you know, history, history tells us and informs us a lot. There's been various flavors of project management and how people kind of develop IT projects and digital projects. Um, so, so, so we have form in the industry, you know, we develop a new way of doing things and then a few years later we'll develop a new way of doing things. I think for me, what I'm seeing is in that Agile mindset space, there are more flavors of Agile coming along. So I think Agile will kind remain that umbrella, uh, title if you like. Uh, the different flavors of Agile underneath that scrum, I think called Extreme programming, Kanban. There's various ways that people can structure Agile deliveries and, and then within that, each of the way that each of those things then start to structure themselves, I think that's the part that will start to evolve or will evolve more. Um, I think we've in the past talked about DevOps as well. You know, that that's a thing that's kind of coming into the frame, which is kind of subject in its own right. But again, helps being Agile in, in certain circumstances. So I think that that's the first part in terms of is it a fad?
Jon:Just before we do the second part, um, that you mentioned extreme programming. Uh, just, just a very quick aside, I was at a, an event, uh, recently and someone was talking about psychological safety in teams. Uh, and, and what they meant was having a team where people can fail, but safely. So it's enco, it's not encouraged to fail, but if someone makes a mistake, it's just got a culture of I've made a mistake. You know, that's, that's what they mean by psychological safety. And the guy was saying that, um, in certain industries where you have psychological safety, there's actually less accidents and in, in places where you are not meant to discuss. Not only are there more accidents, but they're also more serious. So, um, and sorry, so just to get to back to extreme programming, this is where, cuz I'd heard of extreme programming a long time ago with the two, two. So people who don't know what extreme programming is, it's two people programming together. One has the experience of, of either the language or the code, or the domain or the system or all of the above and the other doesn't. Um, but what I learned, uh, on this psychological safety, and apparently they do this in medicine as well, that it's absolutely vital to have the junior person with their hands on the keyboard. Sorry. No, uh, yes. The junior person. And the reason is because if you have the senior person with their hands on the keyboard, or even more scary, the senior person with the scalpel, the junior person won't say anything if they think they've done made a mistake. Because the psychological, you know, the relationship is a little bit parent child a
Dave:Yeah,
Jon:So, uh, I just found that, I found that really fascinating that, um, you know, you got this super bright, you know, person who's, who's watching the really experienced person make mistakes, but they won't say anything. Uh, and switching around, So, sorry, I've dived into a
Dave:No, no, that's good.
Jon:hole there. Um, Dave, But it's just, you know, I just think, um, we mentioned extreme programming. Quite a few people listening wouldn't know what that, what that was. So let's, we'll get back to, um, to the questions we would, we were talking about, um, uh, whether Agile in public sector was a fad,
Dave:I think Agile is a mindset, is here to steer that, that pragmatism, that agility and flexibility. Like I said, I think it's the, the flavors underneath that will evolve more. We touched on, you know, DevOps is a, is a thing that happened over the last few years that actually, uh, is an enabler to being even more Agile under certain frameworks. I think they're kind of things that'll evolve. I think that that Agile umbrella is probably around for a little while, uh, because it offers so much value and, and you know, just touching on psychological safety, you know, that that's kind of core fundamental in smaller teams being able to, uh, you know, feel safe, uh, because then you, there's just that little bit more flexibility to be able to get on with things. Uh, and obviously there are safeguards. Uh, but, uh, but yeah, no blame culture is, is, is fundamental to, uh, you know, all the departments I've worked in, uh, and in go across government as well. Yeah.
Jon:If we get into, maybe fail fast a little bit because I think that links to the psychological safety and the culture bit. So, um, I remember that phrase and just seeing senior people rolling their eyes cuz they don't want to use the f word fail is just not a word you want to, especially when you've got, you know, a certain culture of delivery and, you know, that didn't like that. So I, I sort of thought about it, I said, Okay, can we express this in another way, but mean exactly the same thing? And so I, I put in sort of like, learn fast because the ultimately the, the objective is to get the feedback and go, okay, we made a mistake, we've learnt and move.
Dave:Yep.
Jon:Um, uh, and uh, and it sort of suggests a bit more of a, but I suppose that's an example of me putting my own flavor on the mindset, uh, to sort of learn fast. Um, and then if, if you do create those teams where I, I used to, um, take part in some of the, you know, ceremonies not often cause you know, uh, you're not meant to do that, but I, I did it occasionally, but what I was really careful to say was, Look, we're first amongst equals in this scrum, and I'm taking my CIO hat off now and I'm putting my engineer hat on. So I'm joining this as an engineer and I want to as an equal to, to help with understanding the problem that we're solving. Um, so, which was a bit different from, you know, me going, you know, staring in. Changing the dynamic of the team. And I, you know, I'm very, very careful not to do that very often cuz I know you're not meant to. Um, but, uh, well, what's your thoughts on that? Was I, was I being, was I being naughty? Um, sort of inviting myself into certain sort of scrum meetings, et cetera.
Dave:not, not really. Again, I think it depends on the environment. I think there's a couple of things you touched on there. Uh, I think one is that everybody's equal and, and again, you go back to the experience and the maturity of a particular team. You know, a mature team will accept that. You know, if you are coming in and you've said, Actually, even though I'm the cio, I'm coming in here as an. You will, you know, you'll be credited or, or, or challenged on certain observations like anyone else. So I think, again, there's a lot to do with the maturity of the team and going back to the point about learning fast as well. I think in government there's a kind of structure around that that enables you to, you know, speak with users, understand what their needs are, come back, build something, you know, it might be a storyboard or it might be a kind of prototype or something, Uh, or, or a mimic tool or something. Go about test it and that's that learning fast. Object. I think you're just referring to there, it's learning fast before you actually get, start to build things properly. And there's various fears in the way that government do that, in terms of how they do it to make sure that Okay. The feel fast thing. Yes, absolutely. I think learn fast is probably the better way and I much prefer that term. Uh, but the way government do it, they learn quickly, upfront and they equally learn what doesn't work. Uh, and that then puts them on a stronger footing when they actually start to build something.
Jon:What that then does, I think what we've just worked out is you said right at the start that you've, you, this Agile isn't a substitute for experience and no is waterfall. Um, but actually the learning is building the experience. So actually you've, you're creating almost like, uh, on the job, knowledge creation, knowledge transfer, working it out, and you know, getting that great experience, building up all the way through, which is, let's face it, if you're, if you're an engineer, that's, that's what it's all about. It's learning. Uh, well, not just engineers, anyone, um, in technology, it's, you, you, you are drawn, I think, a little bit to the flame because of it's exciting and you learn, you know, and that that's the best way to do it The worst thing to do, Sorry, go.
Dave:I was just gonna say, even what I'm doing now, uh, you know, I kind of work with other, uh, delivery managers in the role. That's my role when I'm working in government and I'll work with other delivery managers and even then, it's a continual journey. It's a continual learning exercise. Uh, I, I started working with somebody, uh, just over three years ago and, and I saw something they were doing and I really liked it. I thought, Do you know what? I really like what you're doing and how you did that. I'm gonna start doing that. And, and it's, it's having that openness. So, you know, you never reach a, a kind of full level of maturity cuz everything's always evolving. Uh, but you know, you, you know, when you've got a certain level of maturity and able to, to do that looks like that's triggered something.
Jon:I love this story and I learned this when I was doing my A-level history. So that is, you know, 150 years ago. Literally, almost literally. And, um, it was to do with, uh, the Victorians and selling encyclopedias.
Dave:Okay.
Jon:And what they said was, you know, we've got 12, we've done 12. You know, I dunno if you remember encyclopedias, you know what, there's gonna be a lot of people watching this who will not know what we're talking about because basically go Google and other search engines are available, has sort of become Wikipedia, et cetera, have become the, uh, there you go, Wikipedia encyclopedia. So, uh, um, by the way, hadn't just worked that out then. Um, so they, they, the Victorian thought, right, we've done 12, there's probably just 12 more to make and we will have got all the knowledge in the world contained in 24 volumes. And that's, that was your point about learning. If, if anyone's in technology and you're sitting there thinking, you know, what? I think I've just about got it all covered. It's just, that's just, I don't think anyone does that anymore because the pace of change is brutal now. Um, but I do, you know, if you think there was a bit of a lull, um, and you know, the waterfall, uh, there was something called SSADM. I dunno if you remember that, but, uh, it's like the most, Yeah, so it was describing in minute detail how to do effectively the longest project you could ever do. Cuz it was sort of waterfall, uh, made. And I think that was a little bit in the encyclopedia. Okay. That's how you do it. We've written it now. We don't need to. Now let's just get on and, and write some code.
Dave:It's interesting how that past experience, certainly when you talk SSADM, you know, I remember being a development manager, you know, in years gone by, uh, and even doing bits of waterfall and it, it never leaves you that experience. And just generally, whether you're a delivery manager, an engineer, a kind of quality assurance tester, uh, you know, even use the research and now you're kind of continually learning, uh, different things and continually evolving.
Jon:And I suppose it's probably the point, and we mentioned Ss, SSADM in Waterfall and Agile. So I'd like to just get this in, uh, to the, to the episode, which is, uh, and I'll put a link, we'll put a link, uh, to the actual author so that he, he is properly accredited and apologies. I most definitely should have written his name down beforehand. But the author of Waterfall, the original author of Waterfall at the very end of the paper, and I've, I went and got the paper and read it just to, you know, and you get right to the end and he says something like, Of course you'll, you won't get this right. First time through, so you need to iterate. So SS ADM was partly influenced by that paper, but nobody, maybe the, maybe it's one of those cases, you know, where the printer, that last page got, you know, wedged under the, under the desk and nobody read it
Malcom:This episode is sponsored by certs eye tea service solutions. Certs have a new innovative offering called Agility Ability that provides adaptable, flexible and scalable expertise to deliver UK public sector transformation projects. If you are seeking a full journey management service, then our Complete Agility Ability Teams, provides you with multi- and inter-disciplinary teams with skillsets that change in line with the demands and evolution of your project.
Jon:so I think we're talking about that, that psychological, um, safety. And one of the things they were saying is there's, there's no room for ego in, uh, uh, in an Agile team, but actually ego is a psychological trait that everyone has. So if you don't have ego, you, you are probably not human. Uh, but you've got to manage it. So do you see in your experience, you know, when you are trying to get that. Gel working. How do you handle sort of, initially maybe some, some competing ego or folks who maybe haven't done this sort of thing before? I mean, do you find that some people are uncomfortable or how, how, you know, what's your kind of take on
Dave:I have worked in teams that, that, you know, are kind of just forming. Uh, and, and still get into grips with, with what we're doing or what the objective is or, or maybe new team members that are joined, or it's a new team pulled together. And, and it's definitely a thing. And, and then as a, a scrum master in that scrum world slash delivery manager, what I do now, part of what we do is, uh, kind of facilitate things. Uh, we might arbitrate between different things and it's trying to do that in a constructive way. So, so yes, you get people with, with big egos that have a very definitive way of doing things, uh, and people who are probably a bit quieter, you know, the junior people that might not be quite keen to speak up. Uh, and it's really trying to build the forums to make sure that those people have a. voice Um, and I, I have started sessions with those types of people by saying, you know, I apologize in advance if I could show on something or stop you, but I'm doing it because I want to make everybody aware they've got an opportunity to speak and I, and I will kind of bring people in. And, and being able to do that upfront sets the scene. So I, you know, if, if somebody then with a big ego is able to, you know, kind of carry on or, or, or take over a conversation, it, it allows me, it's given me that license to be able to step in and say, Right, thank, thank you for that. You know, Mary, what do you think? And get, you know, get Mary's opinions on that sort of thing. And again, that, that's something you learn when you're in that facilitation piece. It's set that framework up front so no one's upset if you do have to cut them short a little bit, uh, because you know, you've set that, It's like Right, okay. I know Dave said he would do that. Harry might do that. So back off and, and that works really well. It's very effective.
Jon:Just to put like a, a really contemporary spin on what you've just said, um, you know, this, uh, when you talk about, uh, meeting, uh, folks, uh, like we are right now over a webcam, uh, and you've got, except this time, there's 12 of you. You're not in the room, uh, you're not maybe able to read some of the body language, et cetera. Um, but there's, you know, lots of people talk about. You know, not everyone is an extrovert. You've got all, you know, got everyone, but actually everyone's got a, a really good contribution to make. So is there any, have you had any challenges trying to bring out people in that, you know, let's let everyone have a voice, but specifically because of video conferencing? Cuz not everyone's comfortable still just getting in front of a camera. Uh, you know, and I don't mean that in a, I think that's entirely fine because it's just not for everyone. But do you have any experience of that and any, any, any techniques?
Dave:Yeah, it's, it's interesting to, to, I mean, like I say, online gives people a kind of screen to hide behind if they want, and that, and that's fine. Like I say, we don't, you know, we're not gonna, we're not gonna force people to, to make'em feel uncomfortable. And actually one way of addressing that to make people feel more comfortable is to make that whole environment level. So it's bringing everything onto a par. And there are tools out there that can help you do that. Uh, we, we've run retrospectives again, you know, this, this kind of reflection, uh, cycle in what we do or a part of the cycle that we do. Uh, and there are, uh, techniques you can use where you just see it to everybody, like, what do you think? And everybody chi chimes in, uh, in, in a, in a structured way. Uh, but the quieter people might not, they might not do that. And, and that's fine. But then there are other times when we'll do something that's a little bit on a par. And I remember doing a particular exercise, uh, it was just at the start of the pandemic actually, when we thought we were only gonna be working from home for two or three months. And after a couple of months, We said, I know, let's focus on, we had a, you know, you could do, do themes. It's like, Oh, how did that release go? Or something here. And we actually had a theme. We said, Well, actually, let's see how it's working from home. malarkey is going for everybody. Uh, so everybody had a picture of a house and everybody then had to put what they liked about, you know, working from home, what they enjoyed, uh, how effective or productive it made them, and anything they didn't enjoy about it as well. And because of that, everybody was brought onto the same page. Everybody had the same, uh, requirement to, to participate. Uh, and then it was a case of growing around each individual. And again, it was a, it was a very much brought to a level playing field. Uh, and not only did it, I mean, we did have quiet members on the team. Not only did it bring their, uh, their kind of voices to the table, uh, on that level playing field, uh, what it also does is, is reveal some of the challenges, which is exactly what that, you know, the purpose of that forum is for, to to reveal any issues or challenges. So it did a couple of things. Uh, and, and that's why, you know, retrospective isn't necessarily a set thing. It, it's something that you can adapt and change and, and be flexible with, uh, not just in terms of the theme or the objective of, of what you're trying to get to the bottom of, but certainly in terms of creating that level playing field, so everybody's comfortable, uh, participating. Uh, you, you've got some eagles appear, some voices down here, and actually being able to bring them into, into a par, uh, you know, even if it's just for an hour, a fortnight, uh, is really useful. And, and, and does that thing of bringing everybody to, to that same level, whether you're a CIO or being an engineer or, or whether you are, you know, one of the junior developers, uh, listening and learning.
Jon:Just a little bit more on that theme, do you subscribe to trying to get everyone to meet in, in real life, I think is the, uh, social media term, but you know, for real or once a month or something where folks are actually connecting or is, are we now in a space where that's just no longer possible? Maybe who get half the team? Because the, the other challenge I, I've, um, encountered is when you've got, um, 90% of the team in person, uh, but, but in, you know, because of, we're so used to this, invariably there's some people who aren't there. So then you are, you're not just managing across different dynamics, but you've also literally got folks who aren't getting any of the emotional cues in the room because they're not, they're not being able to see that. Uh, so it's quite difficult to manage, but, um,
Dave:yeah.
Jon:it's risky, I think to mandate things, but I've always found it really valuable to just have a connection in person at some kind of cadence.
Dave:I, I do agree. It's, uh, we, we, we occasionally, Uh, meet the office, some of the team now, we would've not mandated it. Uh, in fact, we've tended to choose and pick deers, uh, for team events where there isn't actually a team event, if that makes sense. So, so we, we don't force every to come into the office. Uh, so when we do meet in the office, it tends to be, you know, the objective of being in the office is just to connect. It's just to speak with people. It's not, uh, an op, it's not an, an essential to, uh, you know, bring an, an objective or a forum or a particular meeting. It's purely to get together, chat, you know, and somebody will see it. Oh, actually, yeah, if, if Sue's gonna be in the office, I'll come in as well, or, uh, you know, or, or somebody else is there. It's just a chance to catch up and connect. And, but I think it's difficult because going back to the point you made earlier about, you know, junior, junior people, I think they're probably ones that suffer the most because they don't get the opportunity all the time to sit with somebody who, who understands what's going on and, and be able to chat. We, we do what we can with the tools available online to be able to pair up with people. You know, we've done that literally where people meet in a meeting room and they'll have their, their, you know, pretty much all day working together with somebody else and partnering up that way. It's not a substitute being in the office at the same time. Uh, but there are pros and cons.
Jon:I was just/gonna say, I completely agree with you about the make it, uh, about connecting with people rather than making it part of one of your delivery meetings. Cuz actually we're all so efficient now at doing this, uh, our delivery sessions online, it's actually easier to do that. Uh, but the value of connecting and also you're placing, really, you are telling everyone that actually connecting is really important because we've, we're here just to connect, um, and you get all sorts of conversations come off the back of it. People might be thinking, Oh, this is interesting, but this discussion is turning into a kind of remote working. The reason why I'm, um, emphasizing it so much is because, you know, you've said it's a mindset. We've talked about psychological safety, so there is a huge part of, of Agile, which is about creating a really good team, isn't there? Um, you know, I, I personally, I think it's just a massive part of it. It's bringing out the best of everyone and, and creating that environment where you can really, you know, create value and um, and, and speak freely.
Dave:it is. Yeah, I think it, I mean, it's something we touched on before you were saying what's the, what's the kind of thing I'm really passionate about in the Agile space? And it's something I've been asked before, and for me it is that people. You know, it's having the people on board, it's having them engaged. Uh, I, I have a, a conversation with a, a friend that used to be in the forces and we, we talk about banter. Uh, you know, he had banter when he was in, when he is in the armed forces, and it's not something a lot of other nations do. The same way that, that, that we are doing Great Britain in the United Kingdom. Uh, he'd worked with a lot of foreign, foreign forces as well, and it was quite interesting. You know, it was like they just don't get banter. Uh, and that for me is one of the big things in a, in a team, a functioning team that gets on really well, is being able to have the banter, being able to have a bit of fun in what you're doing, uh, and, and, and engaging it just right. And it makes things, it makes things fun as well as productive. And, and that, that's come up in, in, you know, in, in topics and conversations before. It's like, well, you know, you know what, what do you want in an Agile team? Uh, we want it to be fun. And it's a little bit of a cliche. It's like, Well, yeah, but what does that really mean? It's like, we're not here to have fun. We're here to work. It's like, well, Yes, we are. But that doesn't mean to say we can't have fun whil, we're doing it. So, so being able to create that safe environment and that anybody who can participate to the level that they're comfortable of, uh, you know, even the quiet avoidances sometimes might not want to and that's absolutely fine. Uh, but getting the right balance and blend of the team and, and, and engagement in the team. Uh, cuz when you start to get that, people start to knuckle down. Uh, and, and it's amazing the results. It can, it can really produce
Jon:Everyone who's listening can try this out. Um, if you think back, uh, to a, a great team you were in. I hope everyone that's listening or watching can, can think of a, a team at some point in their career that they enjoyed. Um, you won't necessarily remember exactly what you did, but you'll always remember how you felt.
Dave:Yes, absolutely.
Jon:that's, that's the sign you look back. It's not even immediately obvious, you know, when it's happening, but just a little bit of separation and you are in, you are in a different environment that maybe isn't as good and you look back and you think, Wow, that was an amazing feeling. Uh, and, you know, we could get stuff done. So, um, yeah, we, we are talking a lot about people, but, uh, I, I don't think we need to apologize because I think that is really core. And may, maybe that is a little bit of a distinction that Agile brings out, uh, as, because I don't remember SSADM talking in depth about teams other than maybe RACI matrixes and stuff like this.
Dave:We're kind of in danger, kind of verging in the, the topic of culture. which is a very tough topic to, uh, to start sort. But, but it does actually start to play into that. It does actually start to play into culture, you know, and having it, because it's a mindset then it's difficult to, to break the link between the two
Jon:So there's the saying, uh, and again, we'll accredit the person who said this, um, that culture eats strategy for breakfast. That's the, that's the old saying. And I think if you have, if anyone's done any business change, if you are reading documentation that says we're gonna change the culture of the firm or the company or whatever, that for me is a big red flag. It's like, well, that's gonna take, you know, actually, does anyone really want to change their culture? And even, is it right to ask someone to change their culture? So it's very complicated topic, but I suppose this might be where we're getting into a little bit. What's special about Agile in UK public sector? Cuz all organizations have a culture. So if you think of the UK public sector culture, what elements of that are very receptive to Agile and what elements of that are perhaps not as receptive? If I could kick us off, I would say in my experience, the UK public sector, quite rightly so, there is a, um, what's the phrase when you, you are open to believing in something, but only if you see the evidence, but you won't just, I think it's, I think it might be a sceptic, the actual definition of that is someone who is open minded as long as they see the evidence. So I don't, and I think that's something I've seen quite a bit in the public sector. And I think that's a, that's a really good thing, because you should be looking at the evidence, but it does mean that you can't kind of arrive on a horse and go, We're doing Agile. Why? Well, cuz it's great. You know, there's sort of, I want to see the evidence base. I don't know if, if you've encountered that at all.
Dave:I go back to, uh, when I was starting, like I say, I go back 10 years also go up probably a bit longer, uh, and really starting to get into that spear. Cause I was a skeptic to start with. I'd heard of it, I wanted to, to learn a bit more about it. Uh, and it was really, like I say, I was probably a bit naive at the time, but really it was a, okay, yeah, we can do that. That's okay. That, that seems easy enough. Uh, we, we can do that. So even though it was quite skeptical, it was like, Okay, we can give it a try now. At the time it was very much a let's try it because actually we wanna do, we're wanna try it with the leadership team. So when you start to see the. You might become a little bit more bought into it or a little less cynical about it. Uh, and over a period of time we did. So we, we, we, we were in the department. We had about 10 or 11 teams. We started with the senior management team. We were, like I say, we were kind of doing, we were going through the motions, if I'm honest. Uh, and then we said, Well, let's try it with our delivery teams. Uh, and they were a little bit, not, not cynical, but like, Okay, then let's give it a try. You know, we've got these core deliveries we need to get out. Do we really have to give it a good, you know, can we afford to try and, and, and give it a batch? Uh, and it was actually very much so. And what surprised me was how much more effective and visible the success stories were, or the positives of taking Agile product in a short space of time. I'm talking, you know, two or three months of, of some large delivery cycles. You could just see how the team were functioning. Uh, and I, and I was, you know, one of the kind of team managers walking into the, one of the teams saying, I just wanna watch how this works, just pretend I'm not here. Uh, and, and they did, You know, they really went, they really went for any suggestions they went for, but in a constructive way. And it was really interesting to see that. And I think just for my own personal experience, that was the first time I really started to see the value. So even though I'd been through an exercise, uh, the first time I really started to see the value was when I was kind of stepped into a team that had really bought into it and seeing their interactions, their, their body language, their engagement with the process so that even they were convenient to, to participate. Uh, and I was like, Well, how about that? Are we gonna be able to make time skills? It's like, we can if we do this. And, and it was really, Yeah, it was, it was a real selling point for me seeing that
Jon:People talk about engaging stakeholders, stakeholder management, you know, it's, it's almost, I sometimes I hear it sounds a bit robotic. Um, I think if anyone's listening to this and they're thinking about who are these stakeholders and how do we manage them, I think what you just articulated, which is an audience that can move between being skeptical and cynical. If you can detect those, those are, that's, that's a real practical example of managing a stakeholder. Find your stakeholder. They might be in a cynical state, and I think if they're cynical, maybe they've got ex bad, bad experience. They're not just, it's not just, you know, I just don't like stuff.
Dave:I think it's interesting because actually we, we kind of want the feedback, you know, the idea of what we do with that mindset. It, it is about learning, it's about learning fast as we were talking earlier and, you know, and if we're gonna get a stakeholder in that might be quite skeptical about what we're doing or cynical about results they might get, uh, from this, it's like, well, you know, come on in, you know, and, and challenge what we're doing. You know, give us, give us the thing that you think we're missing, uh, and, and, you know, we'll, we'll play that into it if we can, if it's something that's, that's valuable. So it is getting that feedback. Uh, like I said, that learning as quickly as possible, so it is valuable to get those stakeholders engaged in the right, in the right forums at the right times to capture that learning. And, and, you know, if they've challenged it, you know, it's gonna go one of two ways. You know, on a kind of spectrum, really one half of the spectrum is it's something we haven't got. It's a good learning experience, It's something we can take and we can work with the other half of that. That bit of a spectrum is somewhere in between. Actually. We've already got that covered to actually, we've smashed it, we nailed that. What you mean is this? And then they go, Oh yeah, that's right. You know, So you kind of on that, on that spectrum. But generally it is in two halves of we haven't got that, but it's something that you take away versus, Oh yeah, we've got that. This is what it looks like. Uh, in any event, it's that, here's, here's the feedback, here's my thinking from a stakeholder. Uh, and one way or another, they have to feel like they've gone away with some sort of positive experience, even if it's they've gone away and, and thought to themselves. Actually they didn't have that, but they're now thinking about it, you know, or now it's on their rear. Uh, and, and it genuinely is. So, so either way, there's a, there's a positive to, to that stakeholder engagement
Jon:One, one observation is that, um, getting, uh, requirements. Is, is a really big, uh, empirical kind of fact around why a lot of technology projects don't go so well. And when, I mean, get them wrong, I, I'm not really me, I don't really mean they've been implemented incorrectly. So I'm not talking about, uh, we, we, we articulated the requirements really clearly, but we failed to execute. I'm, I'm more about the, we really articulated the requirements probably too early. Um, and so, uh, so when those, you know, went into the hopper, they've come out pretty much as, you know, as we asked for them. But they've now turned out to be something we didn't need. I mean, how many of us have, we've all been there, haven't we, in this sort of discussion of requirements. So I was wondering about your view on. The Agile, um, approach can help with, with, with trying to mitigate that risk. Uh, so that was part of the question. The other part I wanted to throw in as well, and it's uh, it's linked to your experience point that you said at the start, which is, um, in my, my opinion, Agile Waterfall. I mean, I know Waterfall has a big phase called design, but I think you really can't underestimate how important it is to have the best possible fulfilled view of what your product is going to be or the design, you know, up front rather than saying, You know what, we don't need to know anything at all because we're just gonna start with a blank piece of paper and iterate from, from scratch. Um, in my experience when, when that's happened, you can go down some, you can be very pragmatic. Pragmatism in short bursts is good, but if you are pragmatic all the time, you can end up with these sort of cul-de-sacs of, actually we can't, we now can't do what we want to do with the, with the design. We've gotta go back, we've gotta do something else. So I'll give a, I'll give a computer science example. Anyone, anywhere in the world does anything to do with, anything to do with technology. Security should be in your design thinking right at the beginning because it's almost impossible to reverse engineer that. Um, and with everything that's happening around, uh, cyber, uh, and all the vulnerabilities that we've got, um, that will kill off whatever you've, you're trying to do. Uh, and if it doesn't kill it off when it's gone live, it'll be a couple of years down the road. So I'm just giving that as an example. So, you know, security would be a design consideration right up front, but what, what's your view on requirements and design? How important are those and how do you handle those? In, in, in Agile?
Dave:I mean, a couple of really good points you touched on there. I think in, in terms of, of how the public sector works, there's a, there's a continual cycle of getting feedback and, you know, even, even when a service is live and it's, it's, I'll say finished quote un quote, um, there's a continual feedback loop. So if you go onto any government site, uh, invariably there is a link to provide. And, and again, invariably all these different departments collect that feedback and look to improve it further. So, so even right from the very outset in terms of doing some initial designs, getting a design that actually looks like it works quite well, it's tested with users very well, you know, we've, we've prototyped it will look to move forward and actually build it even through that whole phase. Even when you get to the end, it's still evolving. There's still that, that desire to capture more feedback, you know, have, you know, enter, you know, a survey about what you thought and then your suggestions. So, so in terms of research and feedback that that's just a continual loop and I think UK government do that extremely well. But then, like you say, you talk about other requirements, the design, you know, not just about the design of, of what it looks like from a user point of view, but security, privacy, data, uh, you know, what, how does it fit in with things like policy for various aspects? Is there any legislative, uh, design aspect that needs to be required, that there are a host of. Uh, engineers and, and solution architects that, that sit in the background with service designers and, and policy people that make sure these sorts of things are kind of built in. And in the same way that that feedback loop continually exists once you've got the security and the privacy and data aspects, for example, built into that solution, the job isn't done, you know, as, as, as you know, and as you kind of alluded to there, there's, there's the people that are trying to hack this information or, or, or maybe do some criminal damage to it, will find a new way to do that and, and then follows a security where to be done so. So whilst on the front layer you have this continual feedback loop from a user point of view. So the design, uh, is coherent and up to date and maintained, uh, properly for the, for the time. You know, it's always up to date. So is that bit that sits underneath that security aspect, that technological design sits underneath? Uh, and when we talk about team, you know, we didn't talk about solution engineers, you know, the architects of all this, you know, they're kind of fundamental to what we're doing, uh, and, and, and making sure that they've got the right, uh, foundations in place to prop things up. And not just at that time, but also so that, Oh, hang on a second. We now need to upgrade that because this has happened. And, and again, it's just a continual evolution. Uh, and you can't afford to, to stand back on your laurels on this. It's something that's gotta, uh, continually evolve.
Jon:The exam question is, Dave, how am I going to be successful in a, in applying Agile within UK public sector?
Dave:Remember that Agile is a mindset. It's about being pragmatic. It doesn't mean to say, uh, you know, it's something that you can take shortcuts in things. It's about being pragmatic. Uh, I think for anybody looking at how they're doing this, if they wanna use government as a public sector, as a kind of model and think, well how do they do that? I would say anybody's gotta start small, you know, start small and learn things. And you know, there is that feel fast. Learn. Uh, uh, cliche, whatever we talked about. Uh, and it's true. It's, it's a, it's a thing, you know, it's that fail fast, you will, you will find ways of not doing things properly. Uh, and that's a success. Uh, but yeah, so it is, it, it starts small. Uh, it, it's understanding what it is you're trying to achieve. Flexa, do you really need to be Agile? You might not. It might be a waterfall project. You might be trying to put a square peg into a round hole. Uh, so yeah, so there's a few things, but I think start small. Remember, it's a mindset. Look at the different flavors. Uh, if you want to get someone involved to help you there, a variety of, of what we call Agile coaches, uh, people that will help how you do it. There's plenty of forums, there's lots of material on the internet, and that can be a bit scary in its own right. Cause there is so much material. You know, we go back to the encyclopedia Wikipedia example, Google, there's just so much out there. Uh, but as I mentioned in that example with that developer that I worked with, where we said, Well, actually it's gonna take about, it's gonna be a little bit like that thing we did before and it's gonna take over two months. Uh, the, the kind of principle behind that was looking for something similar that we'd done before. So if you're signing government, look for something simple that's been been done before. You know, can it be mirrored, can it be echoed? Is it very similar, some complications? Uh, and, and just learn from that. Really, it's, it, you know, there's a lot of Agile is based on baselining, uh, aspects. Taking that baseline, comparing it to what you wanna do next, and, and, and having a view from there. So, uh, yeah, I hope that's helped.
Jon:I'd add to that, which is, um, seek out someone like Dave. For a, you know, for a coffee. I mean, Dave, I hope you're not gonna get inundated with coffee requests, but the point is, is that I would be really wary of folks, because there's folks in this space, it does create a bit of a divide and folks go, Well, that's not Agile, that's, you know, people just really, you know, get really worked up in social media. Um, which is actually a sort of a, a study that's been done as to why that is. So we just part that to one side. But if you are learning about this, I would just be really careful of anyone who's telling you what it isn't or sounding very sort of dogmatic. Um, you know, at the end of the day, you are going to deliver your projects successfully, uh, you know, and you're gonna do it in all sorts of different ways. And actually, let's be honest, on some days it is genuinely under the heading of, Make it Up as you go along. We've all been there. Um, but, you know, just make sure you, you, you're getting those sources from folks who have done it before. And then I think that's, you know, that's, that's a good way of doing it. Be just be very careful about calling a, calling out a, taking a position too early on these, on these
Dave:Yeah. Totally agree. Totally agree.
Jon:Excellent. Huge. Thank you for, for, for dedicating some of your, your Friday afternoon. Uh, and it's been an absolute pleasure speaking to you and, um, I'm sure we'll get some really interesting, uh, themes and, uh, reflections on, on, on the topics we just covered.
Dave:Yeah, I hope so. It'd be, uh, it'd be really good to get the feedback that that's what we're doing. It, it's seriously, you know, learn learning anything is, is just useful. It just gets packed into the arsenal. Things we can take forward. But thank you for the opportunity, John, to have this chat. It's been, uh, it is been really good.
Jon:Cool. You're very welcome.
Dave:Brilliant.
Malcom:Rember folks that Agile is a Mindset and culture eats strategy for breakfast. The inventor of Waterfall was Winston Walker Royce(August 15, 1929 June 7, 1995) he was an American computer scientist, director at Lockheed Software Technology Center in Austin, Texas, a pioneer in the field of software development, known for his 1970 paper from which the Waterfall model for software development was mistakenly drawn. Credit Wikipedia CTIO 1 O 1 Business Technology Simplified and Shared. Subscribe now. Sponsored by Fairmont Recruitment, Hiring Technology Professionals Across the UK Europe