Share
The concept of traditional construction could not be a worse metaphor for software development. Yet, for a long time, that’s exactly how it was done. With this kind of formal architectural engineering process, the “right” set of requirements were predetermined and translated into blueprints then implemented, with the hope that enough up-front design would prevent any uncertainty down the road. But because the very nature of software requirements is in a constant flux, this process ensured failure before the first line of code written could be written.
The agile transformation
The solution to the conundrum of change was the introduction of an agile software development process. By segmenting the long, rigid (waterfall) process into shorter sprints, companies could decrease the risk of failure by reducing the time between design and delivery. Reshuffling from a hierarchical organization to one revolving around business capabilities promised less coordination and increased bandwidth during these short cycles. Introducing methodologies such as Scrum and Kanban improved performance for many modern organizations, but experience shows that a change in process management was only half the story.
Autonomous teams
Truly agile teams move autonomously, without constraint. They define their own requirements with the business and design or architect solutions as they see fit. Their constant focus is on continuously delivering value for the customer. With the promise of a radical change in performance, many companies invested in agile restructuring and often had some positive effect. But much more were still doubtful, unable to measure any significant impact overall on their performance.
In Swimming With the Faster Fish - Part 2: The road to technical profit, I explain the dual of Conway’s law, a theory that companies model software in the way that they’re organized, also tend to organize themselves in the way their software solutions are built. In other words, the flexibility of an organization is the consequence of the flexibility in its architecture.
So, how can a team build software autonomously if the design and deployment requires full alignment with other development teams? To improve the flexibility and performance of a business, put the dual to your advantage.
The technical side of agile transformations
The flip side of a successful agile transformation is an investment in a software architecture that supports and stimulates an agile way of working and keeps both teams technologically aligned, but loosely coupled. By stepping away from the idea of software architectures as highly controllable and rigid structures, an agile architecture increases team flexibility and reduces the coordination and management required to go from idea to production.
Like a migration towards an agile way of working is hard to execute without an organisation-wide acceptance and adoption of its rules and boundaries, companies should define and adhere to a same set of principles when implementing the software architectural counterpart. Because in the end, it’s not about the idea of making your organization agile or building your software using a “microservices” inspired design; it’s about the execution while guarding its core principles. Because agile just by name, but without dedication in every layer or your organisation and architecture, is a sure recipe for disappointment.