A common question we analysts hear from our clients is, "How do we scale our Agile efforts?" Now, let's be clear: the question is not how to get Agile to work in a large project. Sure, there are challenges in making Agile work within big teams, but there's a much bigger concern. Organizations invest in Agile, or allow Agile experiments to blossom, and then try to capture the Agile magic in a bottle and mass produce it across the organization. 

That's an entirely different challenge, with ambitions and uncertainties that are both Texas-sized. (I'm in Dallas, so I'll use Texas metaphors. So shoot me. Wait, no, I take that back.) The uncertainties have many faces, including (but in no way limited to) issues like:

• How many projects or products should employ an Agile approach?
• Can we expect our outsourcing partners to use Agile as widely as we do?
• Do we need a common tools strategy to support Agile?
• How much diversity of Agile approaches within teams is a good thing, and how much is counter-productive?

Diego Lo Giudice contributed to this blog post. 

Agile Practices Create The Need For Other Practices
Agile is a big topic that goes far beyond a set of practices and principles. Change the development cog in the larger software machine, and you change how other parts of the machine operate, too. It’s a deliberately disruptive change that’s supposed to make the software development and delivery machine become more adaptable, produce a higher quality product, or satisfy some other goal that makes people willing to ride the tiger of disruptive change.

Lean helps sustain Agile while driving it in the direction of value, flow, team empowerment, and waste reduction. Other practices, such as continuous delivery and design-driven development, also complement, reinforce, and supercharge Agile transformation. 

As analysts, we might treat these developments as an excuse to write research that amounts, more or less, to a list of what’s hot and what’s not. Are more organizations taking a broader approach to DevOps challenges instead of just focusing on continuous delivery? Are Agile-friendly requirements practices, such as visualization, storyboarding, and serious games just a passing fad or permanent additions to the requirements toolkit? How many organizations have adopted test-driven development, and what are the barriers to adoption?

While these questions are important, and the answers more than a little interesting, they’re insufficient. Forrester is in the business of providing practical advice, not academic musings, so that software professionals can apply innovation strategies such as Agile and Lean immediately to the decisions they have to make today.

Organize These Practices Into A Playbook

The story of Agile is more than just one chapter in the history of software development. It's also an extremely valuable case study in innovation, an elusive and often humbling process that doesn't work in quite the way that we instinctively think it should.

The trajectory of Agile points toward increasing the value of the software delivered. However, it started with no metric of value and almost no notion of what happened outside the development team. Instead, the first phase of Agile, as I describe in the recent publication "Navigating The Future Of Agile And Lean," focused primarily on changing the behavior and world view of developers working together in a team. Therefore, you won't find anything in Scrum or XP that says, "This is how you know your software is better." Instead, these methodologies told you how to work more effectively as a team. Presumably, better results would follow.

In fact, the framers of the Agile Manifesto sought to change the whole notion of methodology, according to Martin Fowler:

Fiction writers I've met have said that the hardest section of a novel to write is not the beginning or ending but everything that happens in between. The middle chapters trace the course of the protagonist's struggle in way that must be both engaging and credible. The story of how people adopt Agile successfully also has a beginning, middle, and end. The middle part here, too, poses some of the most difficult challenges. The first chapter is a grabber, with teams energetically and fervently doing daily stand-ups, blazing through sprints, christening a product owner, prioritizing their backlogs, and living through all the other exciting events that happen at the very beginning.

And then the plot takes a different turn. Success at the small team level is fantastic, but how do you fit into a development organization? What if you need to work with an offshore team? How do you maintain velocity when builds take several hours or maybe even a full day? Is it possible to deal with compliance requirements without a significant amount of automation? How do you work better with the ops team so that the speed of deployment matches the speed of development?

Since Agile went mainstream, the number of teams reaching the difficult middle chapters of Agile adoption has increased markedly. Both I and my colleague Dave West answer questions about the middle phases every day. Many of these questions also arise during the yearly conference that the Agile Alliance holds in the US. (This year, it's in Salt Lake City to mark the tenth anniversary of the signing of the Agile Manifesto in nearby Snowbird.)