Making Agile tool selection agile

If we are going to be agile for development, then why not be agile in our tool selection. Step away from the one-size fits all mentality. Being true to Agile values means that the team is empowered, they iterate, they learn from mistakes and correct, they try new things out in order to improve.

Instead of lengthy investigation, concensus building between many, purchasing many licenses, switching over of all projects, and lots of training… let each new project decide if they want to use a currently available tool or if they want to try a new tool.

Hold on just a minute! If we do that, how do we…

Pay for that?

A professional, well supported, commercial application set can certainly be expensive. Purchasing a license set for a large group is daunting and difficult to justify ROI. It will take significant time to transistion a large group to a new tool set and there will not be concensus in its selection. You might just want to stay with what you have.

View it differently. Set a budget per developer per year based on current spend and depreciation. For our company this came in at less than $1,000 per developer per year, and we felt that was conservative. While the budget needs to be managed, it shouldn’t be hard to justify.

Consider dropping maintenance as the tools age and new projects are no longer using them. At this point you can forgo upgrades, and they should be stable enough with backups as a recovery mechanism. Buy licenses for new tools as needed rather than in a large lump sum.

Train on the variety of tools?

Put it in perspective. As software engineers taking on new projects, the technology in our field is always changing. Every project for us encounters something new. The new product technology is typically far more complicated than an Agile tool. Yet it is expected, we manage, and it isn’t holding us back. It is a career development opportunity and a lot of fun!

Don’t let the tool drive your work. Tools have many features, many features you don’t need. Approach the tool knowing what you want to do and you will be fine. Let the feature set drive you and you’ll waste a lot of time on distractions, tangents, reading books and online help.

Manage IT maintenance?

Avoid excess requirements on historical data. At key points, generate a report and move on. Limit the desire to maintain a tool to access historical data. Limit the desire to carry historical data forward into new tools and revisions. Question any process requirements that demand this.

Use the available virtual server technology. Dedicate a resource.

Keep up on tool validation?

This is specific to use of tools for medical device development.

Again, dedicate a resource. Agin, put it in perspective. Often we will validate many tools seeing custom use on our projects. We validate off the shelf software that is used in a medical device. This is unavoidable and scoped to the project so we worry less about the effort, and the decision is kept within the local team. The justification of effort for tool validation gets more attention than it deserves.

Focus on getting value out of your validation efforts. Monitor defects from the vendor, the tool receives much more use through their customer base and testing than you can cover in your own reasonable test scope. Focus on your installation of the tool.

I won’t say we’ve mastered this. It is a work in progress. I’d enjoy hearing your comments. Common problem? Success stories? Other challenges? Other solutions?