In the life of any growing software based company you eventually need to split along domain lines. That way each team can master the area in thier domain.

This does have consequences during and after the split. Who owns what? This has two problem areas: things that belong to multiple teams and things that belong to no one.

Eventually data will end up in an analytics database (sometimes called a data warehouse). The question I have for you is: When was the last time that you checked that this database is accurate?

If many teams are passing data to a system how do you ensure consistency?

You know the ones. The tests that pass 93% of the time and always on the second or third run.

There are several solutuons to this problem.

1. Ignore and rerun
2. Keep tabs and invest in fixing on the third try
3. Aggressivly fix them, frequently asking AI how to recreate the issue.

I have recently started on the third path. Unstable tests kill productivity. They will break when you don’t have the time to spare. Remove them mercylessly.

I play varuous games in my spare time.

Merge Dragons is the one I have been playing longest.

The weekend chsllenges generally involve trying to assemble large items from components that you can mine. This forces you to build a pattern so that you merge the right items at the optimal level. This teaches several of the theory of contraints topics such as reducing wait time at a critical item. In particular you don’t want your dragons to waste time travelling to drop what they mined.

The timed challenges get you to focus on what you need to do. You don’t need to collect everything on the board, just what you need to hit the goal.