MOndoWay
Innovation Ready
"Software design is an art, and like any art, it cannot be taught and learned as a precise science, by means of theorems and formulas."
DDD Quickly - Floyd Marinescu [infoq.com]
Mondo IT guides love maps! We love to guide you!
The models are never perfect, they evolve, so plan that from day one!
Quick Assessment:
01/
Quick Assessment
(2 days)
When kicking off an Event Storming workshop, no previous experience is required by the vast majority of participants.
-
Start with an "Event Storming" Workshop by involving all the right people at the same time in dialogue
-
Everyone participates and will be an active contributor
-
The event storming session will be run as a facilitated workshop
-
Achieve understanding, massive learning and alignment/shared understanding across the whole team
-
Achieve a clear Big Picture
-
Start drawing your Wardley maps
-
Highlight risks and "foggy area" that needs deeper dives
-
Archive meaningful conversation
-
Investigate alternative thinking
02/
Key Learnings
-
Our Brain: Doesn’t learn well under negative stress and provides inferior solutions under pressure
-
Accelerate group learning of common understanding of the domain in which the software operates
-
It’s much cheaper to make changes to sticky notes (in the Event Storming session) than production code
-
Move from vague idea to realization by making proper corrections on the way
-
The models are never perfect, they evolve, so plan that from day one
-
A software product is like art, it has a personal touch of those who designed and developed it, it is a reflection of the charisma and know-how, appetite for risk or not new things (the flair or the lack of it) of those involved from birth through the lifecycle
03/
Outcomes/The Flow Of Events
Key Definitions:
-
A domain event is anything that happens that is of interest to a domain expert
-
The domain expert is interested in the business domain of the things that have to happen (not in underlying technologies)
Output Seminar:
-
Unlimited Modelling Space
-
Define Domain Events - Area of Expertise
-
Find Commands and External Systems
-
Identify Personas
-
Identify User Goals
-
-
Aggregates
-
Bounded Context
-
Subdomains
01/
Honest Proposal Feedback
-
"Non-bias" and honest feedback to your proposals
-
Challenge your idea in a positive way
-
Provide "lesson learned" experiences from a dozen projects we did
-
We listen to your needs, we try ourselves the potential solutions (POC), then we will bring clear arguments to convince you of a specific decision
02/
Resource Management
-
Provide IT experienced resources "near-shore" with new technologies stack know-how and past Swiss project engagement experience
-
Manage better your resources (human and financial)
-
Maximize output by combining local and nearshore IT teams
-
Make sure your team learns daily something new
03/
Be always in control
-
We enable you to have full control
-
Know-how on advanced IT tooling that helps you control collaboration and end-to-end deliveries
-
We can help the team do their work themselves
04/
Provide Guidance
-
Propose/Guide/Review business&IT architecture
-
Mentor, make suggestions, review work
-
Run experiments, if ok you keep it, if not learn and throw it away
-
Big upfront design does not work well
-
Modify design based on feedback
Mondo IT Guides:
Mondo IT Guides:
01/
Manage Unknowns & Uncertainty
-
Continuously test your vision
-
Establish a clear process/methodology around the product development
-
Unknowns and uncertainty will be around you, be ready to take risks
-
Plan to address new findings
02/
Work Efficent
-
Instead of asking "Can this product be built?" your daily questions must be "Q1:Should this product be built?"
-
Next important question is "Q2:Can we build a sustainable business around this set of products and services?"
-
To answer correctly Q1 & Q2 you have to engage and the very early stage with potential/desired customers.
-
Learn to listen to them and address their needs.
-
Build a decision matrix that brings those customer needs into the product.
-
Continuously test your product against customer needs, learn more, adapt direction, and re-iterate
-
By the time product is ready for shipment you should have customers in your boat.
03/
MVP
-
Build a Minimum Viable Product (MVP) that will help to increase the process of learning for you and the customer
-
Measure customer response on the MVP by using metrics that will be input for your future actions
-
Measure the cause/effect on the actions, basically build a sharp measure-learn feedback loop
-
Re-iterate, learn, generate future actions
04/
Validate Learning
-
Focus on figuring out the right thing to be built, including the features the customers want and those they are willing to pay for it
-
Decisions should be concentrated around learning how to build a sustainable business.
-
Make sure you are set for a continuous adaptation ( i.e.do not need to wait for a betta version product launch to change the direction if needed)
-
Adapt the plans incrementally via continuous feedback.

Ask: Should this product be built?
Proof of Concept Guidance
01/
Define Clear Goals and your acceptance criteria
-
POC must be result-driven
-
Define clear goals
-
Define the measurement method
-
Define acceptance criteria
-
With reduced budget and sharp timelines prove that new concepts work or not
-
If it works, prepare next steps
02/
Setting deadlines and work with preset budget
-
Timebox the POC to less than a month (2-4 weeks)
-
POC scope must fit the agreed timeline
-
Align all key people with the POC timeline and budget
-
Make adjustments early if necessary (like descoping certain use cases)
03/
POC Scoping
-
From day one, do not allow scope creep into your POC ("do not try to build the final product")
-
Set appropriate expectations for stakeholders that will make them very confident in the new idea
-
Determine what do you want to learn and achieve with the POC
-
Define clearly success criteria
-
Determine the scenarios that you may want or have to cover
-
Identify the resources that must be available
-
Define the team that has to validate the outcome (potential customers, internal team, stakeholders etc)
-
Define the timeboxed duration
-
Plan in advance what you are going to do with resources involved in the POC
04/
Grob IT Architecture Landscape
-
Create a high-level rough architecture - here is good to have knowledgeable and experienced architects
-
Decide what are the essential components that are part of POC and which will be treated as non-essential and descoped.
-
Choose the proper environment to develop, test and run your POC (perhaps will be a cloud solution)
-
Do not try to build the perfect solution from day 1
-
Try to prove you can build well-scoped use-cases for POC
05/
Build the POC Development Team
-
Identify the mandatory team needed that have proper commitment and expertise for the POC
-
The team should be kept minimal and in sync with POC scope (i.e, in most cases 1-2 person in case the scope is simple, or larger if the scope is big)
-
Rely on Mondo Technologies for the technical team that we can assemble for you
06/
Implementation & Testing
-
Use Mondo Technologies to help you set up the dev environment
-
Use proper agile methodologies and iterative development
-
Use proper modern IT tooling
-
develop easy to follow front ends to be easily understandable by clients
-
Decide on code repository (ie. GitHub), develop automated DevOPS pipelines to deploy new code, manage CI/CD (continuous integration/ delivery) etc.
-
Define testing methodology and acceptance
-
Test and re-Iterate and bring feedback fast to the development team
07/
Evaluate POC
-
Use Mondo Technologies to help you evaluate POC
-
Evaluate and document findings
-
If successful present it to the stakeholders and extrapolate findings with a whole potential scope not just POC
-
Get Mondo Technologies with you to help you articulate your findings
-
If POC fails:
-
F1.Retry POC: redefine goals, timeline and scope for the architecture
-
F2.Shut Down: conduct a post mortem review and document the lesson learned
-