The MoSCow model, at least when I tried to implement it, suffered from the Priority 1 Paradox:

The more we ask customers to narrow down priority 1 features the more they’ll be scared to leave anything out of that category.

The complaint is always the same: everything must be there – especially all the old functionality when replacing a legacy system. Prioritising so that most of the stuff ends up as ‘Must’ pretty much defeats the point of the exercise.

I am currently reading Stand Back and Deliver: Accelerating Business Agility by Niel Nickolaisen and colleagues from Accelinova. Among other interesting ideas, I found a real gem. This book advises aligning business processes (equally applicable to software features) along two axes: mission critical and market differentiation. Nickolaisens calls this the Purpose Alignment Model:

In a case study, the authors describe a discussion with a stakeholder who claimed that their IP protection was a differentiating factor. The authors then asked the VP of sales ‘When was the last time you sealed a deal by touting Lifebrands’ excellence in IP protection? When was the last time you felt you should include the IP protection process in sales presentations and collateral?‘ (pp 36) They also offer a simpler version of this rule of thumb as a Billboard filter:

Would you put this feature on a billboard?

If so, the feature is obviously differentiating and should be invested in. If not, this feature falls into the parity category at best. The introduction of the parity category which, as the authors repeatedly point out, holds mission-critical features which are not billboard material, seems as a great way to avoid the Priority 1 paradox. This is to intentionally avoid the feeling that anything not Priority 1 won’t be delivered. The system must have these things too offer a full service, but it just isn’t worth investing too much or being too creative there. Nickolaisen and co-authors suggest that the Parity category is where companies should apply industry best practices and streamline processing.

Overdoing it in this category might actually be damaging to the bottom line. In another case study, the authors describe a project to automate complicated pricing rules. After it was identified that complex pricing isn’t really billboard material, the project was completely turned on its head. Instead of implementing a complex rule engine, the pricing system was streamlined using industry best practices. It turned out that customers were actually happier with the new model, so simplifying a parity process increased the revenue. This was possible because the stakeholders agreed that while the company must have an automated pricing system, it wasn’t a core differentiating factor.

Strategic design ideas of Eric Evans also suggest some good guidelines what to do with such software: if the thing is available off the shelf (generic domains), buy it. If not, possibly get a third party to develop and maintain it. Evans calls these domains supporting, and they are prime candidates for outsourcing.

This article is part of my Building software that matters series. See other articles here

Btw, I’ve created a mailing list for this topic so rather than commenting here, post your comments to the Building Software That Matters mailing list and let’s discuss them!

Image credits:Steve Rhodes

Developers prefer to talk in terms of value generation without developing related revenue projections. Business stakeholders usually don’t realize that delivery sequences and architectural options have a significant impact on project level ROI. Clearly, software development requires a more financially responsible approach […]. This situation clearly calls for a close collaboration between developers and business stakeholders.

The previous paragraph pretty much sums up the basic idea of Software by Numbers: Low-Risk, High-Return Development by Mark Denne and Jane Cleland-Huang. Iterative delivery and fast roll-out to production makes perfect sense and I do not think that anyone can doubt that, but can you actually put a value on it? Can you compare two alternative delivery plans for the same project? Denne and Cleland-Huang set to do exactly that. By developing a financial model to evaluate and compare delivery plans, the authors show how to make an informed decision about prioritisation on a project so that it maximises the desired financial effect, either reducing risk, optimising cash-flow or return on investment.

Denne and Cleland-Huang explain how to identify and evaluate the financial impact of Minimum Marketable Features, including “intanglibles” such as brand value or customer retention. Then they develop a system of heuristics that combines this information with technical and architectural constraints, prerequisites and timing constraints to come up with the best possible delivery plan, depending on what you want to achieve. Through several case studies, they show how just choosing the next most important thing isn’t as nearly as effective as considering the financial impact of the entire delivery plan. Somewhere in the middle, they also come up with a way to estimate the financial impact of the project by forces other than black magic which helps us answer a key question: should we do this at all or should we do something else?

Effect Managing It, by Mijo Balic and Ingrid Ottersten, deals with things that happen even earlier in the process – coming up with a list of features to achieve the desired business effect. Instead of focusing on functionality, Balic and Ottersten look at software projects as agents of business transformation. The authors argue that the ultimate goal of software projects is to achieve a business change, and that one of the key reasons for failure of so many projects is that the focus is often on the wrong things. They explain a model of structuring requirements analysis in a way that ensures achieving the desired business effect. That focus on business impact, not functionality or technology, is what they call “Effect Managing”.

