Collaborative software design is a visual, shared modeling practice that brings developers, testers, architects, and business experts into the same room to build a common understanding of what software should actually do. Tools like event storming and example mapping use simple sticky notes to surface hidden assumptions, replace document handoffs, and let technical and business knowledge flow in both directions before any code is written.
Key Takeaways
- Assumptions made by developers who never talk to stakeholders reach production as working software, not just as misunderstandings on paper.
- Collaborative modeling sessions work because every relevant role, including testers, architects, and business experts, builds shared understanding directly, cutting out the document-handoff chain.
- Simple visual tools like event storming or example mapping outperform formal notations because participants contribute freely without learning a specialized notation first.
- A 20-minute example mapping session on a single backlog item is enough to reveal whether acceptance criteria are clear or whether more discovery is needed before writing any code.
- Teams that collaborate continuously with stakeholders and move directly to implementation reduce the knowledge loss that accumulates through tickets, refinements, and intermediary documents.
Why most software gets built on unchallenged assumptions
The biggest defect in many software projects is not a bug. It is a conversation that never happened. Teams take a ticket from the board, implement it, and ship it, without knowing why the work matters or what the business actually needs.
Kenny Baas-Schwegler points to a pattern that holds across companies: a developer picks up a story, brings their interpretation of it to production, and that interpretation is mostly assumption. The story on the board is not the understanding in the developer’s head. What reaches production is the gap between the two.
This is the classic handoff problem. Gien Verschatse describes how it played out early in her career. A business analyst talked to the users, wrote down their assumptions about what the software should do, and handed those assumptions to the development team. Developers then interpreted the analyst’s interpretation, wrote it into code, and pushed it live. The feedback that came back was polite and useless: this is not what we needed, but thank you anyway.
The damage is not limited to the team level. Gien once asked a software department about its strategy and heard that the focus for the year was refactoring and improving the old products. Higher management, asked the same kind of question, said the real focus for the next two years was launching new products. Two parts of the same company pulling in opposite directions, with no shared picture of where they were going.
Testers inherit the assumption problem
Quality work suffers more from missing conversations than from missing test cases. A tester sits at the end of a chain of interpretations: the business need, the analyst’s translation, the developer’s reading of that translation. Each handoff adds another assumption.
For testers, a clear understanding of what the software is supposed to do is not a nice-to-have. It is the thing they test against. Without it, they are guessing at the intended behavior while trying to verify it, which means they are testing one assumption against another.
What collaborative modeling actually is
Collaborative modeling is a visual, conflict-laden decision-making process that creates shared understanding among the people who hold the knowledge. The point is to crunch knowledge together rather than pass it down a chain.
Three elements carry the definition. It is visual, because talking in circles wastes time and writing things down focuses the conversation on what is in front of the group. It is for complex, conflict-laden decisions, not for easy calls. And its goal is shared understanding, which is the part that attacks miscommunication directly.
The method breaks the silos. Instead of a document written by one person and handed across departments, everyone goes into the same room: developers, testers, architects, business analysts, domain experts. Stakeholders here include the engineers and testers, not only the business side. The group talks through the real processes, the workflows, the exceptions, and who has to communicate with whom.
How the visual tools keep knowledge flowing
The tools have to be simple enough that nobody needs a two-hour lecture before they can join in. Most of the work is sticky notes and rough drawings. Any visual tool can become a modeling tool once it lowers the barrier to getting knowledge out of people’s heads.
Several established techniques fit this description, and none of them belongs to a single role:
- Event storming: an orange sticky marks a domain event, something relevant to the business, such as “a seat was reserved”. From there the group asks when a reservation is not possible and surfaces the constraints.
- Domain storytelling: another common starting point in domain-driven design for mapping how work flows.
- User story mapping: widely used in product management to lay out the shape of a product.
- Example mapping: strong in the testing space and just as useful for engineers, built on asking for concrete examples.
- Business model canvas: usually owned by product management, but revealing when an engineering team fills it out and the two versions are compared.
Kenny contrasts these with notations like UML or ArchiMate. Those tools are precise but constrictive, with a dialect that not everyone reads the same way, where an arrow’s fill or shape carries meaning few people remember. When the goal is to let knowledge flow freely into a shared modeling space, anything that blocks a participant works against you.
One image captures the intent: the group acts like Dumbledore pulling memories from his head into the pensieve. Everyone empties what they know into the shared modeling space so the team can look at it together.
From shared understanding to software boundaries
Understanding comes first, design comes second. Only after the group sees how the real-world process connects can it decide where to cut the software.
Everything in the real world is connected. Software forces you to chop that continuous reality into pieces for reasons like maintainability, flexibility, and scalability. When you draw a boundary and turn a slice into a microservice, you are making an artificial cut through a process that actually keeps flowing. That cut creates communication between services, and the model lets you see the cost before you commit.
This is also where you decide what not to build. If an exception happens once a year, putting it into the software adds complexity for little gain. Handling it manually is a legitimate choice, even now. Engineers often resist that, but the question stands: is this worth a place in the system?
Because the right stakeholders are in the room, the design can improve the process instead of only copying it. Gien and Kenny call this dual learning. The business brings its requirements; the engineers and testers see where technology could make the process smarter. In a top-down setup where requirements are dumped on a team, that learning never happens.
They take tickets, but they don’t know why they’re doing the ticket. And without that why, they will just bring something to production. That’s an assumption of their understanding of the ticket.
Kenny Baas-Schwegler
How to get reluctant people into the room
Forcing skeptical people into a workshop tends to backfire. If little collaboration exists today, a big mandatory session becomes a self-fulfilling prophecy: people leave saying they learned nothing. Start smaller and earn the room.
Kenny offers three ways in. The first is interviews: talk to people one on one, understand the problems they face, and lead them toward a session they can see the point of. The second he calls guerrilla modeling. In one company where no team would join a shared meeting, he rolled out a paper roll in the coffee corner and started modeling the landscape himself. People walked past, saw mistakes, and corrected him. Being visibly wrong pulls people in. The third is doing it quietly for yourself first. A better internal model lets you ask sharper questions, and eventually people want to know how you got so good at asking them.
Gien’s route is to find allies who feel the same pain. Some developers are tired of rebuilding the same feature again and again. Some people on the business side are genuinely frustrated that what they asked for is not what they got. Pull two or three of them together, say you want to try something, and practice with a small group before facing fifteen people. When those early participants start telling others it worked, the resistance on both sides drops.
The post-its are not the point
The outcome of a session is the shared understanding, not the wall of stickies. One of the mottos is that you should throw the post-its away. What you keep is the knowledge: the business rules you now understand, the case that happens eighty percent of the time and the one that happens fifteen percent, and what that means for the design.
Preparation makes the difference between a productive session and a meeting people dread. Set a clear goal before you start. Decide which process or part of the system you no longer understand, who should be in the room, and what you hope to learn. Tell participants what will happen and what to bring, which is usually just their brain. People work better when they know why they are there.
How long a session runs depends on its outcome
There is no single duration, because the format follows the goal. The range runs from a full-day workshop to a tight twenty-minute exercise.
A useful way to match format to purpose:
| Format | Typical length | Purpose |
|---|---|---|
| Big picture event storming | A day, extendable over several days | Map the whole company, locate the systems, break silos, vote on what to work on first |
| Architecture modeling (e.g. C4 or sticky notes) | One and a half to two hours, repeated every few weeks | Merge each person’s view of the architecture into one shared picture |
| Example mapping | About 20 minutes per backlog item | Surface acceptance criteria; if it is not clear in 20 minutes, you need to discover more |
The big picture session gives massive learning and a shared sense of the most worthwhile thing to tackle, which is why Kenny runs it before accepting where a client thinks the problem lies. Example mapping is the easiest to try: pick an item, ask for a specific example, and see where twenty minutes takes you.
Collaboration is the agile loop, not the Scrum ceremony
The strongest pattern is short: collaborate, code, come back for feedback, collaborate again. Every extra step between those two points is a transfer of knowledge from one ticket to another view to another document, and knowledge leaks at every transfer.
Kenny has seen teams work this way and drop most of their Scrum ceremonies. They keep retrospectives but stop doing refinements, because the continuous conversation replaces the need for heavy documentation. When understanding is fresh, the code can follow directly.
This is closer to the original intent of agile than much of what passes for Scrum today. Domain-driven design existed alongside agile, and Eric Evans was clear that the work needs a continuous conversation with stakeholders. Inspect, adapt, design something, build it, see what it does, bring the feedback back. When you can walk over to a domain expert whenever you need to, that loop never closes into a ceremony. It stays a conversation.
