The construct of a “project” is embedded in the DNA of most development and maintenance organizations. That is regardless of whether a project is the best mechanism to group work, because, in one form or another, it is a nearly universal concept. Developing a common understanding of what a project means in an organization is an important if you want to discuss how work is done. Often people believe, falsely, that he adoption of Agile has disrupted this common touchstone so that communication between Agile and non-Agile groups is problematic. The Project Management Institute (PMI), which provides a common project management certification, defines a project on their website as:
“… 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.”
Agile adherents might use different words in their definition, such as substituting the term time boxed for having a start and end date and aimed at a specific goal for the term defined scope, but these substitutions do not materially change the concept of a project. The concept of a project seems to be independent of whether a team is using Agile or not. To test this hypothesis, I asked a random group of colleagues the following question:
I know there are technique differences, however do you see any conceptual differences in the definition of a project if you are using Agile or not?
The typical answer was that there should be no conceptual difference. However that “no” was almost always followed by a “but”. For example, Mary Prendville (SF Federal Reserve Bank) responded, “Conceptually no, but culturally yes.” Generalizing Mary’s response in light of the majority of respondents: there should be no difference in how a project is defined between Agile and non-Agile on a theoretical basis, however practitioners perceive that there is a difference between theory and reality. The respondents “buts” were centered on two ideas. The first was the perceived flexibility in an Agile project’s treatment of scope and the second focused on project management attributes such as transparency.
The first “but” was that Agile projects can have a less defined scope than projects following the more classic PMI definition. For example, Mauricio Aguiar, President of ti MÉTRICAS, responded “I would say not having a fixed scope in Agile is a conceptual difference.” The basis of this perception can be traced to one of the two primary release management strategies typically leveraged in Agile. Agile projects often leverage a release strategy in which the team size and release duration are fixed. Therefore scope is varied. A simple example of this strategy can be seen when a Scrum team deploys functionality into production at the end of each sprint. A specific example might be when team of 7 people release completed functionality into production at the end of every sprint. Because team members are not machines and work items vary in size and complexity, the amount of work that is completed will vary. The second release strategy fixes scope and team size while allowing duration to vary. The use of the first release strategy feels like a deviation from the classic PMI definition of a project; however when Mauricio and I discussed his response we ended up recognizing that in reality we had seen many standard projects use far less transparent techniques to vary scope. These techniques often include quietly cutting scope or spinning work off into follow-on projects. I suggest that scope is often varied to meet dates regardless of the framework used to deliver business value. This perception could be construed as difference in the definition of a project, albeit the difference is not huge.
The second perceived type of difference identified in the responses focused on project management attributes. Chris Vedete of The Carlyle Group stated his perception of the differences specifically, “Conceptually it is the transparency, feedback and tangible software.” Scrum, the most popular Agile technique, is built on the three pillars of transparency, inspection and adaptation. While classic project managers would argue that all project management techniques include those components, it should be noted that Scrum and other Agile techniques identify these attributes as core principles rather than outcomes of other attributes. Focus generates, at the very least, a perception of difference in behavior. The second category strays away from illuminating precise differences in the definition of a project to highlight differences in how people act when leveraging Agile techniques. This second type of differences, those related to project management attributes, does not reflect a difference in the definition of the word project.
In the end most of the difference is perceived. Where there are differences, such as different release strategies, these are often more a transparent reflection of how all projects really work. Kristie Lawrence, President of IFPUG, put it succinctly, “Conceptually no (there is no difference – ed.) – they both deliver working software, they both have teams of people working on them, they both have customers.” In Agile the definition of a project does not substantially differ from most common definitions. Therefore practitioners – whether using Agile, scaled Agile or some other set of techniques – should be able to develop a common language using the concept of a project.