Car Analogy for Software Development Methodologies

This is a post about some observations and thoughts on software development methodologies.

The way that I see it, a project is like a road trip. We start from point A and want to end at point B - the release of a quality product. Let’s say we chose to use a car to get for point A to point B. The different roles in a project are just like the different parts of a car:

• Business/Product Owner => The Steering Wheel

• Code Development => The Engine

• Test Automation => The Brakes

• Architect => The Route Planner

• Funding => The Gas

In the traditional waterfall methodology, we start at point A, point the head of the car at point B, start the engine, and REMOVE the steering wheel. The car starts moving and we hope it will end up at point B in 12 months. Often times it is not clear where the car actually is until right before the scheduled release. Road constructions and detours are inevitable, but without the steering wheel there is not much we can do. The only way to steer the car slightly is by going through a 5-step change request process.

Then we start to realize that the car didn't arrive at point B like we've hoped. Or half way through the project, we discovered that the competitors are already at point B. So in order to keep the competitive edge, we really need to be at point C. And to be able to do that during the trip, we need to keep the steering wheel in the car the whole time.

By embedding the product owner on a team and empower him/her to make necessary changes during a project, we are more Agile! So now, we have a car with a steering wheel that can react and adjust to the changes on the road. Let’s also assume we have a team of brilliant developers. That means our car also has a powerful engine. We should be good now, right? Think again. Will you drive a muscle car at a very high speed knowing it doesn't have proper brakes? The traditional manual testing works well in a waterfall environment, where the large scale testing usually doesn't start until the code freeze (or feature freeze). The code is stable and the QA team typically has 4 to 6 months to run functional tests and probably a couple of full regression tests.

On the other hand, a well run Agile project usually has a very high code churn rate. Constant code changes require constant regress tests. How can anyone manually test a product that is changing everyday? In other words, having only manual testing on an Agile project is like putting bicycle brakes on a Mustang. How fast are you willing go?

My point is that if Agile doesn't work quite well in a company. For example, stories are not being closed fast enough, or the bug rate stays too high. Among other things, check and see if automated regression tests are put in place and are executed regularly.

In my next post, I would like to discuss test automation in an Agile environment.