The Nature of Scarcity

I heard this great little anecdote on NPR about a Economics book entitled Scarcity, by Eldar Shafir, and all kinds thoughts about Agile came rushing in. That comes as no surprise though. Economics is, at its core, about supply and demand, and Agile software development is about the supply of working code and the demand for working code.

Anyway, this anecdote struck me as a good lesson for Product Owners. I hope I can convey the train of thought that got me here. (My problem being that my train of thought makes all the stops. . . . and is rarely on time).

So there’s this author–Eldar. Six months ago, Eldar received a notice in the mail to update his vehicle registration. Like many of us, he put the notice on the refrigerator and told himself he would take care of it “tomorrow.” Weeks went by, and day after day, Eldar kept telling himself he would take care of the registration tomorrow reasoning to himself: “It’ll only take me a few minutes to do online. I can do it anytime, but I just don’t have those few minutes right now.”

That was six months ago, and Eldar has said this to himself a few times every week. But now, 6 months later, he’s is driving around with expired tags and now does odd things like avoid the police by taking extra turns on his drive to work, or stopping so that the police do not get a good look at his tags. This in return has led him to be late for appointments, or late for classes he teaches, which he then has to re-schedule and fit into his life. Now, Eldar has put himself in a cycle where he has so little time–spending so much of it trying to work out his now chaotic schedule,–that he truly does not have time to sit down and update his tags. (and we may even assume that he will also need to ensure he has enough money set aside to pay the healthy fine he must owe for being so far behind on his vehicle registration.

All because he didn’t want to do the small, simple thing because there were other things that were “more important.”

What Eldar did was get himself caught in a cycle that many product owners get caught in. They decide to respond to the more immediate tactical issues because that will make customers with immediate complaints happy today instead of allowing small strategic items to be completed that will help the project in the long run.

Like Eldar, Product Owners are under tremendous pressure to get things out the door. They get caught in the loop to the point that they can’t seem to get time to take a look at the bigger picture and do true strategy planning–grooming the backlog to ensure that the work coming will lay the foundation for good solid system health.

So how did Eldar get out of the vicious cycle? He took a little time each day to stop and review his activity and ensure he had a clear picture of any of those “small” items that could grow into big ugly ones. He literally set a meeting for himself that was just as ironclad as any other meeting.

What he is really doing is grooming his backlog of personal tasks and setting time aside to do so.

And here’s the big connection–all of those Agile ceremonies- Scrum, planning, grooming, demoing/reviewing, retrospecting? If a team tries putting off the activities that go on in each of them, the result is time debt that can grow to ridiculous proportions very quickly. Skip scrum a few days, and you will likely have developers and testers with lots of questions for each other along with product owners who are brought in so late to answer a questions that it has festered into a full-blown problem. Skip planning or grooming, and the whole outfit lacks confidence, taking on a flying-by-the-seat-of-your-pants approach–further damaging the team’s perceived credibility. Skip demos and the external perception quickly becomes that the team is in black box mode or worse–not doing anything. Skip retrospection, and the team stops checking themselves before they are wrecking themselves.

Do the small, simple mundane things as a matter of course. Technical debt needs to be addressed. Work smart not hard.