We recently produced a webinar here at AccuRev, co-sponsored by Rally Software, about the Top 10 Factors for a Successful Agile Implementation. Number 7 addresses the question of a tools stack. Once Agile coaching and training is complete, now we can think about tools.
Agile manifest declares: ”Individuals and interactions over processes and tools.”
But we believe that this statement doesn’t mean you should forget your tools stack entirely. It’s really about making sure that your toolstack helps facilitate those interactions between individuals.
So it’s no surprise to us that when we hear about people rolling out Agile, they don’t even consider upgrading any of their tools. Studies have shown that new teams that do not invest in Agile tool sets, automated testing and continuous integration, start to struggle around the 10th iteration (4-5 months). The backlog of bugs and to-dos become so great that teams have to stop what they are doing and do a “maintenance” iteration, where they do massive amounts of QA or stop and do code reviews for an entire iterations. If we think about it, this kind of seems like traditional development model doesn’t it? Are you really Agile if you can’t deliver something which is “done” after every iteration?
The problem? Your current toolstack was designed by people who had traditional development models in mind.
Your tools don’t actually facilitate shorter development cycles, they actually hinder you by getting in your way. Your tool stack shouldn’t be the impediment in your Agile rollout.
Lets start with an Agile project management tool. This is the obvious tool to replace in your stack. Converting your traditional issue tracking system to an Agile one will give you the speed and visibility to help your teams practice Agile on a day to day basis.
Traditional source control management systems also hinder the process by following a “waterfall” like model of isolating code changes and leaving them on branches. Most SCM vendors know this is a problem, which is why their solution for an Agile branching methodology is to consolidate branches, or have entire teams work on one branch. This doesn’t make sense. All of your scrum teams should be able to function together and in parallel, while integrating work together on a regular basis.
Smaller iterations mean a faster paced development cycle. Some of the tasks that you used to do a handful of times over the course of a waterfall will now be done on a weekly, sometimes daily basis. This is where continuous integration and test orchestration come into play.
While you’re moving through a 2 week iteration, using continuous integration and automated tests suddenly becomes extremely important. Having these processes in place can help you avoid the 10th iteration problem we talked about earlier. You’re not going to have 4 months to regression test the application by hand in Agile.
The idea here is that your Agile tools must help you build a testable, deploy-able app every 2 weeks like clockwork. You will repeat this process over and over. Isn’t it time your toolstack provided you with clockwork development cycles?
