Beyond the Badge - The Case for Agile Certifications with Dave Westgarth

Embark on a transformative journey with Dave Westgarth, a former psychology graduate who charted an unexpected course into the heart of Agile methodologies. Our latest episode takes you through Dave's compelling shift from academia to the front lines of the tech industry, where he learned to harness his adaptability and thirst for continuous learning as a catalyst for success. From navigating his first post-university job hurdles to evolving into a seasoned project manager, Dave's story is a beacon for anyone seeking to reinvent their career path in technology. His insights into the value of transferable skills and the strategic decision to transition from hands-on development to overseeing projects are not just inspiring—they're actionable strategies for growth in our fast-paced digital world.

We also dissect the nuts and bolts of how Agile certifications—like CAPM, PSM-1, and PSK—can be more than resume embellishments; they're pivotal for influencing project outcomes and team dynamics. Dave brings to light the power of Kanban in enhancing project flow and improving communication with stakeholders, showcasing a practical approach to applying new skills. Plus, he stresses the importance of foundational cloud certifications in bridging the gap between technical prowess and business strategy, a balance crucial for meaningful dialogues with senior management. Connect with us and Dave on LinkedIn to continue the conversation on Agile practices and to become part of a community that's reshaping the tech landscape one Agile step at a time.

Connect with Dave on LinkedIn:
https://www.linkedin.com/in/dave-westgarth/

Join the Alliance and support the show! 👇

Transcript

Mark: 0:06

Welcome to the Agile Within. I am your host, Mark Metz. My mission for this podcast is to provide Agile insights into human values and behaviors through genuine connections. My guests and I will share real-life stories from our Agile journeys, triumphs, blunders and everything in between, as well as the lessons that we have learned. So get pumped, get rocking. The Agile Within starts now. Well, hey, welcome back to the Agile Within. This is Mark Metz. Today, as our guest, I have Dave Westgarth from Sunderland, England. Dave, welcome to the Agile Within.

Dave: 0:49

Hi, Mark. Thanks for inviting me along. Pleasure to be here.

Mark: 0:52

I've been following you on LinkedIn for quite some time, so it's a pleasure to have you and for us to be able to have this conversation, as is tradition on the Agile Within. I'd like to ask our guests find out a little bit about where they're from. And if I were to come to Sunderland, England, in the Northeastern part of the country, if I were only going to come for a day, what's one thing, Dave, that you would say that couldn't miss doing?

Dave: 1:16

There's a few different things that jump out. I could talk about world-class football team, who never let us down, but the number one thing is probably our coast, the beach, the seaside. That's the the best part of the city. Our local council invested all the money there and it's. It looks great now. Good restaurants, too. Passable restaurants, I would say. I don't know how much you know about english cuisine, but it's not. It's not top of the pops, fish and chips, that's it, yeah 100, and I'll love me some fish and chips, that's for sure.

Mark: 1:46

Well, dave is currently working as a delivery manager and he's had numerous roles in project management, agile delivery and technology, ranging from a developer to a manager, across several different industries. He's also an active advocate of the agile approach and contributes to communities by sharing resources, coaching, insights and speaking at events promoting agile ways of working and values. Dave, I thought it would be interesting for you just to give us a recap on your career and where you started and where you are now.

Dave: 2:19

It's sort of starting to make me feel old now because it's starting to become a very long time since my career started now. But if I go right back to the start, coming out of university, I found that I'd fallen into a trap that a lot of people seem to fall into. I'd done a degree in psychology, which I really enjoyed. I loved the, the content, the subject matter. That was all really good. But coming out of university I found very quickly the career opportunities were very limited in that field. So I bounced around a couple of entry-level jobs. I did a few call center positions, which it was decent, I suppose as a first step in my career, but not something that I wanted to do long-term. Anyone who's worked in a call center will know very well what the environment and work culture there is like. It's not a place that many people are going to retire, I think, is the best way I can say it. So while I was there I saved up bits and pieces and I started exploring what it is that I could do more long-term, and the key thing I did this time was actually looked at the job market before selecting what I wanted to do. There was a really big concentration of tech jobs going around and I sort of thought to myself well, that's something that I could make a transition into, Worked a little bit longer, saved a little bit more, transitioned back into university life and did a degree in technology and computing.

Dave: 3:31

