Relevance Points™ - Fixing the Issue With Agile Development

The Problem

When I have mentioned this to other people, most of them have been quick to agree: there's an issue with the way agile software development is done in many big corporations.

Often separate people fill the roles of a business person or developer. Then, a breakdown in collaboration occurs between the two. Particularly, many high performing developers are frustrated. They feel the business people make poor decisions impacting software development.

Consequently, developers lack the liberty to use their software development acumen to choose which software to develop, and how to develop it. Lacking this liberty, they feel pressured into developing software that they know will provide less value to the business.

The Solution

We propose solving this breakdown in collaboration by introducing a couple of easy metrics and roles: the Relevance Points metric, Relevance Spy role, Spy Stripes metric, and Double Spy role.

Solution - Relevance Points™

Developers might be frustrated that business people seem to make bad decisions affecting software. But, their ability to make good decisions is only as good as their information. How is a business person who does not understand software, supposed to assess the value of a software change? We believe Relevance Points may provide a way.

Each task could be assigned a number of Relevance Points, from 1-5.

By "task," we mean a unit of software development work. For example, a task could consist of a technical Jira ticket for a code change, a Git pull request, etc.

The Relevance Points would rate the software development work that went into implementing the task. This metric would signify the relevance of the task to the business problem. That is, the points would indicate how accurately the task did the right thing, and did the thing right.

Difference From Other Metrics:

The Scrum framework already provides for stories to have metrics including complexity points and priority order. Relevance Points are different. By adding Relevance Points to development tasks, we seek to provide a way for business people to assess the business value of underlying development work.

Additionally, Relevance Points could probably be applied equally well to various agile frameworks including Scrum, Kanban, etc.

Solution - Relevance Spies

Who could be qualified to appraise tasks for Relevance Points? Relevance Spies would be business people with adequate understanding of the underlying software. Perhaps some would come from a background in software development and end up working in more of a business role. The business could appoint one spy, to any project.

By "project," we mean a broader software development effort containing multiple tasks, and usually performed by a single, somewhat stable, development team.

The spies could draw on their allegiance to the business, and their understanding of the software, to appraise the Relevance Points for each task.

Solution - Spy Stripes

The Relevance Points would be misleading of the spy did not have a good understanding of software. Each Relevance Spy could be assigned a number of Spy Stripes, from 1-5. The stripes would indicate the accuracy of the spy's understanding of software development. A spy with more stripes would be considered more accurate in assessing Relevance Points.

Solution - Double Spies

The system would include checks and balances between the business people and developers. Double Spies would be developers with business acumen (possibly former business people who became developers). Developers could appoint one developer to be the double spy for any project. Double spies would be responsible to assess the stripes for relevance spies.

Possibly, the identities of relevance spies and double spies could be kept secret from each other to discourage ulterior motives.

Solution Summary

We feel that the Relevance Points would provide a way for non-developer decision makers to accurately assess the value of software development work. We think this would enable those decision makers to make better decisions in regards to the work. Business people would be able to recognize and reward software development that is truly better.

This could help liberate high performing developers to work on what they feel they should, in the way they feel the should--as long as it truly remains within the best interests of the business.

An MVP (Minimum Viable Product)

This system could be worked out with spreadsheets. Within one workbook, there could be a few worksheets, each with a few columns, in the following layout:

1. Tasks
1. Task ID
2. Project ID
3. Relevance Points - Number, 1-5
2. Projects
1. Project ID
2. Relevance Spy ID
3. Double Spy ID
3. Relevance Spies
1. Relevance Spy ID
2. Spy Stripes - Number, 1-5

MVP - Integrating Such a Spreadsheet with Other Systems

The IDs within this spreadsheet would be arbitrary values for unique identification (for example, 1, 2, 3, etc.). Any information to relate these IDs to other systems, would be would be kept separately from this spreadsheet. For example, a Relevance Point Task ID from this spreadsheet could be added to a Jira ticket or Git pull request, tying those systems together.

MVP - Using the Spreadsheet

To apply the system to a new project, a project row would be inserted. The spies would be appointed as described, and IDs would be set in the project row accordingly.

Whenever a developer completed a code change task, a task row would be inserted. The relevance spy for the related project would appraise the relevance points. Then the double spy for the related project could re-apprise the relevance spy's stripes.

The business people could refer to the Spy Stripes to see when they needed to appoint a different spy to a project, to get accurate information. Then the business people could refer to the Relevance Points to get an accurate impression of the business value of each unit of work.

Please comment to share your ideas to improve this system.