Join Murray Robinson and Shane Gibson in a no-nonsense agile discussion. In this podcast Murray and Shane have a robust discussion about whether Projects and Project Managers are compatible with Agile. Can projects be done in a truly agile way or are they inevitably waterfall in practice. Is Project Management an authoritarian role that conflicts with self managing agile teams or can a Project Manager be a servant leader who empowers teams.

Read along you will

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson

Murray: Gibson. And I’m Murray Robinson. 

Shane: Hey, Murray, how are we this week? 

Murray: You good? Good, thanks. And we’re gonna have a controversial topic today. I think, uh, Shane. Well, we’ll see how we 

Shane: go. Right? I know you’re gonna use some of the things that I call swear words like project and project management.

So, um, , let’s get 

Murray: off of that. Yeah. I wanna, I wanna talk about project and project management and I know, I know you do. You are telling me you are having. All sorts of problems. Uh, yeah. With some program managers. So tell me, tell me about a, why don’t you start, Shane, and tell me what in your mind is project and and pro?

What is the problem? What is it? What is a project? What is a project manager and what is the problem with. So, 

Shane: so I think it all comes to semantics, right? Because you know, if I use the word scrum in a sprint, and if I use the word iteration, um, or I use the word project or program, they all come with behaviors.

Right. So we’ve been trained to behave certain ways when, when those words are used. And you know, an example will be, uh, if I use the word project and the fact that we, uh, as a group of us are working together and we have a project manager, There’s an expectation that it’s a smallish team and that we’re focused on, you know, uh, ideally a will defined vision and outcome, and we’re running off to, to deliver that thing.

Um, it also has a perception that there’s a beginning and an end, right? We’re gonna start it. We’re gonna deliver that project, and we’re even gonna disband or we gonna do something. And when I use the word program, there’s an expectation that these multiple projects or work streams, right? Mm-hmm. , there’s multiple, multiple groups of people all with slightly varying visions or outcomes, but those visions and outcomes feed up to a larger program.

Or outcome. And again, the program starts and the program finishes and people dis or go to do other programs or other pieces of work behavior that I don’t agree. Right. Don’t agree with idea. We start something and we and invest in it again. I think, well, especially an it. 

Murray: Why do you think that? So I think we should separate.

Between what people quite often do and what they have to do, right? So, um, let’s say that you have a project to, um, build an application of some sort. That doesn’t mean that, um, once you’ve finished the project that there, there’s no. Updating or maintenance of that application. 

Shane: No, but what happens is the project team handed over to the mythical BAU team, right?

We, we take the thing we’ve built mm-hmm. , we throw it over the fence, we walk away and we let somebody else deal with the fact that may or may not work. It may or may not be. , um, the organization feels like it’s spent the money, and it doesn’t treat it as an asset. It doesn’t depreciate it in a way that it says, well, 30% of that total cost of that project, um, can now be fund will be funded to keep reinvesting in it, right?

With a whole lot of trained behaviors, which I think are less 

Murray: than optimal. It’s often like that, but it doesn’t have to be like that. 

Shane: It doesn’t have to be, but because of the word project and the word program, it typically 

Murray: is. Yeah. Well, to me, project is something that definitely has a beginning and end.

It has a budget and it has a team. So, and it, it has some, some sort of scope or goal. Uh, I agree that what’s happening is that the organization has decided to do something and they’ve moved resources into that initiative, whatever it is to do it. And then once it’s done, then they move them onto other things.

So the there can be, uh, good and bad things about that. I mean, what’s the difference between. Doing a story, moving your resources on to do a story in Epic and then finishing it, moving on to the other one. What’s the difference between that and the project except the project’s bigger? 

Shane: Well, it doesn’t use the word project, right?

It just says there’s a piece of work to be delivered and then deliver it and move on to next piece of work. So yeah. Uh, they should be the same behaviors, right? But when we use the word project, in my experience, the semantics around that word means we show different behavior. Uh, and that, that’s interesting.

It’s interesting how just that one use of that word changes the way people think and behave. 

Murray: Well, projects are, are by their definition, temporary. Right. So I agree with that cuz they, they. Getting a team together to do something for a period of time. And then they, then there’s, you use up the money and they go away and do other things.

So it by def definition it’s temporary. Um, but this, this sort of, I want to dig into the bad behaviors cuz I don’t think that they have to be like this. And I say this from the point of view. If somebody has, uh, many years of project and program management experience, I started doing. Project and program management more than 20 years ago.

And I also started doing Agile, you know, not long afterwards. So I have a lot of experience with both. And my view is that you can do agile project and program management, and I also think projects and programs are not gonna go away. How much, no matter how much, um, you know, people call for it. It’s not gonna happen.

