If there is anything on your team's to-do list that does not concern delivering value, responding to change, or building trust, kill it with fire.
If you want to deliver value, you have to find it first. And most of the work on your desk right now may contain shockingly little of it.
If you mistake work for value, you pay twice. First, in the cost of doing the work. Second, in the opportunity cost of not doing work that does yield value.
Validating your inputs is not just a good programming practice. Question your assignments.
Responding to change
You were taught to stick to the plan. To not change horses midstream. To stay the course.
But everything changes. What was valuable yesterday may not be today.
Can the thing you're building today adapt when tomorrow's wind blows? If not, maybe you should be working on something else.
None of this happens in a vacuum.
Without trust, there is no team. There's just a collection of individuals. Your work becomes laden with bureaucracy and ceremony that yields no value, except to express how little you trust each other.
But when there is trust, your team thinks, acts, and reacts as one organism. You don't waste time on mitigation and control.
Trust frees you up to deliver value and respond to change. Delivering value and responding to change builds trust. Around and around you go.
So here's what this looks like on my team.
User stories help us find value.
To find the value in our work, we break each project into discrete user stories. Then, we work with our client to ruthlessly cull and rank them, so that we only invest work in the most valuable of them.
We don't gold-plate a story. When a new requirement emerges, we don't staple it on to a story we already have—we write a new one. And before we even touch that new story with code, we make certain that it's more important than everything else that's already in the backlog.
We also don't gold-plate the code. If saving data to a file works well enough to solve the problem at hand, we won't rig up a database yet. We let the technical solution emerge, so it will never be more complex than it has to be.
Automated tests help us respond to change.
Everything changes. Software that doesn't change has little value in a world in which everything changes.
In order for our software to respond well to change, we consistently clean the code that we've written. In order to clean the code safely, we regression test the app every time we make a change. In order to not have to hire an army of human testers, we cover the code with fast automated tests.
When anyone suggests that we skip writing these tests to save time and money, we politely refuse. Because we know that that won't save time or money.
Scrum helps us build trust.
We know how to carve out user stories and keep our code sustainable. But our client knows better than we do which stories are the most valuable, and which changes we can (and cannot) ignore.
We check in with them early and often while building their app. And every time we do, we deliver working software.
Once we've done this a couple of times in a row, they begin to trust that we know what we're doing when we politely refuse to skip the tests.
If there is anything on your team's to-do list that does not concern delivering value, responding to change, or building trust, you're paying for it twice. First, in the cost of doing the thing. Second, in the opportunity cost of not doing a thing that does deliver value, respond to change, or build trust.
Delete work that is in your team's way. Everyone else will understand soon enough.
Jon took this whole nerd thing pro well over a decade ago and has been slinging code with Aptera since 2008. He holds an MCSD, a PSM, a PSD, a PSPO, and is a BMF besides. These days, he may or may not be unhealthily consumed with building sustainable software, and with building teams that build sustainable software. Whatever you do, don’t follow @jonfazzaro on Twitter.