Product-Aligned Software Teams
For a long time now, and starting in earnest in the early 1990s, people involved with software development and delivery have been shifting various aspects of the work to the “left,” if you visualize a software delivery pipeline that runs from left to right. What’s the endgame?
Shifting Left
First, unit testing was shifted left to happen concurrently with programming, and later shifted all the way left to drive application design and coding. Then code integration was shifted left through the practice of continuous integration. This enabled trunk-based development, which alleviated a good deal of stress around code merges.
The next steps to be shifted left were static code analysis, security scans, license checks, and so forth.
After that, the packaging and deployment of code was shifted left and added to a growing automated delivery pipeline. Then, integration and functional testing were shifted left and integrated into the pipeline, and later regression testing was added.
Then people realized development practices could be applied to infrastructure work, and the creation of runtime environments was shifted left and baked into the pipeline as well, so that we no longer moved software into pre-existing environments. Some people call this sort of thing “devops,” and some of those people emphasize the cultural aspects of it over the technical ones.
By 2011, some software organizations were able to practice continuous delivery effectively and reliably. At one point, Amazon was said to push new code into production every eleven seconds, with high reliability and few errors. Ten years later, continuous deployment (at least) and sometimes continuous delivery are seen as normal.
That takes us all the way from programming to production…but it excludes production. Is that the next step?
Closing the Circle
If we have a team that is “aligned” with a product or product line, or with a value stream (if you prefer that term), then why must operations and production support be handled separately from the rest of the work?
What would change if the same people who handled software development and delivery also handled operations, proactive production monitoring, and production support?
I think it would finally close the circle. Given a product-aligned, cross-functional, dedicated team, if we extended their responsibility to include production, we wouldn’t have a “pipeline” anymore – we’d have a circle. Feedback from the production environment and from real customers could feed back into the development process in near real time.
Recently, people in the agile community have been talking about what comes next for agile; or maybe what comes next after agile. This next step in consolidating software work may partially answer that question.
All the language agilists use is based on the underlying assumption that the end goal of any software development team is to “deliver” or “ship” code to production or to the market. Once the code is in production, it’s no longer the team’s responsibility. They are “done,” or “done done,” or even “done done done.”
The more repetitions of the word “done,” the less interested they are in supporting what they have written or the people who use the application. They want to turn their attention to the next feature. It’s fun.
But from the perspective of a user, the software doesn’t even exist until it’s been delivered. Delivery isn’t an ending – a definition of “done.” It’s a beginning. It’s realistic to say software isn’t “done” until it’s retired from service. Until then, all software is subject to change.
Another factor has become increasingly important with the advent of microservices and elastic cloud environments: It isn’t possible to test everything adequately prior to delivery. Rather than a single server with a static configuraiton, the runtime environment has become a complex adaptive system in its own right.
Keep the Baby and Raise It
For years now, the focus on “delivery” or “shipping” has struck me as tantamount to delivering an unwanted baby to the steps of an orphanage. We enjoy building solutions, but not supporting them. Maybe it’s time for software professionals to keep their babies, raise them into well-functioning adults, and support them through retirement.
Today, tools based on the idea of observability enable teams to monitor production proactively. Ideally, they should observe production operations when there are no active problems, to gain a sense of how the solution feels when it is working properly. That way, the team can perceive when the solution is drifting into an unstable state and take corrective action even before customers or client systems are affected.
When the development team watch production operations, they see customer/user behavior immediately, they see the effects of changes in the dynamic execution environment immediately, they see what happens when client code misbehaves, and they can feed this information back into the development process seamlessly and immediately. At that point, we no longer have a “delivery pipeline” that is disconnected from operations and from customer experience, and we have a continuous circle of feedback that enables truly continuous improvement of the product and the customer experience.