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.