When Agile Influencers wade into attempting to answer the question of what to make rather than simply how to go about making it the concept of Business Value is often invoked as the measurestick by which to judge competing options. Simply pick the option that will deliver the maximum amount of Business Value and your project will surely be a success and your team will certainly be productive.
I do not believe this is correct. I believe that Business Value is an ill-defined idea, a lie, an irrelevance, and most assuredly not something you should allow to encroach on your decision making if you are serious about your craft (assuming of course, that misery is not your craft).
Blessed are the key stakeholders, for they will achieve the product goal
The Book of Scrum 4:19 (NIV)
What is valuable to a business anyways?
Under capitalism a business exists to concentrate wealth into the possession of its owners by making money 1. This can be a motivating system to spur innovation and the production of goods and the deliverance of services that greatly improve the lives of all those who can purchase them. It can also lead to a bunch of weird dudes exploiting their way into hoarding a massive amount of wealth that they can use on meaningless days out and being dicks to people at websites. So I think we could say that at best it's a mixed bag.
It's cool and good that people suffer and die from preventable problems, because that means that the number representing my almost unimaginable wealth goes up
literally every billionaire
The obvious answer then to the question of Business Value is that anything that would make money for a business is valuable. However, even for things that directly deal with income or outgoings it is not always easy to directly identify which changes will lead to the business retaining a greater share of capital than it currently does - and this uncertainty is only amplified as the relationship becomes more indirect. This uncertainty is not limited only to a risk of developments not providing any return, but also the risk of any change actively harming the current state of affairs leading to losses.
Even if it were possible for a business to predict what actions would lead to the best returns (that is, those that return the greatest amount of profit) it is not certain that this aligns with the best outcome for anyone connected to the business who wants something other than maximum profit. Consider these possible actions:
- a company fires many workers from its product team leading to savings on labour but the fired workers have now lost their employment, and the remaining team is left with more work to split among fewer members causing an increase in stess
- adding extra data collection to an app allows a company to sell that user data to advertisers (or shadier organisations) which brings extra income for the company but worsens the user experience and doesn't fit with the ethics of the developers
- rushing a new feature to meet market demands means that there is no time to properly evaluate the impact on the userbase and it's implementation leads to abuse
Each of these scenarios could include the business realising perceived business value, but the other negative effects make them the opposite of valuable to anyone with other values.
Business Value then is at best a vague uncertainty, and at worst actively harmful on a scale only limited to those things that the business can affect. Using this as a guide for what work should be done is not a responsible way to use people's labour.
A business without value?
Fine. Ok. A business has to make a profit or it can't exist. Maybe that's not a sensible way of organising our whole society given the nightmarish things we've seen it lead to. But fine, given the current arrangement of things we'll accept this for now2.
But perhaps we can be a little bit more discerning than just blindly accepting the wild and unchecked pursuit of profit at all costs?
I did it all for the nookie
Fred Durst, proposing an alternative system of value
To simply remove the worst negative aspects of the pursuit of business value, doesn't solve the other challenges of determining what would offer positive returns - we need to find an approach that allows us to gain some insight into what does. For that matter, we also need to figure out a way to navigate with work that might not be quite so cartoonishly villianous, but could still have an impact that we aren't comfortable with.
How do we decide what's valuable?
We don't need to throw out all of agile at least, so we can start with working in small increments that we immediately make available to get fast feedback. But we are left needing a method of judging that feedback, and we also want to be able to judge our own work without needing to inflict it on our unsuspecting users. While the users may ultimately decide if we keep or revert a change, it is important that we can decide for ourselves which changes we want to focus on in the first place.
To this end, I think it is worth making a semi structured attempt to evaluate our own feelings about a potential change before, during, and after we make it. Because I am ageing and wish to cling to a semblance of my youth, I will call this a Vibe Check3.
Checking the Vibes
Search your feelings, you know this code is bad
Darth Vader (@l33td4rth on github)
I think it is important to start with a disclaimer that this is not merely intended to be a system of self gratification. We are bound by externalities, and the actions we take do affect others - so it is necessary to approach a process such as this with a clear understanding of what we aim to do and where the limits of our understanding may lie. If I am working on something that will impact people who have a significantly different life experience to my own it may fall outside of my own competence to evaluate the effects of my changes on those people - but as I do not wish to cause harm with my actions it would fall on me to learn about those impacts, this is best accomplished by having a person from that group as part of the team I work with so that they are constantly involved but if that is not available I can reach outside the team and use the good ol' fallback of talking with people.
Assuming that we are working as part of a team that has reached some level of consensus on what types of aims we have, and that we have methods in place to gain additional context from outside groups should we need it - we can proceed.
Thinkin' about the future
Before we make a change or build a thing, let's take a moment to consider what it is we're aiming to do and if the thing we're doing furthers that goal. Consider that there are many options of things to do at any given time, so if there is controversy about an option it could well be safe to just punt on it for now, and review it again later if some people still think it's a good idea - sometimes timing is a factor, but it's not worth compromising our integrity for a chance at good timing. Overall our goal should be to be generally happy and comfortable with what we're making, and happy and comfortable with the impact it has - but bear in mind that if something is difficult to do because we're doing it the right way to ensure it has a more positive impact, then that is good and the type of comfort we ought to be sacrificing rather than taking the easy way out but having worse outcomes for people affected by the system.
I promised (semi-)structure so here are some sample questions to ask at this stage, but it's not a prescriptive list so feel free to use your own questions that I am sure are definitely better than the ones I came up with and you should totally feel good about them.
- Will this change let our users do more with the system?
- Are we clarifying concepts in our domain with this change?
- If we had this feature already, what kind of problems would it be causing for us?
- Is there a simpler way to get the same benefit?
- Does making this change prevent us from doing other things in the future?
Note that these questions are a mix of things that relate to the product and user experience, and things that relate to implementation details. I think it is important that we explicitly consider both at each stage of this process but understand that it will be necessary to make trade-offs. Naturally we want to be thrilled about both aspects, but sometimes providing a feature that is beneficial to users will require implementation work that is frustrating or boring and conversely sometimes engineering a solution properly will limit features that can be made available. The important thing is to be aware of both of these aspects and ensure that we are not violating our own constraints on either side for the sake of the other. Or in other words, don't do evil things because the tech was cool, and don't refuse to do good things because the tech is boring.
Conciously doing
As work progresses on any given feature/change/iteration we will learn more about what it is we're making. Hopefully, any new information we discover will simply confirm that we made a fantastic choice to work on this particular thing and that will be that, but more likely we will be presented with questions and challenges about the implementation of what we're doing, and possibly we might even discover that give us pause about the impact of it.
We need to make space as we work to address this information when we discover it, because if it does have a significant impact on how we want to proceed with the work it will save us time, frustration, and effort to consider that impact as it is made rather than progressing along a bad course and making the costs of change higher. I am certain that by this point, you're brimming with ideas for questions to ask when you discover information as you build but I will include some samples here for completeness:
- Could we deliver a smaller version of this change to avoid technical challenges while still getting some benefit?
- Should we expand the scope of this change so that it can properly deliver the value we wanted?
- Can we reasonably delay this change to implement it in a better way, or should we focus on delivering the change now and change the way we implement it later?
- [dramatically] Have we underestimated the impact of this change and should abandon it for now until we know it won't cause problems?
- [less dramatically] Did we discover that this change won't be able to solve the problem that we wanted it to? Is it still worth implementing?
These questions imply the possibility of significantly increasing the amount of work that we need to do, or significantly decreasing the amount of stuff we deliver4 and this is often something that needs to be coordinated with other people. This potential for disruption when an expected timeline has been set is something that makes a lot of people uncomfortable but if we are to give a proper amount of respect and consideration to new information then it is to a degree unavoidable. It is important then to avoid conflict with people who might rely on our work, that we are clear up front about things that can happen during the process. Try where possible, to work with people on shared goals rather than a specific change or feature - it is easier to let go of a feature when it becomes clear that it is not meeting your needs than when you expect it is the solution to your problems.
Spectating retroactively
Some things are never done. Whenever we deliver something we want to know how well it is actually received, how fit it turned out to be for its purpose, how it should impact our future changes, and if we learned anything from the process that should change the way we work or the questions we ask in the future.
Look upon my works, ye mighty, and tell me on a scale of 1 and 10 how likely you would be to recommend them to a friend
Ozymandias, King of NPS
Releasing something new is exciting, it can be all too easy to become attached to what you have made and lose focus on what it was supposed to do, be on your guard against such feelings - remember the reasons that you do things, not only what you have done.
When something is out in the world and in use, it can be tempting to search for simple metrics that fit nicely onto a graph to evaluate how something was received - the graph is going up, so everything is good! Some metrics are good and useful, for example we know how fast something should respond when people are working with it so we can track the response times of our own systems to see if they fall into line. Other metrics are less useful, if we really want to get a feel for how a change is working out in the world, we need to seek out qualitative information from people who actually use it - the ideal scenario being the opportunity to watch people use the system and then talk with them afterwards.
The questions that you ask to users should be different to those that you ask yourselves, the goal when talking to them is to discover how they use a system and why they did it in that particular way - this can often give insights into how it could better work with them to gain a desired result, but it can also provide things to consider about how you got here. The following are some examples of questions that we may want to ask ourselves:
- Did the results match our expectations?
- Was our understanding of the problem domain complete?
- How much information did we reveal while making something, and does that information change our expectations for the future?
- Is there anything we learned during this that we didn't immediately act upon, but now we should do something with it?
Asking questions at this stage is necessarily concerned with the past, and thus has some limited scope for what we can impact - but it also has the most concrete information about what actually happened that can serve to increase our confidence in future changes. Given a comparison between our initial expectations and our actual measured outcomes, we can see the impact of any of our earlier interventions and use discrepancies to guide any future changes we wish to make.
Rinse and Repeat
As described earlier, work on a system should proceed in small increments where possible such that we can pass through each of the stages above many times during the lifetime of a system. It is important both to maintain the process of asking questions as we go, guarding against the complacency that comes with repetition to ensure that we keep questioning what we are doing; and to evaluate the process itself to ensure that our ways of working do not guide us into producing things that go against our goals.
Like with learning another language, or trying to lift heavier weights this is a process that rewards consistent effort over a long time rather than a single burst of herculean exertion. As we produce more new things, and have more history to evaluate and draw lessons from we can improve our every step towards the future.
What was all this about?
I tried so hard, and got so far, but in the end I didn't hit my KPIs
Chester Bennington
You have significant productive capacity, but you can only use it on a limited number of things. Those things should not be decided merely by profit, they should be your way of making the world better according to your own values and ethics. Ok fine, you don't really have to make things better, sometimes getting by is enough - but making things worse as you go isn't fine and you are responsible for stopping that from happening. In order to keep track of what you're doing and the impact that it's having you should be prepared to question things along the way, before, during, and after doing something. You also need to be prepared to deal with the ramifications of acting on the information you gained from those questions.
You get to decide these things, and you can produce great stuff - listen to the vibes, don't chase blindly after business value.
Footnotes
I do realise that software development is undertaken in contexts other than that of for a business, but I can't write about everything. If you are in one of those other contexts, maybe this post is less relevant to you, or maybe it is a trove of brilliant insights - I guess the only way to find out is to read it. xoxoxo
Should we accept this forever though? Send your answer on the side of a bottle filled with burning gasoline to your nearest billionaire's compound.
Do not feel the need to inform me that this phrasing is outdated, I simply do not wish to know.
They also imply the opposite of those, but less work and more stuff done are nice things so let's just enjoy when that happens eh? 🍹