The Sharpest Tools in the Shed

Agile developers find index cards, sticky notes can be as valuable as expensive tool suites in maintaining flexibility

By Alexandra Weber Morales

October 1, 2006 —

Google the words “agile tools” and you’ll scroll through nary a non-IT-related hit. From open-source options to start-ups and consultancies to longstanding ISVs rebranding themselves as agile, the software tool market has assiduously noted the power of agility in the eyes of its consumers.

But here’s a test: Which company outside the software industry has enjoyed increased demand due to agility, without even trying?

If you guessed 3M, you’re right. The maker of sticky notes—interestingly, the company agile consultant Mary Poppendieck modeled her vision of lean software development on—provides many of the paper-based tools agile developers rely on most. Now 3M has come out with sticky, sortable index cards that just may be the next big thing in agility.

A few brains, some cards and a whiteboard—is that really all agile teams need to get by? Conversely, are IT shops in safety-critical or audited industries slowed by their dependence on requirements traceability? Just as agility implies evolutionary product development, agile tool use, it appears, evolves from simple adaptations to complex systems.

U.S. LEADS ‘LEAN’ EFFORT
There’s no small irony in the fact that a movement that began with an emphasis on using IT to improve responsiveness to swiftly changing manufacturing demands should be associated with certain Luddite tendencies among software developers. In the early 1990s, U.S. government efforts to improve on-demand military provisioning and global industrial competitiveness pushed a wide array of companies into creating open standards for manufacturing, allowing parts designed in one locale to be created elsewhere rapidly and efficiently. By the time, nearly a decade later, the concept of lean or just-in-time manufacturing had catalyzed the software industry by way of the Agile Manifesto of 2001, the emphasis had moved toward highly social approaches to developing applications.

Indeed, the first Agile Manifesto value, “Individuals and interactions over processes and tools,” rallied developers to throw off the shackles of prescriptive and expensive application development tools. Many of the practices described by Kent Beck in “Extreme Programming Explained” were aimed at eliminating defects by writing tests before code—the opposite of the rampant “code and fix” mentality lamented by Steve McConnell in “After the Gold Rush: Creating a True Profession of Software Engineering.” And at such sites as Symantec’s American Fork, Utah, campus, Extreme Programming adherents boasted about the fact that they no longer needed debuggers or fancy IDEs.

Over the same period, open-source software became an increasingly important member of the high-tech ecosystem, changing programmers’ views of what should be community property and what should be commercial. As a result, most of the development tool set has become freely available, with a constant influx of new widgets as agile practices become more popular.

PROCESS OVER TOOLS
At first blush, agile teams tend to focus on the paradigm shift rather than the tool set—as well they should.

“I think that tools are of little importance in terms of having a successful implementation of an agile process,” said Jon Kurz, an application architect with Lincoln Financial Group in Arlington Heights, Ill. “The focus should be on the process itself. For example, regardless of the size of the team or the technologies used, it is important to have a solid source code management process. Being able to build and deploy in a robust, repeatable and managed way is also extremely important to the success of projects, but often overlooked. The build process itself could use Automated Build Studio [from AutomatedQA], BuildIt [from Microsoft] and FinalBuilder [from VSoft Technologies] or something homegrown, but this is necessary to allow the team and customers to have a high degree of confidence in every release of the product.”

According to Scott Ambler, prolific author and practice leader for agile development with IBM Rational’s Methods Group, “Agility and tools are pretty orthogonal. I can use most development tools in an agile manner as well as a very nonagile manner. For example, although agile developers use JUnit to take a test-first approach to programming where you write a single test and then just enough production code to fulfill that test, what’s stopping you from writing 10,000 tests up front before writing a single line of production code? Absolutely nothing, other than perhaps sanity. Similarly, even though data modeling tools seem to be commonly used for traditional, big design-up-front efforts, I’ve worked on agile projects where I used them to evolve the database schema throughout the development project. It’s typically a matter of choice, once you understand that you actually have a choice.”

Ambler’s March 2006 Agile Adoption Rate Survey (www.ambysoft.com/surveys) of 4,232 developers found that, of the

