On its own, Agility makes no sense
What is Agility, really? In some respects, it can seem multifaceted, especially since its message is obscured by the “noise” of sprints and other estimations. If I had to sum it up in one sentence, I’d say it’s the pursuit of efficiency in software development, in a context where change is the norm. Agility is the art of “how”: how to quickly ship high-quality software, knowing that requirements are discovered as we go and that production capacity is limited.
Agility has its roots in eXtreme Programming, which had it all: there’s no point in breaking things down into user stories if you can’t deploy to production very frequently. Hence continuous integration and continuous deployment—and, if we keep unraveling the thread, the topics of testability, modularity, and Clean Code. Agility, DevOps, and Craftsmanship are all three necessary to “make it work.”
On the other hand, what do we know about the “what”? I’m referring to the clarification of requirements—knowing what to develop and getting it right. This includes a variety of activities, such as user research (discovering and characterizing the problems to be solved), functional design (defining what needs to be implemented, as well as breaking it down and prioritizing), interface design, and user testing. These concerns fall under the purview of Product Management, which necessarily draws on the field of UX (User eXperience).
What really surprises me is that people talk about Product Management without mentioning Agility—and vice versa—even though the two go hand in hand: they are two sides of the same coin, the former pertaining to strategy while the latter pertains to tactics.
-
Product Management without Agility is pointless: what’s the point of designing great software if there’s no capacity to deliver it? And indeed, what good is a design if it isn’t quickly validated through use?
-
Conversely, Agility without Product Management doesn’t work: it’s a headless duck, the famous “we don’t know where we’re going, but we’re going there.” In fact, many companies that complain about having agility problems actually have problems defining their requirements.
Ultimately, this reveals that Agility was conceptualized by people who came from a development background and who thought through the lens of their own perspective, background, and concerns. And that’s perfectly legitimate. And it already adds a great deal of value. But these developers, as insightful as they may be, sought to optimize their work within an established framework, perhaps without daring to question it. The phrase “responding to change” is, in this regard, very revealing.
To my knowledge, no agile framework addresses the topic of functional design, and certainly not Scrum. A Scrum Master doing their job will likely tell you that the time developers spend on design—assuming they’re involved at all—results in lower velocity, so that’s already factored in… This is an unsatisfactory answer, because the question isn’t how long it takes to develop a feature, but rather how long it takes the company to go from an unvalidated idea to a feature deployed in production. In short, Time To Market.
Perhaps, as Lean suggests, we should view software production as a business flow—one that encompasses both Product Management and Agility—and seek optimizations at the level of the flow as a whole rather than within the boundaries of each individual silo.