In order to realize the greatest benefits in application development, it is recommended that you use good engineering practices.  Those practices include continuous integration, paired programming and TDD (Test Driven Development).  Unfortunately, when arriving at a new coaching engagement, it is common that a tool vendor has arrived on the scene before the Agile (engineering and process) coaches.  Just as many are sold on Agile being a silver bullet, I find people are equally sold on the idea that a tool can solve all of their problems. Are clients wrong to assume an enterprise “Agile” tool can transition them away from a “Waterfall” tool?  I'm sure that is what the tool vendor told them.  Though I would agree some of the leading providers do offer more lightweight solutions, the truth is some people (after the sale) get frustrated when they realize their tools need to be customized, to align with their business processes.  Unfortunately, I have seen that customization not happen.  Instead, customers struggle with the tools they have implemented.  They change their development and delivery process so they can use the tools.  They start to practice TDD (Tool Driven Development).

When I show customers they can accomplish what they need with index cards, painters tape, and Sharpies, the next question is how can they modify the tool to align with reality.

Always remember the first value of the Manifesto: Individuals and interactions over process and tools.  Fix your processes first.  Then, and only then, should you look to a tool for efficiencies.

Image Source: Pictofigo