Scheduling by value?

David Peterson has started a new blog on Kanban (and snaffled a very tasty URL for it). He presents this discussion of scheduling features into a development team. The case the David presents is related to a behaviour I sometimes see with inexperienced teams who's just had someone go learn Scrum. Comes the next planning meeting and this idea pops up that the backlog needs to be ordered by "business value" so that the "most valuable" features can be delivered earliest.

This can easily lead to some very nasty scenes where the Scrum Master demands that the Product Owner produce a "value" for each story—actually write a number on the card. The problem comes to a head when it turns out that the Product Owner not only doesn't know the value of the stories they are putting on the backlog, but they also have no way of finding out what they value of a story is. And this isn't because they are stupid, nor incompetent, nor malicious. It's because finding that value is far, far too difficult and time consuming an activity. And there's a good chance that any answer that came out of it would be so well hedged as to be meaningless.

Sometimes the Product Owner does know, or can find out at reasonable cost, a value for a story or feature. Being able to trade a new asset class probably can be valued. Changing a flow to give 10% high conversion probably can be valued. Improving a model to get 1% higher efficiency in the machines it's used to design can probably be valued. These valuations will be functions of time time and various other parameters. If you really have to, you could get a number of them that's valid today (and perhaps only today). David makes the point that even if you do know that number for a feature, scheduling the next one simply on the basis of highest value might not be the smartest move. There are other variables to consider.

There is a case to be made that within the context of a project value isn't the best figure of merit to use anyway, since someone should have made a go/no-go decision at some point that the planned budget and planned value seemed reasonable. That decision should be re-assessed frequently (far too little of this goes on) based on progress to date, and action taken if the actuals have come too far adrift, but in-between those times trying to optimise on value is perhaps not worth it.

Another option is to indeed demand (and obtain) those value numbers and then schedule work primarily on the basis of business value and dispense with effort estimates, so-called "naked planning". This has caused eyebrows to be raised. The underlying claim is that

value varies along an exponential scale while development costs vary along a linear scale. Therefore delivering the most valuable features trumps any consideration of whether or not the most valuable feature is cheap or easy to develop

whihc, if true of your environment, might give pause for though. How this interacts with the desire to schedule so as to maximise throughput at the bottleneck is an open question, for me at least.

Slipping through our fingers?

It was close. So close.

What's the really exiting thing about the Agile development movement? Is it getting to ship working software? That's pretty good. Is it not having to lie about status all the time? That's great too! Is it being able (and allowed, and required) to take true responsibility for our work? Wonderful stuff! But I don't think these are the best part.

I think that the best part is that we were starting to normalise the idea that programmers are valuable knowledge workers who collaborate with other valuable workers in the business as peers. Big chunks of the industry had to (re)learn how to do all that shipping and telling the truth and stuff in order to get to that point, but that's only the means. The end is to be dealt with by our paymasters as if we make a genuine contribution to our businesses. And even that is only a starting point for the really interesting stuff.

And now along come folks shouting about Lean. A lot of them are Agile folks looking (quite properly) for what to do next that's better. And the message seems to be: programmers are operators of a technical workflow, and nothing else. They pull to-do items from a queue (which someone else manages) and work them through various states of a purely technical nature until they can be handed off into production (where someone else creates value using them). Again and again and again forever. And it is claimed that if they are organised this way then they will be more efficient and shipping those to-do items than if organzied in other ways. This is almost certainly true.

In which case it is going to be hard to avoid being shoe-horned into that mode once the development managers wake up to it. Back down into the engine room. Back to being, rather more literally than before, a cog in a machine.

The Agile approach to developing software (or, something a lot like it) is gaining more and more interest because, along with the stuff about getting to look up at the stars it is actually a more productive way to develop than a lot of the incumbent approaches. If Lean is more productive again but doesn't even have that social stuff as a hidden agenda, I'm not sure that we as inhabitants of this corner of the industry will turn out to have done ourselves much of a favour.

Lumpy Kanban

The coalescing of bits and bobs in this posting to the kanbandev Y! group have brought me to a realisation of why Kanban-for-software seems to make me cringe so much. I thought that I'd replied in the group, but apparently not, so I'll do it here. Reply now here

