Press "Enter" to skip to content

Project or product? Spend your money accordingly.

Project or product? Spend your money accordingly.

Thoughts about Software Project Management methods, round 2

Some time ago I introduced drawings about how common Software Project Management methods compare to each other.

Old, new and future Software Project Management methods

Sharing my thoughts…

Following the initial success of this post, I thought it might make sense to continue the experiment through a slightly different point of view: instead of a single scale, use two different scales.

Batch size?

The batch size is a synonym for iteration length. The longer the iteration, the bigger the size of the chunk of work done in each iteration.

Typically, the far-left end corresponds to Waterfall: with a single iteration, it is the biggest possible batch size. On the opposite, on the far-right end, is Kanban which iterates so fast that the iteration concept is dropped: the batch size is the smallest possible.

In the middle we’ll find iterative methods, with varying iteration length.

“Project” vs. “Product”?

I believe I already introduced this concept pretty well in my previous post.

When the focus is about running a project, then there is typically a start and an end, and the customer is clearly identified, can be spoken to, and knows he needs something — as he is actually requesting to build something!

On the other hand, when the focus is about running a product, then the team might not even know who the product is for: it is yet to be discovered and defined. There is no clear end to the product life-cycle, at least the end is not envisioned in advance.

Practices based on batch size / iteration length

Following the batch size scale, we can mark different zones:

  • On the left, iteration duration is measured in months. In the older times, the biggest projects even measured the batch size in years. By the way, it is possible to run only one iteration from start to finish of the project — but that does not change the batch size.
  • Next comes typical IID & Agile methods, like Scrum. Scrum, for instance, recommends to use iteration lengths between 1 and 4 weeks.
  • Farther to the left of Scrum are the teams decoupling their releasing cycle from the iteration cycles, releasing as soon as possible and several times per iteration. A typical example is the delivery practice of continuous delivery that enable to deliver very quickly, practically anytime.
  • Finally on the right is the continuous flow of Kanban, where iterations are completely dropped: the batch size is the size of the individual work elements, instead of the size of an iteration wrapping a set of work elements.

Laying the Software Management methods on the scales

While it is hard to imagine how the “Product” way could be applied to waterfall, the Project vs. Product scale applies nicely to Scrum and Kanban.

We can also see how project-oriented Scrum is often (wrongly) used as a way to handle support teams, or TPMA — Third Party Application Maintenance.

The continuous delivery practice can be used on both project-oriented and product-oriented Scrum.

Relation between batch size and Project vs. Product

Impact of the Product mindset on the batch size

Let’s analyze this view…


First, let’s get Kanban out of the way: Kanban works fine whether you are project-focused or product-focused.

Project-focused cases

Then, let’s talk about the project-focused part. On the left, waterfall — and more broadly, the old way of thinking — is happy to have a big batch size. People on the team will even justify it as a good thing: after all, since they are driven by a contract, the only thing that matters is the complete, final delivery. What’s the point of partial deliveries?

On the other hand, project-focused Scrum will happily deliver during each iteration of the project. Yet, the team will probably happy delivering maybe once per iteration — supposing that the iteration length have been properly chosen. Once the team is there, why improving? Isn’t it working good enough?

Please note that this is not necessarily a bad thing in itself… If the team is indeed leading a project, then budget and time are constrained: it may make sense not to invest more into a better delivery process, given that the project is short-lived.

Product-focused cases

Now let’s have a look at the project-focused part. On the right, the team has many incentives to keep going faster and faster ever.

While project-focused Scrum teams will have a natural tendencies to stick with “just enough” delivery speed, product-focused Scrum teams will tend to continually improve their delivery pipeline.

On the left, a team with a very big batch size while being product-focused will feel completely constrained by their delivery speed, feeling that nothing gets accomplished. The team will want to fix that, hopefully moving to the right side of the scale.

There, too, being product-focused brings many incentive to improve the delivery capability of the team.

Product focus: the ultimate enabler of continuous improvement?

Is there any good reason not to iterate fast?

Other than legacy code, technologies and organization which are getting in the way? Which also could all be fixed, at least in theory?

The power of faster feedback

The smaller the iteration and batch size, the faster the feedback.

Bigger batch sizes

On bigger batches, the feedback takes so much time that it tends to be completely ignored:

  • At best, some kind of post-mortem is organized at the end of the project to try to run better the next project.
  • Even worse, the business performance of the product tends to become completely decorrelated from how the team and company works.


On project-focused Scrum, the shorter feedback loop enables to mitigate nicely the project risk.

On product-focused Scrum, the shorter feedback loop enables to actually find out things that the user might not know himself.

Continuous Delivery

Thanks to continuous delivery, project-focused Scrum becomes practically risk-free. That’s truly awesome, yet this is a very restricted use of the quicker feedback loop.

What a shame to have built an awesome continuous delivery stack, only to mitigate risks. Was the cost worth it?

On the other hand, continuous delivery becomes a major edge for product-focused Scrum teams: moving faster than the competition is essential to succeed.

Continuous Flow

Finally, what about Kanban and continuous flow?

On the project-focused side, things are even better but still nothing more than risk mitigation. Again, was the cost worth it?

On the product-focused side, the team moves another step by pushing always farther how they experiment with the product and continually improve it. The benefits of the build pipeline greatly exceeds the costs of putting it in place and maintaining it.

The sweet spot

Doing a project? Is investing in the build pipeline actually worth it?

Doing a product? This is a no-brainer: the faster you iterate, the faster you’ll get a great product, out-maneuvering the competition.

Liked this article? Show it!

Please clap 👏 and share the article! It is because of you that I put my heart and soul into writing.

And follow me on my blog to be notified when I publish new articles!

Thank you so much!

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *