(Note: I gave a presentation at the Agile Tour Brussels in 2014 entitled “How NOT to scale Agile”. In it, I touched on some key things that any company serious about doing Agile should NOT be doing. Basically, I decided to use the via negativa approach popularised by Nassim Taleb and apply it to the Agile scaling challenge. I will use this blog post to focus on one of the points I raised in that presentation - projects.)

“We are largely better at doing than we are at thinking, thanks to antifragility. I’d rather be dumb and antifragile than extremely smart and fragile, any time”

— Nassim Taleb, "Antifragile"

“You don’t need a weatherman to know which way the wind blows”

— Bob Dylan, "Subterranean Homesick Blues"

Any organisation serious about Agile should stop doing projects. There, how’s that for an attention grabber? Shock value aside, I do stand by that sentence. The key to it, of course, is how you define the word “project”.

So let’s start by defining projects for what they are in reality, not what they could be in theory. Then I can explain why I think we should stop with them.

Project: (noun) A temporary, collaborative undertaking that has a singular goal, defined scope and resources, and is carefully planned upfront and expertly managed to deliver on-time, on-budget results.

I didn’t coin this myself, just put together 2 or 3 definitions from online dictionaries and from the Project Management Institute (PMI) website. Still, it encapsulates pretty well what we mean when we say projects. So… why are these “projects” so harmful to organisations?

The idea of projects seems harmless, just like a pig with lipstick

This is perhaps the most important issue. If you re-read that definition, you could easily conclude that Scrum can handle a project perfectly well. We can have a defined scope (the Product Backlog), a defined team (the Scrum Team) and a person (the Product Owner) who is responsible to “expertly manage” the backlog (prioritisation, velocity and story slicing) to deliver results on-time and on-budget. See? Scrum (Agile) can handle projects!

The trouble there is that Scrum (Kanban, et al) are about how we build things. So of course you could do deliver a project using an Agile framework. But it misses the bigger picture - Value, with a capital “V”. What we build is just as important as how we build it. And projects have a hard time with the what question because they spend most of their thinking time trying to predict things (budget, scope, and time). Schedule trumps Value in the project world. If you don’t believe me ask a Project Manager (PM) which she would rather have happen to her - 1) delivering a project on-time, on-budget, and on-scope that didn’t bring much value to the organisation or 2) having a project cancelled early because people realised it wouldn’t bring much value.

Take a shot of vodka every time a PM answers #2. My guess is you’ll be able to legally drive home after interviewing 100 PMs…

Projects begets politics, and in politics size does matter

Since value is not the principal part of the equation when it comes to projects, something else has to fill the void. Something else has to sort the pecking order and determine priority. Enter politics, stage left. Exit common sense and focus, stage right.

Politics is the struggle for power, and power typically (with some exceptions) ends up being determined by size. Yes, it’s that childish. So the realpolitik of the world of project work ends up following this simple rule - the bigger your project, the more important it must be (and by correlation, the more important you must be). And this is in direct conflict with what Agile is trying to accomplish inside an organisation. We want to focus on things such as:

the flow of value (value streams)
validating value hypothesis by having small chunks of work that can be quickly done
flexibility, which means pivoting as soon as you realize what you’re doing is not valuable
working on the highest priority, regardless of project or budget code

Also, the bigger a project is, the more complex the web of dependencies and assumptions. Which leads us right into the next issue with projects.

Projects are based on predictive planning and cost-based thinking, concepts as useful and valid as economic forecasts

The old military maxim “planning is essential, plans are useless” (typically attributed to either Eisenhower or Churchill) is a great one. It recognises the importance of some thinking upfront, but also admits to the inherent inability we have to predict. Yet projects continuously ignore this limitation and insist on having planning activities spit out a plan. A prediction.

And here we go, around and around the merry-go-round of fear, guessing and blame. These predictions become baselines against which PMs measure deviations. Everybody knows this. So when people get asked for an estimate, they add buffer because they know in the project world “estimate” means something else than what is written in the dictionary. Otherwise, we would never hear the oxymoron “accurate estimates”. The PMs, of course, know that people are buffering their estimates, so they always challenge the first number they hear. But people know the PMs will do this, so they add even more buffer to their initial estimate. Pretty quickly you have a plan that is meaningless, driven by fear, and based on over-inflated guesses and under-valued assumptions. Then you spend the rest of your time tracking deviation against this “prediction”. And here we go, around and around the merry-go-round of fear, guessing and blame.

Everybody knows this is happening and instead of just putting a stop to it, we try to solve the predicting limitation we have by spending brain power trying to come up with better ways to estimate. Double face palm. This ridiculousness gave rise to the #NoEstimate movement. Look it up, there’s plenty of good info online about it.

But why do we keep doing this? Why do smart people not see this big picture? Probably because if you ever saw a Gantt chart and tried to match that to the “resources” (they mean people) available in your company, you quickly realise it’s way more fun than Candy Crush. It’s the ultimate brain rush. Like playing Tetris but with much, much higher stakes. And so we keep going, like a Korean kid on a gaming binge, high on Red Bull and potato chips… until it all comes crashing down.

Plans make your organisation fragile because they try to predict the unpredictable. Projects make your organisation fragile because they focus on costs, not value. Agile is about exploring positive asymmetric payoffs, which you can only do with value-based thinking.

Projects are based on an outdated understanding of work

Frederick Taylor is the father of scientific management and if we tried to synthesise his theories into one simple concept it would be this - work can be divided into 2 parts, thinking and doing. The former is the work of management, the latter the work of the dumb workers (if you think I’m exaggerating by using the word “dumb”, go read some of Taylor’s actual words; I’m being kind). Project Management is the natural extension of this thought when applied to the complex world of projects. You have few people who are responsible for thinking about the work (planning) and many people who are responsible to execute the plan (workers). The thinkers believe they can predict the future of the project. The workers know they will get blamed when inevitably the thinkers’ forecast turned out to overly optimistic. Ah, the joy of projects!

