Had a very nice and ram­bling con­ver­sa­tion with Ron Jef­fries at the Brighton Agile Round Table yes­ter­day, where we talked all around the two straw men mod­els of “Strict Water­fall Project Man­age­ment” and “Absolute Agile Project Man­age­ment”, in light of the com­plex­o­log­i­cal model I’ve been sketch­ing.

Mostly there were inter­est­ing reac­tions and clar­i­fi­ca­tions to be made on the “analy­sis” end of the model, so I’m going to focus there for the moment. Recall that the point of this exer­cise is to craft a com­plex systems-​​y model of “project man­age­ment” that’s flex­i­ble enough to include the “Water­fall” sto­ry­line and the “Agile” sto­ry­line, keep­ing track of costs, time and fea­tures and… what’s the other one? Oh yeah, qual­ity. [joke!]

So as you’ll recall, I started (as any heir to Stu Kauff­man would) with a Ran­dom Boolean Net­work to rep­re­sent the “ground truth” of what peo­ple want. Orig­i­nally, I’d sketched this as the dynam­ics of an RBN, with the “prod­uct” being built try­ing to pre­dict and match the dynam­ics of the market’s whims. Seems that’s not a very com­fort­able anal­ogy to draw: where I was see­ing the time-​​series of inter­con­nected dynam­ics of many fea­tures “as” a cor­re­lated fea­ture, the lan­guage we use to talk about soft­ware projects very strongly empha­sizes fea­tures as fixed struc­ture, and user expe­ri­ence as the dynamic thing. So the sense of Prod­uct try­ing to match the twin­kling lights of Mar­ket is tricky.

On the other hand, I have to set my heels at the idea of features-​​as-​​atomic-​​traits, since after all I’m ulti­mately aim­ing to model devel­op­ment and team learn­ing as fea­tures are built and revised, and pat­terns are learned and re-​​used. So I’m not will­ing to drop the RBN’s com­plex­ity all the way back to a more “tra­di­tional” Kauff­man­ian sta­tic Nk model of a fit­ness land­scape. Not that there isn’t a lot of nice tun­able ground to be cov­ered in fit­ness land­scapes and stuff, but because soft­ware is used, it doesn’t just have attributes.

So here’s what we’ll try next:

Sup­pose that the ground truth of what the Mar­ket wants is deter­mined by a Ran­dom Boolean Net­work. But not in the sense I described before, where the desired fea­tures are only evi­dent via dynam­ics, and the goal is to build a prod­uct that mim­ics those dynam­ics. So no more “twin­kling lights”.

Instead, con­sider the RBN to be the (secret) map of Mar­ket expec­ta­tions. The Mar­ket will pay (or cost, in some cases) a cer­tain amount for every Prod­uct fea­ture which works in the same way as the ground truth expec­ta­tion. But in this new ver­sion, the Mar­ket is not actively gen­er­at­ing some kind of light-​​twinkling trace of data for the Team now, it’s just will­ing (for a price) to answer ques­tions about its pre­ferred outcomes.

Think of every pos­si­ble tran­si­tion of N input bits to N out­put bits as a use case over the N input fea­tures. “When the browser is open to the home page, AND the user field is empty, AND I click ‘log in’, AND I do not have a cookie set, THEN this other stuff should happen….”

A per­fect Prod­uct will pro­duce all the same out­put strings as the explicit Mar­ket func­tion does, for all inputs. Any given Prod­uct earns money in pro­por­tion to how well the released fea­tures match the Market’s tar­get desires.

But the Team only has access to aggre­gate income infor­ma­tion, unless they pay for mar­ket­ing.

There’s a lot of lee­way here. Sup­pose a Team play­ing the low-​​hanging-​​fruit game comes along, and they release a Prod­uct that is just a con­stant out­put, say 1111100000, the ulti­mate in “you can have any color car, as long as it’s black.” They might just make some money, since there’s a chance the under­ly­ing Mar­ket desire is biased that way.

Although I don’t have any inter­est to do it in this model, I have to note there’s an open­ing here for explor­ing “mar­ket dynam­ics” in such a world. A slightly smarter Team (in the same Mar­ket set­ting) might come along and release some­thing that is just as dynam­i­cally dumb as the 1111100000 folks, but bet­ter matches the aver­age desired out­put for each fea­ture. They’ll make more. Some inno­va­tor may well come along and release a prod­uct that pays atten­tion to some inputs, maybe first-​​order inter­ac­tions. They’ll make a killing.

But today I want to focus on the process within a Team, not the dynam­ics of a full mar­ket pop­u­lated by Teams with dif­fer­ent strate­gies and capacities.

