0.25 Ways of Working
0.25 Business Acumen
Our Guest This Episode: Peter Saddington
Andy Crowe and Bill Yates give their expert opinion on Agile and Waterfall and even answer the tough question -- which one is better? Peter Saddington joins to discuss his experience with consulting organizations who are implementing Agile.
Peter Saddington is an Organizational Scientist and Certified Scrum Trainer (CST) who has been in software development for 16+ years. He has three Masters degrees (Counseling, Education, Religion) and is a published author of the book The Agile Pocket Guide (Wiley, 2012). He is the co-founder of a research and analytics company, Action & Influence, which was named Best Training Company in Atlanta in 2013. In 2014, Action & Influence was acquired by Agile For All, LLC.
Favorite Quotes from Our Talk:
"Agile doesn’t do a lot of upfront planning. They get together. They have a scrum. They do some. They have something called an “iteration,” or a “sprint.” And then next thing you know they’ve got some releasable product at the end of that period of time. And so it’s very different. Whereas in Waterfall, you do all this planning upfront. You come up with a master plan, typically. You break it down. You really decompose the work. You know, the last time we talked about work breakdown structures. Very traditional, very Waterfall. Agile, scrum, things like that are not that way."
"We need a lot of not only open hearts from everyone that’s involved at scale, but we really need to look at opportunities to change the way the organization is not only, number one, organized; but, number two, structured."
"We start with why. Why is it important to think differently? Why is it important to address our customers’ needs differently? Why is it important to embrace change differently? Why is it important to think differently, as Steve Jobs would say; right? And this is where we start. If we can help people understand the value of why it’s important, then we can worry later about the praxis or the practical how we apply change."
ANDY CROWE ● BILL YATES ● NICK WALKER ● PETER SADDINGTON
NICK WALKER: Welcome to Manage This, the podcast by project managers for project managers. Every couple of weeks we get a chance to meet with you and have a conversation about what matters to you as a professional project manager. We’ll cover topics such as project management certification, doing the job of project management, and we’ll pick the brains of some of the leaders in the industry and also hear your stories.
I’m your host, Nick Walker. And beside me are our resident experts, Andy Crowe and Bill Yates. They’re the guys who’ve been there, done that, and not only lived to tell about it, but are anxious to pass on their knowledge to you. All right. Here we are again, guys.
ANDY CROWE: How are you, Nick?
NICK WALKER: Great. Doing well. I know you’re a little under the weather.
ANDY CROWE: I am. I picked up a little bit of a winter cold here. And so no fun, right before a big milestone birthday and going out West for a ski trip. So not as much fun looking forward to that.
BILL YATES: What birthday is that, Mr. Crowe?
ANDY CROWE: It’s a big milestone.
BILL YATES: Does it have a zero, a zero in it?
ANDY CROWE: It does have a zero in it, and we’ll leave our listeners to do the detective work here.
BILL YATES: Hey, no matter how much I mock you – this is Bill. No matter how much I mock you, you’re still younger than me. At all times.
ANDY CROWE: That’s true. That’s true. Just, yeah, a little bit younger.
NICK WALKER: And I think both of you are younger than me by a good bit. So we’ll just pause it right there. Okay. Well, let’s talk a little bit because I’m going to have to admit my ignorance here today; all right? I have to admit that, when you talk, you talk as if you’ve invented your own language sometimes. I hear you talking about scrum, burn-up charts, kanban boards, iterations, grooming, product backlogs. This is Agile talk, I understand. It seems that Agile, though, has its own vocabulary. Okay, it may be Greek to me. But may I assume that these are terms that a traditional project manager might understand?
ANDY CROWE: I think, Nick, that you could manage projects your whole career and not know these terms, not encounter a lot of these terms. And some of it depends on where you manage, the organizational culture. But Agile does have its own vocabulary, and it is its own set of practices. They’re really a lot different than traditional project management.
BILL YATES: That’s true. And what we’re seeing more and more are organizations that are bleeding Waterfall and Agile. They’ll have teams that are using a Waterfall approach, a methodology to managing those projects, and then other teams that are using Agile approaches. Sometimes there’s a bit of conflict between the teams. Maybe team members want to be on one methodology and not the other. So I think more and more people are, even if they come from a pure Waterfall or traditional project management side, they’re going to hear more of these terms and probably be pulled in and find value in some of these approaches.
ANDY CROWE: And you know, Bill, we might as well explain. Somebody out there may not even know, they may be doing Waterfall project management and not even know why it’s called Waterfall project management.
NICK WALKER: And thank you for voicing my very question. Okay. Just a quick explanation of Waterfall.
ANDY CROWE: Sure. So Waterfall, also called SDLC, Waterfall is called that because the activities literally cascade. You plan. That cascades into execution. That falls down into monitor and control. And then sometimes it’ll loop back up, and you’ll go through that, several iterations in that. But Agile, one of the terms you threw out at the beginning was “scrum.” And that term is taken from rugby. So a scrum is where a bunch of people get together and basically make something happen. And that’s much more indicative of what Agile is.
Agile doesn’t do a lot of upfront planning. They get together. They have a scrum. They do some. They have something called an “iteration,” or a “sprint.” And then next thing you know they’ve got some releasable product at the end of that period of time. And so it’s very different. Whereas in Waterfall, you do all this planning upfront. You come up with a master plan, typically. You break it down. You really decompose the work. You know, the last time we talked about work breakdown structures. Very traditional, very Waterfall. Agile, scrum, things like that are not that way.
BILL YATES: And one of the fun things for us is seeing when those two camps start to – when the waters come together. There’s a bit of a boiling point there. There’s a bit of, hey, well, it should be this way; and the Agile camp saying, no, no, no, it should be this way. And one of the things that – one of the misnomers I think people have to overcome pretty quickly from the Waterfall camp is that, well, if you’re an Agile practitioner, you don’t do any planning. You don’t do any planning at all. And Andy, you know, you mentioned the iterations. At the beginning of that iteration there’s going to be a planning time built into it.
ANDY CROWE: Yeah, iteration zero a lot of times is to come up with sort of a high-level master plan, ground rules, things like that.
BILL YATES: Right.
NICK WALKER: So we’re talking not just a difference in words, you know, word substitution. We’re talking about actual different processes, different ways of thinking?
ANDY CROWE: Mm, yeah. So Nick, this is Andy. And when I started programming years ago, started my career as a software developer. And somebody took me aside one time, and I was learning – I was learning machine language, which is a fairly demanding practice as a programmer. But one of the guys took me aside and said, “Once you learn this, and learn it well, everything from this point on is just going to be different vocabulary. All the practices are the same. You really understand how it works.”
That was true for a long time. And then some guys invented object-oriented programming, and I started learning a language called C++. And if you really get C++, it is its own religion. It’s its own – I know the term’s overused, but it’s a paradigm shift. And you have to really think about things differently. That’s the way Agile is. Agile isn’t just substituting, okay, we call it a WBS over here, and we’re going to call it a breakdown chart over here. You know, it’s not just substituting words. It really is a different practice.
And so sort of you can think of it as Waterfall is more top down. It’s driven from the top down, from senior management, through the sponsor, through the project manager, to the team. And Agile is more bottom up, where the customer gets embedded in the team, and they make decisions, and the team is empowered. And there’s not somebody, you know, we joke about the smartest guy in the room. The smartest guy in the room is not over here telling us how to do things and what to do next.
NICK WALKER: So we’re not just talking about translating from English to Spanish. We’re talking about translating from English to Klingon.
ANDY CROWE: Exactamente.
BILL YATES: Yeah, Nick, that’s a – this is Bill. One of the things that jumps out to me as a key differentiator is I think about someone who’s been in the role of project manager for a number of years and is following a traditional Waterfall approach. And now they learn about Agile, and they start to embrace and practice Agile. That’s tough. That’s a big transformation.
Now, you know, fortunately for most people they go, this is awesome. This is truly transformational. I love this. I see value in this. But to Andy’s point, if you have a top-down mentality in terms of managing a team, and you’re going to drive out the planning and then assign out the tasks and the workflow, the resources, now I’m suddenly part of the team. It’s probably a smaller team than I’m accustomed to. And we’re self-organized. I mean, Andy, what do you do with that? I’m self-organized as an Agile practitioner.
ANDY CROWE: Right. So it’s self-organized, which means that there’s not one person driving how the team is going to interact. The team sets their own ground rules. And then they’re also empowered. And that’s as big a deal to me, Bill, than just self-organized. Now the team’s empowered, they live and die by their decisions. So a lot of times you have the customer as part of that team. But the team moves as a unit. And if you and I are on an Agile team together, we’re accountable for each other’s work. We’re collectively accountable. It’s crazy.
BILL YATES: Yeah. It is. It is.
NICK WALKER: So is there a point where we can say, okay, this is better? One is better than the other? Or are they equally as proficient? Or do you have a preference? What’s best?
ANDY CROWE: Yeah. And so let’s talk about religion, too, Nick, and talk about which religion is best. So it…
BILL YATES: Are you a Democrat or a Republican?
ANDY CROWE: Right, which one of those is best? Which political party? That’s a tough question. They each have their strengths. And so let me give you an example. If you have – let’s say you’re working on a government procurement project, and you receive in the mail a bid package. A lot of work has been done. It’s been broken out. They know what they want, they know how they want it, and they know when they want it and to what quality spec. Traditional would be a great fit. Waterfall would be a great fit for that because a lot of it’s known. You’re dealing with knowns.
Let’s suppose, on the other hand, that senior management comes up with this vague idea of a software project that they want. They want a new general ledger, but they’re not really sure what they want in it. This is a beautiful time for an Agile team to get together, put something up there that senior management can start working with. Maybe within 28 days, you know, they get something and then collect feedback and rapidly loop that back in. Each of those has their own strengths, and those are two extreme examples. But each of those has their own advantages.
BILL YATES: Right. I like that. Andy, you make me think of a product backlog, too, and how, when I started looking into Agile, that was one of the first things I gravitated to. I loved the idea of a product backlog. We take requirements, and we list them out. And then we put them in front of the product owner, and we say, “Hey, could you tell me what your priority is? Rank these.” So then we’re engaged. The team is literally in the room with the sponsor, with the ultimate owner of that product. And we’re just listening. You know? What’s most important to you? If you have to prioritize or rank this list of requirements, put them in order for us.
ANDY CROWE: And to me, Nick, that’s the real advantage. Like if there’s just – if you had to narrow it down, what’s Agile’s biggest advantage, it would either be that they can react quickly to chaos and change, like they thrive on chaos and change, they really like that; or, B, that they are so value focused, and so constantly the most valuable thing bubbles up to the top of the list in Agile, and the team can work on it and get it out there quickly.
NICK WALKER: But Andy, are there situations where you might say Agile just will not work in this instance?
ANDY CROWE: Yeah. Okay, maybe. So let me – and this is actually a controversial point in the Agile community. So some Agile practitioners say, look, Agile’s not for every project. Some feel like that is blasphemy. So I’m going to give you my own opinion on it. There’s a couple of ideas where I would say it’s a lot more challenging, a couple of concepts where it’s more challenging for Agile to work and to thrive. One of those examples would be a really, really large team.
Now, there’s a principle within Agile that you should have a team that you can feed with a couple of pizzas. If it’s bigger than that, Agile starts – a friction gets introduced; right? Because this is a democratic process, and the team members are empowered, and they’re making their own decisions. I think, so you get a team of 40 people, 50 people, it can get chaotic with an Agile context. That doesn’t mean it can’t work because there are guys out there who are putting this into practice and making it work. I think it’s more challenging.
I think another example would be, you know, if you’re going to build, okay, if you’re going to build – let’s go back to my general ledger. You’re going to build a general ledger for a company, and you start working on that. Well, there’s not a lot of material cost. The costs are in the people.
BILL YATES: Yeah. You’re not buying concrete. You’re not buying cranes or renting equipment. You don’t have a lot of upfront capital that you have to expend.
ANDY CROWE: Right. But we’re located in Atlanta. They’re building the Braves stadium right down the road from us right now. And that might not work so well from an Agile perspective if you were in the construction phase. The design phase, maybe. And that would be an Agile practitioner’s response is you do an Agile process for design, then you actually manage it more traditionally for the construction.
BILL YATES: Right. Yeah, it’s a great example. So there you’ve got a multi-multi-million-dollar project, a whole lot of assets in play, a lot of capital expenditure. So once you get into that construction phase or those aspects, that implementation, you need to have some pretty solid plans. There’s not a lot of iteration going on, iterating going on then. But absolutely on the front end, the design, yeah, you can see that. So how’s that for an answer, Nick? It depends.
NICK WALKER: Yeah, very often it does depend. Depends on who you’re talking to. So let’s talk to somebody else about this, too, bringing in another voice to this conversation. Peter Saddington is a well-known Agile coach. He deals with teams and leaders and organizations who are implementing Agile, sometimes for the very first time. We’re honored that he took time out of his day. Peter, welcome to Manage This. Why don’t you start by just giving us a little bit of your background in Agile?
PETER SADDINGTON: Sounds good. It’s great to be part of the program. I appreciate you guys. My journey started back in ‘97, when I started as a developer with a large Fortune 50 company. And so I actually cut my teeth on the beginnings of Agile before it even really was. I entertained my first Agile project when I was a scientist at the Centers for Disease Control and Prevention in 2004, and ever since then have been a big proponent, consultant, and coach and trainer of it as it had a lot of powerful benefits to the project work that I was doing as a scientist. And so for me intellectually it made a lot of sense, and pragmatically it actually worked. So ever since 2004 I’ve been doing Agile more properly, I suppose. And so currently I’m an Agile coach and trainer with a company based out of Boulder, Colorado called Agile for All.
BILL YATES: Excellent. Peter, this is Bill Yates. It’s great to reconnect, my friend.
PETER SADDINGTON: Absolutely.
BILL YATES: Thanks for joining us, too. You know, one of the aspects that I think you can really speak to is the transformation that you’re seeing taking place in organizations that are adapting or adopting Agile, perhaps for the first time. And as you look at that, what are some of the cultural barriers that you see, or the obstacles? And then what are some, kind of some lessons learned that you’re finding in your consulting engagements?
PETER SADDINGTON: It’s a great question, Bill. What we’ve found as Agile has grown up, since the manifesto was established in 2001, we’ve seen a lot of trainers and consultants and coaches look at more the tactical level of teams, anything below the middle tier or the middle management level. I think that that area’s been well addressed, and certainly it’s been well covered. And I think really the next level of agility for organizations is at scale.
And so to your question around the challenges, I’ll point out five that come off the top of my head. It’s interesting, I just finished an executive course with a group just last week. And these are the top five that came up. The first was no change in the organizational infrastructure; right? And so we need a lot of not only open hearts from everyone that’s involved at scale, but we really need to look at opportunities to change the way the organization is not only, number one, organized; but, number two, structured.
Number two, there’s often a lot of challenges with a view to the value stream. How is the value created? All the way from the executives and leadership, even to the board, all the way down to the tactical players and engineers who are actually building the work.
Number three, the failure to decentralize control. I think we’re moving to a more cultural arena within the corporate world, where control is no longer a viable option. You know, no one likes being controlled. And so therefore we need to give engineers a lot more autonomy, I like to say freedom within a framework to work.
Number four, a lack of a transformational product donor is a big issue. And so our product manager, someone who has a vision of the product, knows, has done copious amounts of surveying of their target and market demographic, and understanding really what the users want. The last thing we’d want to do is spend lots of time and effort building something that our users don’t like, or that our users don’t use.
And last, but not least, which is really the most important, a failure to transform leadership behaviors. It is no longer viable in the market to, for me specifically, to work with the executives and have them say, “Peter, we want everyone trained. We want everyone to do things differently. And by the way, we don’t need to change.” I think that is a serious lacking at the leadership level. They need to change, too. Times are changing. We’re working in a faster paced environment and market than ever before. And I think it’s absolutely imperative that not only the leaders change, but part of that is part of the heart change, what I consider the heart change, as well.
BILL YATES: I got you.
PETER SADDINGTON: The imminence of change is happening, and so we must embrace it, utilize it to our advantage. And so those are the top five major opportunities for failure at scale that I’ve witnessed easily within the last couple of years or so doing consulting work.
BILL YATES: Yeah. Peter, those are really interesting, and I see a common theme there of transformation. You need leaders to embrace it. You’ve got to decentralize control. Those are, I mean, you think about well-established large organizations. That’s difficult. Those are serious obstacles.
PETER SADDINGTON: Absolutely.
BILL YATES: So how do you, you know, as a coach and a trainer, how do you, from the top down or from the grassroots level up, what’s some advice that you see or what are some aspects that you’ve seen on teams where they’ve embraced this the right way or gone about it the right way?
PETER SADDINGTON: Well, we approach enterprise transformation and agility at scale from a philosophical kind of vantage point. And it’s not to sound too heavy or too hoity-toity of sorts. But the philosophical really should be a priori the praxis. And what I mean by that is often when we work with middle management to – even moving up to the upper echelons of leadership, we find that everyone wants to add – everyone wants to know what to do.
Well, for me as a consultant, I’ll be honest, I don’t really know what to do because I have no full understanding of the cultural landscape or the cultural nuances of that unique culture and company. And so the first thing we need to understand and establish with everyone is the why. And there’s a great book, it’s called “Start With Why” by Simon Sinek. It’s a great book, if you guys would love to read that. But at the end of the day we have to have a good reason and a value proposition of why it’s important to change. I work with many different clients. And as you could probably imagine, every client change is different because the cultural context is different. What is not different from any of these companies is a value proposition as to why it’s important to change.
And so we start there. We start with why. Why is it important to think differently? Why is it important to address our customers’ needs differently? Why is it important to embrace change differently? Why is it important to think differently, as Steve Jobs would say; right? And this is where we start. If we can help people understand the value of why it’s important, then we can worry later about the praxis or the practical how we apply change.
And so that’s where we really start is changing the heart and the mind and opening up the heart and the mind to the opportunity that change is imminent and that within their current demographic and context it’s important to change. And when we get there, then the wheels have been greased, and it makes our job a lot easier as consultants to start building the machinery.
BILL YATES: So, Peter, you’ve hit on one of the key tenets that I see when I look at projects or programs that bring about change. And that is, for those to be successful, research shows that you’ve got top-level support. You have that product owner, or you have that sponsor, or you have that C-suite individual that is pretty loud and proud about the effort, the initiative?
PETER SADDINGTON: For sure.
BILL YATES: It really sells it. They have to own it. So that I can agree with some of those obstacles that you pointed out that, when those are lacking, then there’s not going to be transformational leadership at the end. Those changes won’t stick. So how do you, as that outsider, when you go in and you’re talking with this C-suite individual, and you’re trying to convince her or him that, hey, you’ve got to be engaged, and you’ve got to sell this along with me, it’s not…
PETER SADDINGTON: Oh, absolutely, yeah.
BILL YATES: It’s not up to me. How do you sell that? How do you pitch that to those who are going to embrace this change?
PETER SADDINGTON: Well, you know, there’s a powerful saying, it goes like this, it says, you know, “I don’t care what you know until I know that you care.”
BILL YATES: Right.
PETER SADDINGTON: And my first job when I get onsite with any client is to not only show them and unveil to them the opportunities that exist; but, number two, just to help them understand that I actually care about this change with them. And so I always like to, you know, I coach a lot of other coaches and consultants and help them up their game. And I always tell them that it doesn’t matter how much you know. Your empathy, your ability to connect with people dealing with their issues, their own personal, even personality issues of sorts and the way that they manage and work is so important. It’s even, I would say, it’s even far more important than what we do.
And so building a relational or what I call “relational bridges” or “relational equity” of sorts with people is my primary concern when I get on the ground. And as we grow in relationship, and they can see that I’m not only merely a consultant, telling them, hey, there’s opportunities here, but I’m also being a partner with them in helping them change.
One thing that I always communicate to the leaders of any kind of company is my job is to help mentor and guide them in changing the faith of their organization. And I think that’s not only a poignant idea, but it’s actually very real. We operate from various different world views. And the way that the leadership views the world has intrinsic and powerful ramifications of how they manage the workforce. And so from the top down, if we can change the faith of the organization, then everything else follows.
If you track with me for just a quick second, if you convert from, let’s say atheist, to let’s say a Christian, your world view has changed, your faith has changed, and everything stems from that – the way you dress, the way you talk, the way you communicate, the way you deal with dissonance, the way you deal with conflict, the way you deal with people. It all changed just based on that faith alone. And in the secular world view they’d say it’s the – it’s just your world view. Well, faith world view doesn’t matter. A lot of the opportunity that we have is to change the world view and to change the faith of organizations so they can see the opportunity that exists, maybe in front of their face, and they didn’t even know it was there. And so being a partner in that is absolutely essential for helping them see the opportunities that exist and the rewards of doing things differently down the road.
NICK WALKER: Well, Peter, we care what you know, and we are so delighted that you care. Thank you so much for being with us. You’re going to need to watch your mailbox here for the next few days because we have a very special gift for you. It’s a Manage This coffee mug. And I’m looking…
PETER SADDINGTON: All right.
NICK WALKER: I’m looking at one right in front of me right now. It is beautiful. It is big. And so…
PETER SADDINGTON: Oh, yes.
NICK WALKER: I think you’ll enjoy that. It’s just a token of our appreciation for being with us. Thanks so much.
PETER SADDINGTON: Absolutely. Thank you guys. I appreciate it.
BILL YATES: Thanks, Peter.
NICK WALKER: There’s actually a certification for Agile, the PMI-ACP. One of you is going to have to tell me what that acronym stands for. It seems to be gaining some traction, though. So, you know, Bill, tell me. You, I know, you have this credential. Andy, you have this credential, as well.
ANDY CROWE: I do.
NICK WALKER: All right. Why is this certification important? But Bill, first of all, tell me what it stands for.
BILL YATES: Right, so PMI stands for Project Management Institute. You probably already got that one down.
NICK WALKER: Okay.
BILL YATES: And then ACP, Agile Certified Practitioner.
NICK WALKER: There we go. Okay.
BILL YATES: Yeah. So PMI-ACP. PMI introduced this certification a few years back. Andy and I both have it. Some others here in the office have it, as well. And it solidifies some of the thought that’s out there regarding Agile and Agile practices. And it’s a way for practitioners to show that, okay, I have the experience level to be able to apply for and go after this certification, and I have a foundation of, not just experience, but knowledge related to Agile practices. Therefore I can sit for this exam. And to that end, we’ve created some exam preparation content. Andy started out with a book. Andy, there was a recent update to the book. Why was that?
ANDY CROWE: Right. So the book is “The PMI-ACP Exam: How to Pass on Your First Try.” And as PMI does, they updated the exam spec. They do that from time to time. And when that changed, we always want to make sure that we are in lockstep with them. And so this was really going through with a fine-tooth comb, making sure we’re still majoring on the majors, minoring on the minors, and having all the terms and definitions in the glossary, and practice exams, that type of thing, done. So it was a meaningful update. And now we’re in what we’re calling “Iteration 2,” which is the second edition of that book.
BILL YATES: Nice. I smiled when I saw the book and saw that stamped on the front of it. I was like, very clever. Well done, sir. One of the things I’ll point out, too, Andy, one of the differences that we see with the PMI-ACP versus some others, this is a certification offered by PMI. But there’s not a BOK; right? There’s not a Project Management Body of Knowledge. There’s not a PMBOK guide for the PMI-ACP as there is for the PMP. There’s also, for program managers, there’s a standard. But for PMI-ACP there’s not. So I guess I’ve got to buy your book.
ANDY CROWE: I guess you do, Bill. And I wouldn’t be surprised to see an Agile BOK, an Agile Body of Knowledge, get published at some point. It’s tricky. Agile’s still in a very formative stage. There’s so much activity and so much evolution going on within the Agile practices. So you’ve got Scrum and Lean and so many of the ones represented on the exam that it’s hard to even know how to cull that body down. Now, they’ve done it for the test. And I wouldn’t be surprised to see a Body of Knowledge come out. I think there’s just a little bit of work that has to be done there first.
BILL YATES: I agree. One of the things that’s interesting, too, when you go to PMI, and you ask or look on their website, what should I read, what’s going to be on the exam, how do I prepare for it, there are, I don’t know, 10 or a dozen or more books that are listed. And recently we had a colleague go through the exam. They used your book as their primary means of preparation, and they passed. And one of the things I think that really points out is, and I’m not just trying to pat you on the back, even though you do have a cold…
ANDY CROWE: Yeah, I’ll take it.
BILL YATES: One of the beauties of the book is it takes all these different ideas and concepts from the Agile practice and brings them together, so then you’ve got more resource.
ANDY CROWE: Some of those, yeah, some of those, Bill, will conflict, too.
BILL YATES: Sure.
ANDY CROWE: You know, occasionally there’s different philosophies of how long an iteration should last, and the vocabulary around what you call an “iteration.” And so we try and synthesize that and make some sense out of it.
BILL YATES: Yeah, yeah.
NICK WALKER: Andy, let me ask you this. A project manager listening, wondering at what point do I need this certification, what would be a clue?
ANDY CROWE: Yeah, it’s – you know what? It’s a good source of authority. PMI, the Project Management Institute, largest group of project managers in the world. And their certifications and credentials tend to mean something. So this is helpful if you’re – let’s say that you are either an Agile coach, you’re coaching a team. Let’s say that you’re working on an Agile project, and you really want to differentiate yourself. You want to set yourself apart from your coworkers. It’s a great way. I think past that, “needing” it’s a funny word. I don’t know how many of these certifications or degrees we need to do the jobs we do all the time. But it’s something – so I’m a certification junkie. And that’s a crazy question for me. That’s almost nonsensical.
NICK WALKER: So how many acronyms do you have behind your name?
ANDY CROWE: I have a bunch behind my name right now. I’ve got a few, and that list may not be done yet.
NICK WALKER: Well, we always talk about, you know, the importance of new ideas and perspectives, gaining new knowledge. So what about reading? What are you reading these days, Andy?
ANDY CROWE: Oh, that’s funny. You know what, I’m doing less reading right now, and I’m doing more writing these days. I’ve got an update to my PMP book coming out. And I’ve been taking some time every day and outlining a concept for a new book that I’ll be ready to talk about soon. And we’ll let our podcast listeners know before anybody else about that.
But I’m reading a book by Bill Bryson, and Bill Bryson’s one of my favorite authors in the world, and it’s called “The Road to Little Dribbling.” And he is just an amazing author. He’s written a lot of nonfiction. I guess it’s mostly nonfiction. If you read his books, you have to kind of draw the line. But I’ve really been enjoying that. And he’s one of two or three authors in the world that makes me laugh out loud. And so I’ll be sitting in a restaurant and just guffawing as I’m reading his stuff, and people start looking at me. It has the usual effect on me.
NICK WALKER: You start to do a little bit of dribbling yourself.
ANDY CROWE: Yeah, exactly.
NICK WALKER: All right. Well, Andy Crowe, Bill Yates, thanks so much for sharing your expertise with us once again. And a special thanks to Peter Saddington for adding his insight, as well.
That’s it for us here on Manage This. We hope you’ll tune back in on March 1st for our next podcast, when we’ll be joined by a colleague. Mike is a senior program manager overseeing projects for the CDC, dealing with topics such as SharePoint upgrade and big data.
You can visit us at Velociteach.com. Click on Manage This Podcast. And tweet us at @manage_this – that’s @manage_this – if you have any questions about project management certification, whether it’s the PMP, the CAPM, PMI-ACP, CSM, PgMP, or PfMP. Or maybe you’d like to be a guest on the show. We’d love to hear your stories.
That’s all for this episode. Thanks for joining us. Until next time, keep calm and Manage This.