Just Barely Good Enough Artifacts: An Agile Core Practice

One of the more controversial concepts introduced by Agile Modeling is that agile models and agile documents are sufficient for the task at hand, or as agilists like to say they are just barely good enough (JBGE) . In this article I make the following critical points about a model or document (an artifact) being just barely good enough:

1. Just Barely Good Enough Is Actually The Most Effective Possible

For some reason people think that JBGE implies that the artifact isn’t very good, when in fact nothing could be further from the truth. When you stop and think about it, if an artifact is JBGE then by definition it is at the most effective point that it could possibly be at. Figure 1 is a diminishing returns graph which summarizes the value curve for an artifact being just barely good enough. Value refers to the net benefit of the artifact, which would be calculated as benefit – cost. The dashed line is at the point where the artifact is JBGE: anything to the left of the line implies that you still have work to do, anything to the right implies that you’ve done too much work. When you are working on something and it isn’t yet sufficient then you can still invest more effort in it and gain benefit from doing so (assuming of course you actually do work that brings the artifact closer to it’s intended purpose). However, if an artifact is already JBGE (or better) then doing more work on it is clearly a waste: once an artifact fulfills its intended purpose then any more investment in it is simply busy work. The diagram is a little naive because it is clearly possible for the value to be negative before the artifact becomes barely good enough although for the sake of argument I’m going to assume that you do a good job right from the beginning.

Figure 1. Cost analysis of just barely good enough.

Value curve (ideal) for modeling and documentation

Ideally all of your artifacts should be JBGE, as you see in the diagram. Unfortunately, it isn’t an ideal world. There are three common reasons why you’ll likely overshoot the ideal:

  1. Accidental. You’ll often put too much effort into an artifact, unintentionally overshooting the mark as you work on it. For example, do I really need the arrowhead on the rightmost end of the value curve in Figure 1? If not, then the diagram is more than just barely good enough.
  2. Purposeful. When you’re new to the concept of JBGE it’s a bit scary at first. It can be comforting to purposefully overshoot, to do more than is required, just in case you’ll need it later on. However, the reality is that if later on you do realize that you need something more, or something else, you can likely create it at that time.
  3. Change. Sometimes you create an artifact that is JBGE and then the situation changes and you discover that your artifact now contains extra material, out of date material, or is missing material.

Agile modelers are only human and they are not always going to do a perfect job, so realistically some artifacts are going to be more than just barely good enough. The secret is to learn how to detect when you’ve reached the point of something being just barely good enough and then to stop working on it. Easy to say, hard to do.

2. Just Barely Good Enough is Situational

The fundamental challenge with JBGE is situational. For example, I often draw a UML Sequence diagram on a whiteboard to explore complex logic and then discard it once I’m done with it. In this case the whiteboard diagram is fine because it helps me to solve the issue which I’m thinking through with whomever I’m working. But, what if we’re in a situation where we’ll need to update this logic later on AND will want to do it via the diagram instead of via source code? Clearly a hand-drawn sketch isn’t good enough in this case and we’ll want to create a detailed diagram using a sophisticated software-based engineering (SBE) tool. We’d still create an agile model even though it is much more sophisticated than a sketch because JBGE reflects the needs of the situation (remember, agile modelers Model With A Purpose).

To determine if an artifact is JBGE you must actively work with the direct audience of that artifact. In the case of system overview documentation that would be the maintenance programmers, in the case of a user manual that would be the end users, and in the case of a sketch sequence diagram that would be the programmer implementing the corresponding code. Without knowing what the audience wants, you cannot realistically create something which is JBGE, putting you in a situation where you’re motivated to put far more effort into the artifact than you need to. This often proves to be wasted effort, because chances are very good that the artifact will fall prey to the they aren’t going to read it (TAGRI) principle. To ensure that you know what the audience of an artifact wants, you need to ensure good communication with them and better yet strive for active stakeholder participation.

3. Just Barely Good Enough Does Not Imply Low Quality

Some people seem to think that artifacts which are JBGE will be of low quality. The reality is that they are of sufficient quality for the job at hand. This isn’t an excuse for doing a poor quality job because quality is in the eye of the beholder: the audience for an artifact determines if it is sufficient, not the creator of it. If your stakeholders require an excellent, detailed artifact then it is JBGE when it reaches that point of being excellent and detailed.

4. Just Barely Good Enough Changes Over Time

An artifact can move along this value curve in both directions throughout it’s lifecycle. Your needs may change, becoming either more complex or less so, and therefore you may choose to update your artifact(s) accordingly. If the artifact becomes less than good enough then you will need to consider updating it.

If an artifact is more than good enough should you rework it? Only if it is harming your efforts elsewhere. For example, a hand drawn diagram would have been sufficient for Figure 1 although at the time that I drew it I didn’t have easy access to any writing materials (such as paper or a whiteboard) so I used Microsoft Visio instead. Later, when I did have access to such materials I didn’t bother to replace the diagram because that would also have been useless busy work. Yes, I invested too much effort when I created the diagram because it took me almost 15 minutes to draw it with Visio yet I could have drawn this diagram on a whiteboard, taken a picture of it, and cleaned it up with software in less than five minutes. But, investing an additional five minutes to change the format of the diagram wouldn’t make any sense.

For a second example, let’s say I don’t like the current heading along the X axis and believe that Expenditure would be better. Would it be worth the effort of starting up Visio, reading in the document, updating it, generate the GIF, upload the image to my ISP, edit the HTML for this page to rework the text to match the diagram, upload the HTML, open up my browser and look at this article to ensure that I got it right, do any necessary fixes and subsequent uploads, and then commit the changes to version control? Sounds like at least five to ten minutes of effort for almost no value. Agile modelers Update Only When It Hurts , and the current X axis heading doesn’t hurt enough to warrant this investment (actually, I think the current heading makes sense). In fact, this sort of update would actually decrease the value of this article because the cost is greater than the benefit.

5. It Comes Sooner Than You Think

Figure 2 depicts a more realistic version, specific to modeling, of the ideal graph shown in Figure 1. It shows two value curves, the dashed one indicating the theoretical value of modeling according to traditional/heavy approaches and the solid line which I believe to be the actual value curve. Traditionalists seem to assume that significant investment in modeling, and corresponding specification, will continue to add value over time. Practice, however, shows that the value in modeling comes through improved communication and a bility to think things through, and that this value peaks rather quickly. For example, for initial up-front modeling this typically occurs after several days or a couple of weeks (naturally for high-risk initiatives you may want to invest a bit more time with initial modeling). Even for enterprise architecture you still only want to invest a couple of weeks on initial modeling. For sprint/iteration modeling it’s even shorter, usually just an few hours, and for model storming on the order of minutes.

Figure 2. The value of modeling.

Value curve (ideal) for modeling and documentation

6. Related Resources