agile projects

In this engaging episode, Murray Robinson and Shane Gibson dive into a spirited discussion on the compatibility of Agile and Project Management.

Discussion highlights include:

• The Agile-Project Management conundrum: Is Agile fundamentally incompatible with Project Management? Is it possible to run projects in an Agile manner or is the traditional waterfall and hierarchical approach inevitable?

• Project Managers and Agile: Can Project Managers, often seen as controlling authoritarians, adopt an Agile mindset and become servant leaders?

• The Project Dilemma: If a project is run using Agile, can it still be considered a project?

This episode sparks a controversial conversation on the intersection of Agile and Project Management, challenging traditional notions and exploring new perspectives.

Tune in for this provocative discussion.

Read along you will

Shane: Hey, Murray, how are we

Murray: Good. I wanna talk about project and project management. You were telling me you were having all sorts of problems with some program managers. So why don’t you start, Shane, and tell me what is a project manager, and what is the problem with it?

Shane: So I think it all comes to semantics. If a group of us are working together and we have a project manager, there’s an expectation that it’s focused on a well defined vision and outcome, and we’re running off to deliver that thing. There’s a beginning and an end. We’re gonna start it. We’re gonna deliver that project and we’re either gonna disband, or we’re gonna do something else. And I don’t agree with the idea that we start something and we end it and we never invest in it again. 

Murray: So I think we should separate between what people quite often do and what they have to do. Let’s say that you have a project to build an application, that doesn’t mean that once you’ve finished the project, that there’s no updating or maintenance of that application.

Shane: No, but what happens is we take the thing we’ve built, 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 finished. 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 30% of that total cost of that project will be funded to keep reinvesting in it, so we end up with a whole lot of trained behaviors, which I think are less than optimal.

Murray: 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 is.

Murray: Yeah. To me, project is something that definitely has a beginning and end. It has a budget and it has a team. It has some sort of scope or goal. The organization has decided to do something and they’ve moved resources into that initiative to do it and then once it’s done, then they move them onto other things. So there can be good and bad things about that. What’s the difference between moving your resources on to do a story and then finishing it and moving on to the other one, what’s the difference between that and the project, except the project’s bigger.

Shane: It doesn’t use the word project, it just says there’s a piece of work to be delivered and then deliver it and move on to the next piece of work. They should be the same behaviors, but when we use the word project, in my experience, the semantics around that word means we show different behaviors. It’s interesting how just that one use of that word changes the way people think and behave.

Murray: Projects are temporary. You’re getting a team together to do something for a period of time and then you use up the money and they go away and do other things. 

But 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 of somebody has 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, 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 , no matter how much people call for it, it’s not gonna happen.

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 idea that the organization wants to do something and so they marshal resources to do it, and then they go and do something else. The alternative case that people always put up is, let’s not have any projects. Let’s just have an ongoing, application development or product team, and it’ll be made up of let’s say 50 people and they are going to work on that application continuously. That could be quite good, but it can also have some disadvantages. People who are working in an operational approach can get very focused on the micro issues and the way things are being done now and they may not have the flexibility or capacity to do big things.

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

Murray: It’s often the case that the operations support team, just doesn’t have the capacity to do anything big. So they need extra people to work with them to do something big. The other thing is that there is a skills issue. People who are working on one application all the time get to know it very well, but their skillset becomes quite narrow and they can get quite out of touch with what else is going on in the world.

Shane: But isn’t that just a case of 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 a transient focus as a way of solving that particular problem?

Murray: From a skill point of view, there can be quite a lot of benefit from getting people with fresh ideas to come in and help for a period of time.

Shane: 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? And then exit because either the skills or the capacity aren’t there at the moment? 

Murray: It quite often happens like that, but no, I don’t think that’s a definition of what defines a project. I worked for a large online jobs board in australia and all of our team were permanent staff. But we still did projects. We didn’t have budgets because the budget was already paying for all the staff. But people would be moved on from one project to another to address changing business needs. So the business would realize they needed to do something and then a bunch of people would work on it. And having a project to work on something big became a good way to organize it and coordinate it. 

I’ll give you an example, Shane. So this, jobs company 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 creating new classifications or new markets cause their code wasn’t modularized, or parameterized to be able to go in and just say, add a new category like government jobs. So it was technical debt, or just they hadn’t built for it. And we in it then had to, restructure this online application to allow these new categories to be added. 

And each category had its own pages and different types of jobs. So it was actually complex and it was right at the very heart of the whole business . It’s like doing a bit of open heart surgery, really. And probably about two thirds of the people in the IT department, 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 time targets we were trying to meet. And it really focused everybody on achieving this objective. 

