I recently read a couple of articles over on about Project Management. The first article I read was a rebuttal of the second, so I had to spend some time catching up before I could fully understand the first one. The article that caught my attention was  by Yvette Schmitter. I expected to say pshaw several times but found some of her thoughts very cogent and on-point. But since it was a rebuttal, I had to go read the original article –  by Steven Lowe at ThoughtWorks. Both are interesting reads but I think both miss the mark – sometimes by a fair amount.

First Up – Why Project Management is Bad

We’ll start in the opposite way I did – with Steven Lowe’s article about why project management is a problem. He describes several different antipatterns that typical project management engenders. I agree that some of these items can result in project failures. But one thing that Lowe wrote stands out to me – following a plan is the most important thing.

I see project management go bad when everyone tries to adhere to a plan over all else. One of the four main principles of the agile manifesto is “responding to change over following a plan”. But I find that project management tends to fail most dramatically when a “fixed date and fixed scope” approach are the main goals.

But Lowe writes in the article that deadlines are unimportant. I disagree with this approach as business does have deadlines – trade shows, holiday delivery dates, etc. So deadlines are important. But what we want to focus on – from an agile perspective – is maximizing the value we can deliver before that deadline. That’s why a prioritized backlog is critical. It’s why the business needs to guide the team on the path to maximize value. And this business responsibility is something Schmitter argues in her article.

And next – Why Project Management is Good

Traditional project management still has some good elements. The two main ones are the investigation that occurs at the beginning of the work and the conversations that happen around dependencies and “sussing out” risks and “gotchas”. Both of these have some corollaries in agile.

Good project managers are very pragmatic. They understand that life can get in the way and the “best-laid schemes o’ mice an’ men “. This is why they create buffers and over account for engineering estimates. There are a number of tricks and techniques that good PMs use to help keep projects on track.

Exploring the project space at the beginning of a project gives us a vision and an idea of what that solution looks like. We get a common understanding – and that’s a critical element. Some of the artifacts from these initial meetings, including a project charter, should be considered for any project a team works on, regardless of whether they’re doing agile or not.

The other element is the investigation around the dependencies and risks. These conversations help teams understand the problems they may face and work through potential solutions early.

My Thoughts on the Articles

So I said that I thought that the articles were interesting reads but missed the mark. Why? In Lowe’s case, it’s because he overstates some of the emphasis on accuracy of estimating and the need to track to plan. Many, many project managers I know understand the inaccuracy of estimates. In fact, there’s a project manager adage to “double all engineer estimates” and many project managers create buffers. So I wouldn’t say that many project managers I know are focused on “accuracy” of those estimates but rather on getting an “idea” of the estimates.

Schmitter’s article argues for the project management role as critical and places much of the blame for poor product deliveries on the business for failing to prioritize the work and identify what’s most important to the customer.

There is one thing that both articles fail to address – our customers don’t often know what they want. Customers have needs but are very bad at turning those needs into things we can build. Or they’re too specific (“I want a button to go here that does this”). Good product managers or product owners should be able to identify customer needs, not wants, and work with delivery teams to meet those needs incrementally.

Related to this is the underlying belief that we can have perfect foreknowledge of the product. This is why we have the “cone of uncertainty”. Rather than plotting out an incremental course through the solution space, we try to identify some ideal point in the future and then plot to it. Our product needs to develop incrementally so we can find the best solution for our customers, not work toward what we decided was the perfect solution for them months in advance.

One More Thought on Risk

One final thought on project management in general. People often struggle with the idea of addressing risks iteratively in agile implementations. They think that teams can’t appropriately identify and resolve these risks in an iterative fashion. This presupposes that software isn’t easy to change – which it is. It is something of a new skill, but teams can – and should – develop this skill. And be ready to adapt to change as it happens. This is normal, but it is uncomfortable. Building competency in refactoring – or even rewriting – software is the key to making this successful.

@ Velocity

We work closely with our clients to help establish a prioritized backlog. I’ve used story mapping with some clients to help them create a top-down understanding of their product vision and then turn that into stories the team can use. And there are times when we work with a client who tries the fixed-date/fixed-scope approach. We have some great solutions managers who work with those clients to understand the limitations of this approach. And to help understand how our coaches can help them understand the mindset and changes agile requires.

Closing Thoughts

When I think about traditional project management (and I was a project manager), I think the main fallacy is the belief in perfect (or “good enough”) foreknowledge. That we can – somehow – know months in advance what product will best meet our customers’ needs. For some products, it’s easy to understand why we come to this conclusion. But I feel it’s much like the who hit a target from over 3 kilometers away. The bullet took just under ten seconds to travel from the gun to the target. What could have happened in that ten seconds? Practically anything. Birds, wind gusts, minute miscalculations, etc. So why do we think we can hit a similar target months (or over a year) away correctly? We’re setting ourselves up for failure. Why not find a way to move closer to the end product solution by taking small steps toward it continuously? That’s the essence of the agile approach.

 Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)