Setting up service-oriented teams in a microservice environment

What we do at Humanitec

Even in 2019, the development of customized enterprise applications is a highly individual process. In most cases, either the IT department itself or — even more common especially in Germany — an external software development agency is building a one-off solution to satisfy individual business requirements. This process is vastly redundant and both, costly and resource-intensive. As corporates step into the next level of digitization, demand is growing by 42% CAGR¹ and we are at least 500k short in engineers by 2020 on a global scale². After years of experience as a consultant at McKinsey and as a former Senior Vice President at XING, I am happy to fully dive into this opportunity as CPO of Humanitec. Our vision can be summarized by the 5–5–5 foresight: In 5 years, 5 computer science students will be able to build a fully fledged ERP enterprise-grade in 5 weeks. Exactly, how the business wants and needs it.

Wondering how are we going to achieve this? Our approach is a combination of a revolutionary new IP model that allows developers to reuse and monetize microservices on our marketplace, Core-APIs that auto-detect and fuse these services, and deployment automation to mount them to an infrastructure. From thought to app in seconds.

Our deployment platform Walhall is using a scalable open-source microservice architecture and state-of-the-art automated deployment processes to make customized enterprise software development much faster, more reliable, and easier to maintain while keeping the intellectual property where it should be, with the developer and the customer.

How product management evolved at Humanitec

Humanitec started off in a camp in Afghanistan, where our CTO Greg Lind hacked together a project management software for NGOs, called TolaData. TolaData’s open source version is rolled out in 35+ countries and has a paid solution on our platform. This microservice-based software helps NGOs to keep track of their initiatives and — even more important — the results for each of them. We built this software using a standard approach to modern software development: a dedicated developer team and 2-week sprints in a standard SCRUM approach.

From this 1st software product, we expanded into a second use case, field-force management software for a German corporation. While the two use cases seem to be quite different, they are using a very similar set of microservices in the backend. Like many other software companies, we started to reuse our existing microservices from the project management use case and modified them for the CRM use case. We ended up with two teams both working in 2-week sprints. Right from the beginning, we used the same core service in our backend setup and established frequent knowledge exchange sessions. But still, code reuse was nowhere close to where it could be and we struggled to align the two teams on a day-to-day basis.

The shared set of backend services and the inefficiencies in reusing our own microservices were the starting point to invest into a platform that would significantly increase reuse and could help to significantly speed up development time by providing automated deployment and a central approach to code management for individual microservices. By now, we are close to providing this platform, namely Walhall, to other software development teams in a closed beta.

The challenge

We truly believe in the strategy to “eat your own dog food”, i.e., we are in the process of moving our existing software products to Walhall and the respective standardized microservices. By doing so we needed to fundamentally re-think our approach to product development and team setup. We used to work in a very common setup, with dedicated teams for each of our products (i.e., project management, field-force management, and the platform). Each team had its own set of meetings and tools, from the backlog all the way to sprint reviews and post-mortems. I quickly realized that this approach has a number of significant drawbacks:

• Alignment issues — aligning three teams working on a very similar set of microservices is a real challenge. Over and over again, individual developers were not well informed about what the other teams were doing and we developed very similar functionality in different places (mostly driven by high pressure to implement new features for our direct customers). Also, people started to feel isolated working in any of the individual teams. Sure, there are methods to tackle this challenge (e.g., SCRUM of SCRUMs) but they tend to further increase complexity and are not designed for relatively small organizations like ours (currently, we are about 50 developers in two offices).
• Individual experts — with resources spread across three individual teams, we started to see a growing number of individual experts for certain topics: individual backend developers with deep expertise for certain microservices, individual frontend developers with deep expertise on specific architectural questions, individual backend developers with deep expertise on the deployment process, etc. This is quite dangerous especially in a small company by introducing a significant risk in the case of any of these individual experts leaving the team and by leading to mediocre solutions due to the lack of ideas/concepts being discussed/sparred.
• Narrow product solutions — this is a typical problem in individual software development: the tendency to develop solutions that fit the needs of just one customer. We are facing the same issue and it is a real problem for us since we want to develop a platform that can support a wide range of use cases and must not think too narrow.
• Lack of overview — from a product management point of view, another significant drawback became quickly visible: the difficulty for any individual product manager to get a quick overview of topics in development/research. We organized each team in a separate JIRA project with an individual backlog and individual sprints. Being aware of each topic across all three projects was almost impossible. Especially, with the many other day-to-day topics in each individual team.

Humanitec’s solution

There are a lot of interesting and partly well-tested concepts out there how to set up and manage a service-oriented development organization. The most interesting are matrix organizations and setups with tribes and squads. Unfortunately, we are lacking two important elements to easily implement solutions like that: (a) scale and (b) a large enough number of experienced senior tech leads. It will take us a while to develop these two elements but I am sure we will get there.

Meanwhile, we are in the process of implementing our own solution to a service-oriented approach that we believe will overcome the challenges mentioned earlier:

• Stable frontend teams for individual UIs — we will continue to have dedicated stable frontend teams to develop individual UIs. Those UIs are composed of a set of frontend microservices and some customization based on the specific needs of the customer.
• Stable team for core modules — we will continue to have a dedicated stable team to develop the core elements of our platform, namely the core backend module (BiFrost) and the core frontend module (Midgard). This team also defines a lot of the standards that we are using throughout the platform. It combines frontend and backend engineers with QA engineers and a technical writer.
• Virtual service teams — we are introducing virtual service teams. These teams are composed out of one frontend engineer from one of the frontend teams (and a backup), one frontend engineer from the team for core modules, one backend engineer (and a backup), one QA engineer, and a product manager. Each of these teams is responsible for one logic module.

Especially the virtual service teams are very important for us. Combining engineers from the team developing the core modules with engineers that work on customer-specific UIs and making these teams responsible for generic microservices offers a lot of advantages: (1) it brings the frontend engineers working for any individual UI much closer to the platform, (2) it ensures that the product manager and the teams need to consider much broader use cases when developing a new feature, and (3) it significantly increases the re-use of designs across different teams.

Furthermore, we implemented some other changes to become more agile (e.g., one-week sprints) and allow for more focus on the most important topics. We try to keep complexity to a minimum. 1st results from this new structure are already looking very promising and we are eager to learn more over the next weeks and months to come. Please do not hesitate to reach out to me (christoph.richter@humanitec.com) in case of any questions or recommendations and stay tuned.

1) https://blog.7mileadvisors.com/dissecting-the-custom-software-market-161b4208c1ec and https://www2.deloitte.com/content/dam/insights/us/articles/3767_Signals-for-Strategists_Feb2017/DUP_Software-development-beyond-IT.pdf
2) https://www2.deloitte.com/content/dam/insights/us/articles/3767_Signals-for-Strategists_Feb2017/DUP_Software-development-beyond-IT.pdf