The current buzz at the agile world is scale. Now that we know that agile looks golden, we want to apply it to everything.

Agile started as a development team practice. Extreme programming, Scrum, Feature Driven Development, and others all originated in software development teams. Since they were successful, it made sense to apply those successes to other teams as well.

XP, like most early agile methodologies didn’t have that concept(and frankly, didn’t try to answer that too). If you wanted more capabilities, you had to have another team.  The first that tried to at least start to answer that was, of course, scrum. Like many things scrum did well, it tried to answer a business need, including the question about how to handle big projects. Scrum suggested the “scrum of scrums” idea, that didn’t happen to stick, but at least it had something.

As (few) years went by, another question was starting to come up: Not only do we need to manage multiple teams, but some of them are not co-located! The question did not just appear out of the blue. We had dispersed teams before, and they collaborated on email and phone. But now, in the new millennium, the internet helped with that collaboration. There were video conferencing tools, and skype, and cell phones. We had the technology!

Surely, it can help in solving team problems!

Don’t call me Shirley

There were (and still are) mixed answers. Some teams work together very well on different continents. Some teams don’t work very well, placed on different floors in the same building. We find time and again that tools can be great enablers, but  individuals and interactions come first (ah, the agile manifesto knows  best).

The current view is that things can be worked out to a certain extent, and besides, moving people around the globe is not possible, even if those agile guys say it’s better for the business. So distributed teams are no longer a problem to be solved, but situation we should learn to make the best of.

The next scaling step was how to execute big product decisions, and make sure execution is in alignment with the vision. Out of all the buzzwords, alignment is the one that matters more. It’s easy (sort of) to maintain alignment in a team of 8 people. How can it be done in a team of 200? How can we maintain an execution velocity over multiple team, and still have them all move in the right direction?

Note that this is not the first time the question is asked in the business world. We just expect an “agile” answer now.

The truth is we are still learning. Whether it’s SAFe (as it is now, or a future version), or something else, if any – we don’t know yet. SAFe has some good suggestions, but in fact is still too young to actually check long term effects on big organizations. We’ll see.

But wait, there’s more!

We always want more of a good thing. Feedback, for instance. More, quicker feedback is better.

If before we had continuous integration, that gave us quick feedback on quality, now technology brings us continuous delivery. Now we can deliver to production in a push of a button, (or an automatic trigger) and get the feedback directly from the customer. If we do it right, that is. With current technology and tools, we can deliver and deploy, as well as revert and fix problems. Having the tools is one thing, we have learned, we still need to be able to use them correctly.

If we’re talking about feedback, we should mention Test Driven Development. TDD gives us feedback that our code is working, and using test-first we specify how its interface should be called. But that was at the function level.  To get more, we got Acceptance Test Driven Development. ATDD gives us feedback that our code is now working for the customer, and by doing it test-first, we get that alignment we sought earlier: instead of developing things that the customer doesn’t need, ATDD shows us the way, and we develop that. As TDD gave us less YAGNI to worry about, ATDD scales that YAGNI.

Again, if we do it correctly.

Over the last 15 years, agile did not stand still. It moved forward and sideways, tried a few things and experimented a lot. Mixing the available technologies was part of agile growing up.  In the next chapters, we’ll dive into specific areas and see what kind of progress we made.