How Agile Are You Really?

Although there are still companies out there that are going through the agile transformation, most of the companies that I work with have adopted agile practices at least at the team level. Agile teams are more empowered and because of that, among others, more productive and more motivated. However, if we lift our focus up from the team level to the R&D organization and we include product management, architects, R&D departments, verification and validation departments, release organizations and customer support, the adoption of agility at that level is sorely lacking in many companies. At that level of R&D, yearly release cycles, aligning software release with the release of mechanical and electronic products and other “aim for a goal in the far future” waterfall-ish approaches are still the norm.

For all the chest beating that many companies do concerning their agile teams, in many ways very little has changed if we look at the end to end product development process. The reason for this is that most companies are focused on efficiency. They are concerned with getting as many features built per time unit, measure and increase flow, etc. In many companies, R&D is still view as a machine that we throw requirements into and out come products or at least the software that makes it into embedded products and systems. And if teams feel that by working agile, they can crank out products faster or with more features, the rest of the organization is willing to indulge them.

The problem with only adopting agile at the team level and focusing on efficiency is that it is based on a false premise: it is based on the belief that more features will make the product more valuable for the customer. In an earlier blog post, I have discussed research by us and others that shows that half or more of the features in a typical product are hardly if ever used. As a consequence, in another blog post, I share that in many companies 80% (or more) of R&D resources are spent on commodity functionality. The challenge for most companies is not to get more features out, but to get the minimal set of most valuable functionality embedded in the product. In the words of Antoine de Saint-Exupery: “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

Especially in B2B companies, the standard argument against my line of reasoning is that the customer asked for the feature. This is often followed by the argument that although perhaps some customers are not using it, other customers did ask for it. The fallacy in this argument is that although it is important to listen to what customers say, in the end the real proof is in the actual user behaviour: do users actually use the feature that they said they wanted. In most cases, there is a major, if not huge, gap between “espoused theory” (what people say they do) and “theory in use” (what people really do).

For most of the 20th century, companies did not have the means to measure user behaviour, but with every product that has some inherent value becoming connected to the internet, our ability to measure customer and system behaviour has become orders of magnitude easier. The ability to measure what customers do instead of what they say they do allows companies to finally shift from a focus on efficiency to a focus on effectiveness.

Effectiveness is concerned with maximizing the amount of customer value created for each unit of R&D resources. Obviously, building features that are hardly ever used by customers is not a very effective use of R&D resources. Instead, we need a process where we first collect qualitative customer feedback that makes it likely that a new feature will deliver value. Based on that we build a slice (maybe 10%) of the feature and get it out to customers and measure system and customer behavior. If the behavior is not in line with expectations, meaning that it is not providing value, the feature can and should be cancelled and removed from the system. If the feature does deliver value, the team can iteratively add more functionality until the delivered value plateaus and then end development of that feature and move on to the next. In a research paper (reference below), we described this process that we called the HYPEX model.

Figure: The HYPEX model

Concluding, for organizations to become truly agile and to transition from a focus on efficiency to a focus on effectiveness, it is not sufficient to have agile teams. Instead, the entire organization needs to operate in an agile fashion, support continuous deployment and enforce data-driven decision making. Once we have data concerning customer and system behavior, we can measure whether we are delivering value or not. This, in turn, allows us to stop development of features that do not, remove features that are never used and double down on the features that add most value to customers. To stay competitive, your best bet is to adopt agile across your organization, not just in teams, and to focus on effectiveness, rather than efficiency.

Reference: Olsson, Helena Holmström, and Jan Bosch. “From opinions to data-driven software R&D: a multi-case study on how to close the ‘open loop’ problem.” Software Engineering and Advanced Applications (SEAA), 2014 40th EUROMICRO Conference on. IEEE, 2014.