I find myself more and more involved in the sales process with my company. And while our primary focus is on expertise around technology and information, the team I sell for most does work using Agile methodologies. It’s not the primary aspect of our sale though, as people want to hear about our proposed solution, our work history etc. Rarely do they want a long explanation of how we do our work. But we do briefly explain it. So what is my Agile elevator speech?
I stumbled into this explanation on a particular sales call. I wanted to explain / justify an iterative approach, as opposed to a phased (big design up front) approach to a firm that had a background in mechanical engineering. After all, big design up front comes out of the kinds of engineering found in manufacturing and construction.
When building a bridge, the bridge is the end product. It is tangible and defined. It’s state may change, and it requires maintenance and monitoring, but it is a big noun. Creating software is more like making a muffin recipe (say for a book or something). In other words, it’s verbs. The muffin isn’t the product, the recipe is. After all, software is instructions for a computer, like a recipe is instructions for a baker.
In either case, you want to invest your time and money in the product. So with a bridge, you want all the data and research you can get, in order to have it right before building anything that commits you to all or part of a design. The cost of change is high. And the process is just a necessary evil. There is no value in the process, the value is in the bridge. And before finishing, you will test and refine the bridge, not the construction process.
With a recipe, you are investing in the process. The cost of change (throwing out the muffins) is low. And you are testing the process, not the muffins. Yes, you test by eating the muffins, but they are a proxy for evaluating the process. After all, if the muffins are bad, you don’t try to fix that batch of muffins, you rework the process and make a new batch.
Your mileage may vary, but for me, this analogy helps me keep the core values of agile in mind. I think Sports Management is another good one. Imagine planning everything for a season before it starts, and then refusing to adapt during the season.