Shane: So there’s nothing that relates to a project in what you described.

Murray: It is a project though because you had a scope. 

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

Murray: It doesn’t have to be, No, not at all. So if you read the Guide to the Project Management Body of Knowledge, which is issued by the Project Management Institute, you’ll see that they define a project as a temporary endeavor to achieve a goal. That’s pretty much all it is. And if you go into it, they talk about a whole lot of different ways to do that, and they talk a lot about agile and lean and adaptive planning approaches. So you don’t have to do it in 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 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 a non-project, there’s a group of people that are doing the same kind of work in the same way. But they’re continuously working on that thing. So they’re almost like a product team. 

Murray: Yeah, I would agree with that. So a product team or an application team is ongoing. They might do a whole lot of different initiatives, but they’re not defined by the organization as a project. 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 an ongoing team might take a very uncertain amount of time to get something done.

Shane: Yeah, so when I’m coaching teams I talk about the magic triangle. The idea that when we take a project led approach, we set the time when it’s gonna be delivered and set the scope and then we try and play with the effort, we try and add more people when we’re not gonna make. And then when I talk about iterative or an agile way of working, I say, we set the date and then we set the effort level, how many people are involved, and then we play with the scope, we say what’s in and out within that date. So I could use that to say, one is a project approach and one is a agile approach. 

Murray: But see, you’ve just defined a project as not an agile or iterative way of working and I don’t agree with that. 

Shane: Yeah, but that’s because every time I work in an organization that uses the word project, we see a whole lot of non-agile behaviors.

Murray: When I was Delivery general manager at a digital agency, I reorganized everybody into stable teams. Cross-functional, co-located teams with designers and developers and bas and testers in them. And then projects would come to them. We had to do projects cause that’s what clients were paying for. But also we did B A U. So one team would do a combination of projects and b A U.

Shane: If you’re a consulting company and you are working with an organization and that piece of work is not ongoing. 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’re an external party. Then does that define a more 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 an agile or iterative piece of work?

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

Shane: I’m a firm believer you can, but you never should because we get really bad behaviors. It’s like an agile project manager. You ever come out of PMBOK 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. 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 clear. We’re gonna follow more of a waterfall project approach, or we’re gonna follow more of an iterative, agile approach. We can use the same techniques for either word, but we should be very clear about which word it is because it comes with lot of baggage. 

Murray: You made a whole lot of assumptions there, which I don’t agree with. So I am a PMBOK trained project manager. I’m also an agile coach. I didn’t maintain my PMI accreditation because there’s a lot of the people in the pmi were of the authoritarian project management variety that I didn’t like. But not all of them. I have actually met quite a lot of project managers who have an agile mindset and an agile way of working. I think that a project can be agile. And an agile project works like this. You have a fixed amount of time and money to achieve a goal, and that time and money is defined by business needs. They have something they have to do in the marketplace and people use their political capital internally to raise money and get resources to do something. So it is gotta be clear what it’s trying to do. 

But an agile project focuses on outcomes. So the detailed requirements are not part of the scope. The scope is defined by the outcomes and the objectives. We make the detailed requirements and the detailed solution flexible. We fix the time and the budget and the goal and we make the detailed requirements and features flexible through, your typical product backlog approach.

Shane: So that’s just an agile way of working. But if I advertised for a project manager. Nine times outta 10, they’re gonna want to fix the budget. They’re gonna want to define the scope up early because that’s the behavior that they’ve been trained to do. If I went and said agile lead, or a Agile coach, or owner. They’re naturally not gonna do that. They’re gonna say 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. Those behaviors naturally come with the title and my experience. 

Murray: That’s not my experience at all. I have worked with quite a lot of Scrum managers who used to be authoritarian project managers and continue that mindset 

Shane: Yeah. How does that go for you? Yeah. How does a project manager who became a scrum master who then stands at the beginning of front of the board and asks the team one by one, okay, John, what are you working on? That’s a project manager pretending to be a scrum master. 

Murray: What you are objecting to is the authoritarian behavior. Right?

Shane: Which is what a project manager is taught to do

Murray: In the old days, yes, but it doesn’t have to be that way. 

Shane: 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: Why don’t we have Agile project managers then, Shane?

Shane: Because it’s an oxymoron. 

Murray: I appointed Agile project managers at the agency and, we were able to recruit quite a few who had the right agile mindset and 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.

Shane: Let’s drill down on that. So what skills come out of project management that are not skills within an agile way of working? 

