At the end of the day, the best thing I really enjoy about agile principles and practices, is that they help us be more effective. I’ve been spending some time reflecting on previous projects and though I didn’t necessarily live and breath agile principles and practices at my previous company, I think I used a few of them to overcome other less effective processes.

At my previous company, at least on the project I was on, we had a framework team developing generic services for other parts of the project to consume. At one point, my manager asked me to complete a review for a new framework service that had been in “Design” for about two months. Being one of the consumers of the service, I quickly pointed out a few scenarios where it would not work and ended up joining the project to make solution a viable one.

Here’s a list of things that I think made it so successful in the end:

• Just Enough Design – I found white boarding a very effective technique with my manager, who had much more experience to draw upon. We would use real world models talking through the algorithm until we were both happy with it. I would then go, code it and try it out – we didn’t bother documenting anything until we knew our solution was going to work.
• Iterations – We had several “hang on, that’s not going to work moments”, so each time we would return to the white board, tweak the solution and when happy with the result, I would go back and try it out. We met almost daily (depending on how long it took me to code) to handle each new scenario, slowly tweaking the algorithm into an extremely robust one. We never let ourselves fall into Analysis Paralysis, trying to think of all the possible “hang on” moments when we knew we could progress.
• Automated Tests – For each scenario we came up with, I would write equivalent JUnit tests to make sure that new enhancements didn’t break our existing models. I found that it was also nice to have feedback that was always honest with me. I worked some long hours and some weekends to get it completed in just over a month, and when you’re tired and not thinking things through properly, I could at least try things out, and know when I had broken things.
• Using It For Real – I believe the real strength of the tests was that it was based on using a real model of usage. It was the same model we used during the white board sessions, and the mapping from code back into our discussions was really easy for talking over.

The end result of these was a fully working solution developed in less than half the time of what it took to produce a flawed “Design Document”. I find it assuring that you can make the most of these without having to classify them under “XXX practice”, and have to call the entire process “Agile”.