The small company that was my potential “dream job” had made a name for itself as an “agile” software development shop. A feat not so special, unless you consider they had done this in the Department of Defense arena. They had taken Scrum, formalized it to include CBTs covering the entire SDLC, and pushed out to the customer as the preferred Delivery Methodology. This company had done so well with it, that an 800lb. gorilla decided to acquire the company. So, this company had not only sold Agile to the customer, but sold themselves as Agile. Not bad.

More definition is now needed to go along with Scrum and Agile. Delivery Methodology…to me is simply the vendor/supplier/contractor/consultant-customer relationship, that indeed covers the entire life of the project. No reference needed here, that’s MY definition.

We’ve taken agile, shoved it into a box, shrink-wrapped some formal processes, and stuck it on the industry “end-cap”. Knowing that there are some great businesses out there profiting from the explosion of Agile, I hesitate to ding anyone for capitalizing. But, let’s be realistic…Agile Delivery Methods are just a distinctive competency, providing for a more interesting and competitive landscape. I think the biggest impact is the level of boost given to smaller business, whom compete against those 800lb. gorillas.

Why would an 800lb. gorilla want to buy a small company excelling with deploying Agile practices, Scrum processes, and non-traditional delivery methods? Hmnn. Well, I can tell you that it isn’t a good sign for the consumed small business, but that is another story.

The thing is that anyone can be Agile, from an internal developmental perspective. For all we know, most commercial software development is done in an Agile fashion. We do know that Open Source excels in this way. So, can commercial software, or more to the point services companies be Agile in their delivery methods? (without trying to buy the capability?)

I think so. But, we must go back to treating Agile as a set of practices, which can float any process methodology. Developers understand. Some executives understand (especially the one’s getting VC slop). The Open Source community understands. Why is it so difficult to influence the operational layer, most significantly those describing the formal processes and procedures?

My suggestion: stop selling Agile (or the agile processes) externally, before it has been sold internally. And, more importantly don’t sell it externally unless you can prove quantitatively that you are doing it right internally.

It were sure be nice to see better metrics from large software development houses on their Agile-influence engineering processes. I’ll have to do some searching…