This is another post in the “From the Trenches” series about our research project on communicating the value of architecting within Agile development. I meant to post this earlier, but I’ve been in the trenches digging.
As Ipek Ozkaya discussed in our From the Trenches kickoff post, we are approaching our research on the value of architecture from the perspective of release planning. I am excited about this perspective because it moves the discussion of architecture’s value out of the realm of philosophy and into the realm of action and choice. As practitioners, we may talk to management and marketing and other decision makers about how valuable architecture is, and they may, in principle, agree. However, the real test of whether we’ve made the sale about architecture’s value is when the time comes to make investment choices, and that’s where release planning comes into play.
As part of our research, one of the books we reviewed is Software by Numbers by Mark Denne and Jane Cleland-Huang, published in 2004. The book has been influential in Agile circles, not so much for the specific algorithms that it contains, but for bringing the issue of value to the forefront of discussions on release planning. Here are a few of the concepts that we found particularly interesting and relevant to our project.
In Software by Numbers, Denne and Cleland-Huang coin the acronym MMF (minimum marketable feature) to represent a unit of software value creation. This concept really hit home with me, based on experiences from early in my development career. I was working on a PC product targeted toward several discrete market segments. Our team quickly discovered that to be successful, a given product release needed to have a sufficient “chunk of value” to make a discernable impact on the value perception of at least one of the target segments. A release strategy that provided just a little bit of functionality to all the segments would fail to make the required market impact.
We definitely plan to incorporate the concept of MMF into our research work. We are, however, toying with the idea of changing MMF to MRC (minimum releasable capability). Our thought is that changing “marketable” to “releasable” addresses internal IT and DoD projects that are not marketed, per se, but that still need to provide discernable value at the time of release. The thought behind changing “feature” to “capability” is that the term “feature” may be seen as having a bias toward functionality, whereas “capability” is broader in meaning and could more easily encompass the inclusion of quality attribute enhancements into a release. Any opinions on this proposed terminology would be more than appreciated, by the way.
Chapter 4 of Software by Numbers is titled “Incremental Architecture.” In this chapter, Denne and Cleland-Huang make the point that “architecture needs unambiguous traceability back to the needs of stakeholders so that the rationale behind each architectural element is well-defined.” Linking architecture to stakeholder value is not, of course, a new idea. The SEI’s architecture-centric engineering practices have focused for years on architecture as the key to enabling successful delivery of quality attribute requirements.
However, the authors of Software by Numbers consider architecture not from a technical perspective but from a financial perspective; that is, from the perspective of their “incremental funding model.” Within this model, they propose decomposing the architecture into a set of architecture elements that can be linked to the MMFs that they support and, consequentially, factored into an incremental release strategy. This is an interesting point of view and could certainly simplify the issue of clearly apportioning architectural cost and value. However, it also raises a host of questions such as
- What exactly constitutes an architectural element? Is it a framework, a pattern, a tactic, a mechanism, an architecturally significant component such as a piece of middleware?
- What about efforts related to architectural prototyping and technology selection? How do these costs factor into architecture’s overall value proposition, and how are they apportioned to MMFs?
- How do you account for the critical mass of architectural elements that must be present in the first release and must precede the development of any MMF?
Finally, there is the topic of how to quantify value. In Software by Numbers, the authors use rigorous calculations to determine net present value (NPV), internal rate of return (IRR), and break-even time for a project. This approach is appealing in that it clearly expresses value in the language of NPV and IRR, which are typically used in funding justifications. Also, focusing on NPV and break-even time clearly highlights the issue of MMF timing and sequencing, a key consideration in incremental development and release strategies. On the other hand, the calculations are laborious and require a high (perhaps too high) degree of precision in determining the value of individual MMFs and the impact of time delays on those values. The alternative to the Software by Numbers approach would be to use value points (similar to story points) as a relative evaluation technique. Jim Highsmith discusses the use of value points in his latest book Agile Project Management.
These are some of our ideas so far. Some are fully baked and some are half-baked but we’re making progress on what I find to be a fascinating topic. Thanks for visiting us in the trenches.
Nanette Brown – SEI