Good Enough Software: An Agile Definition

April 2, 2010

I recently examined the Agile Triangle, promoting an Alternative Agile Triangle as a model to reflect the spirit of Agile development. (I also rather quickly revised it.)

In an effort to keep up with the times, I think that we should update the traditional concept of “good enough” software. Actually, the conventional definition is just fine when it relates to non-Agile software projects. What we need is a revised definition for Agile projects.

The term “good enough” was coined by James Bach of Satisfice, Inc., and it relates to software quality, where it is okay to ship with bugs as long as you ship with the right bugs. James’ point is that building bug-free software is prohibitively expensive, and that as long as the benefit provided by the software outweighs any problems, you have achieved your primary objective in building the software.

As far as Agile software projects are concerned, they specifically focus on delivering with quality; James Bach’s “good enough” software definition applies to sequential software projects that have a quality-assurance cycle at the end of the project – where time is constrained and the poor QA folks always get short-changed.

Agile projects don’t work like this.

Good enough in Agile is really about good enough design.

Good design in Agile translates to meeting the needs for the features that are being implemented right now. This does NOT mean that you should throw good design principles out the window! The software design should reflect what is needed to support the features being implemented, but only what is needed, not what you might need later.

We all know that requirements will change, yet all too often software design attempts to reach too far into the future and anticipate change. This leads to two problems.

  1. Implementing too much foundational code that supports a big design up front makes the software more complex. This in turn makes the software more difficult to understand and more costly to maintain going forward.
  2. You will end up wasting time and money developing and testing things that won’t be needed. A design can degrade over time because the requirements dictate changes in some way that the original design did not anticipate.
From my experience, there are some common responses involving the big design approach that is faced with new functionality that is a poor fit for the existing design.

The first is to react by continuing to work strictly within the bounds of the existing design, even if the design is proving to be a burden. A more extreme example occurs when human nature really kicks in, and those who have invested a great deal of thought and time into creating a design become wedded to it and attempt to keep it alive much longer than they should. Changes become delayed until it becomes so costly and difficult that it is painfully clear to everyone that the design must change.

On the other side, there are those who weren't a part of the original design process in the first place, but are faced with updating the software in some way. The deciding factor for these individuals is how quickly and easily the design allows them to make a change. If the design is constraining to the point where working within the bounds of the design takes significantly more time and effort than working around it, the design will not be followed.(At least not without a fair amount of arguing.)

Agile is about embracing and dealing with change. And we all know that change is constant in software projects. Requirements change due to business priorities shifting, or because what we thought we understood really wasn’t quite right.

Agile design should be a small investment up front. The team starts with the simplest design possible, develops and maintains an inventory of unit tests and acceptance tests, and continually evolves and improves the design each and every iteration – keeping the design appropriate for the feature(s) developed for that iteration.

From a software development perspective, be good enough with the design, but be great in the other dimensions of software development. Like writing solid, maintainable code that is tested thoroughly and delivered with quality.

But wait, there's more!

Good enough applies to the business end of the deal as well. Our management team recently read and discussed a book Stand Back and Deliver: Accelerating Business Agility by Pollyanna Pixton, Niel Nickolaisen, Todd Little, and Kent McDonald. The book described what is known as the Purpose Alignment Model.

The Purpose Alignment Model is a tool to help you to examine your business processes and activities in two dimensions: Mission Critical and Market Differentiation. These dimensions are split into quadrants: Who Cares, Parnter, Parity, and Differentiating.
Focusing specifically on Differentitating and Parity, the objective is to understand what truly differentiates your company in the marketplace from those activities that don't really provide competitive advantage.

Parity activities are important because they are mission critical. You shouldn't under-invest in them because they are your baseline; you won't, however, gain any advantage in the marketplace by doing them better than the competition.

Good enough business value is appropriate for non-differentiating, parity activities.

When it comes to Parity activities, do them well, but don't go the extra mile. The investment won't be worth it. Find those few, key Differentiating activities and excel at those to maximize the return on your investment.

Photo by kanu101


Susan Williams said...

Software engineers are working on daily basis to improve productivity of software. They are doing their best to build software those are efficient enough to fulfill our needs. Check for best Paper.

January 27, 2015 at 4:04 PM
sp calvin said...

With regards to achievement, you realize that your business needs the best of everything to accomplish that objective. An undertaking administration application is one of the numerous things that you have to explore deliberately with the goal that you can get the ideal arrangement. web based time tracking app

January 10, 2016 at 2:21 AM
Lorenzo Amos said...

Want to advise you one great solution for your company. If you're looking for some great web developing company you should try this one This one is the best I have ever use. Try to and gain money faster on your eCommerce project. Good luck.

January 14, 2016 at 10:03 AM
Rashel Ahmed said...

Before substance administration frameworks, the substance authors would need to present their substance to engineers who might then change over it for the site. Presently it is one-stage, and the substance authors can have more control over their substance and the respectability behind it. content management system

February 2, 2016 at 5:09 AM
Emily Bleakley said...

We are most time pay for math assignment in our daily life. They think assignment writing or reading is a good habit. For more information

August 18, 2016 at 1:33 AM

Post a Comment