What’s your Choice: Valuable Vs Shippable Software

Valuable + Shippable is indeed what you should achieve.

Software development and delivery is challenge with lower success rate to fully meet customer expectation. And it is always facing the dilemma to leverage on time, on budget and on value. Many people ship on a certain date and then suffer the consequences when value was not present. These firms ship because of pressures by management or because some contract said that they had to. What was shipped in these cases was software that did not work well or as expected. So valuable vs. shippable software, what’s your choice? Do you generally consider Valuable + Shippable Software = Working Software?

It’s important to determine value early in the development process. It is common to ship software that you do not know the value. Seems like a flaw. Shippable Software not working is clearly having no value. The value of the software should be determined from the very beginning of the process by getting it into the hands of real users and responding to their feedback. The product owner and development team are not omniscient. Minimizing the time and effort before validating value allows one to determine whether to continue developing capabilities or stopping and going in a different direction. It’s important to determine value early in the development process in order to be able to either kill or "pivot" change the fundamental nature of a product as early as possible. So often working shipped software is the best way to get feedback - Sometimes the amount of up-front work you would need to do to get an idea in front of enough customers, stakeholders, and others to know how valuable it takes more work than coding it, shipping it, and testing it. So you need good inspection and metrics to notice and you need to adapt quickly with agility from knowledge to next shipment, so there is a strong customer perception that when an issue comes up, it will corrected!

Only customers can value your software. No like inventions in lab in the other domains, which could be "valuable" even before any production, software has to be used in order to be valuable. In other words, value could possibly be realized only after the software is shipped.

Valuable - the feature has some value on its own to the customer. It is worth doing provided the value exceeds the cost by a sufficient amount. A feature that the customer would never use has no value. a feature that a customer might use, but that doesn't do anything useful probably has no value…

Shippable - You can deliver the feature as - is, to the customer, and no harm will be done. Once software is shipped, value can be received in multiple ways. A feature is validated as useful to the customer. A feature is determined not to be useful to the customer, only customers can value your software. Just because it ships doesn't mean it will provide value. There are plenty of examples of products that shipped but were failures because they weren't validated and didn't address a customer's need or desire (which is the true measure of value).

If product is shipped, there are three possibilities concerning value. If nothing is shipped, one is relying on projections to determine whether the eventual deployment will actually provide value.

-The best case is that the product is shipped and provides benefit to the target audience. In this case, the projection has been validated and the team should continue on the projected path.

-A second situation is that the product is shipped, but no detectable benefit is realized. In this case, the projection has been disproved and the team should identify a new path and discontinue the current path. This limits the amount of effort expended on non-productive effort.

-The third case is that the product is shipped, but is found to actually be detrimental. In this case, the projection has be determined to be greatly off track, and the team should roll back the latest change and drastically identify a new direction. This limits effort and out-and-out damage due to a mistaken projection.

The real outcome to aim for should be to ship a valuable solution. The only time you should set a goal to be shippable is if value is already inherently in the solution. If the product increment is valuable at the end of iteration according to the Definition of Done then that increment is shippable. Valuable increment must be shippable and shippable increment must be valuable. Every team must have definition of valuable and shippable product increment based on their nature of work and business people expectations. Shipping the wrong product on time and within budget doesn't benefit anybody, particularly the company. You'll hardly make money by shipping a product that has no value to anybody, and that's the goal, after all: making profit. Agile provides you an advantage because you can ship with value and still make deadlines if the customer representative agrees with the scope and the backlog is documented and managed. You don't have to sweep the software problems under the rug and wait for the consumer or those maintaining the system to find them later when you are gone.

You can only manage what you measure. It is common to ship software that you do not know the value. Sometimes software you believe to be valuable will sometimes turn out to test poorly and need to be removed. In the final analysis it was shippable but not valuable. In the long-run and on average what you ship must be valuable but any given shipment may not be. A high performance company that is analytics driven knows this and freely accepts they will ship software that ends up being of no valuable. Spending money on metrics to learn the in-production value of things produces great returns. It has been that often when a feature is shipped to the field the metrics give you a different story than any upfront work you did with a limited release or a limited set of users. It has usually indicated that the misalignment in the value understanding pre-shipment compared to post-shipment (metrics evaluated) come down to one or more of the following:

A) You have no idea why it did not test as well in product as it did pre-production.

B) Your pre-production test sample was not large enough or not representative enough.

C) The live user based discovered an aspect of the feature or product that was not apparent in the pre-production tests.

To succeed, you need to ship valuable software. The answer, then, is "both." Valuable + Shippable. There is neither a dichotomy or a line to be drawn. There is never a circumstance where one triumphs over the other. Valuable + Shippable is indeed what you should achieve. Product Owner in Scrum should take care of "building the right thing" while the development team is responsible for "building the right thing right." In some situations the development team would like to reduce the functionality to build shippable product increment within the iteration. The question is how to decide if it is still valuable? Making the stories smaller and ordered in terms of value may help in such cases - the team should just make them one by one leaving the least valuable unfinished. You should be focused on the customers business needs and values. Then look for ANYTHING the team can develop to get them there.

Posted in: Agile,Project Management