agility as i understand it is about trading certain kinds of control or control-effort for other kinds of control or control-effort.
a couple of examples, one from where the geeks play and one from where the product team plays.
i should start with that weird combination of control & control-effort. some efforts at control result in actual control. others, no matter how effort-ful, do not.
you might jab the brake pedal in your car a thousand times, an effort at control. but it won't actually steer the car, no matter how hard you try.
i bring this up because i want to sidestep for the moment the question of whether one kind of effort works or not. it is enough for this conversation that we accept that these efforts are good-faith efforts to make the thing do the thing. relative efficacy's irrelevant for now.
so, i'm saying that this movement is centered around using different kinds of effort to make the thing do the thing. the things in question cover quite a broad range. we might be trying to make the org more responsive to the customer base, or the code cheaper to change.
a product team wants more than anything else to have a product that is attractive to its users. there are always lots of factors involved in this calculus. actual value, perceived value, newness, price points, all of these and lots more besides.
the oldest-school way of doing product is to drive product development by writing detailed psuedo-contract requirement documents that project the future of the product into periods as far away as five or more years. more commonly nowadays, one sees such planning cycles yearly.
we'd exert control-effort by looking as far ahead as we could and working on paper backwards to whatever we had. we made a plan, got sign-offs and estimates -- a process itself taking months -- and finally said "go". then we sat back and waited for it to all come true.
this is not the way product folks work in the modern synthesis. instead, they work by a continuous process of asking "what's next?", constraining that work to as small as a couple of weeks, sometimes even a couple of days.
further, that team is diffused throughout the org, not centered in a department, but with product folks "in play" within every sub-team of the org. they're less a hierarchy than they are a network of value-specialists supplying local value-definition all around the org.
their work is driven by some top-level vision, to be sure, but the implementation of that vision is left to them and the teams they're embedded in.
this analogy i'm about to make may go suddenly south, but i'm gonna run with it.
value-definition has to be pushed around to every corner of the building. in the older school, we have a great big value-definition plant, it creates all the value-definition, and then we pipe it around using documents like a big ventilation system.
in the modern synthesis, we do it differently. instead of a large value-definition plant, we have lots of small ones, inside each room. these small "value conditioners" are connected, but for coordination & correlation, not for the actual value-definition creation.
it's not that there's *no* control. value-definers are constantly aligning with one another using their own channels. we are depending on this to get roughly the same value-definition spread all over.
on to geekery. oldest school, geeks sought to solve every problem using two slogans: "right the first time" and "once and for all". this led them to a process of accepting that massive requirements document and planning every step in their five-year or one-year trek.
in that school, "changing code" was considered the most expensive thing. so doing it right the first time and doing it once and for all were fundamental values.
they sought to control the expense by heavy advanced planning. this could boil down to a single person in a room by herself creating a master architecture document, and another single person turning that in to detailed design, then pumping it all out to the geeks on the floor.
the modern synthesis is again very different. here, we embrace "changing code". our slogan isn't "right the first time" or "once and for all". its "get it change-enabled right for now".
and again, the central design plant tends to be replaced by many smaller design-plants distributed throughout the building. they act in coordination, but it's a control-network not a "move design-source around" hierarchy.
so. the modern synthesis can be seen from one angle as replacing central plants driving a hierarchy of basically dumb vents, to a set of smaller localized plants, each creating their output right in the room, based only a coordination network with all the others.
i have some really important-to-me things to say about these two arrangements. the central vs distributed schemes. i am not going to continue just yet, tho. just the same, i want to leave you with one thought to ponder until next time:
the sources in the modern synthesis, for product and geekery both, aren't moving around their respective outputs from a centralized source using a hierarchy. they are creating those outputs according to some coordination network, yes?
how's that coordination network function? if it's not dumb vents passing direct output, what output-precursors *is* it passing?
what factors does successfully rigging a system this way depend critically on?
i'll contend there is one of those factors above all that matters.
what factors does successfully rigging a system this way depend critically on?
i'll contend there is one of those factors above all that matters.
(no blog yet for this one. having it laid out in front of me, i now know what i actually wanted to get at from the start. i'll produce a proper essay over the next day or two.)
