Agile Projects?
SUMMARY
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.
Murray Robinson
So we're going to have a controversial topic today. Shane?
Shane Gibson
Well, we'll see how we go. I know we're going to use the things that I call swear words like project and project management.
Murray Robinson
I want to talk about project and project management. I know you 're telling me you were having all sorts of problems with programme managers, tell me about it. What is a project manager and what is the problem with it?
Shane Gibson
So, it all comes to semantics? Because, if I use the word Scrum, and sprint, and if I use the word iteration, or I use the word project, or programme, they all come with behaviours? we're being trained to behave certain ways when those words are used. an example will be, if I use the word ?project, and the fact that we, 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 ideally, a well defined vision and outcome, and we're running off to deliver that thing. It also has a perception that there's a beginning and an end, we're going to start it, we're going to deliver that project and then we're going to disband or we're going to do something else. when I use the word programme, there's an expectation that these multiple projects are workstreams? There's multiple groups of people, all with slightly varying visions or outcomes. But those visions and outcomes feed up to a larger programme, vision or outcome. again, the programme starts and the programme finishes and people disband or go to do other programmes or other pieces of work. that behaviour I don't agree with, I don't agree with the idea that we start something and we end it and we never invest in it again particularly in IT.
Murray Robinson
Why do you think that? I think we should separate what people often do and what they have to do. Let's say that we have a project to build an application of sorts. That doesn't mean that once you've finished the project that there is no updating or maintenance of that application.
Shane Gibson
No, but what happens is the project team hands it over to the mythical BAU team. 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 it may or may not work, it may or may not be finished. The organisation feels like it 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, can now be funded to keep reinvesting in it. Again, we end up with a whole lot of trained behaviours, which are less than optimal.
Murray Robinson
It's often like that, but it doesn't have to be like that.
Shane Gibson
It doesn't have to be. But because of the word project, and the word programme, it typically is.
Murray Robinson
Well to me a project is something that definitely has a beginning and end. It has a budget and it has a team and it has a scope or goal. I agree that the organisation has decided to do something and they've moved resources into that initiative, whatever it is, and then once it's done, then they move them on to other things. There can be good and bad things about that. But what's the difference between moving your resources on to do a story in an epic and then finishing it and moving on except the project is bigger?
Shane Gibson
Or don't use the word Project? There is a piece of work to be delivered, then deliver it and move on to the next piece of work. Again, they should be the same. But when we use the word project in my experience, the semantics around that word means we show different behaviours. It's interesting, essentially how that one use of that word changes the way people think and behave.
Murray Robinson
Well projects are by their definition temporary. I agree with that, because we're getting a team together to do something for a period of time, and then they use the money and they go away and do other things. By definition, it's temporary. But I want to dig into the bad behaviours, because I don't think that they have to be like this. I say this, from the point of view of somebody who has many years of project and programme management experience. I started doing project and programme management more than 20 years ago. I also started doing Agile not long afterwards. I have a lot of experience with both. My view is that we can do Agile project and programme management. I also think projects and programmes are not going to go away. No matter how much people call for it, it's not going to happen.
Shane Gibson
Why's that? do we think because it's an embedded term, it's been around for too long.
Murray Robinson
It wouldn't matter what we call it, we can call it an initiative, it is still the same thing, the idea that the organisation wants to do something, and that they marshal resources to do it and then they go and do something else. That is a matter of prioritisation, and it can be quite effective. The alternative case that people always put up is, let's not have any projects, let's have an ongoing application development team or an ongoing product team. It'll be made up of say 50 people, and they are going to work on that application continuously. Well, that could be quite good. But it can also have disadvantages. People who are working in an operational type of approach can get very focused on the micro issues, and the way things are being done now. They may not have the flexibility to do anything, or capacity to do big things.
Shane Gibson
In terms of the skills or in terms of the prioritisation. That they always get prioritised for those small fixes, those little changes, those emergency problems, and therefore never get to focus on those bigger chunks of work.
Murray Robinson
Well, first of all, there's a capacity issue, because it's often the case that the Operations Support Team doesn't have the capacity to do anything big. They need extra people to come in and work with them to do something big. The other thing is that there is a skill issue. It's swings and roundabouts, people who are working on one application all the time get to know it very well. But their skill set becomes quite narrow, and they can get quite out of touch with what else is going on in the world.
Shane Gibson
But isn't that a case of we need to invest in their literacy, we need to invest in these 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 Robinson
Look, from a skill point of view, there can be quite a large benefit from getting people with fresh ideas and different ideas to come in and help for a period of time.
Shane Gibson
Is that the definition of a project when people who are outside the organisation 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? Is that the definition of what defines a project
Murray Robinson
It's quite often like that. But no, I don't think that's the definition of what defines a project. I worked for a large online jobs board in Australia, back in the day, and I was a permanent staff member, and all of our team were permanent staff. We only had about 35 people in it. But we still did projects. We didn't have budgets, because the budget was fixed, because it was already paying for all the staff, but people would be moved on from one project to another, and it was a way to address changing business needs. the business would realise they needed to do something or other and then a bunch of people would work on it. Then having a project to work on something big, became a good way to organise it and coordinate it. I'll give you an example. This jobs company always had a problem with its classification system. They wanted to go into new markets, like health care, education and government. they didn't have classifications for those. Also, they didn't have any easy way of creating new classifications or new markets, because their code wasn't structured in a way that was modularized or parameterized, to be able to go in and add a new category, like government jobs. they realised this. it was technical debt, I suppose, or they hadn't built for it. They realised that there was a big market, and they decided to have sales and marketing push it into this, and then had to restructure this online application to allow these new categories to be added. Each category had its own pages, and it had its own different types of jobs. it was complex, and it was at the very heart of the whole business, the whole endeavour. It's like doing open heart surgery, and we got about two thirds of the people in the IT department working on this. Having it as a project meant that it was clear what we were trying to do. we had clear time targets were trying to meet and, it focused, everybody, on achieving this objective,
Shane Gibson
Could we use any term? I could say we're going to do a Bob, a Bob is where we get to create a bunch of product features to improve our classification capability and remove our technical debt. These people over here are going to work on Bob. what the outcome of success looks like. We're going to say these a number of iterations to deliver Bob based on high level estimation, which you've talked about a couple of podcasts ago, we've got a target goal date, where we want Bob to go live. we'll trade off the features and scope to hit that date. The thing I liked about it was we said there's no budget, because when we have this many people working on it for this period of time budgeting is easy, which is one of the approaches I love. I don't need to use the word project. I because there's nothing that relates to a project in what we described.
Murray Robinson
Well, it is a project, because we had a scope. Back in those days the scope was over defined. It wasn't a good Agile project because I didn't understand Agile very well at the time and neither did the team. We did XP stuff there.
Shane Gibson
Would we say that over defining requirements early is a behaviour of a project?
Murray Robinson
It doesn't have to be. No, not at all. There's a big difference. If we go and 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 endeavour to achieve a goal. That's all it is. If we go into it, they talk about a whole lot of different ways to do that. They talk a lot about Agile and lean and adaptive planning approaches. We don't have to do it in stages with a waterfall. That's one way of doing a project. I agree. It is a common way of doing it. It's a bad way of doing it. But it's not the only way to do a project.
Shane Gibson
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 to deliver the outcome and disband. A non-project is a group of people that are doing the same work in the same way. But they're continuously working on that thing. they're, they're almost a product team.
Murray Robinson
I would agree with that. A product team, or an application team is ongoing.They might do a whole lot of different initiatives, but they are not defined by the organisation as a project. Though, they tend to miss a lot of the discipline that we get with Project Management. With Project Management, we'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 Gibson
When I'm coaching teams, I talk about the magic triangle of time, scope, and cost. But the idea is that when we take a Project approach, we set the time when it's going to be delivered and set the scope and then we try and play with the effort. We try to add more people when we're not going to make it. I don't agree that's the definition of a project. But this is the triangle that you'll typically see. 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 were involved. Then we play with the scope lever. We say what's in and out within that date. I could use that to say one is a project approach and one is an Agile approach, you're not going to agree with me, but it's definitely a pattern. I've seen it used time and time again. It's a way of describing the difference between a project and an iterative or Agile way of working.
Murray Robinson
But see you've defined a project as not an Agile or iterative way of working by making an A B comparison. I don't agree with that.
Shane Gibson
That's because every time I work in an organisation that uses the word project, we see a whole lot of non Agile behaviours you've described. Are you saying that if we don't have a project structure, we see teams being ad hoc and fluffing around?
Murray Robinson
They lack focus often. It doesn't have to be like that but it often is. I have examples. When I was a delivery General Manager at a digital agency, I reorganised everybody into stable cross functional, co-located teams with designers, developers, BAs and testers in one team. Then projects would come to the team. We had to do projects because that's what clients were paying for. But also we did BAU. One team would do a combination of projects and BAU.
Shane Gibson
So. Okay, these are different lenses, though. If we're a consulting company, and we're working with an organisation, that piece of work is not ongoing. There's a beginning and an end of that piece of work where we exit because we're an external party. That then defines a more project centric type of work versus if we were a team within the organisation doing the next priority. Could we use that as one way of differentiating a project versus an Agile or iterative piece of work.
Murray Robinson
So, I'm a firm believer that we can have Agile projects.
Shane Gibson
I'm a firm believer, we can, but never should, because we get bad behaviour. You've either 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. Therefore, when we ask for an Agile Project Manager, we're asking for somebody to be that magic unicorn. We should be clear that we've got to follow more of a waterfall project approach or we're going to follow more of an iterative Agile approach. We want to be very clear which one of those we select. Yes, we can use the same techniques for either word nut we should be very clear about which way it is because it carries a lot of baggage.
Murray Robinson
You made a whole lot of assumptions there which I don't agree with. I am a PMBock trained project manager. I'm also an Agile coach. I didn't maintain my PMI accreditation, because 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 were. Perhaps I am the magic unicorn. But I have met quite a lot of other project managers who have an Agile mindset and Agile way of working. I think a project can be Agile. An Agile project has a fixed amount of time and money to achieve a goal defined by business needs. They have something they have to do in the marketplace. People use their political capital internally to raise money and get resources to do something. But an Agile project focuses on outcomes. The detailed requirements are not part of the scope, the scope is defined by the outcomes and the objectives. We make the requirements and the solution very flexible. We fix the time, budget, goal and quality but we make the requirements and features flexible through your typical product backlog approach.
Shane Gibson
That's an Agile way of working. But if I advertised for a project manager, nine times out of 10, they're going to want to fix the budget and define the scope early because that's the behaviour that they've been trained to do. If I went and got an Agile lead, coach or product owner, they're not going to do that. They're going to say, let's understand the vision, the outcome and the acceptance criteria. Then let's build the backlog and do the trade offs we need to make in that timeframe by not delivering stuff . Again, those behaviours naturally come with the Agile title in my experience.
Murray Robinson
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 Gibson
You see the project manager, who became a Scrum master, and then stands at the front of the board, and asks the team one by one okay, John, what are we working on? That's a project manager, pretending to be Agile.
Murray Robinson
What you're objecting to is authoritarian behaviour?
Shane Gibson
Which is what a project manager is taught to do.
Murray Robinson
In the old days, yes. But it doesn't have to be that way.
Shane Gibson
If we use that term we adopt the behaviours that came with the term. When we say we're a project manager we're referring to the old way of working
Murray Robinson
Well why don't we have Agile project managers then Shane?
Shane Gibson
Because it's an oxymoron.
Murray Robinson
It's not at all. I appointed Agile project managers at the agency. We were able to recruit quite a few who had an Agile mindset. They use their project management skills to empower and support the team, to manage the clients expectations and to make sure we're on time and on budget.
Shane Gibson
What skills come out of project management that are naturally skills that are not in an Agile way of working.
Murray Robinson
Budget management is an obvious one.
Shane Gibson
If we work on the basis that there's a bunch of people working, and they're working full time on this one thing, budget management aint hard, it's these five people, this what it costs, we're running for a week, there we go, we've got an estimate that will be finished based on the backlog. Based on that stuff, we talked about a couple of podcasts ago, which I liked about light estimation. We will be done by the end, there is your budget.
Murray Robinson
But that initiation is a type of project management skill. We don't have to be a project manager to learn these skills. But people in the business or the client, or your internal stakeholders are going to ask you, how many people, how much money and How much time do we need to achieve this goal then they want to negotiate. They'll say, Is there a way we could do it earlier or for less money? Then we can say, well, possibly, we haven't started yet, we might be able to have a bigger team or two teams, or most likely we will not deliver the low priority scope items. That's what I would do. That's what a good Agile project manager would do,
Shane Gibson
That's what a good Agile practitioner would do is say, okay, we want to change something? What do we need to do to achieve it? In reality a lot of the time they'll go, that's too much, do it for less, then we're like, cool, what don't we want done? I want all of it and I want it for less.
Murray Robinson
You've got to say no. Project managers are trained in saying no.
Shane Gibson
Isn't that what a product owner does? Don't they negotiate with the stakeholders and say, Well, we're not going to get all of that, given the constraints you've provided. Let's work on what we're trading off.
Murray Robinson
In a very small project with a small team, the product owner can take on those 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 is risk management, and also negotiation with the outside the rest of the organisation.
Shane Gibson
Oh, hold on, I gotta go bullshit on that. I've never met a project manager that does risk management. I've read many project managers that do risk facilitation. I like that. Again, they facilitate the approach or the framework or the way of working to say, how do we identify the risks then how do we manage the risks? They effectively coach the team on what a risk is, and help the team understand how they're going to mitigate it. But a project manager never deals with the risks themselves. They put it in their stupid spreadsheet and then report it with one of those stupid colour things.
Murray Robinson
A project management role is a facilitation role.
Shane Gibson
I disagree because nine times out of 10 I see a project management role is a control role.
Murray Robinson
Risk and issue management is the most important thing that the project manager is supposed to do. Whether they do it or not is another question. If there was a risk, I would ask the team, what do we think of the risks, we would have risk workshops where we would brainstorm what the risks could be, and I would put them in a backlog. We can use a backlog for risk. We can identify them, prioritise them by value and the size or impact, and have a risk backlog which we invest in. Then 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. Then those activities can go into your backlog, and we can do something about it. I often found that issues would derail a project. There'd be a risk that wasn't expected. A critical thing for a project manager is to resolve that issue with the team and with other parts of the organisation as quickly as possible, because they get worse.
Shane Gibson
But isn't that part of the Scrum master role? That when the team is blocked by something outside the control of the team, the Scrum master helps facilitate with the wider organisation to unblock that problem. Isn't that what Scrum masters need to do?
Murray Robinson
Your assumption here is that Agile equals Scrum, which I don't agree with,
Shane Gibson
No, I'm saying in a Scrum approach. Is that what a Scrum master is meant to do?
Murray Robinson
The Scrum Master is supposed to escalate blockers that the team raises. The team identifies blockers and the Scrum master will go to stakeholders and try to resolve those blockers with the stakeholders. the team can move forward.
Shane Gibson
Let's say we go down a lean or a kanban approach, which I'm weaker on than Scrum. Who's the person that helps the system unblock? Is it the team that does it, or is there somebody who has a role to help when it's outside the control of the system or the flow?
Murray Robinson
In Kanban it's unclear. Kanban doesn't have all of these defined roles like Scrum. Kanban is more of a process, and philosophy, like lean. But generally, it's assumed that there's a manager in there somewhere that we escalate things to, they could be an operational manager, or they could be a project manager or product manager. then that person goes and resolves it. The team has responsibility for identifying issues and raising it with a manager who is outside the team to get them resolved.
Shane Gibson
But they don't manage, do they facilitate. Maybe that's one of the things,
Murray Robinson
Facilitation is part of management. It's a core skill.
Shane Gibson
Facilitation is part of leadership. But again, you'd have to agree that when we use the word manager, nine times out of 10, we adopt the command or control behaviour with that term.
Murray Robinson
No, I don't think it has to be like that. That's an old fashioned view of management. A modern view of management is that managers are leaders, not command control police. There are plenty of command control authoritarian managers but it's not supposed to be like that anymore.
Shane Gibson
No, it's not meant to be. But again, that behaviour when we use that term, comes with all the baggage. Why don't we change the term? Why don't we call them leaders, not managers, and why don't we call work something other than a project?
Murray Robinson
Because that's confusing. I think that the term manager is not going to go away and the term project is not going to go away. I would like to start calling them Agile projects and Agile managers and leaders. Leadership and Management are not the same, but a manager should be a leader and a leader should be a good manager. They are overlapping sets. we can be one without being the other. though that's a bad idea. A leader is a visionary and a people focused person, a leader without management skills will need to have managers who do that stuff for them.
Shane Gibson
Do what stuff?
Murray Robinson
Organising stuff, Shane.
Shane Gibson
But isn't the team self organising? Are they empowered to solve problems?
Murray Robinson
That's fine when we've got five people, but it's not fine when you've got 20 people or 100 people or 1000 people.
Shane Gibson
Is it a scaling problem? Are we saying that we need these roles when we're scaling and we have too many pods, and we're getting the usual problem of collisions between the teams between the pods?
Murray Robinson
I would say it's largely to deal with scaling. Yes. For example, I don't think a project manager is needed if we have a small Scrum team. the product manager, and the Scrum master can do the project management stuff between them. A project manager is going to get in the way for one Scrum team. But when we have multiple teams, and when we have other parties, who need to do things like vendors and other departments in your organisation, then a project manager can be very effective. typically, other people like your product manager doesn't have the capabilities to organise all that stuff and neither does the ScrumMaster
Shane Gibson
To use your words against you. They could. There's nothing stopping us having a product owner that has those skills. I'll give you one thing, I see a project administrator having high value, when part of the organization's working in an Agile way, and the rest of the organisation is not, when we have your classic PMO. I see high value in a project manager slash administrator, taking the outputs from the team, and turning them into all those crappy reports that nobody looks at, that they spent half a week doing to tick the box that the crappy report was produced for the PMO. I see high value in them taking that crap work off the team. I'll give you that one. But again, I still think the traditional behaviour of project managers has no value.
Murray Robinson
There is a place for project administrators. But, then project administrators are doing standard processes. They don't do things like negotiate with stakeholders or remove blockers or get the team extra skills and resources that they need.
Shane Gibson
So, if we say that in Scrum, Scrum Master removes the blockers, the Product Owner deals with the stakeholders. then getting extra resources is an interesting one. Does a product owner go and ask for more resources to come into the team because they're needed? Or is that a different role?
Murray Robinson
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. 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 organise, to achieve something.
Shane Gibson
But what I'm saying is if we adopt the Scrum roles and the Scrum behaviours, then we've got gaps. Is what you've said?
Murray Robinson
There's definite gaps, particularly when we're scaling. But let's talk about a situation where we're not scaling first. I want to go back to the Scrum master resolving blockers for the team. Because I have found that generally, Scrum masters are too junior to do this within an organisation.
Shane Gibson
We can't say that because people think a Scrum master doing a two day lovely fluffy certification, and they get thrown at a team as an expert is good behaviour? We can't say that because Junior people put in those roles, and we don't support them and coach them to be effective, that role shouldn't do that task.
Murray Robinson
If I was a Scrum master, I would be able to do it but I've got 20 years of experience in dealing with stakeholders in major organisations and resolving issues and blockers. I find that most Scrum masters are completely unable to resolve or remove blockers for a team. Usually what happens is that they'll raise them with the manager. Then they'll expect that manager to resolve it for them, but then it doesn't get resolved.
Shane Gibson
In your theory, the people they raise it with is the project manager.
Murray Robinson
Let's say there's no project manager, the Scrum master will raise it with somebody else, an operations manager. that person may or may not do something about it, but I would prefer, if we'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 the understanding of technology in business.
Shane Gibson
I suppose part of my frustration comes from the fact that in my experience, project managers don't tend to be servant leaders.
Murray Robinson
When I talk about an Agile Project Manager, they are very much a servant leader.
Shane Gibson
we're saying that if we're a project manager, we aren't a servant leader. But if we're an Agile Project Manager, we are a servant leader.
Murray Robinson
I would make the distinction between a command control project manager and a servant leader project manager. We could be a servant leader project manager without doing Agile. In the old days, we still occasionally got somebody who was a servant leader type of person in the role. But Agile demands that we have a servant leader mindset and approach. That's what we need. In fact, Agile is asking for all of the managers in the organisation to be servant leaders all the way up to the top. if we have a servant leader project manager, and the person they're reporting to is a command control jerk, then everything will get blocked there.
Shane Gibson
I agree, we should talk in another podcast, about the danger of getting a team to be Agile when the organization's not, and all the horrendous stuff that happens. But let's go back to this project thing. are we saying that effectively a project, the definition of a project is when the team's allowed to show up, throw up and bugger off. Because they're there to achieve the outcome, they're not there to achieve new ways of working, organisational change, servant leadership, all those good things. An Agile way of working is where we're changing the way the organisation behaves and works, while still trying to achieve an outcome that the project was meant to deliver. Is that what the definition is, and therefore, we can have people that are good at both. But that's the difference between a project and an Agile piece of work.
Murray Robinson
I've found what you said very confusing. I'm trying to parse it
Shane Gibson
I'm confused. Because again, it's semantics. What is a project and what is not? What is a project manager and what is not.
Murray Robinson
A project is like we're going to land on the moon at the end of 1969. JFK said, that's a project, it's got a clear goal. It's got a time frame, it has a budget, and people working together in a very focused way to achieve it. That's what a project is, we can do a project in an Agile way, or we can do it in a waterfall way. What I'm arguing is that we should do projects in an Agile way. if we do, they'll be much more effective. 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 Gibson
It's PMI, isn't it? That took over disciplined Agile in terms of the collateral and the approach
Murray Robinson
And also the flex approach they've got Scott Ambler and Al Shalloway, the people behind Flex. But, there's a lot of lean kanban stuff in there now. The Project Management Institute has got Agile project manager certifications, and career streams and all that stuff. I'm quite supportive of it. The people who are doing that stuff, particularly in the organisations that they've acquired, are very good.
Shane Gibson
Are we saying that the poor old project manager and the PMI have done a disservice, because those of us on the Agile bandwagon use them as the baddies by saying all they ever did was waterfall. when in fact, they were 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 behaviours.
Murray Robinson
Project management in the 80s, and 90s, it went through this period of being extremely command control, extremely process, document oriented and extremely waterfall. But it didn't have to be like that. That's the direction that the project management community went in as they became this discipline or this institution. They went off in this authoritarian command control direction. Then Agile rebelled against it. The Agile Manifesto is saying things like, we value individuals and interactions over processes and tools because we're dealing with a whole lot of people who are completely focused on processes and tools. We value change over following a plan because we are 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 bad, in my opinion. Then Agile rebelled against it. A whole lot of people who were project managers, like me, were very frustrated with traditional project management and saw Agile as being a real Lifeline, and incorporated it. There's definitely an option now for project managers to do things in a real Agile servant leader way. But I have to agree with you, Shane, that a lot of people don't.
Shane Gibson
So, coming to the end of the session. The takeaway for me is that command control people tend to adopt a lot of waterfall practices. There are servant leaders who adopt a lot of the Agile approaches and ways of working and thinking and mindset. I still stick by my statement that the majority of the time I meet a project manager, they fall in the command control and waterfall camp. Therefore, that's why I don't like the term because I don't like the behaviour that I see come with it nine times out of 10. Maybe that's the type of work or deliveries that I work in. Maybe it's the type of organisation, maybe it's a New Zealand thing. But hopefully it will change over time. But I still think that people who go on to one of those job boards and ask for a project manager are asking for that command control waterfall type behaviour at the moment.
Murray Robinson
Well, I've been looking at those boards recently and there's quite a lot of jobs advertised for programme managers and project managers that say that Agile is very important and they're working in an Agile way. There's others that are clearly saying no, it's all got to be Prince 2 and staged delivery. They don't call it waterfall, they call it staged delivery or the systems engineering or system development life cycle. Prince2 is very much like that. But, there's definitely three camps. There's the traditional hard arse waterfall authoritarian project and programme managers. There's still a lot of them around. Then there's a significant camp, but a smaller camp of project and programme people who are Agile servant leaders. Then there's the biggest camp, the people in the middle who are confused, and who are trying to do both somehow. The combination is not good. We're much better doing one or the other. I see a lot of water-Scrum-fall around. That's the common thing in the corporate world where we're doing things in a staged way with authoritarian management, but each stage is done with Scrum teams. We're going to have a design phase, and in the design phase, people are going to work in Scrum teams, in iterations to produce user stories.
Shane Gibson
Well, they're working in Agile Release Trains.
Murray Robinson
Don't get me started on SAFe .
Shane Gibson
I'm going to be more tolerant of using the word project at the moment because I can see where you're coming from, all people in the IT world, we should make up a completely new word. There's no project or iteration and try and coin it and write a book on it. But until we do that we keep using the project. I'll keep using a piece of work that has to be delivered. We can move on to the next argument next time.
Murray Robinson
Okay. Thanks, Shane.
That was the no nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help with Agile contact Murray at evolve co that evolve with zero. Thanks for listening.