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.
- 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.
- 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.
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.
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