A year and a half later, I had a brand new career set out for me and I made my way into my first development role at a local consultancy and from there the jetpack was really on for my career Moved from project to project within a consultancy. It was a great place to start, gave me a really sort of wide range of positions, experiences, teams to work on. From there bounced into a public sector role working in a more traditional project management role, then moved into a product-focused organization working in the fashion industry, which was a lot of fun and not something that you really expect when you move from tech organizations to tech organizations. So that was a great one to get on my CV. Currently I'm based out of a larger consultancy, working again bouncing from project to project, with a bit of a focus on all things cloud, AI and agile delivery. That is very easy to say, but it took a lot more work and a lot more time than you might believe you started in psychology.

Mark: 4:20

You got qualified in technology. You started in psychology. You got qualified in technology, went back to school, started out as a developer. How did you decide, within the technology sector, where you wanted to go? How did you pick a developer role?

Dave: 4:35

The main reason I picked the development role was because I could see there was a lot of longevity in that. My experience in call center work was the management layer, especially in call centers is typically the first one to get called when the business gets into trouble. So I didn't want to pin myself into a position where I was easily callable. I suppose I wanted to be in a position where I had some skills that I could take with me throughout the rest of my career. To be quite frank, the development skills are quite hard. So if you can develop yourself there and build that skill base up, you're securing your future to some degree. Don't get me wrong the technology, the tech stacks, the tools change all the time. But once you've had a grasp of those underlying principles and concepts, you can start to build that up again if you need to what led you to move away from being an active developer to other areas of project management.

Dave: 5:22

So that was really interesting. I was working on quite a big project. In my first consultancy role I was a development member of the team and bouncing between sort of development, qa, ba type roles in the consultancy I was at was quite small, so we wore a lot of different hats. We had a bit of a problem because one of the senior members of the team left the organization and the project team and he was serving as a bit of a developer slash project manager in the team. So that left a bit of a gaping hole and looking around at the team I was part of, it sort of made sense for me to step into that role.

Dave: 5:54

I was probably the most extroverted in the team and the one who had the most experience. I was a bit older than the other guys because they came straight from university. I'd already had a few years in between where I'd been out in the world and done some real world experience. So that made me sort of an unlucky or a lucky candidate for the role, depending on how you look at it and I sort of started making my foray into project management and delivery from there, leading more of the team level, communications, strategic comms up to program level and getting more and more face time with people more senior than me and learning quite a lot as I went.

Mark: 6:26

That's interesting.

Mark: 6:26

I can see some commonality between our careers.

Mark: 6:30

I was a developer for quite a long time and I never really felt like we're always harder on ourselves than other people are on us or at least I am, that's my personality flaw and I never felt like I really was, even though I was a developer for a long time, that I wasn't like this wizard, this hacker, this super gifted person that could just pick up any new technology and just run with it and teach everybody else.

Mark: 6:56

But as I look back I saw a lot of my skills were that I could communicate the technical side and be able to bring it up a level to others so that they could easily understand it. And I found stakeholders frequently coming to me when they met with developers say that, dave guy, he was talking a lot of technical stuff. Can you, can you tell me what he said? Because I really didn't understand a word of it. That's where my skills really really lied and I got just enough technical ability that I could do that translation. You can't just all of a sudden wake up one day and say, hey, I want to switch roles. How did you do that?

Dave: 7:31

Yeah, there was a huge learning curve because it's very different track from being on the more purely technical side to moving into that business focused role. Just to call back to a point that you made there, I'd sort of taken for granted that a lot of people in the new business role that I was working in would sort of understand a lot of the concepts that I already understood, especially on the technical front. Those illusions were quickly shattered. A lot of these guys were career PMs, never typed a line of code in their life, didn't understand solid principles, didn't understand software architecture and, as you say, that translation piece came in really handy for me being able to straddle both camps at the time and probably save my bacon more than once. Because, because having that underlying knowledge, that were more prepared to forgive some of my business naivety that maybe I needed to build up fairly quickly, and I think this is probably why I'm such a big fan of the certification track.

Dave: 8:24

That was really the first step for me to get a fundamental base level of knowledge of what this new role was going to entail. One of the first certificates I ever took was the CAPM from PMI, which is their sort of foundational level project management certification. I couldn't quite believe how difficult it was, I thought, because I'd had a technology background and I thought, well, if I can crack software development to some level, this should be fairly straightforward. It absolutely wasn't, and there was a lot of learning there to do around how a business functions, how projects exist within that, the different types of projects that can exist and how delivery takes place in a plethora of different organizations and teams. So I was brought very quickly back down to earth there. I would say so.

