Big-A Agile: The Path to Nowhere

How should we evolve our organizations? PRODUCT DEVELOPMENT--product discovery, product-market fit, market share acquisition.

We attempt to do this with Agile practices. We think it'll allow us to pivot our product concept as we go but we don't operate it that way. We start with a concept of the product we want, maybe 50-80% defined. Most organizations require this in order to obtain resources for development and delivery. Unfortunately, this forces the product development and delivery process into a waterfall mode, even if delivery is executed with all the trappings of scrum. (For this reason, the term 'requirements' makes chills run down my spine.) Marty Cagan in one of his talks showed very clearly how agile initiatives conducted this way simply become waterfall projects.

Scrum and it's variants are DELIVERY approaches, not PRODUCT DEVELOPMENT approaches. The scrum approach consists of a backlog of feature and function deliverables (the 'requirements') force-fitted into an arbitrary series of delivery increments. This doesn't account for deliverables that won't comfortably fit in the allotted time for a sprint--either the deliverable is arbitrarily broken up into multiple sub-deliverables to be built in series across sprints or somehow shoe-horned into the standard sprint by assigning multiple developers to it. Why can't we work in variable-length sprints when it makes sense to?

We measure the success or failure of the process in terms of whether all of the features or functions planned for the sprint are completed and working by the end of it. We implement incentive and reward systems to push teams to get their sprints done in the allotted time. Spillover is considered an anathema and often indicative of personality failings among participants. Quality, accumulation of technical debt and drift from optimal market offerings seem to be left out of the equation.

All of this stands in direct opposition to what agile product discovery and delivery should be about--learning, validating and pivoting. If we assume that our original product ideas are 70+% likely to be wrong, why would we strap ourselves into a process that obligates us to deliver it with only nominal modification? Yes, it makes the delivery process more 'predictable,' but it makes no sense. To quote Emerson: "A foolish consistency is the hobgoblin of little minds. . . "

What if instead of features and functions, sprint goals were articulated in questions being answered or assumptions being tested? Then the infamous backlog grooming sessions could consist of reviewing the state of knowledge, identifying what new questions should be addressed and what experiments should be conducted in the next sprint. This, I believe, would get us a lot closer to the spirit of the Lean Startup and could save a lot of wasted and misdirected time and effort.

Invariably, this would discomfort executive stakeholders that worry about returns on investment and predictable progress and project managers that worry about keeping on schedule and budget. But, would we rather deliver the wrong thing on time or the right thing?

I think you know the answer.