Ep14: Assigning teams to features or services
In this episode Swathi Poddar and I are talking about a topic very close to our heart: how do we best assign work to our teams? Do we have clear ownership of features or services, and if so, what do we do with the ‘shared’ service we’ll invariably encounter? Are such services commonly owned, can anyone mess with them, or are we keeping them under tight guard, and we ask: ‘Who owns the frontend?’ Expect an interesting, possibly controversial discussion…
Swathi Poddar is a Business Analyst, Product Owner and Software Consultant. She has worked and studied in the UK, US and currently works out of Pune and Bangalore, India. She can be ‘found’ and contacted here.
Here is our discussion, but in this case it might be worth reading the full blog post in addition:
First, that cat picture
(Don’t ask, I can’t believe I just posted that…)
Assigning teams in a domain with no shared services
Assume you have a domain like the one in graph1, where you have a number of features or services that you need to deliver and you want to scale up, i.e. work with more than a single team. How would you assign your talent to the various work areas?
First off, let’s consider what are principles are:
- Teams should be autonomous with limited dependencies on knowledge, the ability to make a change or deploy on others.
This allows us to work lean, agile and fast.
- Minimal communication boundaries
With the above in mind, we also want minimal communication and decision making barriers. This means keeping local what is detailed, frequently required and low-impact in the grand picture, and only allow making global whas has global impact and repercussions.
- Deliver value
We want to deliver value and use the most efficient and effective ways of working to do that. This means that we want teams to own end to end functionality as much as possible.
Of course, we can already see that there are trade offs to be made here, but generally speaking it shouldn’t be too hard to agree with these statements.
This consequently means that in a domain like the one above, we would assign teams to features or services.
And we believe that the frontend, generally speaking should be owned and built jointly. We’ll see below how we can also understand the frontend as a shared element, and how we can manage that, in fact, turn it to our advantage. What we strongly feel we should NOT have a frontend team. This would break our principles above and leads to awkward bottlenecks. Trust us, we have seen it happen.
We should also say, that the Backend For Frontend pattern (BFF) Sam Newman talks about is an abstraction layer between the backend services and the frontend. While this can solve some issues, especially where you cannot affect the backend service, it is an additional logic layer that creates overheads. So we feel we should apply it if needed, not by default.
The dreaded shared service
But what if, as in our chart 2, we have a shared service, such as in this example a service providing preferences? We are specifically concerned about those services that we will frequently need to change as we change other services. Often services that expose ‘configurations’ fall under this.
Here are the rules we follow:
- Minimise the number of shared services, define for loosely coupled services.
In many cases you may be able to split your domain differently supporting this, but be sure that you are still true to a good representation of your domain from DDD perspective.
- Incept the shared service with a dedicated team. (In some cases this can be the team that needs it first, but that’s not necessarily ideal as it concentrates knowledge)
- Over time, as the core of the shared service becomes more stable, disband this team, and move towards a shared ownership model where everyone can make a change but is also responsible for the overall quality of the service.
- Consider assigning a Guardian of Best Practice and Knowledge to shared services (in fact every service, and possibly the Frontend too). These individuals would be first point of contact to provide information, the ultimate decision makers in terms of conflicting requirements and they might approve PRs that other teams raise against the shared service.
There you go, it’s not that hard 🙂
Our biggest learning, maybe, and the most obvious: do not allow silos to build up, and allow for time to periodically restructure architecture and team shape for most optimal collaboration. Do not compromise on these things in the heat of the fight.
Our guest in this episode is Swathi Poddar, Business Analyst, Product Owner and Software Consultant. She can be ‘found’ and contacted here.
Stuff to read
Books we touch on in this episode, and which are highly recommended to read are