The Key to Meeting Deadlines in Agile: Why Adding More Capacity is Not Enough

One of the first signs that a project is in trouble is that milestones aren’t met and deadlines get blown. When that happens, most project/product managers start adding capacity to get back on track.

But consider: When was the last time you were on the freeway in the middle of a traffic jam and thought that the only way to get anywhere faster was by...adding more cars?

If deadlines are not being met, one of two things is the case: Either the deadlines were unworkable to begin with, or the current structure and workflow of the team was not suitable for the task. If you have the latter problem, adding more people to the mix will only make matters worse. You’ll end up with feature creep, low accountability, frustrated stakeholders, and exploding budgets on top of those missed deadlines.

When it comes to software, Frederick P. Brooks (author of The Mythical Man-Month) summed up this sentiment nicely: “Adding more talent to a late-stage software project makes it even later.”

So, if adding outside help to your teams is not the answer...what other options are there?

First, Understand that Agile Loves Deadlines

When we talk about outsourcing agile software development with our prospects, we often find there’s a misconception: Our customers believe that agile means, in part, that there are no deadlines.

Nothing can be further from the truth. When we apply an agile framework to our own work, we live and die by deadlines. That’s the whole point of having software development by subscription.

Being able to hit deadlines, though, often takes a different approach from traditional project management. That is what an agile framework has to offer. If you can make those adjustments internally so your teams can start producing, great. But if you are going to go the outsourcing road, keep in mind that the point is not to add more warm bodies. The point is to bring on people who are experts at organizing teams in this way.

In what follows below, we’re going to (continue to) use the example of outsourcing to an agile software development firm that understands how to bring this framework to software products. But it’s worth saying that this approach can work for all sorts of products, not just software.

It’s All about Workable Software

What were your original goals in producing the product in question? Maybe you’ve hit the wall with an off-the-shelf solution. Perhaps that great idea was too ambitious, and you’re struggling to hit milestones that are no longer applicable (or, for that matter, important). Milestones and timelines often distract development teams from the real purpose of their work (which is, lest we forget, to deliver useful software).

If you’re managing an expensive disaster, maybe it’s time to stop throwing more money and bodies at the problem. Stop worrying about trying to save the project, and refocus on the product.

The first goal for an agile team should be an MVP, or minimal viable product. In other words, when the team is done, they should have a working software candidate. Getting that up and running is more important than achieving a lofty vision of what the product could be.

That will change what your team prioritizes. Consider a house: If the roof is leaking or the foundation is falling apart, you don’t add an extension to the house. You first fix the leaks and shore up the foundation to make sure everything doesn’t collapse onto itself. A small but livable house trumps a large unlivable wreck every time.

Addressing Skill Gaps

While piling on people to a project is not a wise idea, it is OK to add a person if said person has a skill the team currently does not. Successful product managers and IT leaders know how to take a step back and be realistic about asking for help; while that process can be humbling, it beats the alternative of saying nothing. Outsourcing needed skills isn’t admitting failure. It’s finding a new way to move forward. 

For example, your team might need specific help with CI/CD pipelines. Or containerization. Or cloud migration. Or re-engineering legacy code. These are all areas where it makes sense to bring on additional help for specific things. Partnering with the right agile software development provider can help get a project back on track by facilitating skill gaps.

Getting into an Anti-Project Management Mindset with DevOps

You might have noticed that many of the above skills are part and parcel of a modern DevOps approach. DevOps integrates agile and lean practices into product development. By having all needed stages under one roof, it becomes easier for small teams to execute quickly and bring products “live” faster.

In other words, getting to MVP and hitting deadlines in an agile environment is easier to meet with productive, well equipped DevOps teams. Yes, that requires bringing the necessary talent together. But it also requires the right kind of organization—or rather, the right kind of leader to let that talent self-organize.

So...More Agile? More DevOps?

Let me stop you there. If you are still thinking in terms of “so we need more….,” you’re not going to put out the fire. You’re still in a mindset that is telling you the project needs more quantity. My point here is that, 98% of the time, the issue isn’t quantity. It’s quality—specifically, the quality of the organization that makes hitting deadlines in agile possible.

The key to meeting deadlines, then, is working with people, internally and/or externally, who understand that.