This may upset you to hear: that coding task you’re working on has no value. Not yet, anyway.

Even once it’s finished, even done perfectly, it might not do anyone any good. And there’s no way to tell how this will turn out ahead of time.

This description is so typical of knowledge work that it could serve as its definition. Software development is a kind of knowledge work.

We cannot know the value of our work until it’s done and in use.

That’s it. That’s the problem. It’s what everything under the tent of “Agile Software Development” is there to solve. It is our organizing principle.

It’s a jarring statement. It feels overreaching. All our work? Come on. There’s definitely something we’re building here that’s a sure thing.

At the same time, it’s trite. Of course we can’t know if the user is going to like that thing. That’s what the little feedback widget is for, right?

But if I ask “why?” enough times about any agile software practice, I land on this fundamental truth. Every time. 

Do you have faith?

If you plan your work weeks at a time,
If you track your success by how well you followed that plan,
If you get sign-off on the design before writing a line of code,
Then you believe. You have faith in the value of the work.

But your faith is misplaced, because we cannot know the value of our work until it’s done and in use.

The work of software calls for science, not faith. It’s best done by people with drive and humility—drive to deliver something great, and humility about how.

We ship a quality system early and often,
We learn from the way people use it before we make our next change,
We test everything,
And we don’t believe our work has value until we see that our product is useful.

Our posture is one of doubt, because we cannot know the value of our work until it’s done and in use.

Agility in software development flows from a healthy skepticism of our to-do list.

Have you unlearned?

You and your team have probably learned enough new processes, tools, and techniques. Maybe you even have an expensive piece of paper that says so.

But if these ideas aren’t quite clicking, you likely haven’t unlearned the way you were taught to work before.

You were taught to adhere to the documented requirements. You were taught that the right answers came from the boss, that decisions were made by people above you. And, of course, you were taught that doing a good job meant every last feature on the list got built.

You were taught to have faith in the work before it was done and in use.

If the results of your job are in fact predictable, it’s not wrong to work that way. Boring, but not wrong.

But in software development (and knowledge work in general), you don’t know what’s coming next. Neither does your boss. And agility can only begin after you and your team admit this, stop pretending, and decide together what you’re going to do about it.