Mark: 9:09

it's interesting that that certification was more difficult than you thought it was going to be. How did you find it?

Dave: 9:14

useful.

Dave: 9:15

It was great for a lot of different things, just understanding the full life cycle of different types of projects.

Dave: 9:22

At that point in my career I hadn't worked on tons Not a central theme but it did open the door to things like iterative and incremental development, which at the time for me was totally new, not something that I'd worked on. The organizations I'd worked with were very traditional, very regulation heavy in industries like insurance, finance, so not a lot of agile focus was going there at the time. The other thing that it really helped me with was learning the lingo and increasing my business vocab. The TLAs were coming thick and fast on a lot of the teams I was working with and that really helped me to piece bits together there to develop my understanding. And also I think it gives you a lot of credibility if you can speak that language. I think that's one of the reasons that I advocate for technical skills for delivery people. You'll get a lot more credibility and buy-in from your team if you can speak the same language as they can, and I found exactly the equal and opposite when I moved from technical to business focused.

Mark: 10:15

We had a recent episode Daria Bagina and she's a professional scrum trainer and she was talking about how her opinion has changed over time because she did not come from a development background but she has sinceize with the developers and the people that have to support them about what goes into it, what types of problems they have. So it doesn't just seem like complaining right. Very often, when the technical things are more difficult than they seem from an outsider, if you can't really empathize, it just sounds like somebody is whining or they're just trying to make excuses, but that once you step into their shoes you find out. That's far from the case and I don't know if you found that in your experience through some of your certifications and your real life experience of what you've had.

Dave: 11:13

Yeah, 100%, and just to step away from sort of the negative when it can come across as you're a complainer or a whiner what I also like about development of technical edges you can actually see the problems in a lot more detail now. The problems that the team are wrestling with and the blockers that they've got become a lot more high fidelity for you and you can really see not only more ways, but probably better ways that you can get a lever against this problem and start moving things in the direction that the team need. I'm a huge advocate for developing not only your delivery agile skills but also that technical edge if you're working within these technical teams.

Mark: 11:51

You mentioned the CAPM being more difficult than you imagined and allowed you to empathize more with different types of projects and people working with those different types of projects than you had experience with. Was there any other certification that was very practical that you were able to use and apply? So let's just address the elephant in the room. Okay, we see a lot of chatter on LinkedIn and other social media sites about how people are just chasing certifications, how it's become a business and it's really serving more of the people that are giving those certifications to make money, more so than it is actually preparing people to succeed. But I wanted to look at this from a different angle because maybe it would allow us to have a different viewpoint on it. Can you tell us about a course that you took and how that helped you apply some skills that you wouldn't have had otherwise?

Dave: 12:48

So after the CAPM the next certificate I sort of stumbled into was the PSM-1, which was great for me to open the door to more true agile approaches, especially Scrum. That was really helpful. But straight away I could see with me working in those sort of traditional projects and very project management, program management focused. There was no way I was going to be able to generate the buy-in to get the senior leaders and senior project professionals to totally change their approach and move in a Scrum direction. So after Scrum I'd sort of heard of Kanban and naively I thought, well, I've done a project management certification, I've done a scrum one, let's do Kanban and just continue diversifying. And that was probably the wrong way to think.

Dave: 13:28

I was very naive at the time.

Dave: 13:29

But it was a very lucky break for me because Kanban I found especially the PSK version of Kanban was far more pragmatic and far more forgiving of your existing processes and your existing practices, routines, concepts, whatever however you want to frame that. And having that sort of Kanban focus and that Kanban knowledge, I was more easily able to apply parts of that that were going to be useful and take I know this has become a dirty word in Agile and Scrum circles, but take a little bit more of a pragmatic view. Understand, I'm not going to be able to boil the ocean in this project, but maybe we can start nudging this in the right direction. And this is another one of my sort of themes on agile approaches within your projects and product teams. It's not a case of flipping a switch and saying, right, we are agile as of now. It's more of a temperature dial or a thermostat. You sort of gradually move things along and nudge it in the right direction, building credibility as you go, so you can make those bigger changes as the time comes.

Mark: 14:27

