Agility At Scale Requires Both Discipline And Creativity

Tom Grant

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?
Read more

Agile Development Makes Business Technology Come True; It Embodies Business Value In Software

Diego Lo Giudice

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.
Read more

Agile Teaches Us An Important Lesson About Innovation

Tom Grant

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:

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.

Read more

What Is The Value Of Agile In Your Organization?

Tom Grant

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

Starting around 2009, Agile moved into the mainstream of software development methodologies with startling speed. Today, Forrester’s data shows approximately 38% of developers have adopted Agile across a wide range of industries. The demand for Agile is so great that it has broken through many potential barriers, including ones such as compliance. As year-to-year growth of Agile adoption continues, it’s clear that a lot of teams are seeing a lot of value in Agile. But what kind of value? In some of our earlier surveys about Agile, it was clear that velocity was only one of several perceived benefits.

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.

Read more

Agile, Lean, & DevOps Share An Enemy: Complexity

Tom Grant

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.

Read more
Syndicate content