What's next?

When planning ahead or deciding what to do next, how do you choose?

Work stack
By work stack I mean that when you think of something new, start working on it; when you're done, go back to what you were working on. If you've ever worked with someone who bursts into the room and shouts with joy, "I just got a great idea! Drop everything and work on this now!" then you'll be familiar with the result: you end up going nowhere. These constant interruptions are highly disruptive and cause unfocused thrashing and churning. The product owner doesn't get what they want because their next idea interrupts any progress on the current idea and they don't get what they need because the focus is always on something else. Most of the time is wasted on incomplete, buggy, useless features. I have nothing positive to say about doing things this way because in my experience, it's by far the most wasteful. This is like trying to swim across a river by jumping in and moving your arms and legs in every direction as fast as you can: you might make it across but you'll probably just suffer and die.

There's also a more subtle and personal work stack too. This is where you see something near what you're working on and you decide to take a short detour to fix it or clean it up. If you're especially prone to this then you can end up wandering from one little detour to another and not accomplishing what you set out to do. I've found that I've gotten much better at avoiding this by focusing on finishing one feature before starting on another and setting aside time specifically to refactor and payoff technical debt.

Work queue
A work queue is the opposite: new ideas are added to the end of the list and you'll get to it after you finish everything before it. This sounds a lot like Big Design Up Front and suffers the main drawback too: solutions you come up with probably will be bad since you know the least at the beginning of the project. If you have a long list then when you learn something new, it will be a long time until you can benefit from it. I think human nature and our eagerness to implement new ideas makes it just about impossible to stick to this method - which is for the best.

Horizontal slice: Front end first
You could try the tiered architecture approach and do the outside first. This gives early visible progress but there's a lack of functional progress. Unfortunately, non technical people often don't see the difference between "gui is done" and "app is done". Having such a large disconnect between the customer and team is a recipe for disaster.

Horizontal slice: Back end first
You could try the tiered architecture approach and do the outside first. This gives early functional progress but there's a lack of visible progress. Very few users understand the difference between "non existent app" and "98% of the use cases have passing automated tests". If the person paying your bills doesn't think they're getting anything for their money then it doesn't matter how close you are to really being done because you won't get a chance to finish.

Minimum cost
How about doing the smallest and easiest things first? This has a lot of good things going for it: you make quick and early progress, you're always doing the easiest work available, and you'll probably spend most of your time on things you enjoy and are good at. But as you go you'll find that everything becomes more difficult and risky since you've been putting it off. You may not have a usable product for a long time and what you do have will probably be missing important functionality. Or you can spend a lot of time and only too late discover that the hard parts will be too expensive and the whole thing was a waste of time. Unfortunately for those who prefer the easy way, the hard parts are often what solve the real problem and make software worth it.

Maximum cost
How about doing the most difficult or risky things first? This also has a lot of good things going for it: solving hard problems (or even working on them) can boost morale, you reduce risk over time, the pieces you work on will become easier over time, and if it's too difficult, risky, or expensive you cut your losses before making a huge investment. But there are downsides. Just like when working the minimum cost first, you may not have a usable product for a long time and what you do have will probably be missing important functionality. You'll also be making a lot of long term solutions to hard problems that may be bad since you know the least at the beginning of the project. And possibly the biggest drawback is that difficult problems require skilled teams with skilled people who work well together, which you may not have at the beginning.

Important and urgent first
It seems like thinking about things first works best so far. Hopefully that's not too surprising. Maybe we should try using two variables to categorize things instead of putting things on a high-to-low, inside-to-outside, or newest-to-oldest spectrum? You could use an importance and urgency matrix with 4 quadrants: high importance and high urgency, high importance and low urgency, low importance and high urgency, and low importance and low urgency. Everything that needs to be done is placed in one of those quadrants and you come up with some rules about working the important before the non-important and the urgent before the non-urgent. Sounds good in theory but from what I've seen, it really devolves into two categories: "get to it when we can" and "ignore". Eventually someone will say "this is very high importance!" and someone else will say their task is "critical importance" and another becomes "ultra critical importance" and before you know it, you get importance inflation where the only way to get something worked on is to say we're all going to die unless it gets done by tomorrow. Unfortunately, the difference between Important and Urgent (and sometimes even Nice To Have, or Just Putting Words Together With No Clear Thoughts) seems impossible for some people to understand.

Maximum value
Take your to do list, order it by how much value you'll get from each thing, and call it a backlog. By focusing on the most valuable things first you'll get usable software sooner and as we know, "working software is the primary measure of progress." One of the best things about the list as a developer is that the opportunity cost is clear and can't really be argued. Lets say someone tells me that a certain issue needs to be handled asap. Since two things can't be at the top of the list at the same time, I can ask them what items I should move down the list to make room for it. Should I delay the bugfix that's costing us thousands of dollars a day? How about the feature that the CIO himself asks be about each morning and evening? Or maybe the feature that will prevent our largest client from leaving in a month? Suddenly their request isn't as important as they thought is was. The biggest downsides are that deciding the relative value of things takes discipline and knowledge and that some clients have an all or nothing mentality. The idea that even the tiniest feature might be left out or is less valuable is unacceptable to them.


I've found that I'm most productive and happy when I change it up to maintain flow. I'm almost always trying to focus on maximum value but sometimes visible progress, easy wins, or tackling tough problems soon is important. After all, working software is the primary measure of progress but not the only.