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

 

© 2006-2020 by Mondo Technologies, Zug, Switzerland

​