41 percent who had adopted agile methods, Extreme Programming (XP) and Scrum were the most popular by far. While the latter has more of a project management focus, XP is packed with engineering and scope-defining practices, many of which are tracked on paper. Such “information radiators” as posters and cards are critical components, according to Matt Gelbwaks, former chief agilist for Borland Software (“We invented that title at Borland,” he said) and now chief agilist at VA Software, maker of SourceForge.

“The best way to teach anyone to do agile is to use 5x8 colored index cards, very graphically and physically, in a small room. The approach that I took at Borland was, you get people into a room and you level-set. Then you go through the planning game or doing a couple of iterations with cards. Once people begin to develop that muscle memory, then you look at the tools and ask, ‘What can we do with what you have?’ In some cases, you find you just can’t use them. Then, I usually end up picking the short straw and going to the CTO and saying we need something different. The tools are what make the team efficient,” said Gelbwaks, who boasted that his “very checkered past includes dabbling in every single methodology that has been invented.” But are some tools—say, for requirements management or modeling—inherently anti-agile?

NO TOOL TOO BIG OR SMALL?
“All version control systems are not created equal. Some, such as [open-source] Subversion or CVS, are much more in line with continuous integration and constant check-in. Ones like [IBM Rational’s] ClearCase, however, are at the opposite extreme—the opposite of agile. They want to predict everything up front,” said Glenn Bernsohn, formerly a senior project manager and agile coach at ThoughtWorks in Chicago. “My experience has been that the smaller the team, the less tooling you need. The larger the team, the more you need.”

Gelbwaks, on the other hand, is much more willing to give the tool the benefit of the doubt. At Borland, he worked with the company’s own suite of software development life-cycle tools—“And the suite was never designed to do anything agilely”—while Borland undertook Scrum across its entire 400-person R&D organization.

An article by Gelbwaks in the July 2006 Cutter IT Journal, “Feature This: Transforming Borland’s Development Process With Scrum,” describes Borland’s use of its own Caliber RM requirements management tool in an agile context—a concept that seems counterintuitive to those agilists who prefer to discover requirements iteratively rather than define them all initially. Project management is simply the management of the life cycle of requirements, according to Gelbwaks, and requirements need not be permanently chiseled in bits. Surprisingly, the first agile group at Borland was the Caliber development team, with three-quarters of its members based in Russia and the remainder in Atlanta. British Telecom, in another example, adopted Borland’s collaboration tool StarTeam because it was already in its arsenal—but in an agile maneuver, British Telecom’s developers used an API to pull out data to generate burn-down charts and other agile metrics.

In a similar fashion, in his new role at VA Software, Gelbwaks is focusing on the fact that SourceForge manages the requirements and the components of the requirements—understandably, given its open-source origins. “In the open-source world, you take your stuff down, work on it and put it back up. It’s a hugely distributed agile environment. Now, it’s hard to pair program with yourself, but lots of open-source stuff has one or two people working on something simultaneously. You’re not only distributed in space, but in time.”

Tool use does change in agile teams, IBM Rational’s Ambler concurred, “particularly from the point of view of a traditionalist. Many traditional development tools reflect the mindset that specialists hand off work to one another in a nearly serial manner, whereas agile tools reflect the mindset that developers are ‘generalizing specialists’ working in an iterative manner. For example, there are a lot of really great traditional data modeling tools out there, which are based on the idea that a data modeler will create a comprehensive model from which to generate a database schema for the development team. This sort of tool works well in a traditional environment but proves to be ineffective in an agile environment.” Instead, Ambler said he sees agile developers using an IDE such as Eclipse or Microsoft’s Visual Studio, both of which provide modeling, testing and programming functionality in one tool.

“These tools are incredibly effective for generalizing specialists, people with one or more specialties plus a general knowledge of software development, who pair together to implement high-quality, working software in an evolutionary manner. They’ll use these tools to do just enough agile modeling, just enough test-first programming, and just enough production coding to implement the current requirement that they’re working on. It can be the difference [between] night and day,” Ambler said.

