Listen Now

Subscribe on iTunes

The Software Process and Measurement Cast 373 features our essay #NotImplementedNoValue. The twelve principles that underpin the Agile Manifesto include several that link the concept of value to the delivery of working software. The focus on working software stems from one of the four values, “Working software over comprehensive documentation,” which is a reaction to projects and programs that seem to value reports and PowerPoint presentations more than putting software in the hands of users. For a typical IT organization that develops, enhances and maintains the software that the broader organization uses to do their ultimate business; value is only delivered when software can be used in production.

We visit Gene Hughson’s Form Follows Function Blog!  Gene suggests that while most models have value, some models are can lead to poor decisions.  The punchline for the discussion is “Simple is good, but not when it’s too good to be true” Gene builds the case that we need to be cognizant of our biases when using and building models.

(more…)

Hot air balloons and helium balloons

They are all balloons! Using the right word is important for understanding!

The idea that a flow of value to users is at the heart of concepts such as #NotImplementedNoValue and #NoProjects. At the heart of the flow of value is a conundrum. That conundrum is entwined in three terms; price, cost and value.  These three terms are often conflated, despite representing very different ideas. When project teams or product owners use price, cost and value interchangeability they can easily make the wrong choices as they they lead value through the development or maintenance process.

Price is often equated to value. We have all heard “you get what you pay for.” As anyone that has had to bid for a project will tell you, price is a significantly more nuanced than a straight translation of value. Price is defined as the amount of money given in payment for something. Price can also refer to an unwelcome experience or condition required to achieve an end. The act of pricing is dance between what can be charged and the strategy of the seller (think Game Theory). I have heard sales people suggest that they price the first deal to get in the door in order to prove the value of their product or service; therefore the price of any individual transaction might not be directly related to value. All software transactions must be viewed across the life of the software and the life of the relationship with the provider.  Bottom line: Price of any individual transaction is only loosely related to value.

Cost is a “simple” concept. The use of the term simple is very tongue and cheek, as costs often include labor, materials, office charges, hardware, business changes and opportunity costs. In a commercial product, cost and price are connected by the margin. The discipline of having to maintain a positive margin over the long term mean you need to understand the relationship of cost to price and later value. Most internal IT organizations do not face the long-term discipline of the market, and often only have to manage labor costs, which can lead to poor behaviors. One example of poor practice is substituting labor for automation because automation has a higher upfront cost (resisting test automation software for example).

Value is defined on Dictionary.com as ”relative worth, merit, or importance.” Value measures range from profit and revenue, to a relative measure based on the perception of what an individual or group will get from a service or product. To make matters more complicated, the perception of value changes based on context, which can affect what can be charged. For example, water has significantly more value to someone dying of thirst than a person sitting in their kitchen drinking a glass of water. Value can be seen as the interaction between factors that include global or organizational impact, individual benefit and the probability of use. Many people use cost and price as tools to help determine value.

Price, cost and value are related. Cost plus margin will always equal price for a specific transaction. Over the long run, pricing any specific transaction below the typical margin or at a loss may make strategic sense. Examples might include capturing market share or getting in the door. But in the long run, pricing too many transactions below cost is catastrophic. The link between cost and price is more tenuous, because even if measured using hard currency the amount of value is affected by perception. In order to pursue concepts like #NoProject or #NotImplemnetedNoValue you need to have a handle the nuances of price, cost and value so that you can understand and talk clearly about the value derived from each story, feature or epic. Falling prey to conflating price, cost and value will yield a conundrum that will impact the decisions we make about what to deliver and when.

Programming Note: We will dive into value in more detail on Thursday.

Does writing throwaway code to generate information and knowledge have value?

Does writing throwaway code to generate information and knowledge have value?

When we talk about implementing software into production at the end of each sprint (or for the more avant-garde, continuously as it is completed) as the value that a team delivers to its customer there is always push back. Agile practitioners, in particular, are concerned that some of the code is never implemented. If unimplemented code does not have value, then why are development teams generating the code they are not going to put into production? The problem is often exacerbated by the need of the developers to get credit for the most tangible output of their work (which is code), rather than the knowledge the code generates. In order to understand why some of the code that is created is not put into production, it is important to understand the typical sources of code that does not get implemented: research and development (R&D), prototypes and development aids.

