Discussing "Inventory" in Software Development - Classifying approaches

Interesting comments of Martin Fowler starting from this idea : "So as an example - one of the principles of lean manufacturing is the elimination of inventory.This leads to the question of whether there is an analogous item to inventory in software development."

http://martinfowler.com/bliki/MetaphoricQuestioning.html

Martin Fowler make a very interesting comment about a IMO less interesting idea "up front documentation is the equivalent of inventory": "Now I agree we need to substantially reduce this kind of speculative documentation; but the rationale for doing so must come from thinking about the software development process, not from purely reasoning by analogy."

Here is my comments on these subjects.

Manufacturing-Software Development Analogies

We should be careful on these analogies because these domains areas are pretty different. Examples: Just-In-Time approach in manufacturing must find solutions for a JIT Production (where the design was previously done "offline") and software development must find find solutions for a JIT Design ("Code is design").

Inventory in Software Development 

Manufacturing inventory mean (simplified) a reserve queue of (done) products, ready to be sold. A similar concept in software development IMO is not the massive up-front documentation (based on too many assumptions) , but rather in the motive of producing a such documentation: a massive set of requirements allocated to the same release/delivery/project. "No inventory" approach means as small is possible set of requirements per release. Indeed from this point of view, the classification is already done:

• Large set of requirements releases - non-agile, non-lean approach
• Small set of requirements releases - Agile approach, Lean approach
• Very small set Small set of requirements releases - Continuous Delivery approach

An explicit description of  lean and Agile life-cycle models could be found in DAD- Disciplined Agile Delivery: https://disciplinedagiledelivery.wordpress.com/lifecycle/ 

More: With an increased construction productivity and/or a higher envisioning productivity, a larger set of requirements could be delivered in the same time. Productivity suppose here here good results and quality 

The resulted formula of "Inventory" for software development:

(Set of Requirements "volume")/productivity.

Comment: the "formula" could be enhanced to:

 (Work volume")/productivity. 

But, in this case, it is too vague.  The main aspects that increase volume or complexity of the "work" must be specified. here are some of them:

• Requirements volume and complexity at the start
• Solution that must match the requirement 
• Team productivity 
• Process

All elements of the formula are "requirements" for "No Inventory" process in software development:

• small set of requirements
• good design
• no junk stories with associated phantom features
• high productivity (all contributing aspects)
• small releases 
• adapted/effective/efficient process 

Finally, seems that starting with this assumption about a "No Inventory" approach for software development we are very close to the description of a Lean/Agile approach.

See more here:

• JIT – Just in time and Software Development 
• Two dimensions: Just in time and Envisioning

Requirements, Business Needs, Value: all together

Traditional 

The so called "traditional" approach to materialize WHAT should be done (by a software system) it  is described by "requirements". It is specified also that requirements must be prioritized, but too often that failed because of lack of focus.

Unified Process 

A simplified extension it is provided by Unified Process that define a hierarchical pyramid-like model where Business Needs are in top of Requirements, and there is a trace between each business need and corresponding requirements.

Extended

An extended approach it is described by various sources related to software engineering (Unified Process included): the relationship between target business ans software system requirements are more detailed modeled: with flows (use cases) and data. The software systems use cases/flows are integrated in the overall business use cases/flows (and also the data/information).  

Agile

The most common additional concept associated with the requirements from the Agile viewpoint it is the value (provided to the business) encapsulated by a set of the requirements.

Comments

• Traditional: seems to be incomplete, because all others are adding valid extensions
• Extended - flows and data: it is a valid conceptual model about how the business and software system are integrated in details, but seems also to be incomplete on dimension that quantify priorities of the requirements (for other reason that detailed dependencies that are clearly defined here)
• Business Needs - could be very useful because specify "requirements of the requirements". Anyway, could not describe detailed relationship between business and requirements (as flows and data) but rather most important aspects and it is useful for strategic decisions related to the requirements.
• Value - it is somehow similar with the Business Needs, but add something more: we can address the business needs better of worse, that mean we could deliver more or less value for same business needs (example: by quality and supplementary non-functional requirements). It quantify that they customer will finally receive. 

An integrated approach 

All the above approaches are correct, but all are incomplete. Unfortunately, for the sake of promoting only one method or only one approach, there are advertised - "sold" -  only some of them. It is very common these days, when Agile it is very trendy, to talk about only about value and diminish the others. A coherent and professional software engineering approach should consider all of them and use them when and where it is appropriate.

Story

We have to define WHAT the software system must do for the target business. This "what" need a name and this name it is Requirements. Anyway, these requirements cannot be defined directly, we need to be aligned to some goals and use specific practices and concepts:

• Should be a traceability between target business objectives and the requirements: we can use here the Business Needs concept 
• We need to be more precise about what we shall deliver for business (related to this business needs), and how well are addressed. Here we can use the Value concept 
• The Value help us to fulfill another goal: prioritizing requirements according to what the target business evolution needs 
• Both Business Needs and Value provide instruments to strategically manage the requirements 
• For detailed relationship between business and requirements and their integration, we can use the flows & data model. We can ignore this aspect, but in reality business and system are interacting in a such manner and we need an explicit understanding about what it is really happening. If fact that it is what we will implement and we need to be aware of that.  How much detailed representation "on paper" it is necessary, that it is a another discussion  

Conclusion: there are more aspects and dimensions on the process of managing the requirements and could be very useful to use more concepts and practices (each having its role): Business Needs, Value, Requirements, Flows and Data.

Notes

• User stories are just particular form (less structured and minimalist) of flows & data approach
• "Features" concept it is less useful because it is too generic  ( such as "functionality")