Originally developed with small teams in mind, Agile methodologies are now being used for teams of all sizes. At...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
the Agile 2011 conference, well-known Agile expert Scott Ambler will be presenting The Agile Scaling Model (ASM): Be as Agile as You Need to Be. He’ll describe how to tailor your Agile strategy taking into account eight scaling factors: team size, geographical distribution, domain complexity, organizational distribution, regulatory compliance, organizational complexity, technical complexity and enterprise disciplines (such as enterprise architecture, reuse, and governance).
SSQ: Can you explain a little more about what the Agile Scaling Model (ASM) is? For example, is it a document that will recommend practices or techniques based on the eight scaling factors?
Scott Ambler: The Agile Scaling Model (ASM) is a contextual framework for effective adoption and tailoring of Agile practices to meet the unique challenges faced by a system delivery team of any size. It also distinguishes between three scaling categories (Figure 1):
- Core Agile development: Methods such as Scrum and Agile Modeling are self-organizing, have a value-driven system development lifecycle (SDLC), and address a portion of the development lifecycle. These methods, and their practices, such as daily standup meetings and requirements envisioning, are optimized for small, co-located teams developing fairly straightforward systems.
- Disciplined Agile delivery: This category includes several Agile methods, including Dynamic System Development Method (DSDM), Harmony/ESW, and the Disciplined Agile Delivery (DAD) process framework itself. These methods go further by covering the full software development lifecycle from project inception to transitioning the system into a production environment (or into the marketplace as the case may be). Disciplined Agile delivery processes are self organizing within an appropriate governance framework and take both a risk and value driven approach to the lifecycle. This category is focused on small-to-medium sized teams which are near-located delivering fairly straightforward solutions. To address the full delivery lifecycle, organizations need to combine practices from several core methods, or adopt a method which has already done so.
- Agility at scale: Focuses on disciplined Agile delivery where one or more scaling factors are applicable. The eight scaling factors are: team size, geographical distribution, regulatory compliance, organizational complexity, technical complexity, organizational distribution, domain complexity, and enterprise discipline. These factors are ranges, and not all will be applicable to any given project. Organizations need to tailor their disciplined Agile delivery practices and in some situations, adopt a handful of new practices to address the additional risks that come with scale.
SSQ: I know there are many tools that help foster collaboration for geographically dispersed teams. Do you think teams which are co-located would also benefit from these types of tools? Do you believe they would hinder face-to-face communication and create unnecessary work or might they allow for more flexibility with an occasional team work-from-home day, for example?
Ambler: One of the strengths of the ASM is that it explicitly calls out the eight scaling factors-- there’s far more to scaling Agile than dealing with team size and geographic distribution. For example, a team may be co-located yet find itself in a regulatory compliance situation. So yes, that team would benefit from the improved tooling as we see on the Jazz platform as those tools are instrumented to automatically gather information to support compliancy.
One of the strengths of the DAD process framework is that it promotes enterprise awareness on Agile teams. The rhetoric that any of the senior management “chickens” can attend your daily coordination meetings to find out what’s going on in your project plays well to developers, but it’s completely unrealistic in the mid-to-large sized organizations. Once again, the instrumented tooling of the Jazz platform, and other IBM tools for that matter, feed project and portfolio-level dashboards on a real-time basis, supporting accurate, timely, and cost-effective information which senior management can use to govern Agile project teams effectively. My experience is that Agile teams prefer to be governed effectively, and they prefer to not have to invest a lot of time collecting the metrics which enable that. So yes, more sophisticated tooling definitely helps.
SSQ: Does the Agile Scaling Model start by using a specific Agile methodology such as Scrum or XP as a base, or is it about creating a custom Agile solution different from any of the current Agile methodologies?
Ambler: The first step to scaling Agile strategies is to adopt a disciplined Agile delivery lifecycle which scales mainstream Agile construction techniques to address the full delivery process, from project initiation to deployment into production. Mainstream strategies (such as Extreme Programming (XP) or Scrum, which the ASM refers to as core Agile development strategies) are a good starting point, but need to be supplemented to drive meaningful results. Organizations must either combine and tailor them to address the full delivery lifecycle or start with something like the DAD process framework (for IT project teams) or Harmony/ESW (for systems engineering teams) which has already done this work.
Read part two of this interview.