Meaningful Borders for Self-Responsible Teams

The vision of a team which can work self-determined and self-responsible is an ideal for me, which I try to reach every day. Even though all of us have probably quite different understandings, what it means to be a self-responsible team, the vision is desirable for many of us. The vision might be a team which can decide everything: from the invest in a new coffee machine up to hiring a new colleague. In praxis such a way is not every time easy: a couple of years ago I meat colleagues, to whom “self-responsible team” was more a curse than an ideal. They were made responsible for almost everything. Even though a root cause analysis might have shown that the causes have to be looked for somewhere else, the team was accounted for. “Finger Pointing” to whole team cannot be the consequence surely.

We shouldn’t forget that teams don’t exist in some kind of vacuum even though we are excited about self-responsibility and self-determination. Teams exist in certain management contexts. It might sound trivial, but teams are humans. Only because some kind of ne’er-do-well is part of a self-responsible team, he won’t take over additionally tasks voluntarily. I don’t want discuss tailoring of teams in regard of personalities. That is more to psychologists. But I can describe, what we can do technically and also methodologically, to make the live easier und in that way to do a step in the direction of self-responsibility. There is a lot of literature, which I like to recommend to everyone who want to dive deeper into the topic. I really appreciate Boris Gloger and „Self-organization needs leading” [1]. It is a really well written book, which goes beyond euphoria and contains really good procedures and guidance for self-thinking. And of course, the classic book about self-organization and empowerment by Jurgen Appelo [2].

Decisions of Teams

Which decisions can a team take?

• It should be able, to select the technology which which it want to work.
• It should be able to release new software at every point in time, which each team selects independently, without disturbing other teams.
• Implementation and design decisions lay in the hand of the teams.

Imagine, you want to develop a system, where messages of an ERP system are received via a backend interface. And afterwards they are shown as documents to the user. We would the teams tailor: Backend interface, Document creation, and User interface. Now the teams should select the technology, they want to work with.

• The backend team selects JEE as technology, because they do it a long time and know it well. And the messages from the customer are sent as SOAP anyhow.
• The document team selects a document-oriented database and requires, that all messages are sent as JSON directly to the database. That is refused by the backend team, because they don’t have any experience with such technologies.
• The user interface people want to use Angular, but they don’t get the document people creating the according interface. They create some kind of clickable mockups, which are not usable with the available data.

 

Such or comparable situation was experienced by many of us. Fast some kind of “Finger Pointing” appears and discussion like “They don’t deliver what we need”, “We can’t continue, before they don’t finish.”, a.s.o. The management reaction is as clear – they go deeper into the teams, they define the interfaces and plan everything on hourly base, what everyone needs to do. A daily escalation meeting tracks the according decisions. At last at a planned GoLive, the entire house of cards collapses.

Back to our example: I deliberately hold it so general. When we are more concrete, the world looks completely different.

1. A backend system receives delivery notes via a legacy SOAP interface.
2. Invoice-relevant information is extracted from the delivery notes and is provided via REST interface as JSON.
3. The invoice-relevant information are received by a service and based on that an invoice as PDF is created.
4. The invoice is displayed in the browser via PDF plug-in and the user can sign the invoice.
5. After signature, the invoice is sent via e-mail to the invoice receiver.

With such information the world looks totally different. We can tailor our teams and our services along the business process. The borders of concern and with the responsibility of the teams can defined in everyone’s agreement.

The Base for Self-responsible Teams

Some might be wondering about Borders of Concerns. I mean here “Border of Concerns” out of Domain-Driven-Design or short DDD [3]. Probable one or the other scrum master, project manager, etc. might ask: “What should I do with all those technical details? They don’t interest me!” But as we will see, a clean, technical design base is the base for self-responsible teams, who can deploy independently from each other and who can develop independently.

How look like our domains:

1. Message receiving
2. Extraction of invoice information
3. Invoice creation
4. Presentation of invoice and signature

So, we have not only three, we have four teams. That might be too much in a first step, but we handle responsibilities and how those are tailored. And for that we need a clear detachment between different steps.

The first team receives the SOAP messages again and provides them for extraction. The provisioning is done per JSON and REST, because both teams could agree on that. At the beginning, the second team offers its expertise. The second team extracts the invoice information out of the delivery notes. Because the second team want to work in parallel to the first team, it can’t work with real business dates. But they can work with interface mockups, which are offered by the first team. In such a way, the teams kill two birds with one stone. They can transfer the knowledge to the first team and get such “stubs” with which they can work.

Anyhow, they have to agree on to a contract, how the necessary data are provided. Such a contract is a technical interface description – as e.g. Swagger. The second team writes unit tests against the interface, to ensure that the interface works as expected (Contract Test). The first team has to include those unit tests in their CD/CI pipeline, so that they are sure, not to influence the second team at a deployment negatively. A deployment is broken in case such a test is not successful, as defined in a common Definition of Done.

The invoice information is received via interface by the third team. They are free in their technology selection, because they communicate “only” via one interface with the second team. Again, here is the same valid, the teams have to agree on a contract, which ensures that deployments don’t break interfaces. The contract is not only valid to the second team, a comparable contract is available to the fourth team as well.

The fourth team shows the invoice – completely independently of the other teams. They can integrate a signature environment of their choice, because they don’t depend on database accesses to mother teams.

Database accesses – that we don’t discuss yet, right? Right, I set implicit assumptions, which I didn’t explain. Yes, we need microservices, to get really self-responsible teams. Microservices mean under other points that each service and with that each service has its own database. The communication is exclusively done via interfaces. By this convention we reduce dependencies dramatically and allow, that the teams are really able to work independently from each other.

Requirements to Self-Responsible Teams

Let us go back to the requirements of the beginning:

• It should be able, to select the technology with which they want to work with.

The teams can select the technology, with which they want to work with. Of course, they are not completely free in their selection (e.g. because a contract with a cloud provider already exists). But they can select freer than before.

• It should be able, at each moment, which is selected by the team, to deploy new software without disturbing other teams.

This requirement is ensured by the contract tests. That includes that the Definition of Done contains that contract tests are integrated in the CD/CI pipeline and a unsuccessful test causes a deployment abortion. Especially the second part can cause great discussions, when the deployment contains important new functions. Because of that the entire environment has to ensure that contract tests can be done early, so that one can react as early as possible to bugs. It is not necessary that those tests are done in an environment, where all services are available (how it would be in a pre-production stage). Both services can be tested exclusively, without influence other services negatively.

• Implementation and design decisions lay in the hand of the teams

We have seen, that the presentation and signature function is completely independent from the extraction of invoice data. This would be not successful in the first approach, because we had at least data dependencies in the database.

In this way we can make it possible, that teams can work independently and self-responsible. Of course, the world is not beautiful every time, but with the discussed approach it becomes more beautiful :-).
[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