Years ago, I wrote a book on ATDD. Only years later I notice the value that this practice can bring to an environment with multiple teams working together on the same platform. The connection to scaling agile in the larger enterprise wasn’t that obvious than it became when I started to dive deeper into how to scale agile. Though, most larger enterprise struggle with getting one team running, scaling has become the latest fuzz in the agile community. Let’s see why ATDD is relevant for this sort of environment, and how you can challenge your team colleagues about it.

Continuous Integration

In XP explained second edition Kent Beck writes about different practices from extreme programming, and raises the concern that some practices need certain others to become more successful. There are a bunch of practices that I consider crucial to have in place before you will receive crucial benefits from implementing ATDD.

For example, you should have an automated build in place. A couple of years ago, I was working with a team where this was an issue. I really hope that nowadays programmers have proper coding practices in place to no longer rely on their IDE alone when it comes to building their software system.

But even more relevant with ATDD is to have proper continuous integration in place. What is continuous integration? Continuous integration does not necessarily involve a continuous build system. Continuous integration means that you integrate your working environment with the source code repository regularly. Continuous integration brings transparency to your colleagues that work on the same system.

A few years ago, I worked with a client where we had to deal with some confusion around continuous integration. It appeared that some programmers thought they needed to have a build pipeline in a build system. If you use a CI tool to have a working build environment, and you can’t reproduce those build steps on your programmer machine, then you are doing something wrong.

Integrate early, integrate often. Often means that you should be able to check in your code more than once per day. Usually that is already a large problem in most environments that I have seen. And these problems are solvable. They need discipline from the programmers, and they necessitate a paradigm-shift for most programmers in more traditional environments.

When I was a swimming trainer, I learned about the concept of over-correction. Maybe that’s why us programmer coaches challenge programmers to be able to check in their changes every two minutes – simply because so many programmers are so terrible at this.

Conway’s Law and bounded contexts

Now, think about a multi-team environment. With multi, I mean 20 teams working on the same code base. There are probably a couple of team members working on the same foundation. And they check in their changes a couple of times per day.

Ouch, that might cause a lot of trouble. Right.

In order to help these team members coordinate between each other better, you need to have good coding practices in place if you want to overcome Conway’s Law. Conway’s Law?

Malcolm Conway described this law in 1968. He reported about two different teams he had observed. One was developing a COBOL compiler, the other an ALGOL compiler. The COBOL team consisted of five team members, and the resulting compiler had five phases. The ALGOL team consisted of three members, and the resulting compiler had three phases.

Interesting.

If you want to avoid that your software architecture replicates your organization architecture, then you need to be able to work on the same basic building blocks. In domain-driven design Eric Evans talks about so called bounded contexts in which you solve the business problem in a separate building block. You also re-use pieces supporting contexts – like a commonly used infrastructure.

If 15 of the twenty teams work in parallel on these same supporting infrastructure, chances are high that they change similar portions of the code. This raises the question how to avoid integration conflicts? And how do you avoid that you break a particular functionality in an unfamiliar bounded context of another team?

The answer is that you need something that transports the tacit knowledge of the other code base to your environment.

ATDD

Enter ATDD. With ATDD you document what your particular piece of code should solve from a business perspective in a way that other teams might understand. After you identified different business scenarios, you automate these. The more and more you execute these business scenarios, the more they become the documentation of your software.

This documentation will be up-to-date as long as these tests run successfully. They will document the underlying assumptions about your bounded context, and they will make some of your tacit knowledge explicit for other team members and teams.

That is also why these automated acceptance tests will help you solve the problem of multiple teams working on the same code base. They no longer need to guess how to solve a particular problem they introduced for another requirement area when adapting a particular functionality in the supporting domain. They will be able to execute the same set of business scenarios that you used when you introduced the feature a couple of iterations back.

Thus, in a multi-team environment, given some disciplined practices in place, you will be able to use ATDD to coordinate between teams, and find important problems quickly.

So, make sure that you have proper continuous integration in place before starting with ATDD. You should be able to commit your changes to the production multiple times per day. If you are not yet able to do so, fix that problem in your development process first. Otherwise you won’t have the transparency soon enough to trigger the right set of actions when you break some unknown code. Problems will crawl in unnoticed until it is too late. You will become more defensive with your coding practices, and slow down since you have lost trust in many of your changes. Don’t go down that path.

When you get started, be aware that you will collide with some of your colleagues – maybe even oftentimes per day. Remember that this is good. You notice problems before shipping your code. That is good. By feeling that pain, you now know better where improvements could provide better results. Use that input instead of fighting it.

All that these pain points are really telling you, is where your current team setting is causing a lot more coordinate overhead. You have to deal with that because you haven’t (yet) found a way to deal with it better. Sit together with the teams that you oftentimes have conflicts with, and try to find a solution to these problems instead of fighting and hating each other. Your software will benefit from it, your product owners will benefit from it, and your customers will benefit from it.