black:hole:logic

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…

I love it when things time themselves perfectly.

In Scooby Doo fashion I can imagine an episode ending for this one. Great timing, as I’ve kicked off my own sl/rant on Agile and Scrum here.

This guy dropped an impressive load of ignorance. He calls himself an Agile coach…which predicates that he informs developers on how to best apply the Agile practices. I’m just guessing, but I’d bet he’s more in line with “process policeman”...pimping Scrum, or some other methodology. Then, he’s got the ineptitude to drag the Manifesto in to his diatribe. (Run Agile run…here comes more Methodology madness to stab you in the back!)

Proof’s in the pudding…and this dude is swimming in it. “Heck, I’ve been running agile teams for over 20 years. I know the stuff. I live the stuff. I teach the stuff. I love the stuff.”, says he. Whatevar. 20 bucks says he’s a SM, probably with a PMP cert.

While I wait for a slew of Selenium tests to finish stroking a web application, the product of my current Scrum team, let me capture some of the thoughts and responses from my previous Scrum != Agile post.

First, let me start by saying that I do like and appreciate the formality of Scrum. And furthermore believe that formality is necessary to the success of software projects of any scope. My original intent was to strike some thought around the notion that Scrum abuses “agile”, the agile as defined by the original manifesto.

Agile Software Development needs to separate itself from Scrum. And, Scrum needs to quit doing agile such a disservice.

I’ve seen it a few times now where agile practices, get the root cause treatment for flailing methodologies. I hear way too often “we’re an agile shop; we do Scrum.” And, I’m also seeing more and more organizations attempting to apply Scrum to CMM-centric projects.

First Step: Remove agile from methodologies. Agile practices should stand alone, as simple actions taken by individuals, teams, and stakeholders in support of any given methodology. [Good agile practices won’t preclude process success, but can prevent many process pitfalls. Practices can make {closer to} perfect {software} – but, process can not.]

Second Step: Accept that Scrum is not agile, in of itself. [Just because the process is broken down to more iterative steps does not imply agile anything. In fact it could be concluded that the real Agile says they aren’t related at all: “Individuals and interactions over processes and tools”.]

Obviously, there’s a lot more to be said here. I’m intentionally keeping this short…with the hopes that I will continue the thought in subsequent, more focused, posts.