Murray: 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, 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. Light estimation, we’ll be done by then. There’s your budget.

Murray: Yeah. But that is a type of project management skill. The business or the client or your, internal stakeholders are going to ask you how many people, how much money, how much time do you need to achieve this goal? And then they want to negotiate around that. They’ll say is there some way we could do it earlier . And then you can say if we haven’t started yet, we might be able to have a bigger team or two teams, or, most likely we’ll be not delivering some of the lower priority scope items. That’s what a good Agile project manager would do.

Shane: that’s what a good Agile practitioner would do is say, okay, you wanna change something? 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: Project managers are actually trained in saying no.

Shane: Yeah, but isn’t saying no, isn’t that what a product owner does, don’t they negotiate with the stakeholders and say 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: In a very small project with , a small team, the product owner can take on those sort of responsibilities, although usually they don’t understand how to do a lot of them. There’s quite a lot of product owners that don’t know how to manage a budget. The other thing Project managers do a lot as risk management and negotiation with the rest of the organization.

Shane: Oh, hold on. No, I gotta call bullshit on that. I’ve never met a project manager that does risk management. I’ve read many project managers that do risk facilitation. They say how do we identify the risks and then how do we manage the risks, so they effectively coach the team on what a risk is and help the team understand how they’re gonna mitigate it. But a project manager never actually deals with the risk themselves, they just put it in their stupid spreadsheet and then report it with one of those stupid color things.

Murray: A project management role is a facilitation role. 

Shane: This is where 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. . On projects I was running I would ask the team, what do you think are the risks. We would have risk workshops 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, identify them, prioritize them by impact and size. And then you could say, for our top priority risk, Which is often something to do with architecture or dependency on your deployment team. We need to make these changes, and then some of those activities can go into your backlog and you can do something about it. But I often found that issues were what would derail a project. There’d be some risk that wasn’t expected or something happened you didn’t expect. And a critical thing for a project manager is to resolve that issue with the team and with other parts of the organization as quickly as possible, cuz those get worse.

Shane: Isn’t that part of the role defined for a scrum master is that when the team is blocked and the blockage is outside the control of the team, the scrum master helps facilitate with the wider organization the unblocking of that problem. Isn’t that what a Scrum Master’s meant to do? 

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

Shane: Yeah. So let’s say we were going down a lean or a kanban approach, who’s the person that helps the system unblock, is it the team that do it or is there somebody who has a role to help when it’s outside the control of the system or the flow?

Murray: It’s unclear. KanBan doesn’t have all of these defined roles like Scrum. Kanban’s, more of a process and a philosophy. Like lean, but then 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 team has responsibility for identifying issues and raising up with a manager who is outside the team to get them resolved.

Shane: But they don’t manage, do they? They facilitate. 

Murray: Facilitation is part of management. It’s a core skill.

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

Murray: No, that’s a really old-fashioned view of management. A modern view of management is that managers are leaders, not command and control policemen. There are plenty of authoritarian managers but it’s not supposed to be like that anymore.

Shane: No, it’s not meant to be. But again, the behavior when you use that term comes with all the baggage so why don’t we just change the term, why don’t we call them leaders, not managers. And why don’t we call them something other than project? 

Murray: I think that’s just confusing. 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. A manager should be a leader. And a leader should be a good manager. A leader without management skills will need to have managers who do that stuff for them.

Shane: Do what stuff. 

Murray: Organizing.

Shane: But isn’t the team self organizing? 

Murray: That’s fine when you’ve got five people, but it’s not fine when you’ve got 20 people or a hundred people, or a thousand people.

Shane: So is it a scaling problem? Are we saying that we need these roles when we are scaling and we have too many pods and we are getting, the usual problem of, collisions between the teams, between the pods. 

Murray: I would say it’s largely to deal with scaling. Yes. So for example I don’t think a project manager is really needed if you just have a small scrum team. The product manager and the scrum master can do the project management staff between them. And I think the 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. Your product manager usually doesn’t have the capabilities to organize all that stuff and neither does the scrum master.

Shane: There’s nothing stopping you having a product owner that has those skills. I’ll give you one thing, I see a project manager having high value when part of the organization’s working in an agile way and the rest of the organization is not. So you have your classic pmo. And I see high value in the project manager 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 I still think. The traditional behavior of a project manager has no value.

Murray: There is a place for project administrators, but project administrators are just doing some kind of standard process. They don’t do things like negotiate with stakeholders or remove blockers or get the team extra skills and resources that they need.

