SEAT Global Magazine - Exclusive Interviews of Global Sport Executive Issue 09 March/April 2018 | Page 80

T

here are IT shops that have moved from waterfall application development techniques to one or more agile variants, or are in the process of doing so.

For every one that actually adopted Agile there are probably a dozen or more that follow some form of “agilefall” instead, strictly adhering to every single one of Scrum’s formalisms while completely ignoring the spirit of the agile transformation.

No you aren’t. You aren’t even doing agile. Can’t you read?

Okay, okay. If you must know, in spite of all the buzz about devops, its proponents didn’t invent collaboration. Agile — the real thing, not agilefall — advocated collaboration long before devops came along, although, to be fair, IT operations wasn’t who developers generally collaborated with. Here’s what devops adds to the agile mix:

First, dev teams include IT ops, for purely selfish reasons: They don’t want to wait for their environments to get built, and they don’t want to wait on the CAB to deploy software changes. Second is automation everywhere, a truly good idea. Having to manually shepherd software changes through their paces is simply silly.

Third is that, with devops but not with most agile variants, and certainly not with waterfall, software is always in a deployable state. No, no, no, no, no. Not deplorable. Deployable. Among the many uncomfortable realizations for most agile shops, this means devops and Scrum aren’t entirely compatible. Kanban works better. Sorry to be the bearer of sad tidings.

Hear those snickers coming from the help … sorry, service desk? That’s your service desk staff trading dumb user stories. Not the makings of a customer service culture. One of those would begin with respect. It doesn’t matter, because if they have a customer service culture, their CIO thinks the rest of the business is her customer. Very bad idea. It leads to ill-fitting concepts like chargebacks — a great opportunity to waste time, energy, and trust arguing about the IT bill. If it isn’t entirely clear why “customer service culture” is the wrong idea, see what happens when you delete the word “customer.” CIOs should foster a service culture in IT. How can they know whether they have one or not? If they still hear dumb user stories, they don’t have one.

CIO self-deception #5: We're doing agile.

As is the case with so many other business and IT practices, there’s a difference between checking off the boxes and properly executing the work the check boxes are there to keep track of.

And I’d guess half the IT shops that have avoided the agilefall trap have gone around the bend in the other direction: They aren’t practicing Agile. They’ve instituted Haphazard instead, often at the behest of a waterfaller who was certain before the entire effort started that agile was doomed to failure — and did their best to make sure their prophesy was self-fulfilling.

CIO self-deception #6: We're doing devops.

CIO self-deception #7: We have a customer service culture.

79