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

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!

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 😉

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.

Video of a team self-selection workshop at KPN iTV

The principles are pretty simple:

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!

• Present the current team boundaries.

• 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.

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

Tips

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.

Repeat

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…

Stay up to date with content and upcoming products

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"!