So you took this professional Scrum for Kanban course through Scrumorg and you mentioned that. You just kind of naively jumped into it thinking that you were going to get some knowledge and it was going to just kind of spring forth and the well was going to fill up by itself. And you quickly found that that wasn't the case. So how did that course specifically, how did you use what you learned from that course to really make a difference and see Scrum with Kanban come to life in your team, dave?

Dave: 14:52

So I suppose the first thing that was really helpful was a look at some flow metrics and that was a really sort of easy install that we could make. We weren't working in sprints at the time but we were sort of free to set an iteration that we wanted to trap those flow metrics against and use that as a bit of a mirror for our performance. Kanban boards at the time were a bit of a bit of a brainwave and again we didn't work in formal sprints but just being able to visualize the work and show our working out in terms of what we were progressing was really helpful as well. A lot of those practices and tools really helpful. Getting stakeholder buy-in we weren't now asked every day for an update on what we'd done that day. It was very visible. The credibility within the team was going up. There was a lot more forecasting and signposting when we were either trucking along well or things were hitting a slowdown if there were any blockers or impediments. Those were a lot more available to senior stakeholders. It wasn't the surprise at the end where we need another two weeks every two weeks. So that got us a lot of wins and equally it sort of opened the door to me to that sort of structured learning that these certification pathways provide.

Dave: 15:59

As I say, I'd bounced around a few. Initially. That I was quite lucky. But after I'd got a bit of a practical focus on one with the Kanban one, that gave me a bit of an avenue to start looking at what else was available and what else I could steal and bring into my current projects and current purview and that allowed me to take advantage of a structure like what PMI provide, like what Scrumorg provides, scrum Alliance. You've then got a bit of a pathway that you can look at and you can plot out for yourself, based on what's available here. What are the things that are going to be helpful for me to continue improve and continue development and ultimately, as you've touched on, not improving and developing for a theoretical purpose, but improving and developing in the hope that I can bring something back to my day-to-day role that will make things better for the team, the product, the organization, whatever level, as opposed to you went to school to learn, and you didn't necessarily apply what you had learned.

Mark: 16:58

It was just more about getting all the learnings that you can under your belt. I think that's a good distinction to make, and something that I would pass on to our listeners is think about before you choose the ones that you want to take. Think about where you want to apply them and why you would want to apply them, where they would be most strategic and helpful for you to learn some new techniques that would add value for you and for your team. And then, when you go into that class, have a plan. Have a plan for okay, this is the situation where I want to be able to apply this and, dave, if you have that sort of an outlook, I want to be able to apply this. And, dave, if you have that sort of an outlook, I think that the class really comes alive to you and brings much more tangibility to the whole thing, as opposed to just trying to sit there like a sponge and just absorb anything. What are your thoughts?

Dave: 17:49

Well, I totally agree. And your metaphor at the end I was about to say you move yourself from sitting there and letting the class and the material wash over you to really trying to integrate that within your current understanding of what good delivery and what good agile looks like, which is a really big and important step forward that you need to take on this learning journey. It's really interesting. I wrote recently about this on LinkedIn in a comment and it comes back to me now. It reminds me of martial arts schools and martial arts students where they get a little bit confused and they focus on the next rank or the next belt as the thing. But that is sort of a byproduct or a proxy for your skills and ability, that your skills and ability of the thing. These markers are helpful milestones along the road, but they aren't the important bit. The important bit is what you can apply in a practical way.

Mark: 18:38

Well, it's really interesting to see how you've used your certifications in order to bring value. Looking on LinkedIn, I see you've got cloud and CICD certifications. How have those been helpful to you?

Dave: 18:51

Yeah, so cloud was a bit of a stroke of luck for me the cloud community for L&D and development and study. It's amazing and I think there's a ton that the agile community can learn from the cloud community in terms of the offerings and the pathways. Develop myself for nothing and pick up some credentials as I go. That's great, great result. And I was in sort of a similar position to what you've described there. I used to well early in my career. It was sort of easier for me to straddle the business and the technical side of the role because I'd just come out of that technical focus and I was developing my business skills. Also, I was very I was a lot more junior than I am now, which made a lot of people far more forgiven on the business side because of what I'd bring on the technical side. The reason I made a big push to get back into cloud and a more meaningful way, was I felt that my technical skills were starting to atrophy quite a bit and I could feel sort of discussion starting to get away from me again and the technological landscape had moved enough for me to think I'm probably behind the curve now. I could do with a bit of polish here and cloud's been great for that, because it doesn't, especially at the foundational level, it doesn't focus exclusively on the products themselves.