Research and Development (R&D): R&D is defined as the “investigative activities with the intention of making a discovery that can either lead to the development of new products or procedures, or to improvement of existing products or procedures.” R&D is not required to create a new report from SAP or a new database table to support a CRM system. In R&D in an IT department, researchers generate experiments to explore ideas and test hypotheses, not to create shippable products or an installed production base of code. The value in the process is the knowledge that is generated (also known as intellectual property). Credit (e.g. adulation and promotions) accrues for generating the IP rather than to the code.

Prototypes: Prototypes are often used to sort out whether an idea is worth pursuing (this could be considered a special, micro form of R&D) and/or as a technique to generate and validate requirements. Prototypes are preliminary models that, once constructed, are put aside. As with R&D, the goal is less to generate code than to generate information that can be used in subsequent steps in solving a specific problem. As with R&D, credit accrues for generating the IP rather than to the code.

Development Aids: Developers and testers often create tools to aid in the construction and testing of functionality. Rarely are these tools developed to be put into production. The value of this code is reflected in the efficiency and quality of the functionality they are created to support.

Whether in an R&D environment or at a team-level building prototypes or development aids, does writing throwaway code have value? While this question sounds pedantic, it is a question that gets discussed when a coach begins to push the idea of #NotInProductionNoValue. The answer is to focus the discussion on the information and knowledge that is generated.  In the end, it is the information and knowledge that  has value that will move forward with the project or organization even when the code is sloughed off. When testing an assumption keeps you from making a mistake or provides information to make a good decision, doing whatever is needed makes sense. However, it is not the code that has value per se, but rather the information that is being generated.

Side Note: Many IT departments have rebranded themselves as R&D departments. The R&D metaphor evokes the sense that IT Departments are identifying products and leading the business. In some startup and cutting edge technology firms this is may well be true; however, generally the use of the term is a misnomer or wishful thinking. Instead most IT departments are focused on product delivery, i.e. building solutions based on relatively tried and true frameworks and methods. If you doubt the veracity of that statement just observe the amount of package software (e.g. SAP, PeopleSoft) your own organization supports.

Music on the page is just a potential. Like software, it changes when it is implemented.

Music on the page is just a potential. Like software, it changes when it is implemented.

The twelve principles that underpin the Agile Manifesto include several that link the concept of value to the delivery of working software. The focus on working software stems from one of the four values, “Working software over comprehensive documentation,” which is a reaction to projects and programs that seem to value reports and PowerPoint presentations more than putting software in the hands of users. For a typical IT organization that develops, enhances and maintains the software that the broader organization uses to do their ultimate business, value is only delivered when software can be used in production. Implementing software provides value through the following four mechanisms:

  1. Validation – In order to get the point where software is written, tested and implemented a number of  decisions must be make.  Implementing functional software and getting real people to use the software validates not only the ideas that the software represents, but also the assumptions that were made to prioritize the need and build the software.
  2. Real life feedback – The best feedback is generated when users actually have to use the software to do their job in their day-to-day environment. Reviews and demonstrations are a great tool to generate initial feedback, however those are artificial environments that lack the complexity of most office environments.
  3. Proof of performance – One of the most salient principles of the Agile Manifesto is that working software is the primary measure of progress. The delivery of valuable working software communicates with the wider organizational community that they are getting something of value for their investment.
  4. Revenue – In scenarios where the software being delivered, enhanced or maintained is customer facing, until it is in use it can’t generate revenue (whether the implementation is a new software supported product or improvement in the user experience of an existing product).

In most scenarios, software that is both in production and being used creates value for the organization. Software that is either being worked on or sitting in library waiting to be implemented into production might have potential value, but that potential has little real value unless it can be converted. In batteries, the longer we wait to convert potential energy into kinetic energy the less energy that exists because the capacity of the battery decays over time. Information, like the capacity of a battery, decays over time in any reasonably dynamic environment. Software requirements and the ideas encompassed by the physical software also decay over time as the world we live and work in changes. Bottom line: If the software is not in production, we can’t get value from using it, nor can we get feedback that tells us that if the work environment it will someday run in is changing; therefore, all we have is a big ball of uncertainty.  And, as we know, uncertainty reduces value.