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 lies in exposing the business value of all the work required for a successful delivery, not just the production work.
That is probably a good practice in any field, and I’m now going to continue on in a way which is specific to software development. So if that’s not your field you may want to take away any nuggets you can, and stop reading now.
Some Agile shops have wisely instituted the practice of assigning a business value to each user story (and when advisable, to epics) in the product backlog. This practice can serve as an instructive model for addressing viability and clarity because it shows how to help the business understand the value being delivered. It also helps the business prioritize work and monitor the pace of value delivery.
Maybe it would be a good idea to (1) maintain additional backlogs (that is, of sized value-packages) for each of those two "external" areas and (2) assign each of their backlog items a business value (a viability value or a clarity value). Doing so would result in three backlogs – production, viability, and clarity. Together, they might help address some of the difficulties I've mentioned.
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.