Since the publication of the Agile Manifesto in 2001 the agile approach has in next to no time developed into state of the art in software development. Countless organizations are trying to harness the benefits of agility for themselves. In establishing and optimizing their individual approaches to agility many organizations are, however, concentrating mainly on organizational structures and processes in their software development teams. With this focus they are taking the second step before the first. The software to be developed must first make agile development processes possible.
What is required for an agile transformation? Many companies mainly think in this connection about the organizational adaptability of their development teams. After all, their structures, hierarchies and processes will be consistently adapted to the new way of working during the introduction of the agile concept. This flexibility alone, however, is not enough to make full use of all the benefits of agility.
What else is required is mainly apparent when it is not just an agile pilot team working on a project that is as manageable as it is clearly delimited, but a scaling of agility is envisioned. When several agile sub-teams are to work on a joint software project it can only work optimally if the teams are as less dependent on each other as possible and they are thereby able to work as independently as possible. Yet in many projects the software architecture is so interlocked, complex and obscure in design that connections and structures are very hard for the individual to grasp. In a case of this kind development teams working on a part of the software cannot predict for sure whether their changes will influence other parts. Teams must therefore continuously coordinate their work, thereby slowing down the speed of development work significantly.
In many projects the software architecture is so interlocked, complex and obscure in design that connections and structures are very hard to grasp.
In agile frameworks like Scrum, however, speed is a precious asset. At the end of an iteration as many functionalities as possible are to have been completed that can be tested and, ideally, put to use. But if dependencies and the coordination and communication they necessitate repeatedly slow the teams down there will be a serious risk of even minor changes not being realized in a single iteration. In that case agile working would no longer be possible – not even if the project teams’ structures and processes had already been adapted to an agile way of working and the team members had internalized the agile mindset.
Modular systems make agile software development possible
To realize the full potential of agility the software architecture must also be prepared for the agile working method. That is best achieved by creating a modular system with different components that are as little dependent on each other as possible. A subcomponent is here to be understood as a clearly delimited program unit with a clearly defined task that is loosely coupled with the other modules via a simple, stable interface.
The subcomponents are independent software in the widest sense of the term, but their scope and complexity are so limited that even a small agile team can manage them. So one team should look after every subcomponent autonomously. That, for instance, is why subcomponents should each have their own release cycle so that teams can determine the length of their iterations themselves and dependencies on other teams can as far as possible be avoided.
A further priority should be that all knowledge about a subcomponent is kept in the team in question. Operational and maintenance know-how should be embedded in the teams accordingly. This step not only makes communication routes shorter; it also optimizes collaboration between the classically separate areas development, operation and maintenance. Modularization of the software thereby creates the preconditions for the software development organization to be aligned to the structure of the software and no longer to that of the processes.
Only a modular system creates the preconditions for enabling the agile teams to maintain the independence they need for their work.
In spite of all the modularization the individual autonomous subcomponents do not on their own make up a functioning whole. The task of connecting the different modules with each other meaningfully is assigned to a core component that like the other components is clearly delimited and has its own release cycle. The core component also plays an important part in testing. The connected components are only tested integratively within the core component. That enables the teams responsible for the other subcomponents to concentrate on the unit tests within their own module, thereby further reducing dependence on other teams.
For the choice of the right architecture it is, incidentally, immaterial whether the software to be developed is a newbuild or an existing system. In either case only a modular system will create the preconditions for enabling the agile teams to maintain the independence they need for their work. It goes without saying that refactoring software that has previously been more monolithic is much more complicated than newly developing a modular system from scratch.
In our experience iterative refactoring is advisable in projects of this kind. First, possible components are identified within the existing software architectures from technical and professional viewpoints. They are then newly created module by module as separate subcomponents. As soon as a subcomponent can fulfill its purpose independently queries are rerouted to the new component while the components that have yet to be renewed remain within the old architecture for the time being. In this way more and more system components move into the new modular architecture over time while the old system grows smaller and smaller and finally disappears entirely.
Compared with a complete newbuild this iterative approach has the advantage that the complexity and the risk remain manageable in the individual work stages. Furthermore, a total new development is very time-consuming. The old system undergoes further development during the newbuild, which repeatedly has to take these changes into account. So the new software undergoes repeated changes before it even goes live.
The independence of the teams is a fundamental success factor in respect of efficient agile working. That is why numerous organizations make strenuous efforts to ease the burden of dependencies on their teams. But the organizational aspect, consisting of the structures and processes within the agile teams and of coordination between them, is only one side of the coin. How is organizational independence to be achieved if technical dependencies continue to exist? That is why, as part of an agile transformation, the software architecture should also be consistently aligned to agility. Modular systems the components of which are so clearly separated from each other that the teams can work in them as independently as possible provide the best preconditions for ensuring this independence.
Jürgen Dinsing has been working in software development for more than 25 years – as a developer, project manager and consultant for topics such as software architecture and process models, mostly agile processes. In his position as project manager and key account manager, Jürgen Dinsing is responsible for various projects in the DevOp environment and mgm’s solution partnership with Atlassian.
Karsten Besserdich is Managing Partner of Besserdich und Redmann GmbH and Head of ORACLE Consulting and Cloud Technologies. He is a multi-certified ORACLE specialist with a focus on database architectures, database development, database administration, performance optimization and data warehousing. In addition, he has been working intensively on the agile framework SCRUM since 2013. Karsten Besserdich has been working in these areas for more than 16 years, preferably in medium and large customer projects.
Image source: Fotolia / alotofpeople