Reasonable limits for self-responsible teams

For me, the claim of a team that can work self-determinedly and responsibly is an ideal that I try to achieve every day. Although we all probably have a different understanding of what a responsible team is, the vision of a team is desirable for many people, in which everything is decided from the purchase of a new coffee machine to new hires within the team. In practice, this is not always easy: a few years ago I met colleagues who used “the team is responsible” more as an insult than a claim. They were held responsible for every failure, for everything that went wrong. Even if a root cause analysis showed that the reasons were to be found elsewhere, the team was still pointed to. “Finger pointing” on whole teams can certainly not be the consequence.

Despite all the euphoria about self-responsibility and self-determination, we must not forget that teams do not exist in empty spaces, but are integrated into management contexts. And it may sound trivial, teams are people. Just because a useless loafer is suddenly put into a self-responsible team does not make him the darling of all and voluntarily takes on additional tasks. In this article I don’t want to discuss the cutting of teams with regard to different personalities; that’s more a matter for psychologists. But I can describe what we can do technically and methodically to make the life of the teams a little easier and thus also a step towards self-responsibility. There is a lot of literature on this topic that I recommend to anyone who wants to get to grips with it: I value Boris Gloger very much and “Self-organisation needs leadership”¹ is a well-written book that goes beyond euphoria and contains real instructions for action and thinking for yourself. And of course the classic of self-organisation and empowerment by Jurgen Appelo.²

Decisions by teams

What decisions can such a team make at all?

• It should be able to choose the technology it wants to work with.
• It should be able to put new software into production at any time that the team independently chooses, without disrupting other teams.
• Implementation and design decisions are in the hands of the team.

Imagine that we want to develop a system where messages from an ERP system are received via a backend interface and then displayed as documents to the user. We would cut teams: backend interface, document generation and user interface. Now these teams should choose the technology they want to use to implement the system.

• The backend team chooses JEE as the technology because they have been doing this for a long time. And the messages from the customer are sent as SOAP anyway.
• The document team chooses a document-oriented database and requires all messages to be sent as JSON directly to the database. However, this is rejected by the backend people, since they have no experience with such technologies.
• The user interface people want to use Angular, but the document people don’t get to provide the necessary interface. They create clickable mockups that cannot be implemented with the available data.

Teamwork is not always easy.

Many of us have certainly experienced such or comparable situations before. It quickly leads to “finger pointing” and discussions: “They don’t give us what we need”, “We can’t go on until they’re finished”, etc. The management reaction is also almost clear – they intervene more deeply in the teams, define the interfaces and plan to hours exactly who has to deliver what and when. A daily escalation meeting follows these definitions. At the latest, the whole house of cards collapses during a planned go-live. Back to our example. I deliberately kept it very general. If we become more concrete, the world will look quite different:

1. A backend system accepts delivery notes via a legacy SOAP interface.
2. Invoice-relevant information is extracted from the delivery notes and then made available using a REST interface via JSON.
3. The invoice-relevant data is then received by a service and an invoice is generated as a PDF.
4. The invoice is displayed to the user in the browser via a PDF plug-in and the user can sign the invoice.
5. After the signature, the invoice is sent to the recipient by e-mail.

With this information, the world looks quite different. We can cut our teams and services along the business process. The limits of concern and thus the responsibilities of the team can be determined well and by mutual agreement.

The foundation for responsible teams

One might wonder about the terminology ” Limits of Concerns “. This refers to “Border of Concerns” from the domain-driven design or DDD³ for short. Maybe one or the other project manager, Scrum Master etc. asks himself: “What should I do with these technical details? They don’t interest me! But as we will see, a clean, technical design basis is to cut the foundation of responsible teams. With the clean technical design we achieve that the teams can deploy and develop independently of each other. What do our domains look like now?

1. Message Reception
2. Extraction of invoice information
3. Creation of the invoice
4. Display of invoice and signature

So we no longer have three teams, but four. That may look too complicated in the first step, but this is about responsibilities and how they are cut and we need a clear separation between different steps.

The first team receives the SOAP messages and makes them available for extraction. The delivery is done by JSON and REST as both teams can agree on it. At the beginning, the second team provides its expertise in this area.

The second team extracts the relevant invoice information from the delivery notes. Since the second team wants to develop as parallel as possible to the first team, it has to do without real customer data at the beginning, but they can fall back on interface mockups of the first team. This is provided by the first team together with the second team. The teams thus kill two birds with one stone: they can transfer the knowledge to the first team and get so-called “stubs” with which they can develop.

In any case, both teams have to agree on a contract to provide the necessary data. This contract is a technical interface definition – such as Swagger. The second team then writes unit tests against the interface to make sure that the interface always works the way they expect it to (contract test). However, the first team must integrate these tests into its deployment process so that they are sure not to negatively influence the second team during a deployment. In the common Definition of Done it is defined that an unsuccessful test leads to the termination of the deployment.

The third team receives the invoice information via an interface and generates an invoice from it. They are free in their choice of technology, as they “only” communicate with the second team via an interface. Again, the contract for the interface must be tested for deployments.  Of course, the contract then applies not only to the second team, but also to the fourth team, which must display the invoice.

The fourth team in turn displays the invoice – completely independently of the other teams. They can also integrate a signature environment of their choice, as they are not dependent on information or database access in the other teams.

Database access – but we haven’t talked about that yet? That’s right! I made implicit assumptions that I didn’t explain. Yes, we need microservices in order to enable truly self-responsible teams – and that means, among other things, that each service and therefore each team is responsible for its own database or databases. The communication takes place exclusively via interfaces and an external service must not access anything in another database. Through these conventions, we dramatically reduce mutual dependencies and make it possible for teams to really work independently.

Together for success.

Requirements for self-responsible teams

Let’s take another look at the initial requirements for a responsible team:

• They should be able to choose the technology they want to work with.
  The teams can choose the technology they want to work with. Of course, they are not completely free to choose (because, for example, a contract with a cloud provider already exists). But they can choose more freely than before.
• It should be able to put new software into production at any time the team chooses independently, without disturbing other teams.
  This claim is ensured by the contract tests on the interfaces. This includes that the Definition of Done states that the tests are integrated into the deployment pipeline and that a unsuccessful test also leads to a termination of the deployment. Especially the second part can lead to big discussions, particularly if the deployments contain important new features. The overall landscape must therefore enable early testing of the interfaces so that bugs can be responded to in good time. Such tests do not have to take place in a landscape in which all services are represented (such as perhaps a pre-production staging), but both services can be tested mutually without other services being negatively influenced by the tests.
• Implementation and design decisions are in the hands of the team.
  We have seen that the display and signing function is completely independent of the extraction of invoice data. We would not have been able to do this in the first draft because we would have at least dependencies in the data representation in the database.

In this way we can enable teams to work independently of each other. Of course, the world is not always beautiful, but the world becomes more beautiful through the presented approach. 🙂

Notes:

[1] Gloger, B.: Selbstorganisation braucht Führung: Die einfachen Geheimnisse des agilen Managements, Carl Hanser Verlag GmbH & Co. KG, 2. Auflage, 2017, ISBN-10: 3446454357
[2] Appelo, J.: Management 3.0: Leading Agile Developers, Developing Agile Leaders, Addison-Wesley Professional, 2010, ISBN-10: 9780321712479
[3] Evans, E.: Domain-Driven Design: Tackling Complexity in the Heart of Software, Pearson Professional, 1. Auflage, 2003, ISBN-10: 0321125215

Dr. Annegret Junker has published more articles in our t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.