Cowboy Scrum

Some software firms that attempt to use the Scrum methodology variant of Agile, may do so to avoid the more common "Fireman" method of software development. (The "Fireman" method is to do whatever it takes to put out fires (tickets deemed "showstoppers" usually by the product support folks who just had their ears chewed off. Whoever is screaming the loudest gets their fires put out first.))

When this type of company hears about Scrum they may easily fall in love. With all its compelling claims of taking control of the cycle so that developers can actually focus on something for a few weeks and actually release something, who wouldn't? They may even begin right away to use the daily stand up and a 30 day cycle of release. It is easy to say at that point "hey, everybody, let's do Scrum from now on!"

These are good changes. These changes probably should take place. However, when the chips are down, deadlines are looming, and salesmen kept promising the moon (oops, I mean selling the software) then it may become difficult to implement the nuts and bolts of Scrum.

In that situation, a company may have a hard time keeping things above water. Nothing really has changed. It is not until a company can implement at least 90% or more of the doctrines of Scrum that they will ever actually see the real value of it, and get out of that "Fireman" rut to be able to predictably deliver quality software. By the way, I'm not totally against "Fireman" as a whole. It's fine if you want to play fireman for a given sprint or for a portion of each sprint. What company could ever claim to completely ignore the clients? That would have disastrous consequences, obviously!

The problem is the half baked scrum. This happens when a company tries to apply scrum but only goes so far in doing so. Coming from the "Fireman" mentality, they try to keep their developers on more than one team, in any number of projects. Salesmen still shoot the moon to make a sale, and the Boss changes priorities at will. It is more like cowboy programming. That company may have daily scrums and code reviews, sprints, and even something that looks like a backlog grooming session, the whole nine yards. But any given sprint seems to be subject to complete halt while the team gets re-divided to attack a new competitive edge to make a sale. It's not a scrum of scrums. That at least would provide the appropriate concrete, unchangeable sprints.

I call it a Cowboy Scrum. Not because I'm from Texas, although I may not have come to that name otherwise. More because it looks like scrum, sort of, but each sprint becomes like a character in an old western show. Each sprint comes in with its guns blazin'. Everybody who can, runs. The bold and the daring do their best to wrangle it into a corner long enough to put it to rest. At the same time another sprint comes up along the way, forcing everyone to change plans. Sometimes developers are ambushed by federally mandated compliance issues that seem to be there more as a rattle of the tail and a hiss, rather than for any real business value. At this point, whatever sprints were on track are suddenly completely obscured by other, more important sprints.

It's like the wild west of scrum. Wide open, sprinty, scrummy freedom. So long as you can dodge the bullets, arrows, and the inevitable stampede of product support.