Agile Tools: Ten Best Practices

OK, you’ve decided to transition to Agile development. You’ve done the training, retained an Agile coach, even switched to a new SCM system and acquired your first Agile project management tools. Now what?

Are you worried that you’ve retained some non-Agile baggage and may not be using your Agile tools to their best advantage? No need to worry – here are ten tried-and-true best practices for Agile tool users:

1. Evaluate the Agility of your tool stack

It only makes sense that to use Best Practices for Agile tools, you have to have Agile tools. A good first step is to see if your tool stack fits in with the Agile process. What is an Agile tool ? Simple – it’s any tool that can support one or more Agile practices and fits into the basic Agile framework. That’s it! For instance, a tool which allows you to maintain a ranking of all of the issues that you care about is one that supports the Agile practice of maintaining a backlog. Agile tools need a high ratio of value to effort in order to fit into the short iterations of an Agile project.

For each of the tools in your stack consider the following questions:

• How long ago did we implement this tool?
• Do we have the most recent version of this tool?
• Does the vendor of this tool use Agile development to produce this tool?
• What are the specific Agile practices that this tool supports?
• What are the specific features supporting those Agile practices?
• Are there other tools are better suited to those Agile practices?
• Are there Agile tools which remove or reduce the need for this tool?

2. Measure value-produced instead of progress-against plan

Rethink how you measure progress with your projects. Toss the idea that progress is measured in milestones right out the window and instead think about value produced. Instead of having unfinished work at the end of an iteration, it’s much better to complete work on a regular basis, get some value going, and have a couple of items which are not done at the end of the iteration that get deferred to the next one.

3. Maintain a master list of all work items

All work needs to be represented in the backlog for it to be really useful. Ideally, all work performed should be in the form of user stories and defects and managed through the backlog so all user stories and defects are available in your Agile Project Management system. The benefit is that nothing falls through the cracks and all work can be managed, tracked, and measured with the same process.

4. Use change packages to link user stories and defects to source file changes

A change package is what you call a complete patch of all changes required to implement a particular change. It’s a rollup of all of the changes that have been applied to resolve an issue including a complete audit trail of who made the changes, when they made the changes, and why they made the changes. Each change package is tied to an issue in the Issue Tracking System (ITS).

5. Fail fast: break up monolithic builds and test suites

I think the best way to be successful is to be able to fail fast. In other words, build the pieces of the software which have changed first, and run the tests which are most likely to detect systemic failures first. This way, with multiple teams working on their own builds, you can get rid of the clunkers quickly and concentrate on those ideas that show the most promise.

6. Use branches to smooth out end-of-iteration activities

Branching enables you to start the next iteration without disturbing the previous one. If QA finds any problems, development can fix them on the previous iteration branch. At some point that branch will be declared “done.” Those changes are then merged into the current iteration. The advantage here is that development did not have to stop, and you still have a stable baseline.

7. Use multiple tracks of development to work toward short iterations

One way to make an easier transition to Agile tools is to dump development tasks into one of two buckets: those that easily break down into small user stories, and those that don’t. The main track is work that can be completed within the iteration, including all testing. The secondary track is for all other tasks. Once a secondary task has been completed, it gets merged into the primary track at the start of the next iteration.

8. Use permissive file access policies to support collective code ownership

There should be as few barriers as possible to making file changes when using Agile tools, so use optimistic file locking – or no file locking at all – and set all file permissions to writeable to support collective code ownership.

9. Base iteration reviews on SCM baselines

Make sure that work shown during an iteration review has been integrated into the mainline and passes all unit tests and other end-of-iteration criteria according to the principles of Continuous Integration by requiring the team to prove its demo work is a single set of binaries built from the same baseline. That baseline must be from the mainline and built on an official build machine.

10. Mirror your Agile workflow with branches or streams

Mirror your Agile workflow with branches or streams so you can get many of the same benefits that tracking state gives you in your SCM change management system.

So there you have it — these ten Best Practices will increase your chances of becoming an Agile rockstar and increase the quality of software you create with your Agile software process.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment