Priorities in agile software development

After discussions with friends, family and work colleagues over the past few months it became apparent that we all have a different idea on what priorities are and how do we identify priorities. Here are my thoughts on the matter.
Why prioritise?
It’s very dangerous to ask staff and customers what they want to see in the next release. The result is a mixed wish list of the most amazing things. By the time you’re ready to start development, you’ve got enough ideas for improvement to occupy 500 programmers for a few decades.
Unfortunately, all you have is three, and we wanted to be shipping within 6 months, so there has to be some prioritisation. Time is an important resource, and we have a limited amount of it. With software, one does not have the luxury of a long development period to bring a product, or a new release of an existing product, to the market. Potential new customers will not be interested in a product that does not improve on a regular basis. Someone else may do it quicker. Your customers may migrate to a different solution that has the feature(s) they are looking for.

Capacity must be influencing our priorities. Because capacity is time based, our priorities are time based. Too many software development teams suffer from ‘inflation of time’; that is to say, they devalue future time by using it to solve present problems. The problems may not be the most important ones to solve today. Of course, the time spent on one thing means that some other activity remains undone. Each time we put off a portion of our work to do at a later date, becaue we haven’t time to do it today, we are devaluing future time in the sense that we now have less of it.

There can be a tendency for people to avoid the hard decisions and use capacity, or estimation of effort to set the priorities. For example, if the risk management feature takes more effort to implement we’ll go with the loan book profitability feature instead. While capacity is effective in determining what to do with activities of the same priority, it is not the only influencing factor in establishing a prioritised product backlog. There may be features that are must haves for the next release. They may be expensive to implement, but without them market share may not grow. This is where market research is really important. The product owner must be able to say: “To get the risk management feature we can sacrifice the loan book profitability feature because risk management addresses a need for a broader range of potential high value customers.” The product owner must also have the courage of their convictions and vision, based on their research and understanding of the market. Just because something is difficult does not mean it is not worth doing.

Prioritisation pitfalls

Sometimes certain features or activities can appear to be important and necessary in the next release. Here are some prioritisation pitfalls. If you find yourself condsidering this sort of features in your next release, spending some more time on research, verifying the importance.

Single customer requirements

It is generally cheaper to get new business from existing customers than it is to get new customers. Having customers can cause it’s own headaches, particularly if your sales person has sold the customer a product you don’t sell. This happens a lot more than it should, and opens the door to legal hassles that are just not worth the effort. Even when this doesn’t happen, there can often be enhancements suggested by your customers. Many of these will make sense, others may be bespoke features that no one else is interested in. Building features into your software based on single customer requirements implies that you are actually building consultant-ware, not shrinkwrap software. Shrinkwrap software is better than consultant-ware. That’s because shrinkwrap has no marginal costs for each additional customer, so you can essentially sell the same thing over and over again and make a lot more profit. Not only that, but you can lower the price, because you can spread your development costs out over a lot more customers, and lowering the price gets you more customers because more people will suddenly find your now-cheaper software worthwhile, and life is good and all is sweet. If you have customers that are requesting unique features not no other customer is requesting, then perhaps the real priority feature is a plug-in architecture, rather than the business feature.

Perceived inevitable requirements

Good software developers often think in the abstract so that the real implementations are more reusable in concrete scenarios. However, just because something is the next logical thing to do, does not mean it is the most important thing to do next. For example, a system may have a notification module with SMTP and SMS interfaces. A logical next step would be a XMPP interface for instant messaging. Such a feature may be interesting for the developer to work on, and may even give the marketing department something cool and trendy to draw attention to, but is it a deal clinching feature? Are more customers looking for this feature than some other feature, such as not notifying people who are on leave, but they’re deputies instead?

Prioritise interface that the user sees

There is one category of features that software developers may subconsciously discount. I’m referring to what the end user interacts with as a tool to for their job. The interface with your software may not be the GUI, but also a web service or a device. These deserve our attention because they increase the awareness of the value of what we can do with technology. Nobody sees a shared library or a driver, and no one cares about them, unless they’re broken. Yet that’s where software developers can tend to focus much of their time and resources. Doesn’t this contradict an earlier point about building a plug-in architecture? No. The motivation, in that case, to build something that the user does not see, is to provide a sustainable and cost effective solution so that the customer gets what they want (a business feature) without you having to provide it or maintain it.

A prioritised list, reflecting the capacity of the team, and what the business value of the new features are makes for a more sustainable (if no one pays for it, who pays the team) development effort down through the years.