Customer Success Testimonial: Recovery is Everything

The recent Game Developer Conference (GDC) in San Francisco, California, is a surreal experience.

You'll see cyberpunks rubbing elbows with marketing execs, artistes drinking lattes with engineers, Battlestar Galactica T-shirts stretched over round bellies beside leather pants slung over slim hips.

"When I was first invited to this conference, I did push back," Scott Ambler admitted to Reg Dev during an interview after covering agile techniques and IBM tools such as Jazz Team Concert for use in distributed development by games developers.

"But then I thought about how brutally competitive the gaming marketplace is, how important it is for these developers in particular to deliver quality code, and how time-to-markets is absolutely critical - I mean, you miss Christmas and you're done. Well, after I thought about that, I realized that the gaming market is almost the ideal situation for agile development."

For Ambler, that typifies how agile is "crossing the chasm" and becoming more important to those building software.

Ambler might be right in terms of agile’s journey across the chasm: analyst Evans Data last year reported more than half of North American developers are using agile methods to some degree. That was reinforced this month as it emerged agile deployment numbers have doubled since 2005 to 17 per cent, with a total adoption rate of 56 per cent compared to 41 per cent.

Ambler, of course is best known for putting together a set of principles and practices defining what was called Extreme Modeling but changed to become Agile Modeling (AM) when it became clear the coder was describing a versatile approach that could be applied to the range of lightweight methodologies, as well as traditional heavyweight schemes. Ambler has written or co-authored 19 books, including Agile Modeling: Effective Practices for Extreme Programming and the Unified Process.

He joined IBM - home of the venerable Rational Unified Process (RUP) iterative development framework - just over a year ago as the agile development practice leader in Big Blue's methods group. He is the creative force behind both the Agile Unified Process (AUP), a simplified version of RUP, and the Enterprise Unified Process, an extension of the RUP.

Ambler made the change, he said, when it seemed clear to him that agile development was moving into the enterprise. "I was an object guy for years, and I remember when objects started crossing the chasm that all the big players won the game," he said. "I saw that happening with agile, too. I think the more complex and interesting work is going to happen among the bigger players."

Each phase of RUP address a different kind of risk: business, technical, implementation, and deployment risk, respectively. These phases allow for milestone reviews, which give stakeholders a chance to decide whether the project still makes sense. "It turns out that that's not just important for agile in the small," Ambler said, "but also for agile in the large, because at scale, your risks are usually bigger."

Ambler said that development teams within IBM use agile methods for small- and large-scale projects. For example, the Lotus SameTime 7.5 release - a big piece of software by any standard - was built by an agile team of more than 200 people. It was reportedly the most successful release of that product. The dev team working on the decades-old DB2 product is using agile techniques, too.

"That's a huge product," Ambler said. "It's being used around the world. Most of the major banks are running it. So you can't fool around with it. If there's a bad release of DB2, that news hits the front page of the New York Times the next day. Is it perfectly agile? Perfectly XP? No. But that team is striving to become as agile as they can, and they're getting there."

One of the most common questions Ambler is now asked about agile methods is, can they be applied to service oriented architecture (SOA)?

"My answer to that is, absolutely, but you need to take an enterprise approach," he said. "Chances are, the reason your organization is doing an SOA is to achieve higher levels of code reuse. They want to put up these services that a lot of apps are going to use. To do that, you have to look at the bigger picture. You have to get a handle on what the various systems are, what their potential needs are, and which services will provide for those needs. These are often cross-project issues that the agile methods don't talk about very much.

"This is the type of thing you see when you cross the chasm," Ambler said.®

Regcast training : Hyper-V 3.0, VM high availability and disaster recovery