Dave: 20:09

As you grow in the path and move up to associate professional speciality certifications, there's naturally that curve to the stuff you learn and becomes less applicable across the board.

Dave: 20:18

What I really like about the foundational and associate levels, though, is it's a lot more conceptual and a lot more applicable, regardless of the tools. That was always something I was sort of wary of and alive to, especially early in my career. I didn't want to become an expert or an SME in a tool that maybe isn't going to be here in three years, so if you are planning to make a technical step forward, that would be one thing I would warn you against. Although there might be something brand new and shiny that's come out that looks great, there will be another thing in six months and another thing six months after that and another thing six months out of that. So I really encourage people to learn the things that are going to see you through for a longer period and get as close to the conceptually important stuff as you can, and that will be a really, really big step forward for you, and you'll also find it much more easy to specialize once you've got a foundation in place.

Mark: 21:07

So which certification specifically, if you don't mind me asking, did you find useful regarding cloud?

Dave: 21:13

So there are quite a few. So at the minute I'm probably more AWS focused than any other cloud provider. I think AWS Certified Cloud Practitioner was a really good one, because that gave you a really good breadth of the AWS landscape. It polished you up on things like networking, like storage, like memory. It was very similar to sort of the CompTIA Plus in terms of giving you a really well-rounded look at what goes on within an IT and a cloud organization, which was helpful.

Dave: 21:42

But all of the cloud providers do this and I actually went through all of the foundational ones across the main cloud providers, so AWS, microsoft, azure, gcp and even Oracle's cloud offering. I went and did all of their foundational level certifications primarily because they were cheap and most were free, which was great. But once you've got the foundational knowledge in one, it's good to go to another provider and see what they've got, because they will give you a slightly different slant. You've always got to bear in mind AWS is there to serve AWS, microsoft's there to serve Microsoft. So if you can broaden out that experience slightly in a lot of ways you're going overall ground, but you will get new nuggets from each piece that again, you can start integrating into your own skill set and integrating your own knowledge base.

Mark: 22:30

Let's talk about communication, as we're starting to come to a close here. As a delivery manager, I know you have to communicate up to the senior levels of the organization, whether it be to managers, could be to stakeholders, could be even up to senior exec levels. How have certifications helped you with that communication layer?

Dave: 22:52

Yeah, there's a couple of avenues to explore on this, but you're right. As you become more and more senior in your delivery manager or scrum master, project manager career, you're seen as that conduit between the team doing the work and the senior people who are leading the organization. One really good thing has been well, by developing that technical edge, you're able to probe your team within your events like stand-ups, like retrospectives, and ask the questions that you've got a bit of a feeling or that you know that the execs are going to ask you. So that's good for getting out ahead of executive and management concerns. But equally, by building up that knowledge base with the certifications, you're then able to do that translation ahead of time.

Dave: 23:35

You don't need to go in front of an exec and say I don't know, I'll come back to you or I need to bring XYZ person along. You can probe, get ahead of any concerns, questions, queries and because you've built up that knowledge base yourself, you're able to gain a lot more credibility. Also save your team members a lot of time going to meetings that they don't want to go to and ultimately instill a little bit more confidence in the management and leadership that A the projects go in the way they want it to go, or B if it's not. You know what to ask for from that stakeholder to get it back on the right track, or you know how to convey the concern in a way that they'll be able to digest. That's accurate to the situation that the team are trying to convey.

Mark: 24:17

All right, dave. Well, this has all been fascinating and I appreciate your time and joining us here on the Agile Within. I have a feeling our listeners will want to reach out to you with questions, so what's the best way for them to do that?

Dave: 24:32

The best way is via LinkedIn. On there is Dave Westgarth quite active. I tend to post a lot and I'm sure getting a lot of people's nerves are some of my opinions, but it's all in good fun, I promise you. But yeah, any questions, any queries, please reach out. I love getting involved more and more in the community, so please reach out with any questions or comments.

Mark: 24:51

Great. We'll put your link to your profile in the show notes and so people can get in touch with you. That's great, all right. Well, dave, thank you so much for being our guest here on the podcast. It's been a pleasure. My friend, to our listeners, until next time. We'll see you later. Thanks for joining us for another episode of the Agile Within. If you haven't already, please join our LinkedIn page to stay in touch. Just search for the Agile Within and please spread the word with your friends and colleagues Until next time. This has been your host, mark Metz.