Team Building Goes Viral

DST Systems' large development group of about 1,200 people over the years adopted a hodgepodge of tools, processes, and source code control systems. It didn't have a single central repository for source code nor one developer toolset shared across the organization. Some teams used Serena PVCS, others didn't. Some tools worked in Eclipse, others were standalone. Moving between tools was cumbersome. Many processes were manual and time consuming, especially if they involved Excel spreadsheets or Word documents.

Development teams complained regularly about the tools they had to work with. Managers had difficulty answering basic questions about who was working on what and determining the status of a particular asset, because they had to look in so many places to get answers.

This situation became a serious problem as we looked to accelerate the development cycle for DST Automated Work Distributor, business process management and workflow software that's been around for nearly 20 years. Financial services companies use AWD to process financial transactions. Healthcare organizations use it to process insurance claims. It's a mature, sophisticated product with lots of features. But moving it through a traditional waterfall methodology--from design to coding to testing to integration--was taking two years for each major release. To remain competitive, we needed to speed things up.

So after decades of using waterfall methodologies, we switched last year to the Scrum Agile software development methodology. In a short time, we achieved some impressive results. Our developers accelerated software releases by a factor of four, reducing the software release cycle from 24 months to 6 months. We also boosted developer productivity by at least 20%.

But getting there wasn't easy. Running Scrum sprints with our existing tools caused immediate problems. Processes broke down, and our disparate tools and manual processes kept Scrum teams from reaching their objectives. We knew that Agile was a team-based approach to software development. But to make it work, we quickly realized that we needed an easy-to-use, comprehensive development environment that would put tools and data within easy reach of everyone on the team.

The Right Approach

We put together a product evaluation team to identify the right development environment in mid-2008. It considered about a dozen application life-cycle management (ALM) products, including tools from CollabNet, IBM, MKS, and Serena, as well as several open source options. We settled on three finalists and ran pilot projects with each.

Cost-effectiveness and ease of adoption were key selection criteria. We also examined feature-effectiveness, assessing whether the core features were packaged in a way that made them immediately accessible. We wanted to be able to easily make use of each feature without extensive training that would impinge on productivity. Whichever product we chose, we needed to adopt it quickly so we could continue developing and supporting products in a competitive market. We were, in effect, changing the tires while the car was moving.

From Chaos To ALM

For the three pilot projects, we assembled a typical Scrum team that included a project owner, a Scrum master, a business analyst, and someone from quality control. We then replicated source code into the tool's repository, established some Agile use cases, created processes within the tool to model the use cases, and staged a dress rehearsal to test the day-to-day interaction with the tool. We allowed time following each pilot to assess how the tools would let us meet the requirements we had set.

Once the pilot phase was over, the evaluation team chose CollabNet's TeamForge as our ALM platform, with Subversion as a single, centralized repository for all development projects. We completed the transition to TeamForge in just less than 10 weeks. By June 2009, our core development team was up and running in the new environment.

Now all members of the development team--from product owners to Scrum masters to developers and testers to business analysts--have what they need for all phases of the application life cycle. We're also using Agile templates included with the TeamForge to manage our processes and workflows.

The switch has made development teams more effective. Now, developers aren't struggling to move files among disparate tools, but instead, they do all their work within the ALM platform and Eclipse. Developers aren't complaining about tools anymore.

Our goal was to increase productivity by 20% in one year. We've met and probably exceeded that goal. The combination of Agile development and TeamForge has delivered benefits for our development work, as well as the overall business, including:

>> Competitiveness and market readiness. We're delivering new features every six months instead of every two years, and we're ready to move aggressively in our markets this year.

>> Transparency. We can now answer management's questions about people and products immediately. We have visibility into project status and can drill down to the level of individual assets and users. My team no longer spends hours looking for answers and building reports. All of the information we need is readily available in the new development environment.

>> Happier developers. We're not hearing complaints about tools and processes. Everything the developers need is in TeamForge and Eclipse. The tool's ease-of-use has led to viral adoption by our development teams.

>> More effective support. The new ALM platform provides support engineers with better visibility into our product, including new features under development and relevant test results.

Lessons Learned

If you're software group is struggling with old, inadequate toolsets, it's time to evaluate ALM options. Based on our experience, here's what to look for:

First, keep it simple. Find a product that meets your needs, but be wary of complex "Cadillac" offerings that promise every feature under the sun. Over the years, I've learned that Cadillac-style products generally give you higher costs along with all those features. Focus on what you really need, and don't fall for showy vendor presentations. Simpler is better, and it's almost always cheaper.

Involve key players every step of the way. When evaluating ALM options, put together a team of senior developers who'll ask vendors hard questions and give you excellent advice on selection criteria. Their endorsement of the final selection will carry tremendous weight with the rest of the organization. Your developers will have faith in the decision, because the senior developer team was involved. They're going to trust other developers before they trust a bunch of managers who went off by themselves and then came down from the mountain with product brochures and a purchase order.

Finally, strive for viral adoption, rather than mandating change. Find a platform that's so compelling that people will adopt it without coercion. If you've selected a product that solves problems, meets people's needs, and has earned the endorsement of senior developers, you won't have to force it on your developers. They'll adopt it on their own.

After several months, we already have more teams on the new tools and processes than used our previous ones. It's part of our culture now. People don't question it. There's a groundswell of adoption going on. It's that compelling.

While it would be tempting to give Agile practices all the credit for these results, if you've really selected a product that solves problems, meets people's needs, and has earned the endorsement of senior developers, you won't have to force it on your developers. They'll adopt it on their own.Mandating change is hard. Viral adoption is easier--and more fun.

Read all about software development at Dr. Dobb's: drdobbs.com

Jerry Tubbs is systems development manager for DST Systems. Write to us at iweekletters@techweb.com.