Effect Managing shares many key ideas with behaviour-driven development and agile acceptance testing, but deals with things that are much earlier in the development cycle. Balic and Ottersten base their model on first considering who can deliver the desired change (stakeholders in the BDD lingo), then thinking about how these people can deliver it and what the software needs to do to support that that. Organising all these ideas in a hierarchy which they call an “Effect Map”, this model provides visibility similar to the Goals-Features-Requirements model, but in my opinion much more effective because it is visual. After trying out effect maps on two projects, I’m astonished how they open up a discussion and provide structure to the process of selecting the features for a project and probably equally important throwing away features that are less important.

Be warned, though, that both books are relatively hard to read. Although they are short, less than 200 pages each, the flow of ideas in both books is a bit hard to follow. Effect Managing IT at times reads like a literal translation (from what I understand, the original book was written in Swedish) and Software by Numbers is full of financial tables and formulas. Nevertheless, I think that both books have such great value that getting through them is well worth it.

Quality over speed

Although most agile literature focuses on fast feedback as the primary idea to align software with customers’ needs, it seems to me from the discussion that the quality of feedback is more important than the speed. A good idea to improve quality of feedback was to invite passionate users to join in, giving them early access and allowing them to influence the product. Another good idea was to observe how the software is actually used (I proposed that as the new year’s resolution in 2008 on this blog, and considering that the new year is coming soon again, maybe it’s time to repeat that proposal).

Release and then measure

Of course, this doesn’t mean that quick feedback is not important. Finding whether we’re going in the right direction quickly is key to successful software development. One idea to improve this is to focus early deliveries on the smallest chunks of software that could provoke and provide meaningful feedback. Expanding on that idea, we discussed rapid prototyping instead of analysis. I must admit, I’m not completely in favour of that idea (and I recently wrote against releasing unpolished software), but this might work better for mass-market than in-house software which I mostly do.

This led to a discussion on the idea of releasing a bunch of features quickly and then asking the users to choose which ones they like and which ones should be binned. 37 Signals and Twitter were mentioned as examples for this, releasing and then dropping many features that didn’t work. The key to do this successfully for mass-market applications such as web sites is to have good monitoring on feature usage. Tealeaf customer experience monitoring was mentioned as a tool to support this.

Another idea on how to improve the quality of feedback is to build feature partitioning into the system, enabling features to be turned on and off on demand. This supports measuring effects of individual features. It also allows the system to gracefully degrade services if it starts running out of capacity. Mixcloud was mentioned as a good example of this in practice.

The right sample

As an idea how to improve the amount of feedback we can get from end-users, we discussed giving something in exchange for feedback. This is probably most applicable to web sites where you can give users small gifts or virtual goods in exchange for filling in a form.

We also discussed how choosing the right sample was crucial to get good feedback. An idea that I especially liked was to align the sample with user personae chosen for the project. Clearly defining the target market before a project starts and basing the feedback sample on that is one of those things that seem common sense but are yet to be adopted by software community at large. Another key idea for mass-market software was gradually growing the sample. An example of what can happen if you only listen to early feedback of a small group is the ISnack 2.0 blunder. Kraft foods chose ISnack 2.0 as a new name of their Cheesybite product based on positive feedback from focus groups, which provoked “Facebook hate groups, blogs and angry Tweets [..] and T-shirts trashing the name” when it went public and finally causing the company to admit defeat and bin the name.

Here’s the updated mind map with all the ideas from both workshops:

Some more food for thought

Adewale Oshineye spoke about one of his earlier projects (from what I remember, for Dixons) where an uncaught security bug turned out to be a very important feature allowing stores to share information. This reminded me of one of my projects where a feature essentially developed for easier testing of a network flow algorithm proved to be a key selling point for a system (I wrote about this already, see Blinded by the user interface). Jeff Patton said that both these stories are examples of value produced by accident, and then raised probably the most provoking question of the session: How do we intentionally discover features that users have not even thought of but that could bring a lot of value? This question was, unfortunately, left without an appropriate answer. Round 3 of this discussion is scheduled for the SPA conference next year in May, and this will surely be one of the major themes of that workshop.

See other articles from XP Day 09

Increasing visibility

A common topic in the discussion was increasing visibility, both the visibility of business value to developers and visibility of developer progress to business. We discussed different metrics to increase visibility of the progress, but this turned out to be quite a tricky subject. One interesting metric mentioned was cycle time, how much it takes to get a story from the backlog into production. This would require that stories have a fairly normalised size though. The conclusion for me is that metrics make it very easy to slide towards efficiency but not effectiveness (with the example of a hamster in a cage which might spin the wheel very efficiently, but going nowhere), which also lead us to the fact that teams should be aware where does the value come from and define what success looks like before a project starts. Ensuring that everyone knows the answers to these questions would significantly increase the value visibility and help people prioritise better.

