We sw-developers tend to think we have revolutionized the entire field of project mangement with the invention of agile. Never again will we have to deal with tedious project managers who have their head so far up Excels backend that they have lost all touch with reality. “Traditional project management” is a swear-word that we can attach to anything we don’t like and automatically it becomes something to avoid. Because agile is the new holy grail and anything “un-agile” is by definition bad.
Much like Winston W. Royce formalised waterfall to describe how NOT to develop software or Marx popularized capitalism as a mean of describing how NOT to run the economy, so have we invented “traditional project management” to describe everything wrong with the world without having to actually be specific about it. When a project goes south, we will blame traditional project managers for not letting us work agile. When priorities are not correct we’ll say “if only we had been agile, we could have corrected this, when we found out”. When plans fail, we say “if we had been agile, we could have replanned in time”.
Lately, though, I’ve found that the distain for traditional project management has become a form of learned helplessness that allows developers, scrum masters and entire teams to blame their own fallacies on the evil traditional project management imposed on them by some not-so-well-defined outside force.
We need to take a step back from the bogeyman that we consider traditional project managers to be and look at it with an open mind. I took a course on project management for engineers (in general) at the university and by the virtue of my girlfriend’s recent (also generalised) project management education, I have to say that agile, really brings nothing new to the table.
For there to be a project, someone must have initiated something that requires a project. Maybe someone in marketing needs an app to support a campaign, maybe upper management wants something in the organisation to change or maybe local politicians have decided to change the something in the way a city’s infrastructure works. The project manager’s responsibility becomes to coordinate the idea with users and stakeholders (both of whom have to be identified first), ensure there is consensus around what needs to be done, why, how, when and which/how many ressources can be used. Then the project manager must assemble and possibly lead a team to do the actual work. A plan for the project’s execution must be made and the project owner needs to sign off on them. Success criteria for the project must be agreed upon. During the project period there has to be constant communication between all relevant parties, stakeholders need to be kept informed, new information must be taken into account and the plan must be kept updated. But there is more. Milestones have to be defined to ensure external dependencies (or other projects dependant on this project) get coordinated in a timely fashion. Risks must be identified and appropriate actions must be taken at the appropriate time. And as parts of the project gets done, the project manager has to ensure it gets properly delivered and accepted.
None of this is in any way in contrast to anything agile. All of these things have to be done and have an agile counterpart (which for the most part is in fact no different from the traditional one). The only difference between traditional project management and agile project management is, that in the agile world, we cheat!
We acknowledge that the project owner is important, so are the users and all the stakeholders. Business concerns have to be met and risks and outside world interferences need to be managed. Project goals, plans (for everyone outside the development group) must be made. External stakeholders need to be informed and their input taken into consideration. Deliveries have to be accepted. If milestones are needed they have to be defined and followed up on. But we want don’t want to be bothered by all that tedious complexity, so we have invented the role as product owner. There has to be a clear product owner who has all the necessary insight, decision making power and time. But we cannot have a project manager, heaven forbid! That would be traditional project management.
Well, if I were to sum up most of my experiences with projects that didn’t go so well, most often the blame falls on the only person who is not really part of the development team aka the product owner. Either he was not present enough, not active enough, didn’t have sufficient knowledge about the subject at hand or [insert your own reason here]. It is always easiest to place the blame on someone else and since the product owner is usually outside the team, the blame falls there.
The odd thing is: all the responsibilities agile project management places on the shoulders of the product owner as something he has to figure out by himself IS in fact what is normally referred to as project management. So in agile, we have basically reduced the entire field of actual project management into “oh, but we are agile, so that’s the product owner’s responsibility”. We have replaced the steering committee, and all the users and stakeholders with a single person. We have replaced the need for a certain level of predictability with “let us work and we’ll get back to you when we have something” mentality. Coordination and due diligence gets address with “if everyone talks together enough, it will sort itself out”. We refuse to plan ahead and insist we cannot be held accountable for anything that didn’t work out like it was supposed to.
Agile methodologies are great for gradually executing work that a team needs to do throughout a project, but it does not provide much of value, when it comes to MANAGING a project, since the management parts either become everyone’s responsibility (and thereby no ones) or get outsourced from the team to be someone else’s problem.
I have worked on successful agile projects that went great without a formal project manager. This is not evidence that project management is not needed, however. When competent individuals meet with a common goal, management is not necessarily needed. The world is full of examples of succesfull self-organistion: a group of musicians can make great music by themselves and kids can play in the schoolyard without teachers telling them what to do. Successful self-organisation exists everywhere, but it is the exception to the norm. Most self-organised activities fail, but it happens so fast that those participating don’t even realise it. They just go their separate was and find something better to do. But we can’t do that in businesses. When project is started it HAS to be carried out. If it can be agile and self-organised then great! The project manager can sit back and watch people do their magic. But most often it doesn’t work out that way and the project manger has to interfere to get things back on track. Only… in agile we will have nothing of project managers, so there is no-one who is responsible, empowered and accountable.
Agile project management is not a better form of project management. It is just a way to pretend that projects don’t need managing. The latest step and even more radical step in this direction is the #noprojects movement, which not only eliminates the project manager, but argues that software development is not a project at all.
Instead of being so afraid of traditional project management, we ought to realise that there is no “traditional” or “agile” versions of project management. There is only projects that need managing. And for this we need project managers with a full set of tools in their toolbox. Not agile project proponents or traditional project managers, who look at the other side with destructive disgust.
So pretty please, with sugar on top, let’s stop digging trenches. Go read that non-agile book on project management or attend a course. The worst thing that can happen is that you get confirmed in what you already thought you knew. But I’m willing to bet that if you keep an open mind, you might actually learn something.