Shane: So if we say that in Scrum, scrum master removes the blockers product owner deals with the stakeholders. Getting extra resources is an interesting one. Is a product owner, the person that goes and asks for more resources to come into the team because they’re needed, 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 getting extra people for the team. Scrum is a process framework for a team to self-organize to achieve something.

Shane: Yeah. But what I’m doing is I’m saying if the team are adopting a lot of the Scrum behaviors we’re adopting the scrum roles we’re adopting the scrum behaviors and then we’ve got some gaps. 

Murray: There’s definite gaps, particularly when you’re scaling. Let’s just go back to the scrum master resolves blockers for the team because I have found that generally scrum masters are too junior to do this within an organization.

Shane: Yeah so we can’t say that just because people think a scrum master, doing a two day certification and then you get thrown at a team as an expert is good behavior, 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: I just find that most Scrum masters are completely unable to really resolve or remove blockers for a team. Usually what happens is that 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 in your theory, the people they raise it with as the project manager. 

Murray: 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 if you’re doing a project, then the project manager should be a servant leader to the team and , 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: I suppose where part of my frustration comes from is that in my experience, project managers don’t tend to be servant leaders. 

Murray: Yes, so when I talk about an Agile project manager, they are very much a servant leader.

Shane: So you’re 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: I would make the distinction between a command and control project manager and a servant leader project manager. You could be a servant leader, project manager without doing agile. In the old days you occasionally got somebody who was a servant leader in the role. But Agile really demands it. That you have a servant leader mindset and approach. In fact, agile is asking for all of the managers in the organization to be servant leaders all the way up to the top. If you just go one level and you have a servant leader, project manager, and the person they’re reporting to is a command and control jerk. Then everything will just get blocked there. 

Shane: And I agree. We’ll talk in another podcast maybe about the danger of getting a team to be agile when the organization’s not . But let’s go back to this project thing then. So what is a project and what is not, and what is a project manager and what is not.

Murray: A project is like we’re going to land on the moon at the end of 1969. That’s a project. It’s got a clear goal, you can measure it. It’s got a timeframe, it has a budget and people working together in a very focused way to achieve it.

So that’s 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 I’m arguing is that you should do your projects in an agile way. And 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.

Shane: PMI, isn’t it that took over disciplined agile in terms of the collateral and 

Murray: Yep. And also the flex approach. So there’s a lot of lean KanBan 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 in the organizations they’ve acquired are very good.

Shane: So are we saying then that the poor old project and the project manager and the pMI and those groups have been done a disservice 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 they were actually adopting Agile Ways of 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: Project management in the eighties and nineties went through this period of being extremely command and control, extremely process and document oriented and extremely waterfall. But it didn’t have to be like that. It’s just that’s the direction that the project management community went in as they, became this discipline or this institution. But they went off in this kind of authoritarian command and controlled direction.

And then Agile rebelled against it. And , the Agile manifesto is saying things like we value individuals and interactions over processes and tools because, they’re dealing with a whole lot of people who are completely focused on processes and tools.

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. That is an approach that the project management community went in, which was really bad in my opinion.

And then Agile rebelled against it. And then a whole lot of people who were project managers, like me, were very frustrated with that and the outcomes of it, and saw Agile as being a real lifeline and 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: I think the takeaway for me is I’ll give you that there are command and control orientated people that tend to adopt a lot of the waterfall practices. Yeah. And there are servant leader type people who adopt a lot of the agile approaches and ways of working and thinking and mindset.

Murray: Yep. 

Shane: So 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 camp. 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 it’s the type of organization that I work in. But hopefully it will change over time. But I still think if you go onto one of those job boards and ask for a project manager you’re asking for that command and control what type behavior at the moment.

Murray: 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 working in an agile way, there’s others that clearly saying, no, it’s all gotta be Prince two, staged delivery or the systems engineering or system development life cycle. 

There’s three camps, there’s the traditional hard ass waterfall authoritarian project and program managers, there’s still a lot of them around. Then there’s 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 Water, scrum, fall around. 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 Scrum teams. So we’re gonna have a design phase, and in the design phase, people are gonna work in Scrum teams.

Shane: Well, I’m gonna be more tolerant of you using the word project because I can see where you’re coming from. I think we should make up a completely new word. That’s not project or iteration and try and coin it and write a book on it. But until we do that, you keep using project. I’ll keep using piece of work that has to be delivered.

Murray: All right then. 

Shane: Catch you later.

That was a no-nonsense agile podcast from Murray Robinson and Shane Gibson. If you’d like help to create high value digital products and services, contactMurray@evolve.co. That’s evolve with a zero. Thanks. For listening.