So, 

Shane: so why is that, do you think? Because it’s an embedded term that’s been around for so 

long. 

Murray: It wouldn’t matter what you call it. You can call it initiative Shane. It’s still the same thing. The, the, the idea that. The organization wants to do something and so that they marshal resources to do it, you know, and then they go and do something else.

I think that that is a, just a matter of. Prioritization and it can be quite, um, effective because for example, let’s look at the alternative, right? The alternative case that people always put up is, let’s not have any projects. Let’s just have, um, an ongoing, you know, application development team or an ongoing product team, right?

And it’ll be made up of. Let, let’s talk about, I don’t know, let’s say 50 people and they are going to work on that application continuously. Um, well that could be, that could be quite good, but it can also have some disadvantages. I think people who are working in an operational type of approach can get very focused on the micro issue.

And the way things are being done now, um, and they may not have the flexibility to do anything or capacity to do big things. 

Shane: In, in terms of their skills or in terms of their prioritization that they always get prioritized for, you know, those small fixes, those little changes, those emergency problems, and therefore never get to focus on those bigger chunks of work.

Murray: Well, first of all, there’s a capacity issue because, um, it’s often the case that the operations support team. Just doesn’t have the capacity to do anything big. Right. So they need extra people to come and, and work with them to do something big. The other thing is that there, there is a skills issue. You, you get, you’ve got a, it’s kind of swings and roundabouts.

People who are working on one application all the time get to know it very well, but they, their skillset becomes quite narrow and they can get quite out of touch with what else is going on in the. , 

Shane: but isn’t that just a case of we need to invest in their literacy, we need to invest in their skills on an ongoing basis and make sure they don’t get stale?

Why do we need to create a whole group of people with, uh, a transient focus, um, as a way of solving that particular problem? 

Murray: I think that from a skill point of view, there can be quite a lot of benefit from getting people with, um, Fresh ideas and, um, different ideas to come in and help for a period of time.

Shane: So, so is that the definition of a project then is when people who are outside the organization come in to do a bursting piece of work, uh, and then exit because even the skills or the capacity aren’t there at the. Is, is that the definition of what defines a project? 

Murray: Um, it quite often happens like that, but no, I don’t think that’s a definition of what defines a project.

I, I worked for a, uh, online, a large online jobs, uh, board. In Australia, uh, back in the day, and I was a permanent staff member and all of our, all of our team pretty much were permanent staff and we had about 35 people in it. But, um, we still did projects. Um, we didn’t have budgets because, You know, the budget was fixed cause it was already paying for all the staff.

But, um, people would be moved on from one project to another and it was really a way to address changing business needs. So the business would need, would realize they needed to do something or other, and then a bunch of people would work on it and having a project to work on something. Um, became a good way to organize it and coordinate it.

So I’ll give you an example, Shane. So this jobs company, um, always had a problem with its classification system. and, um, they wanted to go into some new markets like healthcare, education and government. And they didn’t have classifications for those. And also they didn’t have any easy way of, um, creating a new classifications or new markets cause their, their code wasn’t, Structured in a way that, you know, it wasn’t, wasn’t well modularized, if you know what I mean, or parameterized.

To be able to go in and just say, add a new category, like. Government jobs. And, um, so they realized this. So it was technical debt, I suppose, or just they hadn’t, they hadn’t built for it. And, um, they realized that there was a big market and they decided to have a sales and marketing, you know, push into this.

And we, and it then had to, you know, restructure this. Application, this online application to allow these new categories to, um, be added. And, and each category had its then its own kind of pages and it had its own different types of jobs in it. So it was actually kind of complex and it was right at the very heart of the whole.

The whole business, the whole endeavor. It’s like doing a bit of open heart surgery, really. And we got, not everybody, but probably about two thirds of the people in the, in the IT department, you know, Ended up working on this and having it as a project meant that it was really clear what we were trying to do, and we had some clear TA time targets we were trying to meet.

And, um, you know, it, it really focused. Everybody I thought on achieving this thing, this objective you could 

Shane: use, you could use any term, right? So I could say, you know, we’re gonna do a bulb, right? And, uh, a bulb is where we’re gonna create a bunch of product features to improve our classification capability and remove our technical debt.

Um, These people over here are gonna work on Bob. Um, and we know what the outcome of success looks like. Uh, we’re gonna say there’s a number of iterations to deliver Bob based on some, you know, high level estimation, which you’ve talked about. Couple of podcasts to go. Um, we’ve got a target goal date, right, where we kind of want Bob to go live.

