Easily obtainable information can skew how you invest your time and effort.
To produce valuable software, you must address user needs and expectations. If you rely only on easily available information, you will get the balance wrong. Here's why.
The quality of the software you produce is a function of the feedback loops you are responding to. Many teams only use information that’s easily available to them. The challenge is that the best information for meeting the needs of your users is not as easy to obtain.
More often the result to responding to such easily obtainable signals is mediocre or bad software which does not address users’ needs or meet their expectations.
There are two common pathways to good quality. Great software companies usually exercise both to great proficiency:
Apply great craft using the best practices of the day in the appropriate contexts.
Responding to a stream of signals which represent the needs and how well the software is meeting their expectations.
What are examples of easily obtained signals?
Activity oriented teams often rely on very task-oriented signals which do very little to inform them about how well they are meeting their users’ needs. These are signals such as the rate hey complete their tasks, bugs and angry users when the software breaks and the many ideas and feature requests that flow in.
You can think of any of the information you are regularly making decisions on as signals. In the above example the signals may be the feeling of being productive as we write code or complete tickets. It might be removing pain by addressing a request from the boss or an irate user. These are examples of easily obtainable information - either it’s easy to count or it comes to you (whether you ask for it or not!).
The combination of these signals might lead you to create adequate quality software, especially if the user’s needs are moderate and their expectations low. In today’s age software users with low expectations is becoming increasingly unlikely. Users are exposed to better and better software experiences at work and at home.
Of course, they may still produce a degree of quality through the strength of good engineering practices applied in the appropriate context but it’s unlikely to produce the tightness of fit that would be needed to achieve exceptional quality.
The pace of delivering the right level of quality will often be slower as well as there are also less likely to be counter signals which inform them, they have achieved adequately in one quality dimension and could focus their efforts elsewhere.
So, what are good examples of signals?
Outcome-oriented teams with rich signals describing how well their software is meeting the users’ needs and their qualitative expectations use these signals to guide how and where they apply their craft. Assumptions are tested quickly and there is fast adaption to what is working and what is not.
Such teams, in their desire to understand their real progress to delivering on software that will meet their users needs to a level of quality that exceeds their expectations go to great effort to seek out quality signals which are good indicators they are achieving, or making progress towards achieving, their goal.
If the users have a need for low latency, responsive software the software team instrument the software they are creating with performance measurement and they get the software as quickly as possible in the hands of users monitoring how well the software meets the desired performance, iterating and improving towards the benchmark they’ve determined in collaboration with their users.
The signals are not limited to technical measurement either. Qualitative and frequent engagement with the target users is another dimension of the signals that can guide the team. Regular user interviews, every day, every week, every fortnight - a granular and constant flow of information which informs the design and understanding of the needs and degree expectations are being met.
Every qualitative aspect of using software, those which were once described as non-functional requirements, are able to be measured as a near constant stream of information software teams can use to guide them and to inform the decisions, they make every day.
This approach is not limited to non-functional aspects of software. Usage is another common signal. Are the users using the software as intended? Is their behaviour which indicates the software is not meeting a need conveniently e.g., possibly gross workarounds are required to use the software. If you are clear on your strategy, you can devise measures which will help you determine how well, you are realising your strategy.
To teams who focus on quick wins such an effort to collect more difficult to obtain information may seem like too much effort. But its what great teams do with such information that is important. They use it focus on what is important. To understand what the experience of the users actually is. To guide the many decisions, they make every day. To remove their blind spots and to reduce precious attention being wasted lower value distractions.
What signals are your teams using to guide the work they do? How often are they looking at this information and making decisions? Share your experiences in the comments.