The Product Delivery Triangle
Re-imagining popular delivery methodologies in terms of edges on a triangle
Let’s cut to the chase — there are too many frameworks out there for delivering products. If you’re lucky, you get to participate in a couple. If you’re unlucky, you get to work with SAFe (yuck!)
Regardless, it helps to understand the trade-offs each method is proposing.
The Delivery Triangle
I’ve chosen three tradeable areas:
The teams’ ability to react to changes in requirements, development time issues and organizational pivots. You can also consider this as reactiveness to change.
This accounts for commitments made v/s what is actually delivered at a fixed point in time. If the team commits to delivery N number of items in the to-do list in X days, predictability is how close to N the team reaches on an average.
It is of course impossible in real world scenarios to delivery N items as was committed since engineering complexities, process dependancies and people factors come into play. There is also the matter of our inability to estimate the size of the work to be done.
Efficiency looks at how many work packets or items were delivered by the team v/s how much they could have delivered. It is obviously hard to say how much they could have delivered, but you can look at it as a relative (across methods) area.
A perfectly efficient team utilizes all their time in delivering items. This is of course impossible as the same factors that plague predictability plague this area too.
One of my favorite thing about Agile is that it is an adaptive and inclusive approach. It makes no assumptions about the future nor does it lie.
The key principles of agile project management methodologies are:
- It’s collaborative.
- It’s quick.
- It’s open to data-driven change.