And so we’ll trade off some of the features and scope to, to hit that date. Um, and the thing I liked about it was you said there’s no budget because we have a, you know, the budget is, we have this many people working on it for this period of time. So Budgeting’s easy, which is one of the, the approaches I love.

So I don’t need to use the word project, right. I just, I, I Cause there’s nothing that relates to a project in what you described. 

Murray: Yeah. Well it is a project though, because you. You had a scope, I mean, back in those days, you know, the scope was over defined. It was, that project wasn’t, wasn’t a good agile project.

Oh, I would say, cuz I didn’t understand Agile very well at the time and neither did the, the team, we did some XP stuff in there. Um, 

Shane: So, so would you say that, uh, over defining requirements early is a behavior of a project? 

Murray: It doesn’t have to be . No, not at all. There’s a big difference. So if you go and look at, if you go and read the Project Management Guide, the the Guide to the Project Management Body of Knowledge, which is issued by the Project Management Institute.

You will see that they, they define a project as a temporary endeavor to achieve a goal. That’s pretty much all it is, right? And if you go into it, they talk about a whole lot of different ways to do that. And they talk a lot about, um, agile and lean and adaptive planning approaches. So you don’t have to do it within stages with Waterfall.

That’s just one way of doing a project. I agree. It is a common way of doing it. And I think it’s a bad way of doing it, but it’s not the only way to do a project. 

Shane: So, so do we say the only difference between a project and a non-project piece of work is a project has a team who come together, deliver the outcome and to spend, and a non-project, uh, is a group of people that are doing the same kind of work in the same way.

Um, but they’re continuously working on that thing. So they’re, they’re almost like a product team. 

Murray: Yeah, I, yeah, I would agree with that. So something that, yeah, a product team or an application team or whatever is ongoing and they have, um, they might do a whole lot of different initiatives, but they’re not defined by the organization as a project, so they would probably, well, cause they’re not projects though.

They tend to miss a lot of the discipline that you get with project management. So with project management, you’re thinking a lot about trade offs of time versus scope and um, an ongoing team might just kind of like take a very uncertain amount of time to get something. Um, 

Shane: yeah. So we talk about, you know, when I’m coaching teams, I talk about the magic triangle, you know, of, uh, time scope, um, and, uh, How was that one time scope?

And I’ll have to have a look. Um, but the idea that, you know, when we take a product, project led approach, we set the time when it’s gonna be delivered and, and set the scope right, and then we try and play with the effort, right? We try and add more people when we’re not gonna 

Murray: make it. No, I don’t agree that that’s a definition of a project.

No, 

Shane: no, but this is, this is the triangle that you would typically see and what I use. And then when I talk about, uh, iterative or an agile way of working, I say, you know, we, we set the date and then we set the effort level, how many people are involved, and then we play with the scope, leave it, right? We say what’s in and out within that date.

Uh, so I could use that to say one is a project method approach and one is a agile approach. Now you’re not gonna agree with me, but. It’s definitely a pattern I’ve seeing used time and time again, a way of describing the difference between a project and an iterative or agile way of 

Murray: working. . But see, you’ve just defined a project as not an agile or reiterative way of working by making an AB comparison.

And I don’t agree with that. Yeah, but 

Shane: that’s because every time I work in an organization that uses the word project, we see a whole lot of non-agile behaviors. I mean, you’ve just described, um, if you don’t have a project structure, you see teams being ad ho. You see them fluffing around and having no rigor or what, what’s the word you used?

Um, 

Murray: they lack focus often. It doesn’t have to be like that, but, but I have examples. When I was, uh, delivery general manager at a digital agency, I. Reorganized everybody into stable teams as much as we could. Right. Cross-functional co-located teams with designers and developers and bas and testers in them.

And then those teams would, projects would come to them that we had to do projects. Cause that’s what clients were paying for, right? But also we did b a bau. So one team would do a combination of projects and bau. Gone. 

Shane: So, so, okay. So there’s a different lens though, right? If you’re a consulting company and you are working with an organization Yeah.

And that piece of work is, is not ongoing, right? It’s temporal. There’s a beginning of that piece of work, and there’s an end of that piece of work where you will exit because you are a, you know, you’re an external party. Yeah. Then does that define a more product, project centric type of work versus. If you were a team within the organization just doing what’s the next priority, could we use that as one way of differentiating a project versus, uh, an agile or 

Murray: piece of work?

So I’m a firm believer that you can have agile projects. 

