All production, whether in software development or not, relies on “external” collaboration (both upstream and in parallel). And that collaboration seems to fall into one of two areas: viability and clarity.
The first of these, viability, comprises all of the thinking (and its articulation) required to establish a suitable framework for production. For example, if you’re in the construction business, it’s a good idea to have an architect draw up plans for a building before anything else happens. There should be no scheduling, no material ordering, no labor hiring, and no cost estimating before there is an architecture. That is the framework for production. The same is true for software product development, and the same term, architecture, is used. In both cases, you can build without an architecture, but the viability of the product will be in serious doubt.
The other area, clarity, comprises all the thinking and articulation around knowing what you want to produce, and why. In business, production has objectives – usually a combination of need fulfillment, strategy, and profit. There are preparatory and ongoing activities involved in sorting those out (and articulating them) and in insuring that that they and the work product remain complementary during production. Without this clarity, the work product’s value is put at risk. In the construction business, clarity may be supplied by the interior designer, the property developer, the principal tenant, the landscape architect, the HVAC specialist, and others. In the software business, clarity is the responsibility of the product management organization.
Having said all that, I can now state my point, which is this:
Agile as commonly practiced is naive when it comes to providing clarity for and insuring viability of the finished product.Agile tends to take care of the production team (software developers) – in an ingenious and elegant way. But Agile leaves that team dependent on substantial unspecified (and often unbudgeted) effort on the part of system architects and product managers. Planning for the effort and availability of those two groups, essential to the viability and clarity of software development, is treated as an externality – and that is a substantial omission!
To make matters worse, when the need for the effort of those folks becomes apparent, that realization usually comes in the form of an emergency. Architects and product managers are then expected to devote unlimited time to the production effort, without regard to their other responsibilities.
This is not a recipe for success, and most Agile shops are struggling with it. As far as how to remedy the situation, I don’t have a proven answer. But I think the key might lie in exposing the effort required for all the work required for a successful delivery, not just the production work.
What if, in addition to the product backlog (which is a list of production items delivering business value) we maintained two additional backlogs of work, the clarity backlog and the viability backlog? They would be the domains of product managers and architects, respectively, and would expose work that is now usually hidden. The aim, of course, is to permit strategic and proactive allocation of resources to get that work done in time to feed the production work that depends on it.
I’m not exactly sure how this would work in practice, or where it would lead. But it strikes me as fertile enough ground to be tried, and I intend to try it. I will report back if my attempts bear fruit. In the meantime, I’d be interested in hearing about your experiences and observations.
