DEV Community

Cover image for What I Learnt From Doing Remote Collaborative Modeling For the Past 6 weeks ?
Rohit Kelapure
Rohit Kelapure

Posted on

What I Learnt From Doing Remote Collaborative Modeling For the Past 6 weeks ?

I have a confession. In the past six weeks I have spent more time on Miro Realtime Board facilitating Remote collaborative modeling sessions than in IntelliJ or Eclipse. So what have I learnt in the past 6 weeks doing non stop modeling and group facilitation of system and solution architecture of enterprise systems ? How can you succeed in remote software modeling and design ?

  1. Facilitation is very much like Remote mob programming. One driver, multiple navigators

  2. Smaller the group better, high fidelity the outcome

  3. Icebreakers for Event Storming like Cinderella story session are a must. Here is an example of the Cinderella Event Storm. Credit for this idea goes to Paul Rayner.
    Cinderella Event Storm Ice Breaker

  4. If the participants are familiar with facilitation exercises - remote collaborative modeling become smooth.

  5. Focus on pure domain and intention over implementation. This is VERY VERY Difficult for folks who live and breathe the domain every day and are biased by the implementation of the current system. Be very clear on whether you are modeling current or future or intermediate state. DDD language is confusing to most architects and business folks.

  6. Keeping the same level of abstraction in facilitation exercises like ES/BORIS is important.
    Boris Diagram Online Chess

  7. Domain Story telling i.e. writing stories BDD Style scenario-background-rule-given-when-then-and-but is a systematic way to define thin slices before Boris.

  8. Epic Story Mapping to MVPs, Business/value and risks and teams lead to a roadmap.

  9. You cannot sustainably do this for more than 6hrs. max a day - restricted to 90 min sessions each. To retain mental health - no more than 4-5 hours of remote modeling. For a navigator > 2 weeks You need a team of at least 3 facilitators and will need to rotate the primary/secondary to avoid burnout. You will also need a full time Program Manager.

  10. Beyond a certain volume we just annotate the maps/diagrams itself with API, Stories, Messaging and Data - No separate SNAP for each service/domain. If there isn't time to do BORIS to go broad - then do Impact Maps of Pain and Opportunity.

  11. Organize all your work on the board as frames. It is also important to lock down frames if new folks are joining. Please backup your board every night. Facilitators will need to be Miro ninjas. You need an internal and external board. Private workspaces are also needed for ideation.

  12. If your group changes every week, then some context setting needs to occur. An offline channel of communication like slack where ideas can be exchanged in the background helps. Establishing a shared vocabulary helps reduce bike shedding.

  13. Be flexible and ready to adapt. Especially wk-1 you should have an internal sync every day to figure out plan for next day. In the first couple of days we sync'ed up in every break.

Happy Modeling Architects!


  • Cinderella Event Storm: Ellie Bahadori
  • Online Chess Event Storming and Boris: Alexander Basson & David Edwards

Top comments (1)

mohsenbazmi profile image
Mohsen Bazmi

Nice post Rohit, Scenario Hunting is also a technique which can be used to gracefully turn the design artifacts to behavior driven tests.