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?
There is no doubt that Agile growth in the market is significant, and the growing daily number of inquiries I’ve been getting on Agile from end user organizations in 2012 gives me the impression that many are moving from tactical to strategic adoption. Why’s that? Many reasons, and you can read about them in our focused research on Agile transformation on the Forrester website. But I’d like to summarize the top five reasons from my recent research “Determine The Business And IT Impact Of Agile Development” :
Quality was the top — quite astonishing, but both the survey we ran across 205 Agile “professional adopters” and the interviews across some 21 organizations confirmed this. My read is that this is about functional quality.
Change was second to quality. We live in an era where innovation strives and organizations are continuously developing new apps and projects. But your business does not necessarily know what it needs or wants upfront. The business really appreciates the due-course changes that Agile development allows, as they enable the business to experiment and try out various options so it can become more confident about what is really right for the organization. Cutting edge cutting edge systems-of-engagement (Mobile, Web-facing, Social-media, etc) require lots of Change in due course.
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.
Engineering methodologies have been around for a long time. They've not been noticeable for being terribly successful. They are even less noted for being popular. The most frequent criticism of these methodologies is that they are bureaucratic. There's so much stuff to do to follow the methodology that the whole pace of development slows down.
From: Forrester Analysts Tom Grant and Diego Lo Giudice To: App dev and delivery practitioners, especially ones with Agile experience Re: It’s time for us to take another look at the value adoption, and we’re inviting you to join our survey
For example, Scrum is far and away the most widely adopted flavor of Agile. Scrum focuses on how teams organize themselves and how they organize their work. For teams that have struggled to make accurate estimates or adapt to changes to the backlog, the attraction of Scrum isn’t just velocity.
Complexity is the nemesis of application developers everywhere. While software products' complexity may be, to a great extent, unavoidable, we don't have to complicate software development to match it.
That's the conclusion driving many of the new approaches that app dev teams are embracing. For example, Agile breaks down humongous, complex projects into incremental deliverables that are far easier to scope, build, test, and deliver. Lean practices simplify processes, making it easier for teams to achieve a state of flow. DevOps advocates are trying to eliminate the needless complexities that result from throwing software over the wall from one team to the next.
But there's more to Agile, Lean, and DevOps than just a common enemy. It's no accident that practitioners often speak of this trio in practically the same breath. The Kanban board is the symbol of this convergence of practices. Here's an increasingly common use case: an Agile teams uses a Kanban board to manage work with other groups, including the DevOps team.
The evidence for this convergence is more than just anecdotal. When we survey app dev professionals, they report that they're mixing methodologies all the time, including Agile and Waterfall. For a variety of reasons, Agile teams have made the adjustments necessary to accommodate Waterfall. Not every planning activity at the beginning of a project can be handled in a strictly Agile fashion, and not everyone involved at the end of the project (release management, operations, and business users) is necessarily sold on the idea of rapid, continuous delivery. If you work in a regulated environment, you're required to take extra steps at the beginning and end of a project.