PART THREE

The hard limits of shared work

Sharing product code ownership across multiple teams works far far beyond what most do believe, while it stops working beyond some hard limits. These below are a few examples.

• Confidentiality: for confidentiality reasons, specific knowledge cannot be shared. Therefore related work is delegated to a specific person or team that will work autonomously.
  
• Unlearnable skills: the development of a feature may occasionally require, for a limited period of time, specialistic skills. For example, embedded software development or HW design or modelling dynamic simulations using Matlab Simulink or intellectual property law or chemical toxicology. These skills can be sourced timely and conveniently from an external company team.
  
• Different company: whenever the teams are developing a feature for or with another company not willing to share the codebase with them. With the exception of outsourcing, for which there exist better alternatives that can and should be pursued, there are other cases that cannot be avoided, nor the other company can be convinced to share the codebase.

Such hard limits can be avoided much more often than we tend to believe (as discussed before regarding the meaning of Extreme in Extreme Programming). Most of the time, it is the prevalent reality for a majority of companies and teams.

Nonetheless, given the widespread and ubiquitous nature of software nowadays, the increased level of interdependence among different departments and organisations, and the heterogeneity of skills, technologies, and ways of working employed, some companies and some teams cross these borders and face these multi-domain challenges more often than others, and they live with this reality.

Whether a hard border gets crossed, the approach described in the previous article becomes more relevant and useful: Agile Cross-Team Collaboration How-Tos.

The soft limits of shared work

The effectiveness of sharing product code ownership across multiple teams starts to gradually decrease when going beyond some soft limits, up to the point that other approaches start to become more advisable. These below are a few examples of soft limits.

• Team maturity: teams that share the ownership of the product codebase need to reach a consensus on the adoption of some common practices (for example it does not work if one team writes automated tests and another team makes code changes breaking the automated tests and not fixing them). When a new team can’t adopt some of the practices already in use in the codebase learning must happen. Meanwhile, they may not be 100% productive right away in changing the shared codebase, but they must gradually learn those skills and only make changes they can with their current skills.
  
• Cross-cutting concerns: some product changes may involve concerns that cut across the whole codebase and so involve most of all the teams. Think, for example, of the changes to fix the Year 2000 bug, efforts for product internationalisation and localisation, product accessibility, or compliance with GDPR. It may require a massively large feature change where the patterns mentioned before such as Leading team, Travellers and Scouts begin to be insufficient.
  
• Politic and authority: the teams and the product codebase may cross the authority lines of the managers willing to
  share the codebase and its responsibility and agree to common technical practices. Efforts are necessary to build bridges and trust relationships across these formal lines. 

Whether a soft border gets crossed beyond the point where the shared product codebase ownership remains an effective approach, the approach described in the previous article becomes relevant: Agile Cross-Team Collaboration How-Tos.

All in all, should shared work be embraced or avoided?

When thinking about collaboration inside a good Agile team, what usually comes to mind is a very positive and fulfilling professional and social experience. An environment where people constantly learn from each other, experiment, achieve more than they thought they could, enjoy the energetic creativity of the group, and succeed together.

Some of those who experienced being in a good Agile team did not want to go back anymore.

Some of those who tried synchronous collaboration – for example, working in pairs or mob/ensemble programming – did not want to go back anymore.

Shared work reproduces this same experience across multiple teams.

My personal experience and what I have learned so far

While I worked in the Ferrari F1 Racing team, we adopted an approach similar to shared work. With a number of teams in the ballpark of 5÷10 and a number of people in software development in the ballpark of 30÷50.

We were strongly influenced by Extreme Programming and its technical practices.

We worked on two distinct suits of products, the Trackside suite and the Production suite, each containing a number of different applications for the race and the home factory.

The codebase was about 10 years old, so it used older tools and technologies from that timespan, not only the latest and greatest. The size of the codebase was a multiple of what all the teams together could master. And we faced a multi-domain challenge involving other specialistic and non-software domains such as embedded software development, dynamic simulations modelling using Matlab Simulink, and Hardware in the loop simulation. We also faced the challenge of confidentiality for some information and domain details.

