Forem: Joao Kersul

How I Plan Software Deliveries (Team-Solo Method)

Joao Kersul — Thu, 19 Jun 2025 19:30:00 +0000

TL;DR

The Team-Solo Method breaks big, messy features into five clear steps, switching between working together (Team) and working alone (Solo).

Map the problem with the whole team.

On your own, list every open question.

Meet again to check the plan and hand out the tough bits.

Solve the unknowns and turn them into clear tasks.

Lock the timeline and success metrics.

Handle risks early so scope stays clear and deadlines stick.

The Team-Solo Method

Context

Big features die in the gap between idea and execution. Without a clear roadmap, you either over-spec and stall or under-spec and blow up the timeline. The Team-Solo Method dodges both traps by alternating between focused group sessions (Team) and heads-down deep work (Solo).

When to Use It

Reach for this method when the work changes architecture, data contracts, or organizational boundaries. Bug fixes and small UI tweaks don’t need this much ceremony.

Team-Solo Steps

1. Define the Domain (Team)

Kick off with the whole squad in the same (physical or virtual) room and make the domain crystal-clear.

Agenda

Frame the problem (5 min). Desired outcome, constraints, non-goals.
Map the domain (30 min). Brainstorm events, commands, policies—Event Storming works great here.
Scope check (10 min). Explicitly mark what’s out for the first release.
Name things (10 min). Agree on ubiquitous language and key aggregates.

Expected Output

A high-level domain map everyone understands.
A shared glossary of entities and aggregates.
A starter list of known unknowns to investigate later.

2. Organize Ideas and Challenges (Solo)

Step away from the noise and turn the raw domain artifacts into actionable insights.

Cluster related concepts. Reveal implicit modules and bounded contexts.
Surface unknowns. Anything fuzzy becomes a spike task.
Spot quick wins. Identify slices that deliver value early.
Sketch architecture. Lo-fi boxes and arrows—focus on seams and data flow.

⚠️ If something feels vague, write “VAGUE” on it—future you will thank present you.

Expected Output

A Challenge Backlog listing every spike with an owner placeholder.
First-cut architecture diagram.
Draft roadmap sliced by value.

3. First Debrief with Tech Team (Team)

Time to stress-test the draft with the people who will build it.

Agenda

Walkthrough (15 min). Present clusters, spikes, straw-man architecture, roadmap.
Open critique (20 min). Teammates poke holes, raise risks, suggest alternatives.
Spike commitment (10 min). Assign owners and deadlines to each unknown.
Definition of Done (5 min). Agree what version 1 means.

Expected Output

Challenge list with owners and due dates.
Provisional architectural direction.
Time-box for the next Solo phase (e.g., 3 working days).
Parking-lot questions to revisit later.

4. Solve Tech Challenges & Create Stories (Solo)

Engineers disappear into their caves (or pair rooms) to kill the unknowns.

Build throw-away proofs-of-concept to validate libraries, latency, migrations, etc.
Convert validated chunks into user stories or technical tasks with estimates.
Document decisions and rationale.
Escalate if a spike breaches its time-box—don’t boil the ocean.

Expected Output

All spikes closed, questions answered.
Backlog of ready-for-refinement stories with initial estimates.
Updated architecture diagram reflecting discoveries.

5. Final Refine Together (Team)

The “Go / No-Go” checkpoint where ideas become a committed delivery plan.

Agenda

Refine stories (20 min). Apply INVEST, tighten acceptance criteria, right-size slices.
Group estimation (15 min). Planning Poker or similar.
Scope cut / pad (10 min). If the numbers don’t fit, negotiate scope, not quality.
Lock release plan (10 min). Map stories to sprints, set milestones, assign DRIs.
Define success metrics (5 min). Performance, adoption, whatever matters—write it down.

Expected Output

Refined backlog ordered by value.
Release timeline the whole team believes.
Clear success metrics and monitoring plan.

Why This Works

Fast feedback loops. No phase lasts long enough for you to drift too far off course.
Asymmetric collaboration. Meet only when group intelligence is needed; protect deep-work time otherwise.
Risk becomes work. Unknowns transform into dated spike tasks you can burn down.
Trust through visibility. Stakeholders see tangible artefacts at every checkpoint—boards, diagrams, backlog, metrics.

Common Pitfalls (and How to Dodge Them)

Pitfall	Consequence	Fix
Treating spikes as optional	Surprises mid-sprint	Time-box and track them like any other work
Skipping the Final Refine	“Half-baked” stories enter sprint	Make it a release gate
Over-documenting early	Analysis paralysis	Capture just enough to unblock the next phase

Conclusion

Big features aren’t hard because the code is hard—they’re hard because the unknowns are hidden. The Team-Solo Method shines a light on those uncertainties, turns them into actionable tasks, and keeps the team oscillating between collective alignment and focused execution. Steal it, adapt it, and watch your next architecture-level delivery land on time and on target.

Cut through uncertainty, surface risks early, and keep moving—that’s the whole game.

Multiple MongoDB Databases on Spring Boot

Joao Kersul — Fri, 12 Apr 2024 15:02:25 +0000

Intro

If you're working with Modular Monoliths on Spring Boot, you want to separate your modules into separate databases.

That's exactly my case, and trying to do that was a really pain in the ass. Mainly because all solutions that I've found still didn't make auto index creation work.

