Artifacts are not the problem: it’s what people do with the artifacts. Is blaming the artifacts and getting rid of them going to fix the problem?
As I was looking around Twitter this morning, and thinking on what goes on in “Agile” thinking, I had some p-baked thoughts. I’ll try to put some of them down here.
I’m thinking about some popular ideas of the moment and how new they aren’t. #NoEstimates is big right now. There was a small Twitter-storm on the evils of the backlog. There are plenty of them.
There are abuses of estimates and of backlogs. I’ve ranted about them a few times myself, including my recent articles on estimation in Pragmatic Programmers Magazine. To sum up some negatives:
Estimates are bad because they are nearly always taken as promises. They are distracting: people can’t seem to resist improving their estimates instead of improving their product. Most important, they focus attention on the wrong end of the cost-benefit balance. Successful Agile comes from managing scope to the deadline, not from working with fixed scope or from estimating costs.
Therefore, some conclude, estimates are bad. There should be no estimates.
Speaking of deadlines, they are bad too. They lead to death marches, as the organization tries to get us to cram everything in by the deadline. They result in unhappy people, inferior software, and never deliver the whole thing anyway.
Therefore, some conclude, deadlines are bad. There should be no deadlines.
Backlogs are bad because they are always taken as a fixed list of things to do. The organization wants them all done. They probably set a deadline or have one in mind. (See above). They doubt that we’ll get it all done, so they demand estimates and treat them as promises and when they don’t come true, they demand that we improve our estimates. They also demand that they add up to show that the backlog will be finished by the deadline.
Therefore, some conclude, backlogs are bad. There should be no backlogs.
A Generational Thing?
I’ve thought all those thoughts myself, and said them. Sometimes I still think them. If people would just break out of the fixed-scope deadline idea, if they would just work on a few things at once, if they would slice things small instead of estimating, things would go so much better.
That’s when it hit me. I have said those things. I still feel that way in my inner child.
It’s a cliché that youth reject the old paths. Often they don’t really know what’s right, but they have a strong sense that things are wrong. We shouldn’t have to keep our hair short, or long or whatever length they say. We should dress as we want to, namely just like everyone else we hang out with or admire. We shouldn’t have to go to school. We shouldn’t have to do that stupid homework. We shouldn’t have to do what our parents say. No, no, no. Talk to the hand.
It’s equally a cliché that as we get older, we compromise. When we’re young, we know that compromise is bad. Only pure truth — our truth — is good. If we want a tattoo on our face, then that’s the way things should be.
I guess we all, or many of us at least, go through a cycle of rejecting the old to bring in the new.
No estimates, no backlogs, no deadlines. No war, no homework, no dress codes. I don’t know what I want but I won’t compromise to get it. Compromise is bad.
Getting Things Done
It turns out that when we take the path of rejecting the old ideas, certain things inevitably happen. First, the people in power, who value these ideas, or parts of them, reject our rejection. You will cut your hair, young man. You will do your homework. You will do these estimates, you’ll get them right the first time, and they will show you hitting the deadline with full scope.
Oddly enough, these old fogies know your estimates will be bogus, they know you won’t get them right, they know you won’t hit the deadline with full scope. They know the same stuff you do, and it’s very likely that in the past they said the same things you are saying. Then they figured out something that we didn’t figure out in our youth: you can’t get things done by saying “no” all the time.
With rare exceptions, and you’re not likely one of them, people don’t get to positions of power or influence by being negative. They get to those positions by getting things done — things that people want. The result is that crying “No estimates, no backlogs, no deadlines” is a tough road to follow. It’s not impossible but it’s not very effective nor efficient.
In large part that’s because estimates, backlogs, and deadlines aren’t really root problems.
Software Projects Have No API
Done conventionally, software projects offer almost no information, and almost no control, to those who are given the responsibility to manage them. Managers can’t find out how much is done, they can’t find out how much works, they can’t get any decent sense of how much will be in place by the deadline. And deplore this all we will, the people in charge of spending money to get software really do need control and information. Saying “no” doesn’t help them. Since we don’t help them, we’re unlikely to get what we want.
Now many of us have been fortunate enough to find places in life where we can do what we want and say what we want. We call most of those people “consultants”, which really means that no one would hire us for very long at all. We have turned being unemployable into an asset. But I digress.
Managers, teams, projects who have learned enough about how to do software can often get to a point where it seems they have no deadline, no estimates, no backlog. They seem to go along, doing whatever good thing is next, deploying it rapidly, and everyone is happy. There are only two things wrong with this picture.
First of all, they do have a backlog, even if it isn’t written down or called that. No one is really getting up every morning with no idea what they’ll ask the team to work on. They have a list of ideas in their head, ranging from solid to fluffy, from sounds good to really weird, from let’s work on this now to let’s not do this until shortly after never. They do have estimates: all their features are small enough to do in just a few days. They do have deadlines: they deliver stuff every few days. These people have more estimates, more deadlines and at least as much backlog as anyone else. It’s not those things that are the problem, it’s the form of the things and how some people use them.
Second, an organization and team doesn’t just voila! transition to this new and better state of working off the top of a short list of small things and deploying them ASAP. Usually they have to be drawn to that way of working, through a process of fulfilling their desires, increasing their understanding, and learning how to do it. Saying “no, no no” won’t get them there.
Giving software projects an API will get them there. That’s about “yes, yes, yes”.
The Nature of Software Development
I’m writing a whole lovely book about this but here’s a really short look at how we get from where we are to this golden nirvana of no estimates, no backlogs, no deadlines.
Software is about delivering value. It might be any kind of value, from money to laughs or lives. The people funding the project want value.
Delivering sooner delivers value sooner. Software today delivers value today. If we get the software next year, that’s not so good.
Delivering in features delivers value sooner. If we can deliver part of the software, we’ll be able to deliver it sooner. We get value sooner.
Large features waste time. Inside each large feature is a small nugget of value trying to get out. Management needs to deliver high value features rapidly. Large features interfere with what management needs.
Good management demands small features. The above things being true, and they are, good software management will demand small bites.
High value features should be done first. For best value, do valuable stuff. Defer less valuable stuff. Duh.
What is valuable changes. We will change our mind about what’s valuable. We might even change our mind about which product to work on. We may have a long list of good ideas, but we’ll choose from the much smaller list of small, high-value, ideas, and build those.
All these features have to work. Each feature delivered has to be complete and correct. If they don’t work, they don’t deliver value.
The team has to learn how to build small features that work. Conventional phased development won’t support rapid delivery of small features. Management has to have teams that can do this. Management will likely have to help them learn.
The longer term must be supported. We can’t just ship a couple of small features and then stop. The work must be sustainable over time.
The team has to learn to work sustainably. It’s not enough to go fast. They have to go well. Again the team must learn and management needs to help them.
Have a look at that list above. It’s about the inevitable facts of life. It’s not about management stamping their feet and demanding a pony, and it’s not about technologists saying talk to the hand. It’s about the fact that small, high value features, delivered rapidly and sustainably, are clearly best for the business and best for developers as well.
Do you want no estimates, no backlogs, no deadlines? Great, so do I. Now stop complaining, and get to work with business, not against them. And cut your hair, you look like an animal.