Event storming started as a method to model domains more effectively. However, it is now emerging as an effective method for a variety of use cases ranging from product discovery to business model planning.

In this workshop, you will get a chance to experience remote event storming on a simple, but interesting business case. You will learn the foundational concepts of event storming and gain first hand experience in its practical application in a remote context.

Event storming is a wonderful, collaborative way to discover or express your domain. But is event storming equally effective when done remotely?

In this talk we share our experience on event storming some really exciting software products and its role in the product evolution over the last 3 years .. remotely!

When you have a newly formed remote team, which has to deliver a system in a high stakes environment—including very short deadlines, high visibility (especially for failure), limited knowledge of some of the technologies to use, and some hard security and accessibility constraints—remote mob programming might not be at the top of your list of methods to use.

Yet, this is what we did to deliver successfully, and to very high quality standards (zero defects in production, so far) one of the backend systems used by the NHS COVID-19 app—the covid app used in England, and Wales, UK.

In this talk I’ll share some lessons learned (warts and all) on how remote mob programming helped us achieve our very challenging goals, learning a lot in the process.

In the software world we have been looking for “The Methodology” to solve our software development sorrows for quite a while. We started with Waterfall, then Spiral, Evo, RUP and, more recently with XP, Scrum, Kanban, DAD, SAFe (there are many others, but, their impact, so far, has been limited).

In this tutorial, I'll show why this search for the holy grail is bound to fail--each methodology has strenghts and weaknesses that make it suitable only in some contexts--and I'll describe a different approach based on patterns and pattern languages, that teams can use to create their own methodologies to suit their specific needs, which, in my experience, has a higher chance of success. 

The approach is based on the observation that all the practices used in all modern methodologies--e.g., user stories, use cases, team self organization, TDD, unit testing, acceptance testing, continuous integration, iterative and incremental development, etc.--come from the same set. Different methodologies just mix and match them differently. All those practices can (and many have already been) described as patterns whose relationships with each other form a set of pattern languages.