Scott Ambler is chief methodologist for IT with IBM Rational. I recently had the opportunity to talk to Scott about scaling agile for enterprise organizations, how agile affects leadership and requirements on large teams, and his Disciplined Agile Delivery framework.

Heather Shanholtzer: What are some of the reasons enterprise organizations are increasingly looking into agile development?

Scott Ambler: Organizations are adopting agile techniques to help them improve the return on investment (ROI) of their IT efforts, improve the value being delivered to stakeholders, improve quality, and improve time to delivery.  On average, agile does, in fact, appear to be delivering these benefits.  I run an annual IT Project Success Rate survey every year and, since 2006, we’ve found that agile approaches out perform traditional approaches, even at scale. 

Heather Shanholtzer: What are some of the major challenges to scaling agile to a large team and how can you help a team overcome them?

Scott Ambler: A lot of the mainstream agile advice is geared for smallish, near-located development teams.  This, luckily, is the majority of teams, so it’s a good niche to focus on.  But there are some larger agile teams, and you need to work differently to address the issues that larger teams face.  You are likely to invest a bit more effort in modeling, planning, and team coordination.  The way you organize your teams will also vary, perhaps you will take a feature-driven approach, a component/subsystem approach, or combinations thereof.  No strategy is right for all teams.

Furthermore, there is more to scaling agile as I make clear in the Agile Scaling Model.  In addition to team size, you have scaling factors such as geographic distribution, regulatory compliance, domain complexity, technical complexity, organizational distribution, organizational complexity, and enterprise discipline that may be applicable to some extent for each delivery team.  All of these factors will motivate you to tailor your process, team structure, and tooling strategy differently.  So, don’t underestimate the complexity of agility at scale!

Heather Shanholtzer: How are leadership and requirements management affected when an enterprise organization adopts agile practices?

Scott Ambler: It depends on what you’re currently doing of course, but, in general, agile practices require greater discipline, better collaboration, and often new skills in order to be successful.  When it comes to requirements management, agile teams may choose to adopt a range of techniques, including formal requirements management, Scrum’s product backlog, a more disciplined work item stack, a lean work item pool, or even no strategy at all.  There are advantages and disadvantages to each of these strategies, and no single approach is right for all teams.  Disciplined teams understand that they have choices and will choose the strategy that is most applicable to them. 

Heather Shanholtzer: You have developed a hybrid agile process framework called Disciplined Agile Delivery (DAD). Tell me a bit about DAD and what inspired you to extend existing agile processes.

Scott Ambler: The DAD process framework is a hybrid process decision framework for agile development.  Some of its features include coverage of the full delivery cycle from the start of a project to release into production, explicit support for enterprise awareness, and a goals-based approach.  

Agile project teams need to do some sort of project initiation, such as initial release planning, initial requirements modeling, and initial architecture envisioning.  Agile project teams also do work to release their solutions into production, work which typically includes end-of-lifecycle testing, fixing, announcing the release, and actual deployment.  So DAD includes explicit lifecycle support for this sort of stuff in addition to the usual construction-oriented activities of other agile methods. Enterprise awareness includes activities around working closely with enterprise professionals such as enterprise architects and reuse engineers (if you have any), explicit agile governance, and explicit support for DevOps throughout the lifecycle. The most interesting thing for many people will be that DAD is goals-based, and is far less prescriptive than even methods such as Scrum.  For example, one goal is to manage change on your project.  Empirically, we can observe that there are several strategies for doing so, which I described earlier, and they each have their advantages and disadvantages.  So, where Scrum prescribes a product backlog approach, the DAD process framework gives you options and provides advice for helping you to decide which strategy is best suited for your situation. 

Similarly, DAD provides a decision framework to address a host of other goals such as initial requirements modeling, initial planning, coordinating team activities (there are more options available than just daily Scrum meetings), integrating your work, and so on.   So, instead of assuming that everyone is a process expert who can tailor up methods such as Scrum and XP or tailor down methods such as Unified Process to meet their needs, DAD takes the middle road and describes your options and the tradeoffs surrounding them.  These options come from a variety of sources including Scrum, XP, Agile Modeling, Unified Process, Kanban, Outside-In Development, Agile Data, and many more.  

Heather Shanholtzer: I understand you have been conducting an ongoing survey into agile enterprise practices. How is that going? Have you been surprised by the results?

Scott Ambler: I run a series of ongoing surveys, and new surveys are announced at www.ambysoft.com/surveys/. Survey results, including original source data, are also published there.  The surveys are completely open and the results are being used by several graduate students in their thesis work.

Each time I run a survey there are always interesting and unexpected results.  I have data on how agile teams are succeeding at scale, including all of the scaling factors I mentioned earlier.  I have data showing that the majority of teams are, in fact, investing time up front doing initial requirements modeling and architecture modeling, regardless of what some people will claim.  I also have data showing that agilists are more likely to model than traditionalists, something I wouldn’t have predicted, and that the deliverable documentation is at the same level of quality as that produced by traditional teams.  I have data showing that some of the “cool” practices that everyone likes to talk about, such as test-driven development and continuous deployment, are nowhere near as common as you would gather from all the discussion around them, and many other interesting agile topics, too.

Heather Shanholtzer: How can readers learn more or participate in the survey?

Scott Ambler: I would love to have readers participate in the surveys, as it’s one of the best ways we have in this industry to cut through some of the rhetoric that’s flying around about agile approaches (both good and bad).  The easiest way to do so is to follow me on Twitter, @scottwambler, and follow the link when I announce a new survey.  Or you can keep an eye on my survey page.

Scott led the session Disciplined Agile Delivery: The Foundation for Scaling Agile at the Agile Development and Better Software conferences June 10-15, 2012.  The book Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise by Scott W. Ambler and Mark Lines is now available.  Visit www.ambysoft.com/books/dad.html for details.