It seems that whatever business or tech-related Internet corner we find ourselves in another era of “agility debates” is back. What is agility? What isn't agility? I find these debates to be a waste of time, and I spent a good amount of time early in my career engaging in them! If you're familiar with my writing, you understand that I'm always in search of two basic things. First, finding the clearest path from the abstract to the concrete. Theory is important, but only if it has practical application. Practical should be long on value, short on ceremony. Application, to be practical and useful, must be clear and straightforward.
That's the value proposition to anything. It's that value proposition that gets to the second item, the broadest possible application. The irony here is that in order to find the broad application, it requires making the concrete abstract. At the same time, in order to make the abstract have practical application, it must be made concrete. One feeds into the other simultaneously, like an Escher drawing with no beginning and no end. It's more like the two sides of a coin, which is part of the primary currency in business and technology today. Generally, necessary things in business come in pairs - complementary pairs, much like tactics and strategy. Tactics must support and be informed by a coherent strategy and any coherent strategy must be tempered by coherent actionable tactics.
That leads to the two things I'm keenly interested in today: agility and content distribution, two things that have largely become the stuff of middle-management marketing reductionism. Both agility and content distribution, like blockchain, have become misunderstood, despite their importance, and despite the substance they represent. This pair, I believe, is a good example of the two-sided coin metaphor and, when broken down, illustrates what I further believe to be the proper lens through which to view the intersectionality of business and technology and therefrom, realize the value proposition that agility and content distribution present.
Agility and content distribution have become quite misunderstood.
From a practical standpoint, one or the other cannot be viewed in isolation. It's the same line that's between practice and theory or, put another way, the concrete versus the abstract. In isolation, these two things are indeed independent abstract things. They're very much akin to concepts like design patterns and domain-driven design. If there's no practical application for those abstract things, what good are they?
We see this with agile today. A shop proclaims, “We're agile.” Or “We practice agility.” But all too often when we try to pin them down on how they're agile, we're greeted with crickets. This usually happens when agility is but an aspirational thing. If we understand at an abstract level what different and complementary things are, how they relate to one another and in combination, and how they, as a combined unit, relate to other things, then perhaps then we can begin to understand how these different things can be joined as two sides of a coin to fuel the business.
Let's try that with agility and content distribution here.
Agility
Agility is defined in the Agile Manifesto (agilemanifesto.org), which is a set of principles. That's a very important point. In other words, Agile isn't what we think it is. Agile is what it says it is, as defined in the manifesto. Agile isn't a practice, it's a collection of principles. To practice Agile principles, there must be some concrete application. Agile principles state:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The Agile Manifesto concludes with: ...[w]hile there is value in the things on the right, we value the items on the left more. The “left” and “right” here are the things that are stated before and after the word “over” respectively. Ultimately, what is of acceptable value is determined by many things that, among other things, are specific to your firm's and the project's context. The big point is that too often, the manifesto's concluding sentence is forgotten. Put another way, we don't only consider the items on the left to the entire exclusion of the things on the right.
There are infinite ways to practice agile. The only requirement is that whatever mode of practice is implemented, that mode must support the manifesto and such support must be demonstratable through objective evidence. Too often, the manifesto is misread and misunderstood to imply or explicitly state that “agile means no documentation.” A plain reading of the manifest clearly disproves that assertion.
Another misunderstanding is “agile means no planning.” If we look to established agile frameworks, like scrum, that recognize sprint planning as a necessary event, again, we can easily conclude that agility and planning are not mutually exclusive and antagonistic to each other. To the degree that we engage with planning, that planning should be tempered by what we engage in while responding to change.
If there were no plan, all we'd do is react, not respond. Reactions are quick and reflexive, not considered and thoughtful. It's through interactions with our customers that we plan enough to build working software. A document that purports to articulate what proposed software is to accomplish is just that, a document. The document may deliver a good, aspirational story, but it doesn't yield the same value that working software would That story, at best, is a means to some other end. As a communication device, there is most certainly value. The end result must be some value proposition that the business will realize and understand: that is, delivered and working software (working defined as conforming to a defined specification).
Serving the business is what technology is supposed to be about. And agility is one means by which that can be done. And that means can only have efficacy if it's properly matched with what the business does. In my opinion, every business's value proposition is found in how it distributes its content.
Content Distribution
Traditionally, we see the phrase “content distribution” solely in the media context. Think HBO Max, Tik Tok, Netflix, etc. “Content” is simply those things that are contained by some other thing. Content can be tangible like a book, painting, or computer. Content can be information. Content can be an ability. Content can be a service. And of course, content can be software. In the era of the cloud, the phrase “software as a service” (SaaS) is nearly ubiquitous. Even Office 365 is a prominent example of SaaS content. Whatever service or product a business provides to the public to drive its earnings, that's content. How a business delivers that content is typically in the domain of some software application to at least some degree.
Agility is the means by which that software is built. If this seems like a circle with no beginning or no ending, that's because that's exactly what our world of software development is today. In order to break out of this back and forth in favor of a practical tactical prescription, the manifesto itself provides a clear answer: Rely on use cases to drive process and tool selection.
In agile, we identify the items that are planned, and their selection is informed and driven by the items that are in response to change.
In a previous column (CODA: On Tool Selection in the March/April 2022 edition of CODE Magazine), I described a system and approach for tool selection to avoid what I call “tool salad.” Perhaps a good process and approach may be to adopt domain-driven design (DDD) and a tool that supports DDD. For example, your business may have multiple service lines, each in their own domain and perhaps consisting of multiple sub-domains. Further, your business may have several cross-cutting domains like HR, accounting, legal, and compliance. To manage these facets in an agile manner, such that you can respond quickly to change, requires a plan.
Perhaps that plan consists of implementing DDD and DevOps. To speed delivery, you may consider continuous integration and delivery (CI/CD). How do you implement such things? Clean code (SOLID) programming practices are one such way. And if you're in a regulated environment (SOX, FDA, EPA, etc.), those rules and regulations, by and through regulatory agencies, bring many considerations as to how you will distribute your content.
Inspection and adaptation are key concepts in both agile and continuous improvement. That's the circular aspect of the business of software development. It's ironic that businesses often lament about how they must continue to keep pace with their own industries. Keeping pace often requires new and modified services and products (content). And that often means that the way we build that software content must change as well.
Changing how we build software often gets short shrift. It's true that technology must serve the business. But in order to serve the business, the business must also serve and maintain its technology. Although the business is the primary driver, each must service the other simultaneously. That's where the relationship between agility and content distribution comes in.
We must continuously search for the truth with our theories and abstractions. On one hand, we must widen our lens so that our abstractions have as broad an application as possible. At the same time, we must place limits on how abstract our abstractions can be because there must be practical application. The latter requires that we also narrow our lens and lower our altitude.
All of this seems rather counter-intuitive and contradictory. If we accept that one view informs the other and vice versa, and we require that everything be substantive (avoiding marketing chatter and quick summaries), we can undertake the serious hard work of solving today's complex problems. Solving problems involves a certain amount of informed trial and error to make a positive impact. And agility applied to a business's content distribution is a means to achieve that positive impact.
