I just saw this challenge to find real life examples of agile development by Tom Perry. He was hanging Christmas lights and found a way to incorporate test driven development (TDD) and continuous integration (CI) into putting up the lights. He put up his lights, then turned them on and found he had a problem.
I had broken the first rule of agile development - Test First! Of course, any reasonably competent handyman would have known to try plugging in each strand of lights before beginning the life threatening task of suspending them from the roof - right? As I stood there at the foot of the ladder and contemplated my predicament, It occurred to me that the consequences of failing to test in the real world are a whole lot more painful than in the digital world. It’s really quite amazing that Test Driven Development hadn’t come along much earlier. If you stop and look around, people are doing it everywhere! Doing some woodworking? Measure twice, cut once.
I think it helps to try and find examples of these principles in your daily life. As we focus more and more on changing our fundamental paradigm for software development from waterfall to agile, we need to keep seeking validation in the “real” world. Look to other disciplines, look to the mundane, the everyday things that we do. Check and see if the premises that we use for Agile Development apply elsewhere.
So my mom recently got a car that has been overheating. She couldn't drive the car 15 minutes without it overheating. So my brother-in-law and I worked on her car yesterday and also found a problem with a misfire on spark plug six. So we tested something, changed one thing, then tested again. We replaced a spark plug, the air filter, and some bolts we stripped taking the exhaust bypass off of the intake manifold. We replaced the thermostat and bled the air out of the cooling system. Then we did a build and we tested again by running the car sitting still. After it passed this test, we took the car out for a drive to see if we could get it to overheat. This was the big test for overheating, or maybe the QA build and test. In the end we were expecting to get the car to overheat but we couldn't get the car to overheat! This is the proper way I think to test. The best way to prove yourself right is to try to prove yourself wrong. I test with that attitude.
Then we wanted to be sure it was the thermostat (and not just the bleeding of the air out of the cooling system), so we put the old thermostat in a pan of water and brought the water to a boil. The thermostat never opened. So I called my brother and gave him some trouble because he said the thermostat was fine and that wasn't the problem.
Today we worked on the misfire issue a little more by replacing the coil, testing, then putting the old coil back, testing. Then we switched wires and tested again. We pulled the spark plug to ensure that it was firing by watching the spark during the car start. We tested the spark plug gap. Each time we erased the errors off of the car's computer and let them pop up again, hoping they wouldn't. :D
So we came to the conclusion that we fixed the overheating problem, which we initially set out to do. We also troubleshooted the other issue of the misfire. We got to the point where we believe there is most likely a compression problem due to head gasket issue or bad motor. We are hoping that when someone takes a look at it, they find it is the gasket because that (although somewhat expensive to replace) is cheaper than a new motor.
So how many examples of agile development happened here and why didn't we continue working on the misfire problem?
- We estimated it would take about six hours to fix the overheating issue. That is six hours total time, not based on resources.
- The requirements changed on us. We found a more serious problem and alerted the user of it, telling them they needed to correct it and that is was more serious than the problem we fixed.
- We had a limited timeframe so we could only deliver so many features. It was butt cold outside and we were working with it snowing both days.
- The user confirmed that the car has not overheated during a couple of trips out of town, therefore passing User Acceptance Testing.
- Even though the user would prioritize the misfire issue higher than the overheating issue, it wasn't part of the iteration and we worked concurrently on fixing it as well.
- We delivered on what we promised for the one day iteration of working on the car - fixing the overheating issue.
The moral of the story for me is that there are real life examples of agile development out there and that you should make sure you have the proper tools for testing in every environment. We had the proper tools for testing: a code reader. It allowed us to read off the codes, then erase them from the car's computer if we desired. Make sure you have the proper tools.
I tag Russell, Troy, Dave, and Dru to find real life examples of agile development.