Agile development: Built to scale

By David Rubinstein

June 15, 2009 —

The notion of agile development by now is well known for most every responsible CEO and CIO. With the economy stuck in low gear, organizations need to find ways to shorten development cycles and improve quality, all with the resources they already have on hand.

The Agile Manifesto, which spells out the ideas and practices for its implementation, was written in 2001, and in the eight ensuing years, many organizations have taken the first steps toward agile development. By now, many have had successful projects done by designated agile teams and have realized the cost savings and time-to-market benefits that agile espouses.

Now, these organizations want to reap bigger benefits by bringing agile out of its silos and into a wide deployment, across geographical locations, time zones and language barriers. Yet among the Manifesto’s 12 core principles are that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation,” and “business people and developers must work together daily throughout the project.” And there’s the one about “individuals and interactions over processes and tools.”

Those principles would almost seem to inhibit the adoption of agile processes in a large, distributed development organization. So how do organizations scale their agile practices to get a bigger payback?

Not to scale?
Robert Holler, CEO of agile project management software maker VersionOne, took a step back to answer that question. “There are challenges with scale. The problem’s not unique to agile or to software development,” he said. “Scaling is just tough. Sometimes agile gets a black eye for not scaling, but it’s more like, ‘Development doesn’t scale.’”

And Paul Hodgetts, lead consultant at Agile Logic, said that planning before embarking down the agile path is critical.

“There’s no way to get a big organization behind something like this without first thinking it through," he said. "‘Why are we doing this? How will we get everyone on board?’ You must show them a way to get from point A to point B that won’t make their lives miserable for the next 12–18 months.”

Too often, he said, organizations fail and blame it on the methodology. “They say, ‘We tried to implement agile, but we didn’t plan or learn about it, so it didn’t work, so agile sucks.’”

Holler agreed that the foundation for agile must be built before adoption can be successful. Among the factors organizations need to assess are whether the educational base to scale already exists. If the answer is no, the organization must decide if it is willing to bring in the expertise. “If not, it’s an impediment,” he said.

“People say, ‘We want to scale but we don’t want to invest’ in education. That won’t work. [Education] is a fundamental tenet of success.”

Another fundamental issue for enterprise-wide agile development is buy-in. If you can’t get everyone in the organization to agree with the approach, success will be impossible to achieve, said Hodgetts.

“Agile is hard and it takes a lot of commitment," he said. "Every enterprise implementation I’ve seen is a roller-coaster ride. They implement it in one team, see some productivity improvements, better quality software, and then that the people are happy. But when they try to bring it wider, they stir things up—maybe they move people off the successful teams to coach newer people—and they might actually lose productivity for a time.

“As an enterprise, you’ve got to be prepared to live through a number of cycles like that.”

In practical terms, though, scaling across a large, distributed organization poses several challenges. The tried-and-true methods of developing in pairs in the same room, and using a whiteboard at daily standup meetings, or even having those meetings, don’t carry over to teams that are geographically dispersed and working on an around-the-world, 24-hour schedule.

Enter the tools
The original 17 signers of the Agile Manifesto were mostly consultants and developers; as a result, the notion of small, co-located teams doing pair programming and constantly engaging the customer were top of mind. To go with this, a number of excellent point solutions were created for continuous integration, for functional and acceptance testing, and for managing change.

But these solutions optimize parts that can be leveraged by small teams, leaving organizations to do a lot of toolsmithing to integrate the pieces into an enterprise-scale solution, according to Scott Ambler, the practice leader for agile development at IBM.

“The overarching platform has to provide value for developers, or they won’t use it,” he said. “Continuous integration is great. Testing is great. But they’re having to do a lot of toolsmithing to make it work.”

On a management level, automated metrics offer tremendous value, he said. “Manual metrics is a lot of wasted effort. You need a coherent metrics program in place or you’ll have problems adopting agile in a meaningful way.”

IBM’s Rational Team Concert provides an integrated tool set for the agile life cycle, Ambler said. Rational Requirements Composer offers lightweight agile modeling; Quality Manager tackles usability and security issues while managing parallel testing efforts; AppScan—though not yet based on IBM’s Jazz technology—offers security testing for Web-based applications; and Software Analyzer is a static code analyzer that keeps agilists more focused on quality.

Ambler acknowledged there are “some great open-source tools” out there, but at the end of the day, “we see team after team spending so much time on integration. They should be developing applications for their own organization. Doing all this toolsmithing is not a great use of their time.”