Versus what I'm used to seeing (expect to see, want to see) in an Agile development organisation the Kanban that I've seen explained in numerous posts, conference sessions and so forth has far too large a batch size. There's far too much work in progress. The flow of value is far too uneven. I mean, really, the Kanbanista's want us to organise our work around something as big and lumpy and lengthy as an entire feature!?

The Rush to Lean Makes Me Nervous

And I'm not the only one.

Now, I am not an expert on manufacturing, but I have seen some. Software development is not manufacturing. I don't think that it's even very much like manufacturing. Manufacturing is about achieving uniformity across huge numbers of multiples and making some trade-off between the highest and the most economic rate of production of those multiples. 

Software development is about making one. 

I believe that software development is more like product development than manufacturing.

I'm not an expert in product development either, but I work for a company that, amongst other things, does develop products. Product development is very different from manufacturing (which we don't do), although the two are very closely related. A big part of product development is to arrive at a design that can be effectively manufactured. 

Unfortunately a lot of our clients don't want you to know that we designed their products, so I can't brag too much. Which is a shame as a lot of them are waaaay cool. However, this flier[pdf] is public and describes one episode of product development. The flier mentions PEP, our process for developing products. As a deliberate policy we try to keep the processes that we use to develop products and the processes we use to execute software development projects as closely aligned as possible. 

Both are iterative. Both involve exploration. Both are adapted to circumstances while maintaining certain principles (such as actively managing risk). Both have delivered a very high success rate over many, many engagements. So I feel on fairly firm ground in claiming this similarity between software development and product development.

As Steve Freeman points out, by a strict Lean interpretation of the manufacturing school product development looks wasteful. And it is. And that's OK because it isn't manufacturing. The economics and the goals are different.

Its worth noting that the highly-publicised Lean successes seem to be concerned largely with operational activities: never-ending, on-going care and feeding of an existing system. To the extent that your activities are like that, a more Lean approach is likely to work well for you, I think. I've yet to hear of a success story of strict Lean (no iterations, no retrospectives, all the rest of it) run in a project setting to produce a new product. 

I don't say it can't be done, but I've not heard of it. If you have, I'd love to.

"just work"

There's an idea in  the management world that some work is "just work". I once had a holiday job in a factory that involved a good deal of one kind of "just work"—unpack a box of bottles of nose spray originally destined for one market and re–label them for another, put them into a different box. Well defined tasks, repeated many, many times. At the limit "just work" comes close to the physicist's idea of work: it's what happens when a force displaces its point of application.

Over the last century or so "just work" has been the topic of intensive study. Techniques for organising the execution of "just work" with the goal of maximum output are very well developed. But what is "just work" for programmers? The question arose in the comments attached to this discussion of distributed development. It also relates to some thoughts I've been having recently about the rush to adopt Lean practices in some quarters.
 

Andres says that 

In knowledge work, “just work” is learning. [his emphasis]

If that's true then I think we have to say that a lot of contemporary development activity isn't knowledge work. Wiring up GUI controls? Transducing between HTTP requests and SQL queries? Mashing up web services? You have to learn how to do these things at all, it's true. But what do you learn while doing it once you know how? What learning takes place that is the work? 

I'm reluctant to accept "finding out how to hack your way around the deficiencies of the current framework" as a form of knowledge work. Meanwhile, this maybe does give me a way to think about a curious claim (see comments #3 and #4 on that posting) from the Lean camp:

A pair team has to produce twice as much output at a given level of quality as two solo programmers in order to be worthwhile.

What would we have to believe, in order to think that this claim were true? I think that we would have to believe that the paired programmers are engaged in quite a strong sense of "just work". What is it that a pair of programmers necessarily do half as much of because they are pairing? I can't think of anything but typing. Are keystrokes really what it is that programmers do that adds value? At a slightly higher level of sophistication we might say (as Corey in fact does) that the measure of value added is function points. That's a much better measure than typing (which implies code)

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.—Bill Gates

but still gives me slight pause. Function points are still a measure from the technical solution space, not the business problem space. One of the things that makes me a bit nervous about the rush to Lean is the de–emphasis on conversations with the user/customer (which Leaners have a habit of dismissing as wasteful "planning") in favour of getting tons of code written as fast as possible. 

What I really want to see is getting users empowered to make money (or whatever it is they value) as fast as possible. That's knowledge work. And that requries learning.