Some interesting examples of what companies do to increase visibility were estimating technical debt with monetary value (how much will it cost to fix it) and assigning monetary value to stories (how much benefit will it bring) and implementation estimates (how much will it cost to make it). Although everyone agreed that getting these figures right would be a challenge, even rough estimates can help immensely to set the priorities and ensure that we’re building the thing of greatest value.

Another challenge mentioned is actually measuring how much value features bring when they are in production and do they justify the cost of maintenance. We all agreed that it is very hard to measure effects of individual features, but A-B testing was suggested as a way to to measure this. In A-B testing, a part of the system runs with a feature and a part of the system runs without it, and then the results are compared to determine the effectiveness of that particular feature. This approach has additional management overheads and risks involved though.

Waste

Unsurprisingly, the discussion often touched upon lean software development principles and looking at what causes waste in the process. Two good books mentioned about this were Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck (ISBN 0321437381 Addison-Wesley 2006) and Agile Management For Software Engineering by David Anderson ( ISBN 0131424602, Prentice-Hall 2003). Anderson is also apparently working on a new book related to this subject. Additional suggested resources for Lean Software development included Lean Conference 2009 videos, David Anderson’s blog , Karl Scotland’s blog , David Joyce’s blog and the Agile in action Blog.

A common theme in the discussion on waste was building too much software, where people did not know whether they really needed it. As a possible solution for the problem we talked about the DDD core domain idea, where companies should focus on identifying a very small core of the system that makes it worth building, something that brings direct competitive advantage, and source the rest from external providers or buy off-the-shelf solutions. Core domain is explained more in Domain-driven Design: Tackling Complexity in the Heart of Software by Eric Evans (ISBN 0321125215, Addison-Wesley 2003).

Another source of waste was building “nice to have” features suggested by the business but not really bringing any value. As a possible solution for this, we talked about the Goals-Features-Requirements breakdown (a variant of which is Goals-Stories-Acceptance tests) where each feature introduced into the system has to be connected directly to a stated project goal, and each requirement has to be directly connected to a feature. If the person suggesting a requirement cannot name a feature (or likewise someone suggesting a feature cannot justify it by naming a goal), this gives us ground to push back and reject scope creep. This idea comes from The Art of Project Management by Scott Berkun (ISBN 0596007868 O’Reilly 2005).

The development counterpart of this is just-in-case code, something that developers decided to put in because they think it is needed. This was called the biggest source of waste by Mary Poppendieck in the Lean Software Development book. As possible solutions for this, we discussed specification workshops and agile acceptance testing – explained in my book Bridging the Communication Gap Specification By Example and Agile Acceptance Testing (ISBN 0955683610, Neuri 2009). As the answer to the problem ‘we know that we’ll need it soon’, we discussed a fine line between making the system flexible to accept a future change and actually building in flexibility. The former would involve isolating a piece of code that we know is going to change, the latter would involve actually building in a very flexible framework to start with. The conclusion was that very often these complex flexible frameworks don’t pay off as requirements might change and the requested flexibility never actually makes it into the product.

The fourth related cause of waste was working on a problem that people don’t know enough about and identifying that too late. Specification workshops are also a solution for that.

UI design and redesign was also perceived as a common source of waste, perhaps because all the people in the room were developers. Someone suggested Yahoo’s UI design pattern library as a good source of information to make this process quicker and easier.

Prioritisation

The last major theme of this discussion was prioritisation – how do we actually decide what to build first and how to deliver value quickest. Value visibility certainly helps, and assigning monetary value to features and costs of production might help prioritise. There was a concern though that only low-risk features would ever get implemented by this, but we concluded that this would probably be pushed back to the business and they would be able to decide how much risk they want to take.

We also discussed the difference between iterative and incremental development and how that helps with prioritisation – rather than asking customers to prioritise between a car door and an engine, for example, we could ask them to prioritise between a car with a poor door system but a great engine and a car with great doors and a poor engine, delivering a car that they could use in any case. This is explained in a lot more detail by Jeff Patton (also see Alistair Cockburn’s response and my write-up of Patton’s keynote at XPDay 07).

Having a map of goals to stories and tests makes it easier to prioritise as well, because business should be able to prioritise goals and we can derive priorities of lower levels based on that.