You might thing that delivering “value” is redundant in an article about values. But you are wrong!
This value is about making sure that the work that we do is valuable to our customers. When deciding how to prioritize work, or whether we should even undertake a task should be decided based on how it can make the experience of our users better.
One way of delivering value is ensuring the teams that count on us, can trust the estimates that we give them. Often decisions of what to prioritize are based on how long a particular feature will take to implement. If we are not able to make realistic estimates on when features will be delivered, then making effective prioritization decisions becomes impossible. One of the ways for us to be able to give effective time estimates is to work at a sustainable pace. If we are consistently delivering about 20 points worth of difficulty per week, then we can be fairly confident that a feature with 80 points worth of complexity will take about 4 weeks of full time effort.
Delivering business value
Sometimes this is quite obvious, as in the case of adding a new product to our loan offerings, but other times it’s not so easy to determine.
How can we determine if adding a messaging queue, or refactoring a tricky bit of code, or adding a data warehouse is going to “deliver value?”
For the cases where determing the benefit of a task, we try to evaluate it from a number of smaller topics which can help us determine if there is value in the task.
Automation is all about efficiency. If you can take an error prone manual process and turn it into a consistent and repeatable process, you can get great gains in overall efficiency, as well as eliminating the possibility of the fat finger. The one flaw in automation is the risk of over-automation, which leads us to…
YAGNI - “You ain’t gonna need it!”
One of the core principles in delivering value is making sure that somebody needs it, or at least wants it. No value is delivered when there is nobody that can, or will, take advantage of a feature.
Often developers look at a problem, see that in some future condition it may need additional coding, and dive in right away to developing the code about the future condition, only to discover several months later that either they didn’t understand the full ramifications, or have it decided that an entirely different approach is desired.