Shane: Uh, I’m a firm believer you can, but you never should because we get really, really bad behaviors. It’s like an agile project manager, right. My view, and again, I’ll say it, is you ever come out of PK and that’s what you’ve been trained to do or you’ve been trained in an agile way of working and it’s hard to switch between the two.

Um, and therefore when we ask for an agile project manager, we’re asking for somebody to be that magic unicorn and we shouldn’t, we should be. We’re gonna follow more of a waterfall project approach, or we’re gonna follow more of an iterative, agile approach. And we wanna be very clear which one of those we’re we’re.

And so, yes, we can use the same techniques for either word, but we should be very clear about which word it is because No, but 

Murray: baggage, you made a whole lot of assumptions there, which I don’t agree with. So I am a pmbok. Project manager. I’m also an agile coach. I didn’t maintain my PMI accreditation because the, a lot of the people in the pmi, um, were of the authoritarian project management variety that I didn’t like.

Right. But not all of them. So perhaps I am the magic unicorn, Shane. Yeah, you’re . But I have actually met, um, quite a lot of, Uh, project managers who are, you know, have an agile mindset, right? And an agile way of working. So, um, I think that a, a project can be, can be agile, and an agile project works like this.

You, you have a, um, Fixed amount of time and money to achieve a goal, right? And that time and money is defined by business needs. They, they have something they have to do in the marketplace and basically people use their political capital internally to raise money and get resources to do something. So it is gotta, it’s gotta be clear what it’s trying to do.

But an agile project focuses on outcomes. So the detailed require. Um, are not part of the scope. The scope is defined by the outcomes and kind of the objectives, but we, um, make the, the detailed requirements in the detailed solution very flexible, right? So we fix, uh, typically I’d say we fix the time and the budget and the goal.

and we make, and the quality and we make the, um, the detailed requirements and features flexible through, through, you know, your typical product backlog type of approach. 

Shane: Yeah. So that’s just an agile way of working. Right. But if I advertised on that jobs for the job board that you used to work for, assuming that the classification system works now, and I asked for a project manager and I get one turning up.

Nine times outta 10, they’re gonna want to fix the budget. They’re gonna want define the scope up early because that’s the behavior that they’ve been trained to. If I went and said, you know, uh, agile product project, uh, agile lead, or, uh, agile coach, or, you know, someone, product owner, they’re naturally not gonna do that, right?

They’re gonna say, well, let’s get a good understanding of the vision and the outcome and the acceptance criteria, and then let’s build the backlog. and then let’s do the trade-offs. We need to meet that timeframe, um, by not delivering some stuff, right? Again, those behaviors naturally come with the title and my 

Murray: experience.

I don’t, that’s not my experience at all. And I say that because I have worked with quite a lot of Scrum managers who used to be authoritarian project managers and continue that mindset through. Yeah. How does that go 

Shane: for you? Yeah. How, how does, how does, uh, a project manager who became a scrum master, who then stands at the beginning of the front of the board, And asks the team one by one, you know, okay, John, what are you working on?

Right. You know, that’s, that’s a project manager ending 

Murray: to be a No, but see, what you’re objecting to is the behavior, the authoritarian behavior. Right. Which is what 

Shane: a project manager is 

Murray: taught to do. No, no. In the old days. Yes. Yes. Right. But it doesn’t have to be that way. 

Shane: What? Because we don’t, if we, if we use that term, we adopt the behaviors that came with the term.

Because by definition, that’s what it is. When you say you are a project manager, You are referring to the old way of working. 

Murray: Well, why don’t we have Agile project managers then Shane . Cause it’s an oxymoron. It’s not at all. I, I appointed agile project managers at the, at the agency and you know, recruited them and you know, we were able to recruit quite a few who had the right.

Um, agile mindset and, you know, they use their project management skills to empower the team and support them and to manage the client’s expectations and to make sure you are on time and on budget. So, so let’s, 

Shane: let’s drill down on that. The, the project management skills, right? So what skills come out of project management that are naturally skills within an agile way of working 

Murray: that are not.

Yeah, 

Shane: because you, you said the word project management skills rather than as humans, they had the skills to do the right work. Right. To get the right things done, which is constantly communicate with the customer about where 

Murray: we’re at, right? Yeah. Yeah. All right then. So, um, budget management is an obvious one.

Shane: budget management. So if we work on the basis that there’s a bunch of people working and they’re working full-time on this one thing, the budget management ain’t hard, right? It’s, there’s five people. This is what it costs. They’re running for a week. There we go. We’ve got an estimate that will be finished based on the backlog.

You know, based on that stuff you talked about a couple of podcasts ago, which I really liked about light estimation will be done by then. There’s your budget. 

