Channels ▼
RSS

Design

Team Building Goes Viral


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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video