Every time I use the term ‘Project’ in front of an Agile team, someone has to tell me that ‘project’ is no longer the right term to use. In some cases, I am reminded that projects are dead and no longer applicable in the 21st century. Personally, I totally disagree with this belief. Projects are here to stay and they will be applicable for a long time to come.

Let’s first start with PMI’s definition of a project:

A project is a temporary endeavor undertaken to create a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.

We can clearly understand from PMI definition that a project has specific definition – scope, a beginning, and an end.

The main Agile’s argument relies on the fact that agile team works on Product and not on project. However, the team works on multiple releases for a product, with set start and end date, and a defined scope for each release. You might find an agile team working on the same product for so many years, yet they work on different releases, features, and epics. In a nutshell, the team has been working on multiple projects. Let’s take Android development as an example. Agile team has used different code names instead of releases or projects. Android code name like Pie, Oreo, Nougat, Marshmallow, and Lollipop are few examples. Each of these code names was most likely a “temporary endeavor undertaken to create a unique product, service, or result.” In other words, each code name was a project.

One advantage of Projects is that they provide a mechanism to accomplish something bigger than could be done in a single iteration. They serve as ways to group common work and provide a real goal for teams working on them. Furthermore, Projects facilitate communication about related functionality.

Agile approach focuses mainly on short term goals. Product owner generally selects the most important user stories each iteration (or PI in the case of Scaled Agile), running the risk of addressing short term goal instead of long term one. Agile team and product owner will be tempted to select urgent items that customers are in need today rather than important items that will deliver more value over the longer term. In contrary, project mitigates this risk by keeping the team focused on the long term work of the project while addressing the short term need of the customer as support items.

In summary, projects remains an important unit of work. Becoming agile does not mean we need to throw out everything we’ve learned over the past 200 or so years of doing project management. Some things remain valuable. Agile team should benefit from all the knowledge gathered by project team and stop being sensitive about the term ‘Project’. Every release, code name, or PI is a project with a specified start and end date.

What do you think?

Does your organization still use the term project even though they are using Agile? Are you sensitive about using the term project? do you agree or disagree with me? Then Please share your thoughts in the comments below.