THE METRICS THAT MATTER MOST
In his recent work as a consultant employing SourceForge Enterprise Edition with IT shops that were agile tyros, Bernsohn found the tool to be methodology-agnostic. In order to configure SourceForge to support agile teams, he linked stories (units of work, or use cases) to their related automated tests, and also created tracker objects that mapped to stories and prompted stakeholders for necessary update information.

“There are two parts to a story: the story itself and the metadata, such as the estimate, who created it, when it’s due, and so on. The document repository was useful for storing the stories. The other thing I did was to create an agile template using the wiki that’s built in to SourceForge.” The only missing piece, according to Bernsohn, is reporting. To solve that problem, they built a plug-in that downloads the metadata from SourceForge to an Excel spreadsheet.

It’s important to keep quite a few metrics about the progress of agile teams, Bernsohn advised, to counter the many myths about agility: “People usually pick the easiest part of it, like iterations and standups. People tend to ignore the engineering practices, like test first, continuous integration and pair programming.” Tracking code coverage, velocity and unit tests provides concrete insight into the team’s progress—or lack thereof. If, for example, unit test numbers are not trending up from one iteration to the next, that means either the team isn’t writing new code or new tests—or that the code isn’t easily testable.

The other metric Bernsohn likes is more complicated, he warned, but is important if one of the goals of lean programming is to eliminate wasted effort. That statistic looks at the lifespan of a story. “When does a business analyst start writing a story, when do the developers look at it, when does QA test it, when does the customer try it? Is it a week, is it six iterations later, is there a backlog? We want to do things just in time. If the stories are getting written too early, that’s a problem. We want to know how long things are in cycle. You won’t see that in the basic XP books.”

As agility has matured, the focus on useful metrics has grown. Bernsohn has observed that, as teams mature, they too begin to gather more comprehensive information about their progress—and that’s a move that sounds suspiciously like it’s stolen from Carnegie Mellon University’s Capability Maturity Model. Be that as it may, spreadsheets, cards and wikis can all help track and motivate collocated team members at a glance. On the other hand, “if you have a team that’s distributed, the wiki helps a lot, but the spreadsheet starts to break down because it’s a one-person tool. But every single team I was on, distributed or not, still had a story card wall, somewhere, because the developers want to see what’s happening in this iteration.”

THE 30,000 FOOT VIEW
Some argue that you can tell how successful an organization will be in adopting agile methods by the tools it already owns: A company replete with licenses for a Borland or IBM Rational suite will be staid and slow-moving, so the conventional thinking goes, while one that embraces SourceForge or the open-source XPlanner will be toying with agile concepts from the get-go.

Regardless of the development team’s predisposition, according to chief agilist Gelbwaks, “in any organization you need someone responsible at the highest level for the methodology, because how you do things has a direct effect on what it’s going to cost. Also, when an organization decides to move to a new paradigm, it’s very scary—people don’t want to endanger themselves or force themselves to learn something new.”

While agility to date has focused on practices primarily designed to improve the quality and responsiveness of software development, there has been little effort to extend that concept upward in the IT world. This is where a new class of tool, portfolio managers, can be extremely valuable, said Gelbwaks.

“I’ve been trying to get people to look at portfolio management tools at the agile level. There are all these articles asking what is the earned value of your agile projects. You should look at your projects as being akin to a release. Get your CIO looking at it the same way a product manager would,” he said. Rather than viewing software projects as sunk costs, portfolio management tools can help ascertain what’s delivering the most value to the business as a whole.

If a company is faced with the choice of augmenting its call center’s functionality or adding competitive features to release 2, such a tool can help evaluate how much money either scenario will generate. “We’re very adept at doing that at the project level, but we don’t do that at the portfolio level. In my experience, both of the budgets are cut so they can do half of each,” said Gelbwaks.

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

Guest View: Software development Darwinism Developer tools have come a long way, so what else can they do to improve their capabilities?

Business Briefs: September 15, 2008 Google decides to sell off its Performics division to the Publicis Group, while Hewlett-Packard acquires Colubris. Also, Microsoft and Novell have decided to expand their 2006 interoperability agreement.

Why Commercial SCM Tools Are Better Than Open-Source Tools Your organization has a core competency that has a direct bearing on your competitive advantage. The more of your time...

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