First word of caution: this blog is in the category ‘personal insights’: it is thus PERSONAL, it should be the start of a conversation, not the end… What is more useless than a blog with no comments?

In this blog, we will describe how to manage the consequences of the ‘Monday topic’ event as described in a previous blog. We will start here from the fact that you have engaged your teams, and we are now in action!

Action

Now we must organize the work. If the ‘Monday topic’ was already part of the domain knowledge of the team and was below in the stack, no problem, if the topic is brand new to the team, we recommend that you use https://blogs.sap.com/2021/02/01/vision-scope-engineering-of-complex-software-systems-requires-more-than-just-a-good-backlog/ as the blueprint of the knowledge transfer exercise. In a nutshell, the team needs to have information on the business context, the opportunity for innovation, the vision and business value before digging into the solution scope and both high level and detailed level architecture. I would also strongly suggest using a description of all foreseen edge cases to be used as a tool to grow the knowledge of this team and help build a test strategy. Of course, this means that we have access to some subject matter experts who can provide this information. If you do not have a subject matter expert, try to hire one (external or internal), because if not, not sure there is hope.

Monitor the impacts

Of course, what was planned to be delivered before the ‘Monday topic’ will not be delivered. Remember, when we talk about complex software, it is very unlikely that all functions will be delivered in one sprint/wave, by one team, even if you manage to have user stories delivered every sprint or wave, they will not reach the minimum practical scope in a snap. Pushing down in the backlog the user stories that were on top is equivalent to prepare for other escalations, especially if some of these developments were so called ‘committed’. Briefly, there will be several types of consequences to watch:

1. Trading some customers satisfaction with some other customers dissatisfaction. This means that the customer success team (change this team’s name as fit in your organization) must be full thrust on these changes. It is also very likely that your organisation will have to deal with some coming customer escalations, entering into a vicious circle.
2. Productivity impacts, because of the context switching of the development teams, especially if they do not have time to finish something that is in a desirable state for the users.

1. 1. Make sure you collect the time that was required to ingest the knowledge transfer as specific tasks, and
   2. Keep a specific backlog of the developments that were stopped while not finished, and make sure you are revising their relevance at every new sprint.

3. Employee Satisfaction: developers do not see themselves only as “code line producers”, in most of the cases for good reasons, especially in the case of complex software. More importantly, there is a feeling of autonomy loss, or empowerment, linked to engagement, so while the team is working on the new topic, it may be important to carve out some time for the original topics. It will delay the development for the ‘Monday topic’, it will split the team focus, but it may be the only way to keep the employee in house.
4. It is also especially important to understand the long-term ownership that the team is engaging through this development: agile methods usually focus a lot on the development phase and do not elaborate on the maintenance phase. When dealing with complex software, it is particularly important to understand who will get the long-term ownership of the development, especially if this is in the case of helping another part of the overall organization, and especially if your solutions are used for tens of years (yes: this exists in Enterprise Software). You have to carefully plan for the maintenance of the ‘Monday topic’.

These 4 actions are the ones that keep the teams together and help continuing building the trust and goodwill that is mandatory in an environment where there is change, then uncertainty, then response.

Long Term ownership

Out of the 4 actions, I think that the long-term ownership deserves a special focus, especially in the case of complex software, of which Enterprise Software is an example: the problem of long term ownership must be taken into account as soon as possible in the management of change for several reasons:

1. Developments are made of human (still), and the engagement of a team is not the same if you tell them that they will own the topic long term or if they help in a ‘commando’ style. The point is not that they will provide less quality work, but rather that they will not feel empowered with pushing radical changes (refactoring for example) on a topic they will not own long term. In case of uncertainty on the long-term ownership, they will take the weaker engagement path.
2. The maintenance problem will show up quickly, and here, you will have to face two situations:
   1. Long term ownership will remain in this team, in this case, the team has acquired a new domain knowledge, and the number of domains that a given team can handle cannot grow indefinitely, and you will soon have to make sure your organization handles the maintenance in separate teams. You cannot ask agile development teams to master an ever-increasing number of topics and maintain the code for all the topics this team has encountered in his life span. In other words, it is a rough management to evaluate the success of a team on both the adherence on a service level agreement on defects resolution on old topics, and, at the same time, on the productivity of delivering stories on the new topics.
   2. Long-term ownership will not remain in the team, and you will have to plan when and how the knowledge transfer back to the target team will occur. Communicating that plan is a key element in keeping the trust high.

At the end, there will be several areas in the overall complex software, dealt with different team profiles, all under urgency:

1. Mature area where teams need to master complex pieces of code: We have seen code sections where it takes between 6 months and 2 years for a newcomer to be autonomous (I know that for fact since some of the lines of code I wrote more than 20 years ago are still in use today – and useful I may add). Their urgency is driven by the very high or high bugs coming in.
2. Green area where teams need to show the goodwill to react to ‘Monday topic’ requests. Their urgency is driven by this adaptation skill.

The level of incoming bugs per period can be used to move components from Green to Mature areas or vice versa. The way to manage this is to have an architecture diagram that represents the maturity of these elements, and the associated owning teams.

The purpose of this explanation is to make explicit the fact that it will be difficult for a team of ten (or a squad, or whatever is the unit that you are using) to own both mature and green components.

A little caveat to this paradise picture is when you need a major refactoring where a lot of components turn Green.

Conclusion

In our world of large and complex enterprise software, there is nothing, absolutely nothing, that is carved into stone, and there is no absolute truth on what is needed by the customer enterprises. Therefore, agility is not an option. But changes will require a proper management of the customer (or internal stakeholders) dissatisfaction for the ones who were expecting something that will not happen, a proper monitoring of overall quality (since the developments that were stopped early will lead to quality issues and will eat some upcoming resources in the same development teams), a proper monitoring of the productivity loss (and do not mix activity with productivity), a proper monitoring and specific actions to elevate employee engagement. A specific focus must be given to the long-term ownership of these new topics that will be maintained in the long run.

I said at the beginning that this blog was personal, I must say that I am lucky enough to have a stellar team who lives through these changes with the trust, the goodwill, and the ‘can-do’ attitude that makes the difference.