What is an Agile Project Leader?

(translations: Turkish)

I wrote this article because of two observations:

1. Many organizations use a “project model” when they shouldn’t.
2. There is a lot of confusion and debate in the agile community about projects and project leadership.

I don’t claim to have “the answer”, but I’ve thought about this a lot and also experimented on my clients (don’t tell them… sshhhh). So, here is my take on project leadership in an agile context.

Oh, and by the way, this article is a Bait & Switch. I’m trying to get you to read What is an Agile Leader. You might save time by just skipping this and going there right away 🙂

Beware of “projects”

The word “project” is controversial in agile circles. Some companies use the “project model” as some kind of universal approach to organizing work, even for product development. However, a surprising number of projects fail, some dramatically. I see more and more people (especially within the software industry) conclude that the project model itself is the culprit, that it’s kind of like rigging the game for failure.

A “project” is traditionally defined as a temporary effort with a temporary group of people and a fixed budget. Product development, on the contrary, is usually a long term effort that doesn’t “end” with the first release – successful products start iterating way before the first release, and keep iterating and releasing long after. And teams work best if kept together over the long term, not formed and disbanded with each new project. Also, the traditional approach to planning and funding projects often leads us to big-bang waterfall-style execution, and hence a huge risk of failure because of the long and slow feedback loop. The project model just doesn’t seem to fit for product development.

I’ve spent many years observing and helping companies improve the way they develop products, and the trend is very clear – less project focus, more product and team focus. Seems to work a lot better! So it’s no coincidence that “Projects” and the “Project Manager” role are absent in the most widely adopted agile frameworks such as Scrum, Kanban, XP, and SAFe.

What about project management?

So what happens to project managers then? Aren’t they needed?

Wrong! Project Management hasn’t disappeared, it’s just been redistributed. The thing we are managing is a product, not a project, and management is too important to leave in the hands of a single person. In Scrum, for example, the project manager role was deliberately split into two separate roles – Product Owner (focusing on the product), and Scrum Master (focusing on the team), and the team manages itself rather than “being managed” by a PM. So most of “project management” still happens but in a different way – mostly decentralized.

What about projects? Should we abandon that model entirely?

No, don’t abandon projects entirely, just shift the default. In particular for product development, projects should be the exception, not the norm. In a typical agile context (Scrum, XP, Kanban, Continuous Delivery, etc), the project model and project manager role is often redundant and will slow you down.

But wait – what if you’re going to do something that requires a coordinated effort across many teams from different parts of the company that don’t normally work together? What if you have lots of external and internal dependencies, content licensing, hardware procurement, external vendors, regulatory compliance, and offices in multiple time zones?

THAT might be worth treating as a “project” – especially if it is a temporary effort rather than something continuous. Basically, if the whole thing has a “definition of done” then maybe it’s a project.

However, regardless of whether you call it a “project” or not, if it’s big and complex you will need a leader. And if you want the work done in an agile way, you’ll need an Agile Leader (or Agile Project Leader if you prefer). Doesn’t much matter what you call the role, there just needs to be someone at the helm (or a pair, or a small team fulfilling the role).

• Myth: “But we’re agile and self-organizing, all these teams will magically coordinate with each other and stay aligned without a leader!”
  • My experience: You’re probably kidding yourself. Or maybe you are a rare exception.
• Myth: “Project Leader means top-down micromanagement and big-bang waterfall processes.”
  • My experience: Only if the project leader doesn’t get Agile. Get the right person for the job (this article will hopefully help!)
• Myth: “All projects have to be agile”
  • My experience: Not necessarily. If the work is complex and innovative, then yes. If repetitive we’re-cranking-widgets-and-we’ve-done-this-dozens-of-times-before, then probably not. Most product development falls into the first category. But I’m biased though, I’ve worked mostly with innovation-driven product companies.

So, in short: don’t use projects for everything – but when you do, make sure you have an awesome Agile Project Leader!

So what is an Agile Project Leader?

This started out as a fairly long article. Then I realized that the role I was describing was really about agile leadership in general, and not specific to the project model at all.

An Agile Project Leader is really just an Agile Leader that happens to work in a project context. So I moved that role description to a separate article, so as not to scare away people who are allergic to the project model 🙂

• What is an Agile Leader

Hop over and read that article, and mentally swap in the word “project” wherever it makes sense. Told you this article is a bait & switch 🙂

There are some things that may be different in a project context – for example the “change agent” aspect. By definition, a project is something different than your “business as usual” work, and most likely involves collaboration between teams and departments that don’t normally work together. Unfortunately, since we’re dealing with people, this usually means some amount of politics and diplomacy. Hence, a project leader needs to deal with organizational (and cultural) boundaries – either breaking down the boundaries or improving collaboration across the boundaries. That’s a tough job, so don’t forget to give your project leader a pat on the back from time to time.

Final words

I hope this article (and the other one) helps you improve the success rate of your projects, regardless of how you solve the leadership issue! And don’t forget – despite all the talk about projects in this article, always start by asking yourself if you even need a “project” at all.

Big thanks to Alistair Cockburn, Mary and Tom Poppendieck, Anders Haugeto, and a bunch of Spotifyers and Crispers and Legoists who helped improve this article. I’m honoured to have such an awesome group of advisors!

Note that this my personal opinion, my take on what an Agile Project Leader is (or should be). Some people may disagree, that’s fine. I’m also happy for feedback, although I won’t always be able to respond.

…

(Why are you still here? Go read What is an Agile Leader!)