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.
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.