2019年/04月/01日
Guiding Goes Better “Feature by Feature”
The first thing we know about any project is the deadline—at least it always seems that way. That’s the vertical blue line with the triangle at the bottom.
And what do we want by the deadline? Why, everything, of course. That’s the horizontal line. The star is our plan: have everything by the deadline. No problem!
Somehow it doesn’t turn out that way. We usually wind up shipping less, or later, or both: the red lines with the question marks. Heck, we’re sure to get less than we want. After all, we asked for everything!
We really can’t have it all. Let’s manage that reality, not just let things happen. Let’s steer our project, not just ride it wherever it takes us.
In a recent project of yours, what important things didn’t get done? What got done that turned out to be wasted? What did you find out about too late, or nearly so?
Conventional software projects proceed in phases.
Many projects plan with activity-based phases: Analysis, Design, Coding, and finally Testing. The green line is our plan for such a project, and it may look good. But even if we get Analysis done on time, that doesn’t tell us how well we’ll do on Design or Coding.
Until we begin to see the software, we can’t really tell how well we’re doing. And when we start getting and testing that code, what happens? Generally nothing good!
Have any of your projects given you too little time to react when trouble arose? Would there be value to knowing sooner what’s really going on? Did you ever wish you could get at least some value out of all that effort?
Worse yet, things rarely go according to plan.
Finally, we begin to see and test the code. And the facts aren’t good. Inevitably we’re later than we thought. We have less done than we thought. What we have done doesn’t work very well.
We knew we had asked for more than we could do: that’s the nature of goal setting. But by the time we find out where we are, it’s too late to do much about it.
With more warning, maybe we could have shipped a subset on time. Now we have few choices. We could write the project off, but that would be career suicide. Or we can trudge gamely on, hoping to ship something before they give up on us.
Either way, we look bad. Either way, it is bad!
Have you ever had to ship in bad condition? Were there too many defects still in the software? Was the software too hard to change? Were important features missing? Important new ideas that it was too late to add?
The activity-based product is a monolith.
With a monolithic project, late in the game we can’t do much to cut costs. We have already written requirements for things we’ll never get. We’ve designed and even written code for things that we’ll never complete. All that work is wasted.
If only we had known the truth. We could have deferred some of that work.
We laid out this project with an all-or-nothing mentality. We analyzed it all. We designed it all. We tried to code it all. We discovered, too late, that we can’t have it all.
Trying to plan and build it all has hurt us. We have no time to change, and even if we had time, we’d never untangle all the things we shouldn’t have done from the things we should have.
Instead, let’s plan for multiple releases from the very beginning. Multiple releases are easier to manage and deliver value sooner. It’s even easier to build the software that way. Everyone wins.
Do those plan, analyze, design-code-test phases really help you manage your project? Wouldn’t it be easier to manage things if you could just get the features, a few at a time, in the order you wanted them, starting right at the beginning? Let’s look at that.
A project that delivers feature by feature is more predictable.
We’ve seen that delivering release by release, feature by feature, lets us ship value sooner. What about our ability to manage and guide the effort?
Our old red conventional project drones on and on, deliver- ing too little information, too late. But the green project shows us real, valuable features at frequent intervals. We can see what is happening. We can see the software!
Can you see how a flow of visible features would be easier to manage? Can you see how you could maximize project value as you go?
What about risk? Can you see how to evaluate or reduce a project risk by building something visible? Can you see how to deal with a marketing risk with a small test feature?
Feature by feature gives better information, better guidance, better results.
When we build our software projects feature by feature, things go better. We can see how much is done and how rapidly the project is progressing. We get a good sense of how much will be done by any given date.
We choose the most important features to do next. We build the best possible combination of features for any desired shipment date—even one earlier than our original desired date. We can even change features, adding new ones in response to better ideas or changing user needs.
When our projects grow feature by feature, we can respond to what’s really happening. We can respond to the changing needs and inputs of the business and of management.
What would it take to make this way of working possible? How can we plan a project when we don’t even know what we’ll wind up wanting to do?