Now I’m reminded that the mod­els of project man­age­ment (at least the ones we’re used to) will include some big block process labeled “analy­sis” or “mar­ket­ing” or “project man­age­ment”, and since Agile project man­age­ment implies holis­tic adap­ta­tion that should include mar­ket research on the Team when­ever mar­ket research gen­er­ates busi­ness value, we’d bet­ter include that block in our model.

Call it Require­ments Gath­er­ing (or maybe Refine­ment, if you want to imply the inclu­sion of the tra­di­tional “Main­te­nance” func­tion­al­ity, as we should in an Agile Team). Let’s give them some tools.

How about inter­views? Say each inter­view costs a cer­tain amount of money and time, and the Team’s ana­lysts can (with 100% con­fi­dence) elicit one input-​​output com­bi­na­tion from the Mar­ket. “If you’re 1011100011, what will you do next?” To me, this has the metaphoric capac­ity to han­dle peo­ple not know­ing until they’re asked, and also rev­e­la­tion of only indi­rect infor­ma­tion.

An inter­view like that should be expen­sive, I think. How about A/​B test­ing, or more gen­er­ally polling? “If you’re 1001101111, which of the fol­low­ing do you pre­fer as the out­come, 1011100011 or 1100000011?

Then of course there’s sales data, for sit­u­a­tions in which there is in fact a Prod­uct already released: As I men­tioned, even a very dumb prod­uct that fills some roles slightly bet­ter than the ones it messes up has the capac­ity to pro­vide his­tor­i­cal infor­ma­tion (and rev­enue to pay for improvements!).

Now this brings up one more change from the pre­vi­ous iter­a­tion of this model: Revenue.

In the first ver­sion, I pro­posed a model in which each fea­ture had an intrin­sic pos­i­tive value, and a released Prod­uct col­lected that value dur­ing every time period where it matched the intrin­sic Mar­ket dynam­ics. We don’t have Mar­ket dynam­ics now, we have a Mar­ket that’s a black box.

The base­line in this old one was “you make noth­ing”. I’ve rethought that, too; let’s throw a mon­key wrench into our Team’s world, and allow fea­tures to be neg­a­tives as well as pos­i­tive desires. In other words, when­ever a fea­ture with a neg­a­tive value is matched, the Team loses money.

So where are we now?

Let’s say the Prod­uct is some kind of func­tion that takes gen­er­al­ized Boolean inputs and pro­duces (coin­ci­den­tally) gen­er­al­ized Boolean out­puts. The space of inputs is all –bit binary strings, gen­er­al­ized to include # or “don’t care” inputs where an input is ignored, and the out­put space is all –bit binary strings gen­er­al­ized to include ? or “unset” out­puts, when an out­put bit is not explic­itly set to either 0 or 1.

Take a sec­ond here. We can there­fore say a Team “starts” (hav­ing done no work think­ing about or devel­op­ing any Prod­uct at all) with a “default” Prod­uct that ignores all inputs and pro­duces no out­puts: ###…### -> ???…???. They aren’t earn­ing or los­ing any money because their Prod­uct has no vis­i­ble fea­tures to cap­ture (pos­i­tive or neg­a­tive) Mar­ket share.

Sup­pose after some devel­op­ment time a Team releases a (rather stu­pid) Prod­uct that imple­ments ###…### -> 111…111; in other words, it always returns 1 for every fea­ture. How much money do they earn?

We deter­mine this either by doing the math or by sam­pling. We know the ground truth Mar­ket func­tion, a large and rather com­pli­cated truth table. If we want to do the math, we can con­vert it into a cum­ber­some prob­a­bil­ity func­tion, and just assume that the diver­sity of peo­ple in the mar­ket is absolutely uni­form: that is, that peo­ple will “use it” by apply­ing every pos­si­ble input. Alter­nately, we can sam­ple this space (using the same assump­tion of uni­for­mity) by tak­ing 1000 or so ran­dom bit-​​strings as inputs, and count­ing up how much rev­enue the Prod­uct gen­er­ates (or loses) by match­ing those features.

Sup­pose in our exam­ple there are 21 fea­tures, and that the value of the first is , the sec­ond , and so on, with the 21^st pro­vid­ing value of . The Prod­uct that returns 1 for every input will lose $10 for every 1 in the first feature’s out­put table, and earn $10 for every 1 in the 21^st feature’s out­put table. So it’s just a mat­ter of count­ing to deter­mine how prof­itable it turns out to be.

Just to make it clear, sup­pose some other spe­cial­ized Team releases a Prod­uct that does a per­fect job at only one fea­ture whose intrin­sic value is $4. It will earn the Team $4 for every pos­si­ble input com­bi­na­tion, regard­less of the other fea­tures; no money is lost or gained for fea­tures that are not present, or do not match desired outputs.

More later; time for lunch!