Skip to main content

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.

Comments

Popular posts from this blog

Shared Project Manifesto Version 2

Contents:IntroductionLaunchTradeRewardDevelopVoteHarvest 1. Introduction IP (Intellectual Property) is a great asset but it is hard to produce well. We hypothesize that a market to facilitate shared projects would make it easy to produce IP better.


The market contains projects. Each project has one admin and a number of traders and developers. One user can have any combination of roles at the same time. For example, a user may be an admin and also a trader, or a trader and also a developer. ProjectsUsersAdmin: Provides ideas in exchange for controlTraders: Provide incentives in exchange for growthDevelopers: Provide IP in exchange for incentives 2. Launch When somebody came up with an idea for an IP product, they could create a project for it on the market. That person would be the admin.
The market would record the time the admin launched the project. That lasting record could provide for the admin to claim credit for the project idea, on a first-come, first-served basis. This recogn…

Contact Codes Lite™

CCL (Contact Codes Lite™) would be a software product to help people exchange many kinds of contact information much more easily. CCL would do this by providing users with relatively simple contact codes. The users could distribute the codes to many people in many ways. Then, a person who received a contact code could use it to retrieve the original person's contact information through CCL.

For example, many people still exchange business cards. Retrieving various information from the cards can be time consuming and error prone, especially when there are many cards. Also, when somebody updates their information, the information from the card is no longer valid.

Other good examples for usage of contact codes include:
On a slide in a presentationIn email signaturesOn name tagsIn applications that provide limited space for profile informationWhenever you want to provide easy access to many different contact options without listing each
The main thing that would make CCL different from…

Fog Machine

Fog Machine™ (named because fog is like a cloud, on the ground) is a software product to provide cloud services to customers without a cloud service provider. The problem with the traditional cloud is that it requires a provider. Fog Machine™ would run cloud "nodes" in idle system resources on ordinary user's devices. This would be a peer to peer system in which each connected device would be a peer.

It would support standard cloud APIs (perhaps Cloud Foundry?) and it would be easy to port cloud apps to it off providers such as Google cloud, Azure, or AWS--or maybe it would be effortless for apps that were already portable through compliance with open standards.

We might use encryption for privacy, redundancy for reliability, and remuneration/incentive for resource consistency. The showstopper (critical assumption) is that the synergy would be sufficient to significantly surpass the overhead, and provide competitive performance for at least some types of cloud applicat…

Please Comment

Have you ever heard of a similar idea? What challenges might an idea run into? How might you like to be involved? Comment to add your voice to each idea.