Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Trading Off Value, Quality, and Time

DZone's Guide to

Trading Off Value, Quality, and Time

Time, quality and value - as much as we'd like to get the best in terms of all three, we've got to make trade-offs in the real world. Which ones do you choose?

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

The traditional Iron Triangle tries to explain in graphical form how software projects need to make hard tradeoffs between scope, schedule, and resources.

img

This is alternatively referred to as the Time-Cost-Quality Triangle, Triple Constraints, the Triangle of Balance, or the Iron Triangle.

Many Triangles

There are many variants. A common variant is the phrase, "Fast, Cheap or Good. Pick two."

img

A more nuanced version illustrates the nature of the tradeoffs that you're making and allows for a middle option where all three are in balance, but you're not really optimizing any of them.

img

Software engineers are all about managing tradeoffs. The highest level tradeoff is during planning and prioritization in the form of trading off value delivered, the quality level of that value, and the time to deliver it.

The Agile Triangle

"If you're a team that practices waterfall development or are new to Agile development, the important thing to remember is the difference between what is fixed and what is estimated. Unlike Waterfall development, Agile projects have a fixed schedule and resources while the scope varies." https://www.atlassian.com/agile/agile-iron-triangle

Agile methodology, in particular, uses fixed time periods and fixed resources. This is typical of a start up environment, where you need to ship quickly and do not have the resources to hire many engineers. You're also typically building an MVP type product, trading off scope versus time. Scope can be further broken down into feature breadth and depth, and the quality of the whole experience.

img

My Agile MVP Triangle

To simplify, my version of the Agile MVP triangle looks like this.

img

You can pick exactly one spot on this triangle for a given project. If you choose a spot close to the value point of the triangle, you are explicitly giving up some focus on quality and a polished experience. You're also choosing to push out time to delivery somewhat to get more value in.

This is jokingly talked about as "Fast, Cheap, or Good. Pick two. No, not that one." Alternatively described as, "Nine women cannot make a baby in one month" (Mythical Man Month), meaning that even if you did add resources in the form of extra engineers, you can quickly get to a point of diminishing returns where adding people doesn't actually speed up the delivery.

What do these points mean, exactly?

Value

This is basically scope. It could also be labeled "Features," both in terms of breadth of different features, and the depth/scope of an individual feature. I thought about calling this "User Value," but quality could also be considered to deliver user value. Likewise, scope could include quality/polished work. In the end, this isn't a perfect term, but I basically mean user value excluding quality/polish.

Quality

Some examples of quality are high fidelity graphic style, UX optimizations based on feedback and performance tuning. This is often subjective and can take a virtually unlimited amount of time as you polish on the far end of the diminishing returns curve. The trick is getting to 80% of max quality with 20% of the effort.

Time

This is simply the time to ship - to put the software in front of real users.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
project management ,mvp ,agile ,iron triangle

Published at DZone with permission of Chase Seibert, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}