According to Nikola Bogdanov, the real challenge in agile transformations is adapting to business domain specifics and industry constraints; understanding agile is not the problem that needs to be solved. He presented domain-driven agility which utilizes design thinking to visualize agile adoption and make it empirical. It is based on domain-driven design strategy which are tactics used in software engineering to handle business complexity.
Nikola Bogdanov spoke about domain-driven agility at ScanAgile 2023.
The core problems in agile transformations come not from the application of agile or its understanding, but from the complexity of the domain and the specific application of the agile ways of working, Bogdanov said. As we deal with complex domains, he suggests reusing domain-driven development. This is a strategy that puts the business domain and its complexity at the heart of software solution development:
Domain-driven agility is a blend of the agile mindset and the domain-driven design strategy. It approaches transformation as an agile project, treating it with the same flexibility and adaptability.
Domain-driven agility starts with forming a cross-cutting team consisting of agile specialists, domain experts, decision-makers, and a certain number of change agents (usually middle-layer people who can and will execute the change). Bogdanov suggested running workshops like event-storming to identify the teams and values stream around which we are going to form the new teams and product organizations.
The next step, according to Bogdanov, is to create a backlog of change. This can be done by running brainstorming and refinements to identify what needs to be done, for instance with OKRs and goal-setting sessions to create the strategic direction.
Domain-driven agility needs a cadence. Bogdanov mentioned that they choose monthly to quarterly execution cycles split into two-week sprints.
The domain-driven approach is also very useful to define and redefine the ubiquitous language for a certain sub-domain, as Bogdanov explained:
For example, what is an increment for a pharma team? To release a medicine takes six years, how come they will release an increment every two weeks? So here we redefine what increment is. In this case, we usually define the increment as the most important question that we need to get answered or the most important hypothesis that we want to get verified.
Bogdanov mentioned that we need to redefine the "transformation project" as a concept, as transformation is always a journey and we usually just know the direction and maybe the dream state:
We usually define transformation as an agile product itself that evolves constantly.
Don’t rely on out-of-the-shelf solutions like Scrum, SAFe, or kanban alone, Bogdanov said. Collaboration between domain expertise and an agile culture is essential, he added. Leveraging domain-driven design can reduce industry-led complexity and help you seek guidance and learn from others’ experiences.
InfoQ interviewed Nikola Bogdanov about domain-driven agility.
InfoQ: How does applying agile differ for different industries?
Nikola Bogdanov: The solution involves aligning language, defining organizational boundaries, forming change teams, building a backlog, and executing change iteratively, incorporating empiricism, and adapting to various levels including culture, process, product, and quality.
For example, in a few companies we’ve worked with, words like "agile" and "Scrum" were totally forbidden because of the unsuccessful attempts from the past. And totally to the contrary, in other companies we have used the same words as magical spells that can open every door, as they were perceived as some sort of dream chimera.
InfoQ: What’s your advice to companies that want to embark on a journey of increasing agility?
Bogdanov: My advice to companies looking to increase agility is to customize their approach, embracing the complexity of their domain and treating the transformation as an agile initiative. I suggest using design thinking to prototype solutions, maintaining transparency in their goals, and continuously learning from experience to make the transformation empirical. And please, stay away from one-size-fits-all magical solutions.