Murray: Yeah. But that’s, that is a type of project management skill that I was discussing there. Maybe it, maybe it’s something that you can, it’s something you can learn.

You don’t have to be a project manager to learn nice skills. Right. But. People are going, the, the business or the client or your, you know, internal stakeholders are going to ask you how much, uh, how, how many people, how much money, how much time do you need to achieve this goal? Right? And then they wanna negotiate.

Uh, around that, you know, they’ll, they’ll say, well, what if, what if we could, um, is there some way we could do it earlier is typically the question. And then you can say, well, possibly if. If we haven’t started yet, we might be able to have a bigger team or two teams, or you know, most likely we’ll be not delivering some of the lower priority scope items, but this is 

Shane: all, yeah, I think you’ve been kind there.

Yeah, that’s what they 

Murray: should do, right? They should say that’s what I would do and that’s what a good Agile project manager would do. 

Shane: That’s what a good Agile practitioner would do is say, okay, you want change something? What? What do we need to do to achieve it? In reality, a lot of the time is they’ll go, that’s too much.

Do it for less. And you’re like, cool. What don’t you want done? Oh, no, I want all of it. Just want it for less. 

Murray: You gotta say no. It’s very important to say no. Hey, you know what? Project managers are actually trained in saying no, . 

Shane: Uh, yeah, but isn’t, isn’t the, the saying no, isn’t that, uh, what a product owner does, don’t they negotiate with the stakeholders and say, well, actually you, you know, you’re not gonna get all of that given the constraints you’ve provided.

So what do you know? Let’s work on what we’re trading off. 

Murray: So, um, I think that the, um, in a s in a very small project was say, you know, like a small team. Um, the product owner can take on those sort of responsibilities, although usually they don’t understand how to do a lot of them. Like there’s quite a lot of product owners who don’t know how to manage a budget or, um, the other thing, um, Project managers do a lot as risk management and also negotiation with the outside, the rest of the organization.

Oh, 

Shane: hold on. No, I gotta call bullshit on that. I’ve never met a project manager that does risk, um, management. I’ve read many project managers that do risk facilitation, right? And I like that. So again, they facilitate the approach or the framework or the, the way of working to say, How do we identify the risks?

And then how do we manage the risks, right? Um, so they effectively coach the team on what a risk is and, and help the team understand how they’re gonna mitigate it. But a project manager never actually deals with the risk themselves, right? They just put it in their stupid spreadsheet and then report it with one of those stupid color things.

Murray: Project management role is a facilitation role. You get. 

Shane: We disagree because nine times outta 10 I see a project management role as a control role. 

Murray: So risk and issue management is the most important thing that the project manager is supposed to be doing, right? Whether they do it or not is, is another question I always found.

Um, so, so I would find on projects I was running. You know, if there was a risk, like yeah, sure. I would ask the team, what do you think of the risks? We would have, you know, risk workshops perhaps, where we would brainstorm what the risk could be, and I would put them in a backlog. You can use a backlog for risk, so you can, you know, identify them, prioritize them by value and size or impact, I would say, and size.

And then, you know, have a risk backlog, which you invest in, and then you could say, for our top priority, , which is often something to do with architecture or dependency on your deployment team. Um, we need to make these changes, right? And then some of those activities can go into your backlog and you can do something about it.

But, um, I often found that the issues were what would derail a project like, um, there’d be some. That wasn’t expected or something happened you didn’t expect. And a critical thing for a, a project manager is to resolve that issue with the team and with other parts of the organization as quickly as possible.

Cause those get worse. But isn’t that 

Shane: the, isn’t that part of the role? Is that when the team is blocked and the team are the blockages outside the control of the team, the scrum master helps facilitate with the wider organization the unblocking of that. Isn’t that what a scrum masters meant 

Murray: to do? So your assumption here is that agile equals scrum, which I don’t agree with.

No, no, no, no. I’m just 

Shane: saying in a scrum approach. Is that what a scrum master meant to do? Is that one of their rules, one of their tasks? 

Murray: Uh, yeah. The scrum master is supposed to, um, escalate blockers that the team raises. So the team will identify blockers and the scrum master will go. Um, to stakeholders and try and resolve those blockers with the stakeholders so the team can move forward.

Right? 

Shane: Yeah. So in a, so let’s say we’re going down a lean or a, you know, a approach, which again, I’m, I’m, you know, weaker on than, than Scrum. Who manage, who’s the person that helps the, the system unblock, you know, is it the team that do it or is there somebody who has a role, um, to, to help when it’s outside the control of the, the system or 

Murray: the.

