Avoid the technology tunnel when evolving your software product

(You can also read this article in Italian)

In the software development world, it is not so frquent to work on a completely new product. Most of the time is spent by the teams maintaining an existing product. Often, however, I have dealt with a type of activity that is between the new product and the legacy: we make it fall into the large category of migrations. Sometimes there is a major change in the architecture, others are real rewrites and just to this last type I refer: chasing the technology evolution we have the opportunity to update the functionality, the ways of using a service, the methodologies adopted, the development techniques practiced by dev teams.

As a coach with memories from software development I have always recommended to change only one thing at a time, in order to be able to evaluate the effects, or to quickly understand if an error had been introduced. Of course I broke this rule several times and on several levels: the higher the level, the worse I got myself. Other times it was all or nothing, and I do not say it lightly because I mean that with that risky bet the closure of a department has been avoided. It is a lesson that I learned unconsciously, when those decisions were taken by other people whose courage I could only appreciate with hindsight.

Let's get to the point: we have a product developed by non-vertical teams that over the years has seen a stratification of technologies that are no longer cutting edge, where modern development techniques, particularly those where tests drive, have not been applied and the processes "imposed" to the end user should be reviewed.

This is one of the many cases in which we are dealing with many forces that pull in different directions: architects would like to adopt paradigms that are the latest, developers would like to work with new and fascinating frameworks, product managers would like to revisit processes, the coach would like everyone to agree with each other so that he can take a further nap. As always happens, no one wants to listen to the other's reasons and I've often seen that in the end the architects, or whatever the name of those who command on the software development, drive the whole thing because they have the car keys or simply because they are the ones who complain first. I am convinced that everyone is an expert on the problems he has in the first person, and I have often driven that car.

What is the risk involved in these situations? In my opinion the biggest one is that the technicians lock themselves in the laboratory and, coming out full of dust after several months, they realize that in the meantime the world has changed, the customer has disappeared or simply expected something different. A sort of waterfall, indeed, a real tunnel where the first useful feedback is obtained only at the exit. Can we mitigate this risk ? Agile and Lean Startup rely on frequent releases to acquire learning useful to make the appropriate decisions, but everything gets complicated if the goal is to replace a system, a subsystem, a technology. One of the most interesting approaches that can be adopted is the one described by the Strangler Application pattern. This is a great tool but fits when we have clear ideas and we know with certainty that we do not have to change anything from the functional point of view or we can add functionality without touching the existing.

With some teams at one of the companies I worked with, we have adopted an approach that somehow helps in the application of the "Strangler". We did it because the objectives were also to improve, where possible, the user experience, which of course also involves the modification of existing system parts. We tried to stay as light as possible, trying to "control" as little as possible.

After the technicians have scouted the possible initiatives to be put on the track, largely guided by the desire to counteract technological obsolescence (in this specific case it is also a matter of replacing hardware components) we have brought together experts both from the business and the technological domain to remind us why we are undertaking this activity, answering these 4 questions:

• Who are our users ?
• What are their needs ?
• What are their expectations of the system we are proposing to them ?
• What initiatives can we put in place ?

Answers to this kind of questions are not always obvious. The least that can happen is that new users will appear, but also that some initiatives seem foolish while others almost obvious were not even hypothesized. It is indeed a very simple type of workshop that we have often used to "create" new initiatives. In this case we have exploited it, perhaps inappropriately, to put ourselves in the shoes of the users and catapult us in a session of User Story Mapping, otherwise impossible without having shared to whom we address with our system. We did a small change also to the way we use the User Story Map. Typically we try to use it also to make a release plan, even by identifying an MVP. In our case we tried first of all to define a tracer bullet exclusively focused on the technical issues, that is, that minimum set of stories that allow us to obtain a first "end to end" of confirmation that the architecture "holds", the monitoring tools work, the sub-systems speak to each other, the basic automatism are ready and the synchronization mechanisms (aka face to face meetings) are standing. I am talking about something that needs to be done within a week or two and then to be refined continuously.

While trying to avoid the use of Technical User Story, is almost certain that the user stories that will be identified will have extensive technical content. A very useful method for making technology-driven splitting is the User Story Hamburger, described by Gojko Adzic. In practice we will find ourselves with a User Story Map where the stories proliferate down also depending on the progress we make in biting the sandwich stuffed using the technique of Gojko Adzic. There is no optimal recipe but everything becomes a fantastic visual tool to decide, in a collaborative way, how to proceed in order to mitigate as much as possible the risks I mentioned at the beginning.

Please note that a workshop of this type that should lead to identify e.g. a hundred user stories for one or more features of a medium complex product, will last about a day, limiting the number of participants to a minimum. Among these I consider essential:

• a domain expert (a product owner or a product manager)
• a technician who participated in scouting on architectural evolution
• a couple of team members (one should be a testing expert)
• a facilitator

The outcome of the meeting, in addition to a greater alignment on the strategy, must be a backlog of stories and a first simple release plan, containing at least one technical tracer bullet and a demoable release. The next step is to do a Rough Affinity Estimation of the stories identified in order to be able to reason even in front of a calendar.