Tools should not lock a user into a particular discipline, cautioned Ryan Martens, founder of agile project management software provider Rally Software. “It’s more about picking a partner that keeps you on the path” toward a mature agile process, he said. “Otherwise, you end up with a heavy process that’s not well lined up with agility.”

Rally’s software, simply called Rally, focuses on project planning and management, Martens said. The software integrates with development tools for Eclipse, .NET, scripting and embedded projects, he pointed out, and also lets organizations assess their agile prowess and bring in elements of coaching and training. “There are a lot of choices available at the development tool level. We don’t provide tools for individuals. Those pieces get integrated with our products,” he said.

Borland Software, which is the target of an acquisition by Micro Focus, transformed its in-house development to agile at the end of 2006. The company has development centers in Austria, Australia, Singapore and Santa Ana, Calif. To achieve its goal, the company created Borland TeamFocus, an electronic team board that enables project management.

“We built out team rooms and use projectors for virtual corkboards,” said Chuck Maples, senior vice president of research and development at Borland. “You can click on the corkboard and create tasks, and then drill into those tasks. It was all designed with an enterprise agile model in mind. It’s been very successful for us. We’ve improved quality, shortened our release cycles and increased the predictability to the business.”

VersionOne is also focused on project planning and management with its V1 software, and it now has Java and .NET SDKs to allow integrations with organizations using those technologies. In late May, the company announced V1 will include IdeaSpace, modeled after Salesforce.com’s IdeaExchange, for high-volume tactical planning, prioritization and collaboration, VersionOne's Holler explained. “There’s nothing like an economic downturn to deliver some new functionality,” he quipped.

IdeaSpace, written by VersionOne to tightly tie in to its agile platform, is a place for the business side and developers to write stories and get feedback from customers. It supports multiple forums, with security, and lets managers see who’s generating the most requests and who’s responding the most, as well as other information for use in the planning cycle, Holler said.

OutSystems offers agile platforms for an on-premises development, delivery and operations management environment, and Agile Network as software-as-a-service for managing agile projects, including training and forums. Among the important features of the software is a sizing and scoping tool that leverages user stories to define the scope of a project, so an accurate budget can be generated, according to Mike Jones, vice president of marketing for OutSystems, which has more than half of its customers making changes to and building custom packages for SAP environments.

One of the keys to the OutSystems platform is the “true change engine” built into the platform’s model-based repository environment, which enables users to understand the impact of a change to the code and provides self-healing impact analysis; it either fixes a problem or reports on it. Further, Agile Network provides a place for end users to insert comments alongside a running application, and developers can launch the code underneath that submission screen to make the change, Jones briefly explained.

“End-user acceptance flies through because it’s been so vetted by that point,” he added.

To scale for the enterprise, Jones said OutSystems found it had to break some Scrum-type roles to leverage remote resources. “We split the traditional role of Scrum Master into an engagement manager, who’s always with the customer, understanding the feedback, setting expectations and leading the demo at the end of every sprint; and a delivery manager, who is where the development team is and who owns the architecture, the application, and who’s responsible to set the scope and deadlines,” he said. “The two managers work together to facilitate collaboration between the in-house and remote resources.”

Respecting the process
Even with tooling, Agile Logic’s Hodgetts said the agile advocates within large organizations get that it requires a change in their approach to development. “You can’t just purchase agile and install it and be done with it,” he said. “You can’t just buy VersionOne and say, ‘I’m agile,’ or hire Paul [Hodgetts] for three training sessions and say, ‘Now I’m agile.’”

There are some common themes that most agree are the first steps down the road to agile development: running in shorter cycles, higher visibility, and worker collaboration. “Getting those cores in place are critical to success,” Hodgetts said.

The question of scaling agile for enterprise-wide development is no longer a question, according to Rally’s Martens. “The question now is, how good do you want to be, by when, and who’s the best partner to get you there?”

Related Search Term(s): agile

Share this link: http://www.sdtimes.com/link/33552

Guest View: The half-agile path leads nowhere While businesses are taking on agile and adopting its practices, an incomplete implementation does more harm than good

From the Editors: Agile isn't an all-or-nothing choice The editors say that shops should go their own way re: agile, and that mobile development gains from two main competitors

How agile are you? The more agile is adopted, the more debate there is on what it means to be truly agile, and whether pure beats pragmatic

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST