Incremental Delivery of Features May Not Be Desirable

There is a popular notion in agile that incremental delivery of Features allows the project to stop at any time and deliver value to those paying for the work. This is another concept of agile that needs a domain and context and could be more meaningful regarding actionable decision-making.

We need to know what collection of features produces what business value to the customer ahead of time. Arbitrarily stopping the project may be too soon or too late. If too soon, we'll leave the current features orphaned. They won't have what is needed to provide value to the customer.

Stopping too late leaves the delivered features with partially completed work that either pollutes the functionality or prevents complete use of that functionality.

We were speaking at Homeland Security yesterday on Agile development in the Federal Government, and there was a senior director who brought up a paradigm that resonated with me.

The infrastructure for enterprise IT has a critical impact on the operational aspects of projects. The notion of continuous delivery in an enterprise like Homeland Security is an interesting discussion. That discussion is deep and broad, but a simple cartoon drove home a point.

We live in a golf course community, where our wastewater is processed locally inside our area. The Wastewater plant can be seen from our deck. That non-potable water is used to water the course, so complete recycling is the result. The grass is green, the solid waste is hauled away for further processing, and we benefit from lower costs.

Agile Incremental and Iterative Development and Deployment

Like the agile incremental house cartoon, or the bicycle morphing into a car, discussion of software's incremental or iterative development can only occur with a Product Roadmap and Release plan. With these two plans, the Product Backlog and Sprint Plans can be developed incrementally and iteratively to produce the needed Features for the customer. 

But only sometimes does a Feature standalone unless it is a de minimis project. Here's the paradigm we use for our enterprise development programs.

In the residential wastewater development paradigm, the Concept of Operations (ConOps) describes the capability to use the toilet (the Feature) only to the homeowner if the infrastructure of taking that waste from the toilet to reclaimed water is in place. The Integrated Master Plan (IMP) of the neighborhood builder shows the sequence of connecting the bottom of the toilet to the wastewater plant. The Integrated Master Schedule (IMS) shows the build sequence of the touch labor work, install all the equipment, and make all the connections.

The same is true of any agile enterprise IT product or service development. The ability to pay vendors is of little use without the ability to Invoice vendors. The Product Roadmap would show that. Along the way, each feature in the value proposition chain has to be in place in some way. 

So when you hear Continuous Integration (CI) and Continuous Delivery (CD) as buzzwords, ask if you can show me your Product Roadmap and Release Plan (either a Capabilities release plan or a Cadence release plan). In these plans, the needed Capabilities the customer expects will be shown in the proper order, with the predecessor and successor dependencies to the Capabilities delivered before and after the Capabilities needed by a specific person or business entity.

This goes along with the nonsense idea of starting with the most important Feature and keep developing until told to stop. This means someone else is prioritizing, sequencing, and funding the effort needed to produce value. The developers are then just labor, being told what to do by outside entities. That's fine, but then expect little consultation with the developers since they are not in the loop of making decisions in the presence of uncertainty.

No? Then those words are just hollow buzzwords. 

What we need is a PLAN.

A business capability deployment plan like the one below for a health insurance provider network system. This system integrates legacy systems with a new Insurance ERP system.

Project Maturity Flow is the Incremental Delivery of Business Capabilities on the Planned Need Date.

Partial completion may provide value to the customer. Or it may not, depending on what is provided. The pilot with demo-grade data conversion could do the providers a lot better as it's not real data, and it needs to be real enrollment. Getting the shared group matrix up and running can test the integration across the provider network. The real value starts when real data is in the Data Mart and accessible by the new ERP system.

So Once Again

When we hear the platitudes of deliver early, deliver often, or incremental delivery can be stopped at any time and value delivered to the customer, please ask for a picture like this and have that person point to where and what on the picture can be stopped at what time. 

Building this picture is part of Project Governance. Part of the business management planning process is how and when to spend the customer's money in an agile emerging domain where requirements change. But it's not about coding and the needs of the coders. It's about business management and managing in the presence of MicroEconomics of Software Development. This project governance paradigm should be in place for any non-trivial effort.

Incremental Development DoD Style

The notion that Government contracts are somehow "Big Design Up Front," "Waterfall" behemoths are not only misinformed, it misses an important concept of the "increasing maturity" as a critical success factor for any large program - including, and especially including Enterprise ERP style programs. The key concept here is

What does done look like in an incremental manner?

No, in the normal agile manner of a list of requirements from the business that are worked down in the form of a "burn down" chart. But CAPABILITIES are needed at each point along th road to completion. Capabilities that define how the business case - or the mission - will be accomplished along the way.

  The requirements for the development team are derived from these capabilities. Systems Engineering Technical Review Timing defines this concept in the government domain.

At each Program Event, there are maturity assessment criteria that can be downloaded. NAVAIR has a very sophisticated approach that is used by other services. The idea of direct use could be more practical. But the "Notion" that incremental maturity planning provides physical percent complete measurements, incremental capabilities (ala Scrum), and direct measures of increasing business value. The real measure of value in the agile sense.

And the Final Notion

Of course, to do this successfully, we need estimates of everything to ensure the business plan will be met with some degree of confidence. Time to reach a useful capability, cost to reach that capability, risks in reaching that capability as planned, resource demands, and a myriad of other random variables. We can decide on business choices with this information and a statistical model (Monte Carlo, COD, Method of Moments, Design Structure Matrix, Probabilistic Value Stream Map).

Without these processes, any non-trivial project is just coding until time and money runs out.