The modernization of existing software is becoming ever more important in the development ecosystem. Quoting Forbes: “Now Every Company Is A Software Company”, but a large part of enterprise software is not ready for the extremely fast changes that companies need now.
Flowing is currently helping a lot of companies that are in struggle through their path to software modernization. Most of the times we are called to help development teams when they are stuck with a new set of features that seems not feasible with the current codebase/framework/architecture. Other times our purpose is to help refactor a codebase in a bad shape, that is not letting the team bring enough value to their core business.
For both of these use cases, we developed a dedicated brainstorming format called Architectural Clash.
Architectural Clash is a two-day workshop with the purpose to help clients to remove the roadblocks with which our clients are struggling. As an example:
“We would like to build a mobile version of our desktop application, but our desktop clients are directly connected to the database.”
“Our codebase is a big ball of mud and we are struggling in adding a new set of features to it. We would like to start working with microservices but we don’t know where to start.”
“Our frontend is based on AngularJS. We would like to stop using it and we think that the only solution is to rewrite everything from scratch. Are there other options?”
The main advantage of Architectural Clash is to be an extremely practical format. We don’t waste a lot of time in analysis and hypothesis but we start working immediately on the existing codebase. Half of the time of the workshop is actually hands-on, trying to tackle problems mixing our team with the existing client’s team.
An Architectural Clash is divided into three phases: Sense-Making, Clash and Decide.
The first phase of an Architectural Clash is called Sense-Making and its focus is to help everybody (our team and the client) better understand the boundaries of the problem. The presence of all the interested stakeholder in the product is required for this phase.
The main purpose of this phase is to understand how technical problems are related to business problems. Most of the times, refactoring processes fail because they are not directly connected with business goals.
When a developer team complains about having to work with old technologies or with a very confuse (or untested) codebase, we ask “What is the real problem?”. We do that together with the stakeholder to find hidden connections between code and business. As an example, we try to make it clear that having an untested codebase would lead to dangerous bugs that could be disastrous or the connection between a big ball of mud with the throughput of the team.
We do that by asking the client for the goal of the business and then trying to understand what are the technical roadblocks for reaching that goal. One of the exercises that we use in this phase is the Elevator Pitch.
After the definition of the goal of the product, we start to identify the roadblocks and how to tackle them. But in proposing a solution there is a caveat. All the proposed solutions to roadblock should be written as an experiment. As an example:
We believe that using Cypress we could add an end-to-end test suite to our product in short time.
Notice that you add an expectation to the task of adding Cypress, this force you to analyze your results after the experiment, comparing them to your expectations.
So, the outcome of the first phase of the Workshop is a list of experiments, that will be the main ingredient of the next phase: Clash.
There is another important difference between an experiment and a task, a timebox. During the Clash phase of the workshop,** the purpose of the team is to run the greatest possible number of experiments**.
The eight hours that form the second phase are split into eight one-hour slots. For every slot, some experiments run in parallel, dividing your team into a bunch of small teams. Every team can work for 45 minutes. At the end of the 45 minutes, all the small teams gather together to share what they learned running the experiment in the remaining 15 minutes of the slot. To help the team to track down and share their results we use a simple document.
After the slot ends, a new cycle begins, until the time runs out. After every cycle, the teams could be mixed up and every team could decide to go deeper with another experiment on the same topic or to start with something new.
As Flowing, we don’t just provide a facilitator for this workshop but also a development team that can work in the clash phase with the client’s team. This is quite important because when dealing with legacy code developers should have a bias towards their codebase. Reasoning and writing code with somebody that doesn’t know anything about that codebase and its history can help see things in a new way, finding new and unexpected solutions.
The last phase of the Architectural Clash is “Decide”. In this phase, we take all the information about the business goals analyzed in the “Sense-Making” phase, with the outcomes of the Clash phase. Trying to define and prioritize a roadmap that will in time remove most of the roadblock that are causing problems to developers and the business of our clients. In this phase, a possible exercise to use is called “Options Board”. In this exercise, all the actions extracted from the outcomes of the Clash phase and put on a cost/value graph.
From this and other types of charts, we categorize and prioritize the actionable, creating a roadmap.
If you think that Architectural Clash could be useful for your company, or if you have any questions, feel free to contact me at firstname.lastname@example.org.