Introduction

One of the twelve principals of Agile development is, “Welcome changing requirements, even in late development.” This has made our craft to be more responsive to our customers and deliver projects that better fit their business needs. However, “changing requirements” can also unreasonably escalate cost if it is not properly defined and managed.

A changing requirement is a new calculation in a report. A changing requirement is an additional business rule applied to an input. A changing requirement is a report that must be generated after every purchase order.  An agile changing requirement is always defined from the perspective of the customer.

Changing software languages or development tools are not an Agile changing requirement. Changing languages, environments, and tools are mechanical implementation changes that are always defined from the perspective of the software engineers. Software engineers are not the customer.

Shifting the sequence of milestones is not a changing requirement. Shifting project milestones discards much of the development tooling as often milestones do not share the same tooling. There is tooling that goes into hitting milestones in a project. Defining requirements, loading code, setting up the project to generate the software artifact, locating directories and endpoints, and setting up service accounts are all part of that tooling. Shifting priorities triggers tooling and retooling with each shift. These are always defined from the perspective of the project manager. The project manager is not the customer.

Two Types of Cost

Basic accounting splits cost into two main categories: fixed costs and variable costs. Fixed costs are costs that must be paid independent of business activity. Rent, property taxes, and insurance are examples of general fixed costs. Software development also has specific examples of fixed costs. Buying the necessary hardware equipment and software tools are fixed costs that are not associated with the number of software artifacts produced. Training in a particular programming language or tool is not tied to the number of software artifacts produced. This retooling time is completely independent of the number of lines produced. Every developer must have some “gearing up” time between using different languages. This “gearing up” time is also a fixed cost. Fixed cost is independent of the quantity of software artifacts produced.

Software variable costs, in a programming shop, behave just like any variable costs in general accounting. There is a direct relationship between the variable costs and the number of units produced. That is the only difference. In a software development shop it is software artifacts being produced instead of something like loafs of bread.

There is also something like economies of scale with software development. Variable cost tends to drop as more of the same development is performed. In other words, the twentieth C function is easier than the first five C functions when you are going from programming in Java back to C after a couple of years away from pointers and headers. You get quicker the more you program using the same language and tool continuously.

Dynamic Demands on the Craft

Our craft has always had dynamic demands. Projects were stopped and restarted in the days of waterfall development. Executives can fund one part of a project but then the goals change.  They can only fund another part of the project. Finally it’s complete so the shop goes back to the first part of the project. Start, stop, start, stop — spend, spend, spend.

New government regulations require massive changes to the account receivables.  This requires changing the DBMS that can handle more records. Change, change, spend, spend.

The competition starts discounting tickets based on seat availability. Now your business customer must do the same to keep the business afloat. You have to totally rewrite of the pricing algorithm. Change, change, spend, spend.

Property tax laws change so the asset management system must now take into account physical location. Change, change, spend, spend.

Business has never been a static activity and our software development has had to reflect the dynamic nature of business then and now. That’s always regardless of which particular paradigm is popular this week.

Dynamically Managing Fixed Cost with Variable Documentation

Dynamically managing fixed costs sounds like a line from a comedy skit. But, it’s not a joke. It is a necessity to manage an efficient software development shop.

Documentation is a component of fixed costs. Resources are expended to create diagrams and user stories. Those resources do not generate one line of code. Oddly, it’s also a factor in lowering fixed costs. That is when fixed costs are spent the second or third time around. The diagrams and user stories are reused when a component of the projects is started and stopped three or four times. The agile/customer portion of the changes are more variable cost. The non-customer portion of the changes are more fixed costs. Thus, the documentation is more valuable when the project is less Agile.

The key to applying Scott Ambler’s Just Barely Good Enough (JBGE) principle of documentation is knowing how Agile is the project. Ambler says documentation should only be as good as it needs to be in order to serve its purpose. I am suggesting we must know how Agile is the project to know the best JBGE. Customer changes generally require little documentation because those changes are Agile. Thus, it has a low JBGE. Non-customer changes are never Agile. Changing from Java to Python in the middle of a project requires a significant amount of documentation. Starting and stopping large chunks of the overall project requires significant documentation. Those are not Agile changes.

Decide how truly Agile is your project when guessing how much documentation you need. If the project managers and executives can let the project be completely Agile then you will most likely need little documentation. If your priorities or environment will always be changing then document your project to a fault.