Um, in CanBan, it’s, it’s unclear. CanBan doesn’t have all of these defined roles like Scrum Kanban’s, more of a process and a, and a philosophy like lean. But there, I think generally it’s assumed that there is a manager in there somewhere. That you escalate things to. They could be an operational manager or they could be a project manager or a product manager, and then that person goes and resolves it.

So the, the team has a responsib quite a lot of responsibility for identifying issues and raising it with a manager who is outside the team to get them resolved.

Shane: But they don’t manage, do they? They facilitate. So maybe that’s one of 

Murray: the things that facilitation is part of management. It’s a core skill. 

Shane: So I think facilitation is part of leadership. But again, you’d have to agree that when we use the word manager, we, we, nine times outta 10, we adopt a commander control behavior with that term.

Murray: Uh, no, I don’t think it has to be like that. That’s a, that’s a really old fashioned view of, of management, like a modern view of management. If you read all of the. You know, what people are talking about is that management and managers are leaders, not command and control policemen. That’s the, that’s the idea.

I mean that there are plenty of command and control authoritarian managers, but they, it’s not supposed to be like that. 

Shane: No, it’s not meant to be. But again, the behavior when you use that term is comes of all the package. So why don’t we just change the term, alright. Why don’t we call them leaders, not managers.

And why don’t we call them something other than project? So, 

Murray: Because I think that’s just confusing. I, I think that, um, I also think that the term manager is not gonna go away, and the term project is not gonna go away. I would like to start calling them agile projects and agile managers and leaders.

Leadership and management, I think are not, are not the same, but a manager should be a leader. And a leader should be a good manager, but they are kind of overlapping sets, so then, then you can be one without being the other. I think that though, I think that’s a bad idea. A leader is like a visionary and a people focused person.

A leader without management skills will need to have managers who do that stuff for them do what stuff? Organizing shit. Shane . 

Shane: But isn’t the team self organiz? Aren’t they empowered to 

Murray: solve? Okay, that’s fine when you’ve got like five people, but it’s not fine when you’ve got 20 people or a hundred people, or a thousand people.

So is it a 

Shane: scaling problem? Right? Are we saying that we need these roles when we are scaling and we have too many pods and we are getting, you know, the, the usual problem of. Not conflict, but, um, collisions between the, the teams, between the pods. 

Murray: I would say it’s largely to deal with scaling. Yes. So for, for example, I, I don’t think a project manager is really needed if you just have.

you know, a a small scrum team, the product manager and the scrum master can do the project management stuff between them. And I think that project manager’s probably just gonna get in the way for one Scrum team. But when you have multiple teams and when you have other parties who need to do things like vendors and other departments in your organization, then I think a project manager can be very effective.

Because typically other people don’t have those. Your product manager usually doesn’t have the capabilities to organize all of that stuff. Neither is the scrum master 

Shane: to use your words against you. Um, they could, right? There’s nothing stopping you having, uh, product owner that has those skills. Um, I’ll give you one.

I’ll give you one thing. I see a project manager, effectively a project administrator having high value when, uh, part of the organization’s working in an agile way and the rest of the organization is not. So you have your classic pmo, um, and I see high value in the poor old project manager slash administrator taking the outputs from the team and then turning them into all those crappy reports that nobody looks at, that they spend half a week doing just to tick the box that the crappy report was produced for the pmo.

I see high value in them taking that drossy work off the team. So I’ll give you that one. But again, I still think, you know, uh, the traditional behavior of a project manager is, has no value. 

Murray: I don’t look, there is a place for project administrators, but, um, You know, really then project administrators are just doing some kind of standard process.

They don’t do things like negotiate with stakeholders or remove blockers or, you know, get, you get the team extra skills and resources that they need. So, 

Shane: so if we say that in Scrum, right? Scrum master removes the blockers product donor. Um, Deals with the stakeholders, they’re getting extra resources, is an interesting one.

Right? Does is, you know, is a product owner, the person that goes and asks for more resources to come into the team because they’re needed, right? Or is that a different role? 

Murray: Scrum has nothing to say about this. There’s a lot of things that Scrum has nothing to say about Scrum has nothing to say about how to initiate something and it has nothing to say about budgets.

It has nothing to say about career management. It has nothing to say about, you know, getting extra people for the team. It, it, scrum is a, um, process framework for a team to self organize to achieve something. 

Shane: Yeah. So, but what I’m doing is I’m saying if we pe the team are working, adopting a lot of the scrum behaviors, right?

Some of the scrum, we’re adopting the scrum roles, um, we’re adopting the scrum behaviors and then we’ve got some gaps, right? But you is what 