One important information: Here I'm using Kotlin with Spring Boot 3.2.

1. Adding Properties

First, you have to configure your application.yml to set the database names. Mine I decided to configure this way:

# application.yml
spring:
  data:
    mongodb:
      uri: mongodb://localhost:27017
      first-db:
        database: first-db
      second-db:
        database: second-db

2. Creating Mongo Config for Each Module

Since I'm using a modular monolith, I want to separate Mongo configurations for each module. So repositories in each module can use different databases.

// first/config/FirstMongoConfig.kt
@EnableMongoRepositories(
    basePackages = ["com.example.first"],
    mongoTemplateRef = "firstMongoTemplate"
)
@Configuration
class FirstMongoConfig(
    @Value("\${spring.data.mongodb.first.database}") val dbName: String
) {
    @Bean(name = ["firstMongoTemplate"])
    fun firstMongoTemplate(
        @Qualifier("firstMongoDatabaseFactory")
        factory: MongoDatabaseFactory,
    ): MongoTemplate {
        return MongoTemplate(factory)
    }

    @Bean(name = ["firstMongoDatabaseFactory"])
    fun firstMongoDatabaseFactory(
        @Qualifier("firstMongoClient")
        mongoClient: MongoClient
    ): MongoDatabaseFactory {
        return SimpleMongoClientDatabaseFactory(mongoClient, dbName)
    }

    @Bean(name = ["firstMongoClient"])
    fun firstMongoClient(
        mongoProperties: MongoProperties
    ): MongoClient {
        return MongoClients.create(
            MongoClientSettings
                .builder()
                .applyConnectionString(
                    ConnectionString(mongoProperties.uri)
                )
                .build()
        )
    }
}

Do exactly the same for the second module:

// second/config/SecondMongoConfig.kt
@EnableMongoRepositories(
    basePackages = ["com.example.second"],
    mongoTemplateRef = "secondMongoTemplate"
)
@Configuration
class SecondMongoConfig(
    @Value("\${spring.data.mongodb.second.database}") val dbName: String
) {
    @Bean(name = ["secondMongoTemplate"])
    fun secondMongoTemplate(
        @Qualifier("secondMongoDatabaseFactory")
        factory: MongoDatabaseFactory,
    ): MongoTemplate {
        return MongoTemplate(factory)
    }

    @Bean(name = ["secondMongoDatabaseFactory"])
    fun secondMongoDatabaseFactory(
        @Qualifier("secondMongoClient")
        mongoClient: MongoClient
    ): MongoDatabaseFactory {
        return SimpleMongoClientDatabaseFactory(mongoClient, dbName)
    }

    @Bean(name = ["secondMongoClient"])
    fun secondMongoClient(
        mongoProperties: MongoProperties
    ): MongoClient {
        return MongoClients.create(
            MongoClientSettings
                .builder()
                .applyConnectionString(
                    ConnectionString(mongoProperties.uri)
                )
                .build()
        )
    }
}

3. Enabling Auto Index Creation

This way that we've done, still don't auto create indexes. I was trying to do this multiple ways and checking Spring Data MongoDB documentation I decided to use IndexOperations to solve this problem.

I simply wrote a component that gets all MongoTemplates and creates indexes for each one:

// config/BuildMongoIndexes.kt
@Component
class BuildMongoIndexes(
    private val mongoTemplates: List<MongoTemplate>
) {
    @EventListener(ContextRefreshedEvent::class)
    fun initIndicesAfterStartup() {
        mongoTemplates.forEach { initIndices(it) }
    }

    private fun initIndices(mongoTemplate: MongoTemplate) {
        val mappingContext = mongoTemplate.converter.mappingContext
        val resolver = MongoPersistentEntityIndexResolver(mappingContext)

        mappingContext.persistentEntities
            .stream()
            .filter { it.isAnnotationPresent(Document::class.java) }
            .forEach {
                val indexOps = mongoTemplate.indexOps(it.type)
                resolver.resolveIndexFor(it.type).forEach(indexOps::ensureIndex)
            }
    }
}

4. How to Test

Creating Testcontainers Config

To be able to test for multiple databases, I recommend you using Testcontainers. That's my configuration to start the container:

// test/config/MongoTestConfiguration.kt
@TestConfiguration
class MongoTestConfiguration {
    companion object {
        private val container: MongoDBContainer = startContainer()

        private fun startContainer(): MongoDBContainer {
            val container = MongoDBContainer(DockerImageName.parse("mongo:6"))
            container.start()

            return container
        }
    }

    @Primary
    @Bean
    fun mongoProperties(): MongoProperties {
        val connectionString = "mongodb://${container.host}:${container.firstMappedPort}"

        return MongoProperties().apply {
            uri = connectionString
        }
    }
}

This will set the MongoProperties uri. That will enable the MongoConfig files to get this URL and connect to MongoDB on tests.

Using on Tests

// test/ExampleTest.kt
@SpringBootTest
@Import(MongoTestConfiguration::class)
class ExampleTest {
  @Autowired
  lateinit var exampleRepository: ExampleRepository

  @Test
  fun `example test`() {
    // Here you can normally use your repository
    exampleRepository.save(Example())
  }
}

Conclusion

That's all! Now you have multiple databases configurations with automatically index creation and as extra can use these configurations on your tests! \o/