How agile is your triangle?

Traditional project management represents constraints as an “iron triangle”, meaning that a given project has 3 inter-related considerations: schedule, cost, and scope.

Someone defines the scope up front, then project managers figure out the cost (resources like materials and people) and the schedule (time lines, Gantt charts, critical path, and so on).

The idea is that the customer (or someone, at least) knows the scope. In fact, scope is not under the control of project managers. If the estimated amount of materials was too low, project managers can request more materials (increase the costs). If the estimated time line was too low or the project team is slower than estimated, project managers can request more time (increase the schedule). The scope is non-negotiable.

In traditional projects – whilst the focus is on delivering the scope (defined up front) – the risks therefore are that schedule and/or cost increase. This is the way organisations manage waterfall software projects. And it results in many projects running over budget, over schedule, and (worse still) delivering a broad scope only to discover later it is not what the customer really wanted.

Agile project management flips this. The agile project management philosophy is that you – as a product company – know the schedule and cost. You know when you want to release. You know the resources you have (developers, testers, devops, and so on). The thing that can change is the scope.

The risk with this approach is reducing the delivered scope. However, agile combines this with the incremental delivery of the highest value backlog items (features, bug fixes, improvements) thus enabling organisations to focus on what really matters: optimising the output of fixed resources.

Who decides the highest value backlog items? Why, I’m glad you asked. The Product Manager, of course.

With various flavours of agile taking over the product world, it is easy to see why the Product Manager role is central to success.

Have a look around in your organisation and ask yourself: how agile is your triangle (on the scope vertex of the triangle, at least)?