How to Start New Agile Software Projects: Business Domain Discovery

How do you help someone solve a problem if you don’t speak the same language? You learn their language and teach them a bit of yours. Without a shared language, you won’t understand the problem, and your solution may not end up being a fit. You are endangering the entire project. Read on to find out how I establish a shared language with new clients.

This post is part of a series. Check out the other posts in How to Start New Agile Software Projects.

As an Agile Software Architect and a startup founder, I am one of the first to develop new client relationships and projects. When the client starts working with us, I have to discover enough about the project to solve their problem as quickly and efficiently as possible.

Motivation

The Domain of the project encompasses the entire problem space. It usually consists of a set of processes, an ecosystem, and a set of users of the system. Users or stakeholders that have the highest level of knowledge of the domain are called Domain Experts. I want to spend as much time absorbing knowledge from these experts and consulting with them at every step of the project’s technical execution.

Agile software delivery tells us business people and the development team must work together every day. If the team is comfortable with the business domain, everyone is speaking the same language, and communication is easy.

You may have heard of Domain Driven Design. This isn’t really the same thing. DDD is a process through which Domain knowledge is used to model a software project’s design and architecture. Regardless if you are planning to adopt DDD for the technical design of your software, you must understand your problem domain.

Timing

Forging a strong and effective line of communication with stakeholders and project sponsors is the very first thing I do. I start working on learning about the industry, processes, jargon, challenges, and outlooks before the very first meeting.

I then spend some time asking my clients about their internal processes to see how they differ from industry standards and their specific challenges and successes. It’s imperative to learn what is working and what isn’t.

Tools & Techniques

Let’s review four useful methods for rapid business domain discovery:

Industry Analysis

As soon as a new project pops up on my radar, I work on organizing a coherent collection of knowledge about the business, its competitors, the path to producing value in the relevant industries, and the market.

This provides just enough context to create a shared pool of language and knowledge with my clients and helps me approach discovery interviews with confidence and genuine curiosity.

Discovery Interviews

Everyone conducts discovery interviews, whether they know it or not. In its simplest form, a discovery interview is a discussion of the project’s requirements.

Discovery interviews benefit from some structure. It can be a prepared list of questions that came up during your review of the project description or your industry analysis, or it can be a workflow for keeping the discussion on target.

An alternative to discovery interviews are surveys, but I don’t like those because they tend to completely miss essential nuances that are important to get good clarity on the problem space.

Shadowing

Depending on the type of project and buy-in from the client, I like to spend time on the field and see with my own eyes how the challenge manifests itself and how it affects users and stakeholders.

This enhances the perspective and gives you a lot of contextual clues that may be omitted from a discovery interview because it may not seem relevant to either party.

I don’t have a recipe to prescribe for scheduling shadowing sessions, as that largely depends on the client’s line of business.

Event Storming

Event Storming has become my favorite method of gathering detailed, functional knowledge from domain experts, users, stakeholders, and engineering teams.

Event storming sessions are interactive workshops that involve all key players in the business and/or project to gain a big, yet very precise, picture of the mechanics of the business and/or the project.

Event storming can be applied to model business processes, operations, software components, or all of the above at the same time.

In its essence, event storming involves gathering all relevant personnel in a room, mapping out a series of domain events on a whiteboard, and identifying the actors and systems responsible for responding to those events, and for each of them, listing the processes and interactions between them. Oh, and by the way, this is all done by sticking post-its to the board.

The creator of the Event Storming technique, Alberto Brandolini, gave an excellent presentation explaining and demonstrating the mechanics and the motivation behind it at the DDD 2019 conference. The video is available on youtube.

The value of event storming to the discovery process is immense:

• It breaks silos of knowledge between actors.
• It speeds up the onboarding of current and future members of the team.
• It highlights poorly understood processes, systems, or infrastructure.
• It informs the design of future systems.
• It ensures all personnel share the same understanding of the business process and technical systems.

It is with these approaches and tools that I gather the information I need to properly design the project for the client. I will be describing the next steps in future posts; how I start the actual design from the discovered information, how to select an architecture, and how to structure the team will be forthcoming. So be sure to come back and read about those.