Murray: you’ve just said. Yeah. There’s, there’s definite gaps, particularly when you’re scaling. But let’s just talk about a situation where you’re not scaling first. Right? I wanna go back to the, the scrum master resolves blockers for the team.

Because, um, I have found that generally Scrum masters are too junior to do this within an organization. Yeah. 

Shane: So, so we can’t say that just because people think a scrum master doing a two day lovely, fluffy certification and then you get thrown at a team as an expert is good behavior. Right? We can’t say that just because junior people put in those roles and we don’t support them and coach them to be effective, that that role shouldn’t do that task.

Murray: So it’s, it’s. I mean, I could do it if I was a scrum master, I would be able to do it right. But I’ve got 20 years of experience in dealing with stakeholders in major organizations and resolving issues and blockers. I just find that most Scrum masters are completely unable to, to really resolve or remove blockers for a team.

They can. They can raise them. Usually what happens is that they’ll, they’ll raise them with some manager and then they’ll expect that manager to resolve it for them, but then it doesn’t get resolved.

Shane: Yeah, and then your, your theory, the people they raise it with is the project manager. 

Murray: Manager. Let’s say there’s no project manager. The scrum master will raise it with somebody else, like an operations manager. And that person may or may not do something about it, but I, I would prefer, uh, if you’re doing a project right, then the project manager should be a servant leader to the team and they’re, one of their primary roles should be to help the team remove blockers.

By using their influence and their skills at stakeholder management and their understanding of technology and business. 

Shane: Okay. And, and, and so that’s, I suppose where part of my frustration comes from is that in my experience, project managers don’t tend to be servant leaders. 

Murray: Yeah. So when I talk about an agile project manager, they are very much a servant leader.

So 

Shane: you are, you are saying that if you’re a project manager, you aren’t a servant leader, but if you’re an Agile project manager, you are a servant leader. 

Murray: Um, I would make the distinction between a command and control project manager and a servant leader project manager. And I would expect that, um, uh, Today’s day, you could be a servant leader, project manager without doing agile.

Like in the old days, you, you occasionally got somebody who, who was a kind of servant leader type of person in the role. Um, but Agile really demands it. That you have a servant leader mindset and approach. Um, so I think that that’s, that’s really what you need. In fact, agile is asking for all of the managers in the organization to be servant leaders all the way up to the top.

Because if you have, if you just go one level and you, you have a servant leader, project manager, and the person they’re reporting to is a command and control, you know, Jerk. Uh, then everything will just get blocked there. 

Shane: So, okay. And, and I agree. Yeah. We should, we, we’ll talk on another podcast maybe about the danger of, uh, getting a team to be agile when the organization’s not, and all the horrendous stuff that happens.

But let, let’s go back to this project thinking. Yeah. So are we saying, um, Effectively a pro, the definition of a project is when the team’s allowed to show up, throw up and bugger off. Um, because they’re, they’re there to achieve the outcome. They’re not there to achieve new ways of working. Organizational change, servant leadership, all those good things.

And an agile way of working is where you’re actually changing the way the organization behaves and works while still trying to. An outcome that the project was meant to deliver? Is that what we’re saying? The definition is, and therefore you can have people that are good on either side and you can have people that potentially are good at both, but that’s the difference between a project and an agile piece of work.

Murray: I find that I’ve just found what you said very confusing and I’m trying to pass it 

Shane: Well, I’m confused, right? Cause again, it’s, it’s semantics. Like, you know, what is a project and what is not, and what is a project manager and what is 

not 

Murray: project is like we’re going to, um, land on the moon in, you know, at the end of 1969.

like JFK said, that’s a project, you know, it’s got a clear goal, it’s got a, you can measure it. Um, it’s got a timeframe, you know, it has a budget, um, and people working together in a very focused way to achieve it. So that’s what, what a project is. Now you can do a project in an agile way or you can do it in a waterfall way.

And what. Arguing is that you should do your projects in an agile way and um, if you do, they’ll be much more effective. And also the Project Management Institute is very supportive of agile project management approaches. Now, they’ve had a big change over the last 20 years. Yeah. And, and I think 

Shane: it’s PMI, isn’t it?

That took over disciplined agile, um, in terms of the, the collateral and, and the approach. 

Murray: Yeah. And also the flex approach. So there’s a lot of lean CanBan stuff in there now and the project Management Institute has got agile project managers certifications and career streams and all that sort of stuff.

And I’m actually quite supportive of it. I think the people who are doing that stuff, um, Particularly the, in the organizations they’ve, they’ve acquired are, are very good. So are 

Shane: we saying then that uh, the four old project and the project manager and the PMI and those, those groups have been done at a service because we’ve all gone off on the Agile bandwagon?

