Domain Driven Design and Scrum

In this article,I will try to combine two different concepts that actually are closely related with each other.One is Domain Driven Design(DDD) that is about translating customer requests into technical design.The other one is Scrum that is project management strategy as most of you know.

I think these two seperate concepts are too much required if your teams size exceed 20 people.Because if you reach to 20 people,performing Scrum may be problematic.Because maximum advised people size for one Scrum team is between 5 and 9.So again if we use Scrum despite of this,it seems it will be more reasonable to use Scrum of Scrums approach.

But if use Scrum of Scrums approach,we will face with another concern that is related seperation of teams.

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

— Conway law

According to Conway law,actually our projects’ architectures are based on our organizational structure.For instance we can look at opensource projects like Postgresql.You will see a lot of extensions developed by different teams and indivudials spanning all over the world.Because Postgreql is for opensource comunity so its core developers designed its architecture in line with this huge comunity.Contrary to this,If look at small companies developing Erp software,you will see monolith of which the seperation into modules is hard.Because human resource is limited to develop across the different teams.

Without distracting your attention ,I want to mention splitting with preferences.We can use domain driven design by seperating domain into subdomains that will be maintained by seperated team.Also as per our team size we may prefer not to split teams as well as our project architecture.

Let’s make it clear.If we handle booking project in the below picture that you can think this project as a kind of footbal match ticketing system or theatre event.

Booking System

It has got several user interfaces that consist of web,mobile and backoffice.Now lets look at human resource in a team in the below picture

Booking System Team

As you see totally,There are 28 people from Project manger to Devops that spanning on a lot of categories.

If we design our project structure based on the above team,we have hardships to move in modular software development that can be modular monolith or microservice.Because there are a lot of dependencies.Backend developer depends on frontend developer and vice versa.Developers depend on tester and analyst and vice versa.All groups have dependencies on eachother.

So in this organization,to perform scrum of scrums is very risky.Because it is reasonable to have cross functional teams if one team size exceed 9 people and here is 28 people.

Ok now second question comes to our mind.How will we split teams?Is it as per technological aspects like frontend developer,backend developer,analyst or as per domain driven design using subdomains?

If we split our team as per technological aspect,It will be like the below pictures.

Backend Team
User interface team
Quality Assurance Team
Devops Team

As you see in the above 4 images,we splitted one team as 4 teams having one team leader in each team as per technological functions.Maybe now we have got small teams that will be easily managable.But again we have dependencies on a team basis.Backend team depend frontend team and vice versa as before mentioned in the above.

Implementing scrum of scrums still is problematic in this design.Because teams doesn’t have cross functional.

“Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.”

— Scrum guidelines

I think in Scrum cross functional team is misunderstood by some people.They may think that one member of team is capable of frontend development,backend development,analyst.It may be reasonable in small enterprise to some extent due to limited human resource.Actually meaning Scrum try to tell is that one team must be capable of to produce some concrete product that a customer can understand.A team must be able to produce sub products belonged to one domain.A team must be able to bring given tasks to done.

But in technological seperation,generally no team can bring a task to done.Because even if backend developer finished his/her task,he/she will wait for frontend developer in another team.Scrum meetings will be meaningless.Because what did you do yesterday? what will you do today? Developer will say “lastly my task is in tester team(QA).” But we need the other people that has got this information.So insisting on Scrum is meaningless due to cross team dependencies.Maybe Scrumban method can be choosen.This may be another topic for the sake of the brevity of this article.

So Domain Driven Desing may be solution.For example firstly lets seperate our domain.Our domain is booking.So it will be core domain.Also integrations may be subdomains.I mean booking domain has got multiple sub domains that consist of core domain(booking this is also one subdomain),integration subdomain.Lets have a look on new design as per DDD.

Booking Team
Integration Team

Booking Core Domain(Main Subdomain)Integrations Subdomain.As you see for now,we have cross functional teams from backend to devops.If we have a task like crm integration.Integration team can finish the required work without dependency or with minimal dependency on booking team.Seperation of concerns and minimizing team size both were being provided.
I also want to explain team size concern.

“adding manpower to a late software project makes it later”
“The Bermuda plan, where most developers on a project are removed (“sent to Bermuda”) and the remaining are left to complete the software, has been suggested as a way of circumventing Brooks’s law”
— Brooks’s law

As per my understanding of Brooks,we must limit our team size to maximize throughput.Because large team requires more comunication channel.For example he points in Bermuda Plan,let alone expanding the team,he mention to minimize the team because of communication channel and due to ease of collabration.Another overlapping law with Brooks as per team size is Price’s law in the below

“Price’s law says that 50% of the work is done by the square root of the total number of people who participate in the work.”
— Price’s Law

If we have 9 people on our team,square root of 9 is 3 so 3 people will do 50% of the work other 6 people will do the rest %50 work.This is logical when we think human nature.Because the collabaration will be hard when team exceed certain amount and some people prefer to be in small team.

So when we merge Scrum guidelines(from 5 to 9 people),Brook’s law(Bermuda plan) and Price’s Law(square root of team),5 people will be better for all thoughts from these three places.If one of 5 people is team leader,the others will be 4 and square root of 4 is 2.In any case 2 people will be responsible for 50% work.I think it will be reasonable to 6 people.

As a result,I tried to mention about DDD,Scrum,reasonable team size as per the experience that I obtain in software development cycles.I may think something wrongly.Please share your comments.I am open to your constructive criticism.Thank you.

Software Development Manager