Most of the applications were mission-critical, and we worked in a fast-paced and high-pressure environment.

We faced the hard limits listed before and some soft limits too. Over time we managed to work around some of the hard limits, and the advantages were evident.

From a technical point of view, we used a one-repo approach with a very reactive Continuous Integration, Trunk Based Development, elements of Continuous Delivery including automated remediations plans (for example see https://www.infoq.com/articles/continuous-delivery-coding-patterns/).

The biggest challenge we faced with shared work was the size and age of the codebase, together with the complexity of the domains and the number of different technologies employed. We made an explicit effort to limit the number of different technologies added to the codebase to keep the number of skills required at a manageable level. And we made an effort to solve similar problems in various parts of the codebase in similar ways, to avoid unnecessary complexity. And we made an effort to make the code easier to read, understand, change and evolve.

In a context of time pressure and the need for quick reactions, regardless of our continuous knowledge sharing and skills learning, and our pair-programming and some pair-rotation:

– the size of the codebase,
– the number of applications,
– the complexity of the domains,
– the number of different technologies in the codebase

we felt at times that we were stretched too thin in terms of specialisation vs generalisation. Even if we avoided any catastrophic mistakes (the reliability of our delivery was pretty high) and we did pretty well, we felt each team could have done better given the opportunity to focus on one suite (trackside or production).
With Joseph Pelrine, to describe this situation, we came to the term “complexity budget”, which represents the idea of a maximum number of different programming languages, libraries, tools, codebase size, and business domain skills that a group of teams can handle effectively.

In conclusion with Shared work, we experienced an extremely effective, frictionless and enjoyable cross-team collaboration, and we reached high levels of productivity in a fast-paced and high-pressure environment where most of the applications were mission-critical. We felt we were operating at the boundary where more product areas, on top of the Trackside suite and the Production suite, could have been formally defined also for the related support activities.

The trade-offs between shared product codebase ownership and stream-aligned team codebase ownership

Based on my personal experience, I have drafted some of the trade-offs that I have experienced between the shared product codebase ownership and team codebase ownership, in both cases for autonomous teams capable of completing end-to-end customer-centric features.

Conclusions & links

Shared work has proven to be very effective, far beyond the point most believe it would stop working, and many Agile teams succeeded in adopting a shared work approach. Shared work can transcend painful cross-team dependencies in codebases with massive technical debt and therefore many accidental technical dependencies. It is very effective and helpful during the time needed to pay back the technical debt, separate concerns, and let the boundaries of the different domains and the APIs of different modules emerge. It also is the preferred option for new complex developments where the boundaries and the interfaces between the modules are still changing, evolving, and emerging.

In shared work, as in Extreme Programming, there is a strong social component, synchronous collaboration, team discipline and technical mastery. For those who like social collaborative learning, shared work makes it completely frictionless and enjoyable.

For those that experienced the pain of the failed recipes for scaling agile, shared work is the closest option to Chet Hendrickson’s view on the topic:

Since Agile is simple, a scaled version of Agile should also be that simple, or even simpler. Otherwise, it will no longer be Agile.

Even when shared work reduces the immediate impact of technical dependencies, technical excellence remains fundamental to make the codebase easy to learn and understand and to avoid exponential growth of the effort required to change or add functionalities. Teams should always start by cleaning up any mess and keep things clean thereafter.

You cannot be agile if you’re fighting your code and architecture to make every small change – Allen Holub

Links

Here are a few useful links:
– Feature Teams Primer: https://featureteams.org/
– Collective code ownership: https://www.agilealliance.org/glossary/collective-ownership
– Feature Teams structure: https://less.works/less/structure/feature-teams 
– Feature Team Adoption Map: https://less.works/less/adoption/feature-team-adoption_map 
– Technical excellence: https://less.works/less/technical-excellence

---

<< Part 2 (Part 3)

---