Scott Ambler is chief methodologist for IT with IBM Rational. Heather Shanholtzer 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.
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.