The Quality Trilemma

I'm a software developer and computer scientist who loves building things. I will share things I learn on this blog. Feel free to contact me on twitter.

Introduction

The iron triangle is to project management what the CAP theorem is to distributed data stores—well, in a way. It is extremely difficult to change one without affecting the others. Before we proceed, here is a quick breakdown of what we are looking at in the image above:

Scope - How much work we need to do; features and other improvements fall into this bracket.

Cost - The resources available to get the work done; team members and financials are parts of the cost.

Time - How long it will take to complete the work.

Imagine there are levers at the different ends of the triangle, allowing you to tweak how much of each point you can add—but there's always a resultant effect on the other angles.

An Example

Assuming we have to build a to-do app. In our planning stage, we have to make decisions (pretty much pick how much of each lever we will pull) and allocate priorities.

Waterfall

In waterfall, we have to get all of the work done to achieve any form of quality. This means the scope is not negotiable; we cannot pull that lever. That leaves us with time and cost required to get that scope of work done in the most efficient way—the levers we can pull. If we decide we need to deliver to market very quickly, then our costs go up (we need more engineers and we need to throw cash into infrastructure as we may not have time to optimize).

Agile

In this case, we can break our work into small [alterable] scopes and iterate over a fixed amount of time. Here the team commits to certain deliverables (sprints or WIP depending on the framework) and is allowed to pull the scope lever. It can be desirable to keep the team size consistent; this makes the team more cohesive and, by extension, more productive.

Application

It is simplistic to say, "prioritize one component, sacrifice one, and accept the one you can't change." But no two projects are the same, and even within a single project, it is important to reevaluate after a while and make changes to remain efficient and actually deliver the work.

It is important that during planning sessions, all team members are properly aligned with the current work at hand. It could be "save costs we incurred in a previous stage". Note that in this example, we have scope as well—work on a specific part of the app to reduce infrastructure costs (this is how some teams pay technical debts).

Conclusion

All teams are unique, just like all projects (even different stages of the same project). It is important to know where you are and what you have. This is the real constraint for delivering on your project, not really the three angles of the iron triangle. The triangle exists as a guide and a way of documenting and validating your decisions and workflow. In the end, make the quality of work delivered the best possible given the resources, time, and scope at hand.

The Quality Trilemma

Comments

More from this blog

Interface Segregation Principle (explained in Go)

Handling Errors in Golang

Learning Go as a Node.js Developer

Using JavaScript generators to optimize APIs

Introduction

An Example

Waterfall

Agile

Application

Conclusion

Command Palette

Comments

More from this blog

Introduction

An Example

Waterfall

Agile

Application

Conclusion