Feature Teams vs Component Teams? Decide with Event Storming and DDD

3 minute read

Team organization is tough. Event Storming builds enough shared knowledge and architecture for successful team re-organization workshops.

Here is Conway’s Law:

“Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

M. Conway[2]

If you have an existing team and a product you are trying to transform, this law is of paramount importance to you. If you did the Event Storming workshop, you should have a shared architecture vision. Let’s see how you can make Conway’s law help you to refactor!

Humoristic drawing of the organization big software companies
Credits to Manu Cornet from http://bonkersworld.net/organizational-charts

💡 Together, Event Storming and Conway’s Law help long term refactoring.

⚠️ Disclaimer: You might be few enough to organize well as a single team. In this case, you don’t need all this… until you grow, hopefully 😉

Poster introducing an Event Storming and DDD workshop intended to re-organize teams.

This is also the 18th post in a series about how to use Event Storming to kick start architecture on good tracks. It all started with misadventures with Big Design Up Front.

Principles of Teams

Teams that follow the boundaries of the architecture vision will more easily realize it. We should not map teams to our existing system, but rather to our target system!

The idea is to conduct a team re-organization workshop as a follow-up to Event Storming. It’s best to run this activity just after we draft the target architecture, when it is still fresh in everyone’s mind.

Thumbnail from a video of a team self-selection workshop involving 200 people at KPN iTV
Video of a team self-selection workshop at KPN iTV

The principles are pretty simple:

Poster with 9 team structure principles. Presenting the some general teams principles helps attendees of a DDD Event Storming to go past the "feature teams vs component teams" debate.

  1. Display the architecture vision and team principles
  2. Let people self organize into new teams!

💡 Event Storming helps people to dynamically self-organize into teams.

Workshop steps

Here are the detailed steps for this activity:

  • Do this in front of the Event Storming board. It’s better to have the bounded contexts and relationship patterns. They make good starting points for team boundaries
  • Present the team principles
  • Let people brainstorm ideal team boundaries. Again, use wool, tape to mark this on the board
  • Ask attendees to identify the skills needed for each team. They can mark this on the board with post-its
  • If it was not the case already, bring everyone in!

Poster presenting an example of 'legacy' team structure. Event Storming and DDD create the necessary shared knowledge for a successful re-teaming workshop, and letting people decide what's best between feature teams vs component teams

  • Present the current team boundaries.

Cover of the Dynamic Reteaming book by Heidi Shetzer Helfand. Use Event Storming, DDD and Dynamic Re-teaming workshops to let people chose between feature teams vs component teams

  • Let people self-organize into new teams according to all the constraints. Depending on your situation, this step might take more or less time. If you envision a rough time, it’s a good idea to have a look at this book for how to run this activity.

Photo of the board at the end of this team re-organization Event Storming. After discussing trade-offs for a while, people usually come up with a compromise on team structures. Rarely do we end up with all features teams or all component teams

  • Draw a quick diagram of the agreed on team structure.

Diagram of the target team structure. A typical example of how to record outcomes of a DDD Event Storming. We see that the target organization contains both feature teams and component teams


Here are a few simple tips to make this workshop more successful:

Get Everyone In

It’s best to involve everyone in Event Storming workshops if we can. When we follow up with this team re-organization workshop, we’ll get a natural buy-in. This will make the change a lot more sustainable.

Sometimes thought, if the team is too large for example, it will not be possible to include everyone. In this case, we can send a call for volunteers before the workshop. Everyone will get a chance to take part. We should make sure to have representatives from all teams and jobs. We’ll need to invite everyone in the final re-teaming activity though.


Agile teams will adapt! Once we’ve done this workshop once, we should not be afraid to let teams re-organize from time to time. That’s the whole point of Dynamic Re-teaming. Practice shows that only 20% of people change teams every time. (As Laurens Bonnema told us in his presentation at XPDays Benelux 2018) Running this kind of re-teaming once or twice per year seems like a good frequency.

Repeating this team re-organization workshop should also improve people’s motivation. They’ll feel they have control over what they do, and what they can learn. They’ll also be more likely to build compromise on team structure if they feel they have the chance to move again in 6 months.

Try it yourself

Combined with this workshop, the Event Storming high participation and natural buy-in shines. Event Storming is an easy way to speed up DDD (Domain Driven Design) adoption. It’s an easy and flexible workshop. This was the 18th post in a series about how to use Event Storming to kick start architecture on good tracks. Get started here.

In the next post, I’ll list other workshops that we can run in conjunction to Event Storming.

Continue Reading…

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!

Leave a comment