Benjamin Franklin's turn of phrase was just as applicable in his time as now – who can deny that being prepared is always a good idea? This week's edition features a roundup of some well-known software failures, many of which were traced back to issues which could have been either avoided at the initial requirements definition stage, or discovered in testing. The continuing popularity of agile methods brings with it the danger of miscommunication between teams – like the metric vs. imperial confusion on the Mars Climate Orbiter. Here are 10 tips to avoid pitfalls when starting an Agile – or any – project 1. Avoid requirements creep: Many Agile methods use “working software” as the main (or even only) measure of success. Allow change at the detailed level, but the major functions of a software project should be fixed as early as possible. If you don't have a definition of “working software”, you risk never completing. 2. Package work: Identify major functional areas and group them logically, with communication/data flows identified. Draw this up as lines and boxes (often known as a “City Grid Plan”) and test the concept by following data paths and user experience to make sure you've got all the interactions covered. Everything inside a box should equate to one delivery project. 3. Identify dependencies, and address them first: Where your application relies on data storage, user management or interfaces, make sure these are complete and available for dependent components to test against as soon as possible. 4. Front load your risk: any new or unknown technologies should be prototyped first, to make sure they'll perform as expected/intended. It's no fun at all getting several months into a project only to discover a major flaw, and have to make a technology change. 5. Choose wisely, then resist change for change's sake: new technologies appear virtually every day. De-risk your project by selecting and prototyping your technology stack then stick with it unless there's a very compelling reason not to. Technology changes cause rework, which costs time and money. 6. Estimate honestly: try to come up with as accurate an estimate of the size of each work package as possible. 7. Define interface contracts early: where there is a need to communicate between solution components, define those data paths as early as possible. Again, this is an area where a paper (or whiteboard) based exercise against a functional block diagram can pay dividends. Wherever possible, use standard interfaces – less to build now, and less to maintain in the future. 8. Don't forget the non-functional requirements: when doing the initial design review, make sure to include failure scenarios for each functional block. How will the system respond to the user? How will it recover from the failure? How will it respond to peak or spike workloads? 9. Test, test, test: create test plans for each component, and test harnesses for individual components and the integrated system. Don't rely on ad-hoc testing or assumptions – instead of loading an existing test data set with users and data preloaded carry out a scripted plan to exercise all of the functions each time a new component is integrated or a change is made. 10. Communication is key: make sure everyone understands both what they need to do and the environment in which they're working. Publish changes and progress updates frequently, and report bugs/issues as early as possible. Make sure that the whole team is part of the communication process, and that nobody's voice goes unheard.