Assigning teams to features or services
A post and podcast on how to assign teams across your domain
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?’
This post is a summary of a podcast my colleague Swathi Poddar and I recently recorded on the topic of how to split / assign teams. While I certainly think you should listen to the Podcast (and be it alone to hear us talk cat pictures ), this post is a good summary of our thoughts.
Podcast | Beautiful Abstraction
Digital consulting We help design and deliver better digital products and services, help work in better ways, and…beautifulabstraction.com
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 here.
Assigning teams in a domain with no shared services
Assume you have a domain like the one below, 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 ‘simple’ domain like the 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.
Teams are assigned to features or services which they then own end 2 end. The frontend is consequently jointly owned.
What we strongly believe is that 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.
On a side note: 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 example 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.
We apply the following rules:
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 joint 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.
Teams own services and deliver end 2 end. Shared services are incepted by a single team, then handed over in joint ownership. Service guardians are the fountain of knowledge and guardians of quality.
In a future post / podcast we will be building on this discussion:
Frontend vs Backend User Stories
Should we or Shouldn't we allow frontend (FE) and backend (BE) specific user stories? Surely, stories should describe…thedigitalbusinessanalyst.co.uk
Related reading
Books we touch on in this episode, and which are highly recommended to read are