In the knowledge economy this model of splitting work between thinking and doing simply doesn’t apply. They are inextricably linked. And mixed. Nobody only thinks and nobody only works. Everybody does both. Thinking doesn’t only precede work. Work doesn’t always proceed thinking. Both thinking and working should be done by cross-functional teams in an environment where plans are meaningless and value is king.

Projects are a finite game, survival in the marketplace is an infinite game

Projects have a clear defined end. This is what is known as a finite game. There is no such thing as a never-ending project. Finite games are fun because there are clear winners. The only problem is that this is not how the world works. Organisations don’t win, they survive to play another day. We need a way of organising our work that doesn’t rely on the over-simplification of a finite game.

If you run a marathon (a finite game), cross the finish line first, and die immediately afterwards of a heart attack, you still won the marathon. Congratulations! We’ll be sure to engrave that on your tombstone.

Survival is an infinite game, which is why organisations should focus on having a way of working that prizes value flow and learning over meeting arbitrary deadlines and goals.

Projects favor silos over value streams

There’s another thing that projects fuel - the creation of silos. In the project world, everybody is worried about causing a delay to the critical path. If I know problems are going to come (because the project has a dense web of dependencies and guesses) and somebody is going to get blamed, it is a better strategy for me to build up walls around my area and focus on my part of the project. As long as I don’t screw that up, I’m safe. I don’t care if the overall project fails, I just want to make sure I don’t get blamed for it.

Silos are a safer strategy for people living in a project world and playing a finite game. Trouble is, silos are the kryptonite of Agility and value flow.

Projects are a relic of an outdated work paradigm

See, the basic problem we have in the world of work is that we are smack in the middle of a paradigm shift - where two paradigms are battling it out for supremacy. Bruce Lee style. On the dark side of the intellectual octagon you have the Scientific Management Paradigm, still chugging along after almost 140 years. On the light side, you have a management paradigm that is formed by groups such as Agile, Beyond Budgeting, Radical Management and Lean Startup. We still haven’t coalesced around a name, but for the purposes of this post I’ll call it the “Agility Paradigm”.

As part of this struggle, both sides end up fighting over the meaning of words. And words matter. The dark side wants to incorporate the new, fashionable terms such as “Agile”, “responsive” and “pivot” into its vernacular in an attempt to make people believe the Scientific Management paradigm is evolving. Meanwhile, the light side wants to appropriate some of the words from the old vernacular to spare itself the effort of having to re-write the whole management dictionary. (And also because it’s difficult to sell consulting services if your clients don’t understand what you’re talking about)

“Project” is one of the words caught in this tug of war. The Scientific Management paradigm needs it to remain the central building block for value generation in an organisation. Without projects, a lot of what we see in companies nowadays go away. This is good if you’re in business of change management and want organisations to re-think their culture and processes for delivering value. This is not so good if the existence of projects pays your wages (PMs, PMOs, the PMI, …) or keeps the power structures that benefit you in place. Nonetheless, Agilists are hesitant to denounce “projects” for fear of not being invited to the big boy’s table when it comes to discussing the art of management. This is because despite all the fuss about disruptive innovations, flow, and flat organisations, management thinking is still plagued by the century old predictive fallacy - the notion that we can somehow predict the future of endeavours if we only manage to gather enough data and analyse it well enough. The desperate hope that we’re smart enough to make time travel in the opposite direction. Deep down though, we all know it’s bullshit. But you can’t say it around most managers or big companies. Their job (and yours, if you’re a consultant) depends on the acceptance of the fallacy. The emperor’s new clothes.

This is the central paradox of the consulting industry, Agile or not. We all want to change the world, but we don’t actually produce anything. We support those that do. And it’s a high-risk business model to comment on the nakedness of the emperor. It’s much safer to tell the emperor his new clothes look magnificent. For the service industry, snake oil will always be more profitable than the real thing. It takes principle (and courage) to leave money on the table in order to do the right thing. That’s the key moral challenge of the service industry and, worryingly, one of the struggles that will decide the outcome of this paradigm battle we’re experiencing right now.

So Agilists use projects to get a foot in the door of companies. The concept serves us well - companies doing projects are experiencing the typical problems associated with waterfall and are desperate for something that works. Of course they are. And we convince ourselves that “project” is one of the words we can re-use, one of the concepts we can improve. We convince ourselves that there is nothing inherently wrong with the idea of a project. We convince ourselves projects can be done in an Agile way.

It’s funny what you can do with a word. We try to bend it, shape it, stretch it, transform it. Anything to co-opt it. We’ve tried the good ol’ formula of adding “Agile” in front of the word (Agile Project Management). We’ve tried an arranged marriage (PMI & Agile). We’ve even tried breeding cross-species (Lean Project Management). But in the end, we can’t escape the age old truth that regardless how much lipstick you put on a pig, you’re still dealing with a pig (albeit a confused one who is wondering “dude, why the hell do you keep trying to put lipstick on me?!?”).

I think this is a mistake - a handshake with the devil at the crossroads of paradigms. And you know what the devil does to pigs in lipstick? Turns them into Napoleon. Because the real danger is no longer recognising you’re dealing with a pig. As Orwell put it, “the creatures outside looked from pig to man, and from man to pig, and from pig to man again but already it was impossible to say which was which.”

We can do better. No compromising with the devil. Full honesty with the naked emperor. No lipstick on pigs. No turd polishing or word play.

We can do projects in an Agile world only if we completely change what the word “project” means. Why bother? Let’s just be upfront and honest - no more projects. Let's talk about value streams instead.