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 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.
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.
| Reference: | The New AgileāMore, Please! from our JCG partner Gil Zilberfeld at the Geek Out of Water blog. |
