Over a million developers have joined DZone.

Is It Time to Stop Thinking About Projects?

DZone's Guide to

Is It Time to Stop Thinking About Projects?

In most software companies nowadays, development efforts are continuous, with no foreseeable end date. Are traditional projects dead?

· Agile Zone ·
Free Resource

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.

For at least 15 years, I’ve heard people say that projects are dead. Projects and project-based thinking are relics of the 20th-century.

I don’t buy it. Let me explain.

Let’s start with the definition of a project. The Project Management Institute (PMI) defines a project this way:

A project is a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates that a project has a definite beginning and end.

The general argument against projects is that work is more continual now. There is no “definite beginning and end.” And many endeavors we might call project do not have a “temporary nature.”

As an example of why we might think projects are dead, think about a developer with a freshly earned university degree. The developer gets hired at Google and is assigned to the AdWords project. The developer then works on AdWords for the next 40 years.

Has this developer worked on a project? After all, a 40-year career spent on AdWords was not of a “temporary nature.” And there was no “definite beginning and end” other than the beginning and end of the developer’s career on the same product.

Yes, that’s true. But during our developer’s 40-year career on AdWords, there were undoubtedly initiatives or milestones that were focused on.

For example, Google occasionally overhauls or significantly enhances its ranking algorithms. Past algorithm updates have been given names like Penguin, Panda, Pigeon, Pirate, and Hummingbird. Each of these updates was likely a “temporary endeavor undertaken to create a unique product, service, or result.” In other words, each was a project.

Did each have a definite beginning and end? Perhaps not. The ease with which software can be released today (especially for web-based products) often blurs start and stop dates of projects. An initial release is made and then, for example, is quickly updated over the next few weeks.

But, for all reasonable purposes, our developer’s 40-year AdWords career can be thought of as having been split into a series of shorter projects.

Why This Is Important

With any iterative and incremental process such as Agile, there is a risk of delivering less value than possible because of focusing too much on the short term. When product owners are told to select the most important things each Sprint, they can be tempted to select urgent items that customers are screaming for today rather than important items that will deliver more value over the longer term.

Projects mitigate this risk. Projects provide a planning horizon that is longer than a Sprint--typically in the range of two to six months. This “definite beginning and end” that is focused on a “unique product, service, or result” encourages product owners to select truly important things to work on rather than whatever some customer or salesperson screamed about yesterday.

I always encourage product owners and their teams to identify a milestone they are working toward that is longer than a single sprint. I like doing this quarterly, but other cycles can work equally well. The project, then, is the temporary pursuit of that milestone.

Projects remain a useful construct. They provide a motivation to accomplish something grander than could be done in a single iteration. Further, they serve as ways to group common work and provide a tangible target for teams working on them. Projects also facilitate communication about related sets of functionality.

Projects aren’t dead yet and I don’t see them going away.

What Do You Think?

Does your Agile team organize work in projects (temporary endeavors in pursuit of an objective)? Have you experienced the sub-optimizing I’ve described when product owners look ahead only one iteration? Please share your thoughts in the comments below.

Take Agile to the next level with DevOps. Learn practical tools and techniques in the three-day DevOps Implementation Boot Camp. Brought to you in partnership with Techtown.

agile ,sprint goals ,product owners ,iterations

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}