"If you want to create an Agile organization, you can't rely on stacking the deck with your best staff members -- everyone needs to make the transition, not just your star players."

Opening Statement

DISCIPLINED AGILE DELIVERY: THE FOUNDATION FOR SCALING AGILE

This issue of Cutter IT Journal is a follow-up to June 2013's "Disciplined Agile Delivery in the Enterprise" issue. That edition of the journal covered strategies for bringing greater discipline to Agile software delivery teams, while this one focuses on how to scale disciplined Agile approaches. The term "scaling Agile" has at least two distinct definitions, both of which make complete sense. One vision focuses on adopting Agile techniques across an entire IT organization and ultimately instilling Agile behavior in the enterprise as a whole. The second vision focuses on how to apply Agile techniques in complex situations, in geographically distributed teams, or in regulatory regimes. Some people mistakenly believe these situations are outside the purview of Agile, but that's clearly not true in practice. In this issue, we explore these visions and show that both are key aspects to truly scaling Agile.

Scaling Agile Across the Enterprise

The first vision for scaling Agile concerns how to adopt Agile strategies across an entire IT department and eventually throughout the organization as a whole. This requires you to adopt Agile delivery techniques in most if not all development teams. This is much more challenging than simply cherry-picking "Agile friendly" teams, because if you want to create an Agile organization, you can't rely on stacking the deck with your best staff members -- everyone needs to make the transition, not just your star players. When scaling Agile to the IT department, you will need to adapt all IT activities to achieve true agility (see Figure 1). Your Agile transformation efforts will need to take into account how your enterprise architecture, portfolio management, operations, data management, and many other teams work together. Furthermore, your IT department is just one group within your overall organization, so a true Agile transformation will require new behaviors within the business, too.

Figure 1 -- Activities within an IT organization.

When helping to transform organizations to become Agile, my associates and I use something we call the P³ Change Framework. The idea is that when making a transformation, you need to consider people, process, and product factors -- a slight rewording of the people, processes, and tools strategy from the 1980s. Each of these change factors has subfactors:

• People encompasses skills, mindset, and culture.

• Process encompasses practices, principles, and lifecycles.

• Product encompasses both tools and platforms.

Although they use slightly different terminology at times, in the two articles I've chosen for this topic, you will see how the authors found the need to address all three change factors in some way.

The first of these two articles is written by Alan W. Brown, author of Global Software Delivery: Bringing Efficiency and Agility to the Enterprise, former IBM Rational CTO for Europe, and now a professor at the Surrey Business School in the UK. In the article, Brown argues that enterprises require greater openness and agility to be more innovative in the marketplace. He describes how the Disciplined Agile Delivery (DAD) framework provides the most realistic approach to Agile software development for enterprise-class environments. However, he warns that organizational culture and inertia will choke off the benefits of Agile unless you specifically deal with them. The article focuses on how to build an Agile organization, exploring the ways the technology, processes, and people will be affected. Regarding the people factor, Brown's experience is that you need to get the right people, promote greater collaboration between them, align responsibility and accountability, and then strive to steer instead of control (a key plank in DAD's approach to governance). On the technology/product side, Brown recommends that organizations adopt integrated development tools that support a business-led continuous delivery approach. Finally, he advocates such process improvements as moving from a development to a delivery focus, adopting Agile management techniques, promoting validated learning strategies, embracing innovation accounting, and adopting build-measure-learn cycles.

In our second "enterprise scaling" article, consultant Peter Herzum shares his experiences bringing Agile practices and software lifecycle automation into all of the development teams at Wolfe.com, a leader in the gift card and online prepaid domain. This Agile development strategy enabled the business itself to innovate, grow, and rapidly respond to change -- in other words, to become an Agile enterprise. This article isn't specifically about the adoption of a DAD-based approach, but almost all of the Agile practices that Herzum applied at Wolfe are encapsulated within the DAD framework. These strategies include adopting a parallel independent test team to support the "standard" testing strategies employed within the delivery teams, adopting a full delivery lifecycle that explicitly addresses architecture, transition/release practices, Kanban-based strategies, and development intelligence, to name a few. While Herzum calls this "Agile 2.0," my colleagues and I have called it "Disciplined Agile." Terminology aside, we as an industry are sharing similar learnings from different sources, and to me that's a healthy sign of progress within the IT community.

Scaling Agile Delivery for Complex Situations

The second vision for scaling Agile involves ways you can tailor Agile strategies within teams to address the complexities they face "at scale" in situations that require more than a single, small, colocated team. Many people relate this version of scaling to large teams, but there's more to it than that. As Mark Lines and I describe in our article, Agile approaches are also being applied by geographically distributed teams, by teams in compliance situations, by teams that are organizationally distributed (think outsourcing), and in situations where there is significant domain complexity or technical complexity. DAD's process goal-driven strategy provides the guidance that teams require to adapt their approach to the context that they find themselves in, enabling teams to work at scale.

All IT delivery teams are governed in some way, including Agile ones. The DAD framework provides explicit advice for governing Agile teams effectively, because many organizations run into trouble with Agile when they mistakenly apply traditional governance strategies. In fact, not updating your IT governance approach to reflect the realities of Agile solution delivery may be one of the leading causes of failed Agile adoption programs. In our fourth article, University of Bolzano researchers Saulius Astromskis, Andrea Janes, Alberto Sillitti, and Giancarlo Succi describe in detail how to enhance your governance efforts through automation. The authors focus on how to noninvasively measure what is occurring in Agile teams so that you can then identify potential improvements in your process. This sort of noninvasive measurement is called development intelligence (DI) in the DAD framework, and it supports both process improvement efforts, as described in this article, as well as governance in general. DI is a strategy in which a project or portfolio dashboard is automatically populated from data generated by tool usage. This is an important technique for enabling teams to understand what they are actually doing as opposed to what they believe they are doing. When implemented fully, DI provides senior management with accurate insight regarding the results of the team's work and thus allows them to govern more effectively.

One interesting thing about this article is how the team worked with tooling from multiple sources, most of which were open source. They in effect showed how it's possible to implement DI without requiring a single-vendor application lifecycle management (ALM) tooling solution. Another interesting aspect is the authors' discussion of how to analyze the data so as to visualize the existing process, thereby enabling the team to identify potential bottlenecks that need to be addressed.

Last but certainly not least is the article by Mindtree's Raja Bavani. Bavani begins by discussing the particular challenges of distributed Agile delivery and then works through 10 principles that he has found to be critical to success in these situations:

1. Methodology is driven by project teams.

2. Consistent usage of common tools improves productivity.

3. Infrastructure for communication and coordination is crucial.

4. Knowledge management is key to success.

5. Quality is multidimensional and owned by everybody.

6. Distributed Agile requires an inclusive approach.

7. Governance is the backbone of successful distributed teams.

8. Automation enables sustainable pace.

9. It is essential to streamline the payoff of technical debt.

10. Ensuring early success is a collective responsibility.

I believe that you will find this issue of Cutter IT Journal to be very informative. It is not only possible to scale Agile approaches, it is highly desirable. Enjoy!

ABOUT THE AUTHOR