IT Employment

Rally Software: Agile development for the masses

One of Justin James' biggest problems with Agile development is that it requires a lot of hard work and thought to be successful. Find out how Rally Software's suite addresses these issues and more.

 

A recent trend in the development community is the push towards Agile development methodologies. I have been fairly opposed to these development techniques but, throughout the past year or so, I discovered that much of my information about Agile came from bad sources.

Agile is not about "Let's dump the PMs and BAs and get the programmer talking straight to the customer" (although in many cases that does happen). Agile is about trying to avoid the problems that lead traditional plan-based approaches to overpromised and under delivered results.

One reason I've learned a lot more about Agile is because I talk to the Spiceworks folks on a regular basis. Spiceworks has had great success combining Agile with crowdsourcing to get a connection between the development team and 250,000 users.

I have been consistently impressed with Spiceworks' approach to things, so I was struck by how much Rally Software reminded me of Spiceworks when I got the chance to talk to one of its VPs.

How Rally's suite addresses Agile issues and more

On August 7, 2008, I spoke with Richard Leavitt, the VP of Product Marketing for Rally Software. Rally makes software that manages the development of projects in Agile environments. Rally offers two versions of its software suite: the free Rally Community Edition for smaller teams and the Rally Enterprise Edition for larger teams and projects. I hesitate to call the software Application Lifecycle Management because Rally's suite covers so much more than ALM stuff traditionally does. At the beginning of my conversation with Richard, I was still skeptical yet open minded about Agile. One reason I was open minded is because a former coworker is having great success using Rally's software and described it in glowing terms.

Rally's PR team sent me a press release describing great efficiency gains in a study of five companies across a range of project sizes. (Note: CNET was one of the five companies.) The study used lines of code as the measure of developer efficiency and reported bugs as the metric for code quality. Any real-world developer knows that neither lines of code nor reported bugs are great measures. After all, lines of code could just indicate some really sloppy programmers, and reported bugs only make sense if the bugs are found.

Rally understands that working with Agile is not easy. This has always been one of my biggest problems with Agile -- it requires a lot of hard work and thought to be successful. Richard talked to me in depth about how a lot of Agile shops have a hard time: staying close to shippable code, being willing to change requirements, and bringing the QA people and processes in as a full-fledged part of the development cycle. Rally's suite addresses these issues and more, with a focus on planning, tracking, and collaboration.

"Software is a team sport." -- Richard Leavitt

In Richard's words, Rally's attitude is, "Software is a team sport." I definitely agree with this mentality; I think most of us have seen first-hand how miscommunication, delays in information dispersal, and so on can break a project, even without being under the pressures that Agile brings into play. Rally's suite goes beyond bug tracking and version control and integrates the entire Agile cycle, from soliciting customer feedback to publishing the latest versions.

My impressions of Rally's software suite

Richard gave me the "10,000 foot view" of Rally's suite, and frankly, I was insanely impressed. One of the features I think is really great is Rally's system for building a community; it lets users suggest and vote on new features. In fact, they've dog fooded themselves with this; you can go to Rally's Web site and vote for new features to be added and pet peeves to be fixed. Richard told me that Rally devotes a portion of its development cycle on each iteration to working on items from the Top 10 list. (This is a lot like the crowdsourcing that Spiceworks is doing.)

Rally's software integrates with a wide variety of other products, including Eclipse, Visual Studio, Team Foundation Server, Subversion, and a lot more. There are a number of APIs for accessing the software, including SOAP Web services, REST APIs, and JSON/JavaScript. Also, Rally supports Ruby (another interesting comparison to Spiceworks, which also writes its product in Ruby).

Rally typically offers its product in an on-demand environment that the company hosts. I find it brilliant that Rally will sell its software as a virtual machine that you can put on one of your servers in your own LAN. I am a traditionalist, and I really want a throat to choke when something goes wrong. By offering the software like this, Rally lets developers like me use their software in a way that feels comfortable.

Study results

Getting back to the study that got Richard and me talking, there were some interesting points in there. One of the things that caught my attention is that, with a compressed timeline, the Agile projects showed a linear increase in bug counts. The typical experience is that a shortened timeline results in an exponential increase in bugs. Again, while I was skeptical (Richard acknowledged that measuring these things is notoriously difficult and inaccurate), the trendlines are hard to ignore. I know that any kind of project measurement won't be super accurate, but the consistency of the numbers painted a very attractive picture.

A marketing exec who knows development

I think what surprised me most about our conversation was Richard himself. I talk to companies on a fairly regular basis, so I'm used to cutting through the marketing fluff and getting to the meat. This Marketing VP comes from an engineering background. He's worked at some really big shops and knows the frustration of trying to ship a product with traditional development methodologies.

Our scheduled 45 minute call ended up lasting nearly two hours, during which we discussed a broad range of topics. Richard knows developers, and he knows development. If he represents the caliber of people in Rally's Marketing department, the product team must be truly formidable. Over the next few weeks, I will bring you a much more in-depth look at Rally's offerings.

Download book chapters about agile development

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.

---------------------------------------------------------------------------------------

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Justin James is the Lead Architect for Conigent.

3 comments
alindcool
alindcool

Agile is efficient SDLC model to compete with the emerging demands of market. Agile is best suited for smaller organisations and mostly towards the Sofware product development company. Planing of work is done in chunks of iteration which may last upto 2 week max. Scrum is done in order to be aware of daily status of the iteration and according manage the backlogs. Scurm master is apponited who head the scrum. One of the suited too for it is Rally, which works mainly on agile manifestos. Refer: www.rallydev.com It uses more effecient techniques like : Test Diven Development.

Justin James
Justin James

Is Agile something that you've been struggling to use? Does it seem to you like barely managed anarchy? Or have you been using Agile to great success? J.Ja

cupcake
cupcake

I have worked for two companies who have both tried to implement Agile. The first one used it in a pilot project for development of a non-business critical project and it was a major failure. Not only did people not respond well to the change in methodology, it is my belief it was not implemented nor then managed well. My current company is now on their second project utilizing the Agile methodology. I am not directly connected to the project, but get to sit outside the 'bullpen' where they have pulled all the team members together. Those who aren't physically able to be present are connected via an open conference bridge. It makes for a very noisy workplace. I believe they are making strides with Agile, as our project management has just been told that my team is now inline for Agile training. Personally, I liked your words and that's what it appears to an outsider: "barely managed anarchy". [Edited for clarity]

Editor's Picks