My company is standardizing how agile initiatives will be run organization wide. It is a <1000 people company where few hundreds waterfall projects are either running or close to start.

I understand that a common high level understanding of how an initiative is run is important (go/no-go, reddition, vocabulary, gouvernance...)

The discussion led to 2 phases of an agile initiative:

  • agile project: either the first iteration of a brand new solution leading to an MVP, or a timeboxed mission to achieve a specific scope/goal

  • agile product evolution: considering an existing solution, a timeboxed phase where iterative evolution is made on the solution with no specific scope

It would mean that in order to start a new product, an agile project would be done and then followed by agile product evolution phases. Here and then, additional agile projects could be done on the existing product.

Do you consider agile project and agile product evolution two different things?

  • Hi cptCloud. Welcome to the community and thank you for your contribution. After reading the question i get the feeling it's primarily opinion-based, specially due to the very last phrase. Commented Nov 9, 2019 at 14:37

3 Answers 3


agile project: either the first iteration of a brand new solution leading to an MVP, or a timeboxed mission to achieve a specific scope/goal

I am struggling to see why this is necessary and why the Agile product evolution approach you mention cannot be used instead.

A brand new solution can be developed using an iterative evolution. You may decide to not release at the end of each iteration for marketing/business reasons, but that doesn't stop you from iterating in exactly the same way as you would with an already existing product.

As for a time boxed mission to achieve a specific scope/goal, what is the logic behind that? Putting a time box around a scope/goal suggests that you have somehow managed to work out how long this will take to complete, which suggests waterfall thinking.

As one of the guiding values of Agile is to responding to change over following a plan, it is difficult to see why these projects would be described as Agile. What seems to be implied is that new product development will be done in a waterfall fashion and that only product enhancement will be done using an iterative Agile approach.

  • Certain goals are naturally timeboxed, e.g. dates stipulated by contract, regulations or laws. A timeboxed mission is a reasonable thing in itself and of course it can still be delivered in an agile and iterative manner as a way of managing risk and trying to ensure those deadlines can be met.
    – nvogel
    Commented Dec 11, 2019 at 11:37

Because Agile has no single authoritative body, many terms and concepts are up to interpretation. That is not inherently problematic - these slight differences in interpretation often help people find the solution that best meets their needs. So, to that end, if what you are describing works well in your context, enjoy the success.

However, it is certainly not the only way to look at that. To provide some additional perspective to work with, I can share another way to contrast project vs product in an agile context.

Projects are usually constrained in some way. These constraints can be loose or rigid. For example, I may expect to finish sometime in the second quarter or I could have a deadline of April 3rd. Project are usually also constrained in scope, though in agile projects it is far more common to see outcome-based scope rather than output based scope. For example, a traditional project may detail the changes to be made to a system whereas agile projects may say something like "Reduce average time to complete the 5 most common tasks by at least 20%." Also, agile projects are usually structured differently in that the exact path of the project frequently emerges as the project progresses. This allows for more complex work to be handled and adjusted for effectively. These aren't hard and fast rules however.

Products, on the other hand, are "living" things. A product exists until either the company goes under or the product is end-of-life'd. Many things influence if the product is ideally suited for its environment. Technology, competition, skills of both your employees and your customers, market perception, and more all shift around your product. A radical change in the market could mean that the perfect product today is practically useless next week. Because of this, product development is a constant exercise in reflection and adaptation. In the past, products had been evolved through projects and while you certainly can do that still (and even in an agile way), this is often far too slow.

In this perspective, they are two different ways of working - each potentially useful in the right place, but there is no hard-and-fast rule like you have to start one with the other. Again, that is not to say that what you wrote is incorrect, only that there are different ways to look at it and you need to pick what works in your context.


The concept of projects derives from business management practice and the way that new initiatives receive support and funding. Given the management time required to make decisions, people who control budgets prefer to see things in terms of relatively large tranches of work with funding "gates" (but not too many of them) before work proceeds.

A more product-centric perspective is that evolution of products is a normal, day-to-day business activity and what matters is how you assign finite resources at any point in time to meet business priorities and maximise value.

Both perspectives have their place. The different perspectives don't have to imply different kinds of delivery however. The salient difference, if any, is one of cash-flow rather than the mode of delivery, i.e. new initiatives may have no existing returns to offset the initial costs. This is essentially a matter of accounting rather than project/product management.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.