Agility on Waterfall projects

So you find yourself on a strict waterfall project, but you want to inject as many Agile practices as you can, where do you start? There are many agile practices that can be incorporated into your day-to-day activities. Here is a start:

1. Acceptance Tests. Regardless of your role, you can write acceptance tests to verify your understanding of the requirements and to reduce the waste that is 'UAT'. Do this before you code.

2. Technical Excellence. TDD, SOLID Principles, etc can be used on waterfall projects even if you don't have official support to write your code that way. Depending on the development team make-up, you may have to find a way to refactor your tests when someone else changes your code, but since waterfall projects are sometimes silo-ed, this may not be an issue.

3. Customer Accessability. Find ways to get near your customers, analysts and testers to walk them through prototype screens, talk about the requirements, or discuss acceptance tests. Do this frequently (daily if possible).

4. Work to done. Make sure your code is shippable and passes all the tests you wrote, plus all the requirements. Be thorough.

5. Deliver Frequently. While you may not be able to put the code in production every 2 weeks, you can certainly put the code (prototypes, screen shots, diagrams, etc) in front of your customer frequently.

6. Be ready for change. Don't be upset when requirements change or new requirements are found. Make sure your code (and your mindset) is change tolerant. You'll still need to fill out the change request forms and follow the process, but at least your code will be ready for it.

7. Team of One. You may not be invited to help with the project estimate, plan the project, write status reports etc, but you can run your own tasks like an agile team. Create your own visual project management board, hold stand-ups and retrospectives with yourself, practice your planning poker skills by re-estimating all the tasks assigned to you, plan your iterations.

8. Suggests phases. If you can, suggest a phased approach to the project (rather than iterations). This may enable you to eliminate some of the waste and respond better to change.

In short, try to intregrate as many practices as possible, but don't necessarily ask permission to do so. Hopefully someone will notice and ask the important question: "Why are you doing that?"