Projects and Agile — a Match Made in Hell?
No, absolutely not!
In the agile community, though, you will most probably have heard statements like “In agile, we do not have projects, only products”.
I disagree.
We have both!
When doing agile product development, you will be dealing with a lot more projects than ever before. Like, a lot more.
Purpose of this article
My ultimate wish is to carve out simple definitions for terms we use in context with agility, to allow us to have better discussions and understanding.
When simplifying things, there is almost always something getting lost. But it also gets easier to recall, understand and use. Finding a good balance is the trick. Or, to use the words of the German philosopher Gunter Dueck: Making it brilliantly simple, rather than stupidly simple. I hope I manage to do just that.
In this article, I’ll look at the words product and project.
First, what is a project?
It’s easier asked than answered. Even the Project Management Institute doesn’t have a clear definition on their homepage, or at least I couldn’t find anything but “Essentially, projects are temporary efforts to create value through unique products, services, and processes”. In the search for something more substantial I came across Wikipedia (“A project is any undertaking, carried out individually or collaboratively and possibly involving research or design, that is carefully planned to achieve a particular goal”) and ultimately asked ChatGPT.
A project is a temporary endeavor undertaken to create a unique product, service, or result. It has a specific start and end date, with a defined scope, objectives, and resources. Projects typically involve a series of tasks, activities, and milestones that need to be accomplished in order to achieve the desired outcome. They are often managed by a project manager, who coordinates the efforts of a team of individuals with various skills and expertise to ensure that the project is completed on time, within budget, and meets its objectives. [ChatGPT]
Sometimes people refer to a sprint as a project, and while that isn’t entirely wrong, it isn’t good enough. A completed project delivers value to the users, and we shouldn’t settle for only delivering value at the end of each sprint (even worse, only at the end of each program increment). We should strive to deliver value, and get feedback on whether we are headed in the right direction, if at all possible, at the end of each user story¹.
Project = User Story
The first part of ChatGPT’s definition of what a project is could work just fine as the definition of the implementation of a user story, or product backlog item, if we were to use Scrum only terminology:
The implementation of a user story is a temporary endeavor undertaken to create a unique objective. It has a specific start and estimated end date. User stories typically involve a series of tasks or activities that need to be accomplished in order to achieve the desired outcome. [Klaus Bucka-Lassen]
Having established that, we can conclude: Agile is not at odds with projects, as a matter of fact, in any given agile product development we will have loads of consecutive projects. Hundreds, if not thousands, of them. Each single user story — if it qualifies as one and not just is a task — is a project in itself.
Any product is brought to life and continually enhanced through a series of projects, ensuring the product's ongoing relevance.
The two terms project and product are orthogonal and thus not at odds with each other.
Conclusion
It’s not either or. You are already doing both, product and projects:
Everything is a product, each change to the product is a project.
The only relevant question is: How big are your projects?
The smaller the projects, the more agile you are. It is that simple.
But wait, there was a second part to ChatGPT’s definition of what a project is. The thing with the project manager … what about her²? I’ll cover that in the next blog post.
Always …
Any feedback is welcome. I enjoy discussing stuff like this. I enjoy being challenged. I enjoy learning about and experiencing new perspectives.
[1] Assuming your product backlog consists of user stories. If not, just replace “user stories” with the generic and lifeless term “product backlog items”, as per Scrum guide.
[2] … or him. I am not too occupied with the whole gender discussion, and “them” as an alternative is grammatically wrong. That’s why I decided to refer to everybody as a female. It could just as well have been a male, of course.
Thanks to Klaus Abert, Dirk Bucka-Lassen, and Fernando Guigou for providing valuable feedback that has improved (I hope) this article.
