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:

1. Ensure system understanding.
2. Ensure and optimise interactions.
3. 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):

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.

What does t2informatik actually do? One click and you'll know.