All Posts in Project Management

|In: App Dev Methodologies|Last Updated:

And now some admiring words about Mitt Romney.

No, no, no, no, no. I’m not referring to any recent votes he might have made in the Senate. I’m referring to his recent, well-publicized 72nd birthday and the parallels he and his staff established for achieving business and IT agility. The standard they set for business and IT thought leadership rivals anything Romney achieved during his years at Bain Capital.

Start with his staff’s innovative multi-Twinkie cake architecture.

Most birthday cakes are layer cakes and result from waterfall design and production techniques. The baker starts with a recipe — a complete specification for the cake itself, coupled with a detailed work breakdown structure for creating it.

Many cake makers achieve excellent levels of success using these waterfall techniques, and I’d be unlikely to reject their work products.

But … personally, I’d be likely to concentrate my gustatory efforts on the icing. It isn’t that I dislike the cake component of the finished product. It’s that the cake component dilutes the flavor of the frosting, which I enjoy quite a lot more.

In business/technical terms, layer cakes aren’t modular, and deliver unnecessary features and functionality. Twinkie cakes are, in contrast, modular. Each component Twinkie is a complete, integrated whole.

Also: A layer cake is an all-or-none proposition. The baker decides how big a cake to make and that’s that. If unexpected guests show up, well that’s just too bad. Either everyone gets less dessert, or the new guests do without.

Traditional cake-baking doesn’t scale. Because Twinkie cakes are modular they scale easily: Just add more Twinkies, frost them, and everyone’s happy.

Another aspect of the Twinkie cake deserves mention: It evokes the value of an important technical architecture design principle: buy when you can, build when you have to.

Layer-cake bakers start with raw ingredients and baking infrastructure (the oven and other paraphernalia) and engage in actions equivalent to application development.

Twinkie-cake-makers start with a pile of commercially manufactured Twinkies. They do then make and apply their own frosting, but that step is more analogous to application configuration and integration than to application development.

Our final step in beating the metaphor to death (as opposed to beating the eggs that go into many layer cakes) is testing.

Bake a layer cake and the only way to test it is to mar the cake by cutting a slice out of it. Sure, you can reserve some of the cake mix to bake a mini-cake instead, but small cakes bake more quickly than full-size ones so the baker can never be sure the test cake tastes the same as the production version.

Compare that to a Twinkie cake. Want to test it? Eat a Twinkie. Not sure? Eat another one.

No problem.

The Twinkie cake architecture was innovative and interesting. But just as there’s no such thing as an IT project — it’s always about doing business differently and better or what’s the point? — so Romney himself deserves credit for the “business innovation” of using Agile techniques to blow out his cake’s candles.

Traditionally, candle blowing has been just as waterfall-oriented as cake baking: The birthday celebrator attempts to blow out all of the candles in one great whoof.

As is the case with waterfall project management, this is rarely successful, due to another waterfall parallel: Just as the risk of failure rises in direct proportion to the size of a project, the older the candle-blower, and therefore the more candles there are to extinguish, the less likely it is that anyone could nail all the candles in one breath.

Not to mention the unpleasant thought that unavoidably, in an attempt to blow out all those candles, some of the blower’s saliva must inevitably end up on the cake.

I’ll leave it to you to figure out parallels to application development or business change. And please do feel free to share your analogies in the Comments.

In any event, Romney used an Agile technique — iteration — to dodge the challenges of traditional candle out-blowing: He removed each candle from the cake and blew it out separately.

Especially, kudos for explaining that this way each candle was another wish.

The candles, that is, were his birthday backlog. And he dealt with them as all Agile teams deal with items in the backlog: One at a time, with little stress, and a very high level of success.

And, in the end, a spit-free cake.

Comments

|In: App Dev Methodologies|Last Updated:

When my children were young, I offered them two alternatives. They could either make the same mistakes I made growing up, or they could learn from my mistakes and make a bunch of new ones instead. I’ll let you guess. Heck, I can only guess myself.

But I don’t have to guess about DevOps, where some practitioners are making mistakes IT learned to avoid decades ago.

In particular, we learned IT shouldn’t release application changes into the wild without: (1) conducting comprehensive regression tests if the application change in any way alters system integrations; and (2) providing at least delta communication, and in many cases delta training, if the user interface changes.

Wait! Why am I wasting your time with 30+ year old wisdom?

I know it looks like I’m changing my name to Captain Obvious. But while I know you know better than to engage in these IT worst practices, that doesn’t mean your technology vendors do too.

If you’ve read anything about DevOps, you know CICD is a key element. But many vendors, having invested significant money and effort into adopting DevOps as How We Do Things Around Here, only got three of the four letters right: Continuous, Integration, and Continuous.

But they read somewhere that the “D” stands for Deployment, and, with the enthusiasm of the converted, gave the matter no further thought.

As a regular KJR reader you know the difference between a release and a releasable build, and with that the difference between Continuous Integration/Continuous Deployment … appropriate for eCommerce applications where what changes is the customer’s shopping experience … and Continuous Integration/Continuous Delivery, the model that works for applications whose purpose is to support internal processes and practices.

Just in case: The difference between delivery and deployment is simple: Delivery installs to the staging environment; deployment installs to production.

It’s past time to make sure your vendors deliver to staging and don’t make you vulnerable to vendor-DevOps-driven unmanaged deployments.

Start with your contracts. Do they prohibit your vendors from deploying changes to the UI and application interfaces without your permission? If not, start negotiating the requisite contract changes.

SaaS providers are particularly notorious for unmanaged deployments, because you can’t block changes they install on their servers with your defenses. But increasingly, providers of customer-installed COTS are adopting DevOps practices too.

This doesn’t make it okay to go back to … or, in many cases, to persist in … the outdated practice of staying on stable versions as long as possible. Staying current or nearly current is no longer one choice among many. In an age of state-sponsored and organized-crime-sponsored assaults on your information systems, staying current or nearly current is now the choice, not a choice.

So let your vendors off the hook, and accept a deadline for implementing new releases. Your vendors should give you ample time to test. You should let them retire ancient versions.

This doesn’t just apply to the IT vendors you have, either. Every time you go through a solution selection, make sure you include your requirement that the vendor doesn’t push changes into your production environment without your knowledge and consent.

Second: It’s time to automate regression testing. Yes, setting it up is painful and expensive. For that matter, maintaining the automated test plan is no picnic either.

The alternative, though? There’s an old, old rule in IT, which is that you always test. Professionals test before putting software in production. Amateurs test by putting it into production.

And we’re well past the time when just grabbing a bunch of end-users and having them bang on their keyboards for an hour or two will give IT a passing grade.

Third: Make #2 less expensive by cleaning up your interface tangle once and for all. While reliable industry statistics are hard to come by (strike that — they’re impossible to come by), anecdotal and conversational evidence suggests that the ongoing cost of maintaining an ad hoc collection of point-to-point interfaces can, over time, overwhelm IT’s ability to implement new applications and application changes.

To put a bow on it: How could DevOps proponents make such an elementary mistake as conflating delivery and deployment? It’s sadly easy to understand. As a member in good standing of the KJR community, you understand there’s no such thing as an IT project.

But we’re still in the minority. The IT pundit class thinks moving from projects to products is an exciting transformation.

If the job is done when the software runs, CI/CDeployment is fine and dandy.

If it isn’t … choose the wrong goal and wrong practices are inevitable.

Comments