Is ‘Good Enough’ Good Enough?

Fast, good, and cheap. Pick two.fastgoodcheap

This is the familiar instruction represented by the project triangle. A project that is of high quality and delivered quickly will be costly. One that is done well with limited resources will likely take time. An inexpensive project delivered quickly will suffer in its execution. Keeping this in mind, compare waterfall with agile.

Waterfall demands a certain level of quality. All of the upfront research and design, as well as the many gates and checkpoints insure that when the product is released, it meets the expectations defined up front. Waterfall projects can be good and fast, or good and cheap, but the underlying notion is good. Now, experience tells us that the definition of ‘good’ can vary greatly on waterfall projects. ‘Good’ can mean that the end users find the product useful and usable, or that the project is predictable, i.e. that the budget is met with the expected scope, or that the target date is hit and the expectations of scope are managed. I’m sure each of you has experienced many variations on what stakeholders consider ‘good’.

Agile chooses fast and cheap. Sprints are short and teams are small. There are many good reasons for this. They are well documented elsewhere, and include getting working software to users faster, being able to address high priority problems quickly, and abandoning features with little value. With this approach, the mantra for each sprint is ‘good enough’. When choosing fast and cheap, what is sacrificed will be quality. At least initially, this may be true, but agile counters this by adding many revisions following quickly on the heels of an initial release. Problems can be quickly identified and fixed in the next release, which may be as little as two weeks away.

This requires a significant shift in thinking for User Experience. It is our job to ensure that the users have something they find valuable and easy to use. We think big thoughts about mental models and context and integrate detailed thoughts on layout and implications. We have been accustomed to defining the entire picture, making sure all the pieces fit, before moving on. It can be very challenging to take one piece of a larger project and just get it to ‘good enough’ while ignoring the rest of the system. We are judged on how the product looks and behaves. Sacrifices made for expediency affect our credibility and reputation.

We also may have different ideas of what constitutes ‘good enough’. To a prototypical engineer, it may mean that the feature is present and functional. For UX, it’s about utility and ease. A product owner may fall somewhere in the middle. Its important for each team to agree on their shared definition of ‘good enough’. If forced to work under the simplest extreme of ‘functional’, we may not be pleased, but at least our target is clear and we know what to work towards.

This change in thinking is a key challenge to successfully integrating UX and agile. One approach is define a rough, high-level vision so that all involved can get a sense of the whole. During each sprint, or prior to each sprint, fill in the details of the pieces, or stories, about to be built. It won’t guarantee that there won’t be rework, but it will help balance the need for holism with the need for speed. If you don’t get it right this time, there’s always next release.

Share this post

5 comments on “Is ‘Good Enough’ Good Enough?”

  1. Tim Peacock Reply

    I have worked on plenty of waterfall projects that, despite the upfront research and design, failed to meet expectations. The truth is that the state of the art in waterfall doesn’t ensure quality or predictability. There are many reasons. One of them is that customers often can’t tell us (or we can’t hear them) what they want or like, except by using an actual product to do real work. Waterfall projects, time and again, go astray as they build features, often beautifully designed, that customers do not actually want. Just look at any MS Office release 😉

    Agile is not a cure all for this problem. But its iterative nature (when done well) allows designers to home in on what customers actually want and need. Agile may or may not, in the end, be harder on UX than waterfall, but I’m pretty sure that rapid iterations will prove to lead to better designs than design it all up front.

  2. Jeremy Kriegel Reply

    My initial response is, was the upfront research given enough time and resources? There are many proven ways to be successful in waterfall, but they do rely on each stage being done thoroughly (as well as being willing to go back and make changes). Too many times, the upfront work gets cut to meet budgets or deadlines. Given that waterfall’s success relies on the quality of upfront research and design, gutting that work will produce a predictable result.

    So, if you’re not going to do proper upfront work anyway, then agile certainly makes sense. However, it seems that more and more agile practitioners are recognizing that some upfront work has to be done first, although less than what waterfall prescribes.

    I would posit that, done well, an agile project will have a similar amount of design work as a waterfall would, but the balance is different. Less is done before code writing begins and working software is delivered earlier.

  3. Pingback: method sans madness » Listen, Don’t Obey

  4. Pingback: method sans madness » Do Disruptive Startups Need UX?

Leave a Reply to Evan Vannuland Cancel reply

Your email address will not be published. Required fields are marked *