We’ve used them as the baddies by saying all they ever did was waterfall and that was bad when in fact, uh, they were actually adopting hedge, always working where it was fit for purpose. But we streamed off with a whole new brand, left them behind, and therefore, They can’t catch up in terms of a brand point of view when they may or may not have already been doing those behaviors.

Murray: Look, if I think of project management in the eighties and nineties, it, it went through this period of being extremely command and control, extremely process and document oriented and extremely, um, waterfall. But it didn’t have to be like that. It’s just that that’s the direction that the project management community went in as they become, became.

This, uh, discipline or this institution, cuz there wasn’t really, if you go back to like the, the forties, um, there really wasn’t a, any sort of project management discipline or association or anything. It, it really only began in, in the early eighties. Or maybe the seventies. Um, but they went off in this kind of authoritarian command and controlled direction.

Right. And then Agile rebelled against it. And you, the Agile manifesto is really saying, you know, things like we value individuals and interactions over processes and tools. It’s saying that because they’re dealing with a whole lot of. People who are doing, who are completely focused on processes and tools, you know, we, we, um, I can’t remember the word exactly, but we accept, um, we value change over following a plan is because I’m dealing with a whole lot of people who are totally focused on following a detailed plan.

But that, that is a, um, that is a, an approach that the project man management community went in, which was really bad in my opinion. Um, and then Agile rebelled against it. And then, um, a whole lot of people who were project managers. like me, were very frustrated with, with that and the outcomes of it, and saw Agile as being a real lifeline and you know, incorporated it.

So there’s definitely an option now for project managers to do things in a real agile servant leader way. It’s just that I have to agree with you, Shane, that a lot of people don’t. 

Shane: So, so I think, you know, we’re kind of coming to the end of the session. Uh, I think the takeaway for me is I’ll, I’ll give you that there are, um, commander control orientated people that tend to adopt a lot of the waterfall practices.

Yeah. Yeah. And there are servant leader type people who, uh, adopt, uh, a lot of the agile approaches and ways of working and, and thinking and mindset. Yeah. Um, so I’ll, I’ll give you that. I still stick by my statement that the majority of the time I meet a project manager, they fall in the command and control and waterfall.

Um, and therefore that’s why I don’t like the term, because I don’t like the behavior that I see come with it nine times outta 10. So maybe that. It’s a type of pro type of work, uh, or deliveries that I work in. Maybe it’s the type of organization, maybe it’s a New Zealand thing. Um, but hopefully it will change over time.

So, but I still think if you go onto one of those job boards and ask for a project manager, uh, you’re asking for that command and control what will type behavior at the moment. 

Murray: Well, I’ve been looking at those boards recently and there’s quite a lot of jobs advertised for program managers and project managers that do say that Agile is very important and they’re, they’re working in an agile way, right?

So, There’s others that, that are, are clearly saying no, it’s all gotta be prints too. And, um, you know, staged delivery, they don’t call it waterfall, they call it staged delivery or the systems engineering or system development life cycle. Right. Prince two is very much like that. Um, but uh, yeah, there’s, there’s definitely, well there’s three camps, right?

There’s the traditional hard ass waterfall authoritarian project and program managers. There’s still a lot of them around. Then there’s a, you know, a significant camp, but you know, a smaller camp of people who are agile servant leader. Project and program management type of people. And then there’s the biggest camp is the people in the middle who are confused and who are trying to do both somehow.

And the combination is not good. I think you’re much better doing one or the other. So I see a lot of, um, water scrum fall around. Uh, that’s the common thing in corporate world where basically you’re doing things in a staged way with authoritarian management, but each stage is done with. With Scrum teams.

So we’re gonna have a design phase, Shane, and in the design phase people are gonna work in Scrum teams, um, in iterations to produce, um, user stories, basically. , well, 

Shane: I mean, I don’t like that. They’re working in arts, right? They’re, they tend to be working on a release train. Um, cause 

Murray: that don’t get me started on

Shane: I thought I just gonna drop one, that one in there, right near the end.

Well, I’m gonna be more tolerant of you using the word project at the moment because I, I, I can see where you’re coming from. I think like, uh, all people in. It, uh, world, we should make up a completely new word. Um, that’s not project or iteration and try and coin it and write a book on it. Um, but until we do that, you keep using project.

I’ll keep using a piece of work that has to be delivered. Next argument Next time. 

Murray: Alright, then. Catch you later. Thanks, Shane. Hi, that was the No Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you’d like help with Agile contact murray evolve.co. That’s evolve with a zero. Thanks for listening.