Project management software, and the project management practice in general, should include a Return on Investment feature.
The problems with modern-day implementations of Agile and its various flavors have already been detailed by many (here’s my favorite), but like it or not, the practice is here to stay. That is, here to stay until the backlash becomes so strong that the same entities who sold its unsuspecting victims on the practice are forced to go back to the drawing board and invent (or rather, vampirically subvert) another methodology that will in turn be sold back to the same companies.
Rather than complain and suffer under the tyranny of poorly-implemented Agile practices, software development teams can help lessen the blow by requesting the return on investment for each user story or feature be committed to by business/product/UX folks. Just as developers commit to X number of user story points during iteration planning, those driving the requirements would also commit to a quantifiable – or qualifiable depending on the context – return for the feature. Agile project management software holds developers to high levels of accountability through its various tracking mechanisms. Adding a ROI feature would bring the same accountability to product requests and ensure they are thought out enough to warrant putting the work in the developers’ queue. If you’ve ever worked with bad product managers, you’ll have seen the negative consequences that random, thoughtless feature requests have on your technical team.
Implementation of this idea is not meant to be dogmatic, as there are certainly many plausible scenarios in which quantifying such would be impractical. Some business features are pure experimentations, just as technical spike user stories are often meant to be exploratory, and we shouldn’t inhibit experimentation. But there is a huge difference between experimentation, which requires a hypothesis, and absent-minded, I-have-no-idea-what-I’m-doing, throwing requirements and features at the wall and seeing what sticks. Just as good developers will question and test their code, good product folks will question the necessity of their requests and have a clear vision of the benefit their request will bring to the user, to the product, and to the company in financial return.
Another point to make very clear is that this proposition is not meant to divide the business and technical teams. Quite the opposite. The best product managers I’ve worked with have been empathetic towards the technical team while also understanding the big picture enough to understand where a user story and its value fits within the overall product or project. Likewise, some of the best technical people I’ve worked with have demonstrated a solid understanding of how their code ties to a particular feature and the value that code brings to the business.
For developers, this suggested change in Agile practices even presents an opportunity – an opportunity to become more than a code monkey by contributing to the product and business. Few words have saturated the conversation around the alignment of business and technology as much as “yeah, we really need technical people that can understand the business.” Such a statement has always seemed so vague and useless to me. What exactly does “understand the business” mean? And what is meant by “the business”? Instead of thinking about business and technology alignment like something as vague as the statement above, what if you, as a developer, started thinking about how your code brings in money for the company? I can guarantee that with such a change in mindset, you would quickly begin noticing opportunities for potential revenue-generating features, ways to improve the user experience, and process improvements that can help deliver projects faster. What if you even began helping the business work through its ideas to come up with an identifiable return on investment? You would start to become more than a software developer. You would start to become a product developer.
The criticism launched against Agile implementations is often that it voids developers of creativity, and from what I’ve experienced this can certainly be true. But I believe product developers can rise above this limitation.