The systematic organisation of software development
Many companies take a less structured and systematic approach to designing efficient and adaptable software development organisations. For example, they focus on working on the agile mindset or use standard solutions without taking specific circumstances into account and only realise late on that they are failing to achieve their goals.
In this article, I would like to show you how to do things better.
I have been involved in software development and the optimisation of software development organisations for 30 years. As an engineer with heart and soul and as a systemic coach, I know both sides:
- The engineering and therefore rather structured approach and
- the human-centred, systemic approach or, as we say in Switzerland, “Gspuersch mi, Fuehlsch mi” – freely translated as “Feel me, get me”.
For many engineers and technicians, the human-centred, systemic approach to designing software development organisations is less visible and tangible and therefore more difficult to access. In my experience, however, a software development organisation can be “engineered” in a similar way to structured software development. This makes it more objective and comprehensible, which is particularly helpful for people with a technical background.
A software development organisation is a complex system
The following figure shows a software development organisation in abstract form:
Figure 1: The elements of a software development organisation
The software development team takes centre stage. Its task is to develop a software system or a subsystem. It usually interacts with other departments, external partners or even stakeholders and management. There are dependencies and it is not trivial to organise these and ensure smooth cooperation.
We are talking about a complex system!
There are basically three key aspects to mastering a complex system:
- Ensure system understanding.
- Ensure and optimise interactions.
- Pay attention to self-management and control in a goal-orientated manner.
Figure 2: The three essential aspects of mastering a complex system
The visualisation shows a dichotomy: on the one hand, the systemic aspect, which focuses on people (self-management) and, on the other hand, the interactions, which focus on elements, structures, processes, connections and interfaces.
The aspect of system understanding is again divided into two parts. Understanding the scope, elements, structures and interfaces is part of a structured and systematic approach. Making the relevant energies and fields visible and visualising them through a system constellation is part of the systemic world.
In the context of agile transformations, I often observe situations in which agile processes, methods or frameworks such as Scrum, Scaled Agile or LeSS are introduced and work is started on the agile mindset with those involved – but often with little success. It is not enough to simply provide coaching, work on the agile mindset and not adapt the structures and interfaces. However, it is also not enough to only look at and optimise structures, methods, interfaces and communication channels and neglect the systemic, i.e. people-centred aspects.
The structured design of a software development organisation
Based on a structured and systematic approach to building software or creating a software architecture, how can a software development organisation also be set up in a structured and systematic way?
Imagine the following task: Develop software for adding two numbers.
As the following examples show, this task can be solved using various approaches:
Figure 3: Various software solutions for adding two numbers
Which is the best solution?
The question can hardly be answered by consensus, because although the solutions have completely different characteristics, they all fulfil the task at hand. This is a typical mistake that is often made when creating software: It is not enough to just define functional requirements. Framework conditions and quality requirements must also be determined, as this is the only way to ensure that software can be built as expected.
Without appropriate input, various solutions can be discussed at length, but constructive agreement is practically impossible. Without defined framework conditions and explicit quality requirements, it is impossible to decide whether, for example, the dialogue-based application or the variant with a single input field (as with Google) is the better solution.
The following visualisation illustrates this issue:
Figure 4: Requirement space and solution space
The functional requirements create a requirements space. The blue, red and green solutions all fulfil these requirements. However, they fulfil them in completely different ways. The differences lie in the fulfilment of quality requirements such as maintainability or performance. In order to develop a system, these properties must be specified. In addition, there are often framework conditions on the solution side that must also be met. This can be, for example, the technology to be used.
And what does all this have to do with organisational development?
When setting up an organisation, you should proceed in a similar way and take the same inputs into account. Here, too, there are functional requirements, e.g. the tasks and activities of individuals or teams. But here too, these functional requirements are not enough. It is usually not enough for people and teams to complete their tasks. Qualitative requirements such as performance, i.e. efficiency and effectiveness, or scalability are often important in order to build an optimal organisation. And similar to the actual development of software, there are also framework conditions for the development of a software organisation.
Structured and systematic creation of an architecture
Based on the relevant inputs, so-called architectural elements are created that fulfil the requirements in the best possible way. Creativity or experience is required here in order to find various possible solutions.
Architectural elements are generic solution modules. They structure the solution – in the case of software, these can be various subsystems, in the case of an organisation, for example, teams, departments or people. The properties of these elements must be explicitly defined. As soon as several elements are present, the dependencies, i.e. the interfaces and communication protocols (technical protocols for software elements, more communicative protocols for organisational elements) must also be defined. These are referred to as design decisions.
Figure 5: Necessary design decisions for two architectural elements (for a software architecture)
The following table lists the necessary design decisions for a software architecture and their analogies for an organisational architecture:
Table 1: Analogies of the necessary design decisions of a software architecture and an organisational structure
A real-life example could look like this:
Figure 6: Real software development organisation with (architectural) elements and their interfaces
With such a view, the aspect of system understanding, as shown in Figure 2, is already well fulfilled. Based on such a diagram, the design decisions from Table 1 should now be gone through and clarified. Once this has been done, the suitability of the solution can be assessed. To do this, the fulfilment of the relevant inputs is checked.
Such a procedure ensures that organisational development is comprehensible. It clearly shows why which changes have been made and ensures that the requirements can actually be implemented. Ideally, this clarity should exist before all changes are made, teams are formed and employees are transferred to teams. Just as a software system should be structured: performance, maintainability or scalability should be taken into account when designing the software and not only once the software has been fully implemented.
Conclusion
A software development organisation is a complex system. Every change or optimisation of the organisation also requires a systemic approach. However, it is not enough to consider only people-centred aspects; structures, processes, methods and tools must also be approached in a structured and systematic way.
The first step is to ensure a common understanding of the system. This can be done efficiently with simple diagrams that can be harmonised with those involved. Building on this, the relevant inputs must be recorded in a structured manner: In addition to the tasks and functions that the organisation and each element has to fulfil, qualitative aspects and framework conditions must also be defined and recorded transparently. Only then, in a second step, can the tasks, responsibilities and interfaces of the organisation be optimised in a targeted manner and reviewed at the planning stage.
The subsequent change process will be easier if this procedure is comprehensible for everyone involved!
Extra bonus
Here you will find 3 additional questions about software development organisations answered by Matthias Kuenzi (please press the plus buttons):
How can a software development organisation recognise that it has developed a good understanding of the system?
Matthias Kuenzi: This can be recognised by clear language. In other words, relevant elements and connections within the organisation are named clearly and unambiguously. It is clear what the elements mean, where there are interfaces and how they are organised. Specifically, these are elements such as teams, people or processes, process steps and other relevant artefacts. There should also be clarity about aids or tools and the corresponding areas of application. All in all, this leads to greater understanding and efficient and effective collaboration for everyone involved.
What additional error in thinking occurs when developing a software development organisation?
Another misconception is that organisational development can be redesigned and thus optimised in a single step. The procedure described above can be used to derive comprehensible options for action. However, implementation should then be carried out carefully and, above all, iteratively and incrementally. In other words, only a few changes at a time in order to be able to assess their effect on the organisation. This is also an engineering approach:
- Ensure measurability.
- Implement the change.
- Assess the impact based on the measurement.
- Derive findings for the next steps.
Self-management addresses many aspects that are individual to each person. Should these individual characteristics be addressed at team level?
- Which individual aspects are at all relevant to the team level, i.e. the collaboration – or are personal and not relevant?
- What should be addressed at team level?
There is a simple answer to the first question: from a systemic perspective, every aspect of every individual in the system is relevant to the system. To put it in more detail: the more central the role in the team is, the more relevant and influential the characteristics of the corresponding individual are for the team. This may be plausible and understandable for a manager – but in practice, for example, it is often underestimated that long-standing, respected employees can have a very large influence on a system (team), even if they are hierarchically “normal” team members. If this is not taken into account, the resistance or scepticism of such a person can cause entire change projects to fail.
In my opinion, whether an individual aspect should be addressed at team level, i.e. addressed openly, depends very much on the maturity of the team. Ideally, a “disruptive” issue is addressed by someone from the team itself and then discussed within the team. Initiated by the manager, it would be a topic for an appraisal interview.
Notes:
With increasing diversity, dynamism and networking, the complexity of projects, especially projects involving software, continues to grow. Employees with very different backgrounds have to work together effectively in order to achieve the project goals. It is becoming increasingly difficult to maintain an overview. Matthias Künzi will be happy to support you in bringing structure, systematics and methodology to your projects. Simply contact him if you are interested. And if you are interested in smooth software development and well-designed software, then it is also worth taking a look at the German language visuellklar Blog.
If you like the article or would like to discuss it, please feel free to share it in your network.
Matthias Kuenzi
Matthias Kuenzi (Dipl. El. Ing. HTL, Dipl. Software Ing. FH, Systemic Coach) has gained a great deal of experience over the last 30 years as a software developer, software and system architect and manager in the development and organisation of software systems in the embedded and commercial environment. With his company “visuellklar”, he supports software companies in optimising their organisation and product development. His goal is to master complexity and systematically develop companies into a smooth software development machinery.