All Posts in App Dev Methodologies

|In: App Dev Methodologies|Last Updated:

There’s no such thing as an IT project. There is, on the other hand, such a thing as There’s No Such Thing as an IT Project: A Handbook for Intentional Business Change. It’s now officially available for purchase (or will be tomorrow morning). Humility prevents my coauthor, Dave Kaiser, and me from telling you it’s the most important business book published this year.

It’s a good thing we’re so humble. Or maybe not, because if you have anything to do with making business change happen … intentional business change, that is … you need this book. And I hope you’ll forgive a bit of hard selling because if you want the organization to change you’ll want your peers and collaborators to understand what it is you’re doing and why.

What’s the book about? It’s about 180 pages long. It’s about eighteen bucks … a dime a page … if you want the Kindle edition, more if you want crushed trees smeared with ink, and if you do, consider buying it straight from our publisher (https://www.bkconnection.com/books/title/Theres-No-Such-Thing-as-an-IT-Project ).

It’s about the difference between “implementing software” and something useful coming of it.

It is, we think, comprehensive without being tedious; practical and pragmatic while still presenting big ideas; clear and concise without being humorless.

If you’re a long-time KJR reader you’re familiar with the mantra, for example from this ten-year-old evergreen from the archives – https://issurvivor.com/2009/12/07/someone-elses-problem/ .

Now, instead of having to root around in the archives to pull everything together you’ll find it all in one place.

That’s how KJR works. You get a concise account of a narrow slice of a big topic once a week, out of the goodness of my greedy little heart. You get a complete view of subjects that matter from the books I publish from time to time (look here if you want to know what else I’ve written over the years: https://www.amazon.com/Bob-Lewis/e/B001HMOX0I/ref=dp_byline_cont_ebooks_1 .) It’s one way you can support KJR — something readers ask from time to time.

If you like the ideas and need help making them real, give me a shout. https://issurvivor.com/contact/ . With many consultants you don’t really know what you’re getting into. I am, more or less, an open book.

Well, 12 open books, but who’s counting?

Oh … one more request. Books aren’t real until they have a bunch of Amazon reviews. So I’m asking you to write one — preferably after you’ve read the book (as a consultant I have a strong sense of sequence).

If you like the book, please say so and explain why. And if you hate it, please explain that in a review as well. I’m not trying to put my thumb on the scale — I like good reviews as much as the next author, but it’s more important for the book to be real.

And don’t worry. Unlike public radio, I’m not going to hold KJR hostage until enough of you have bought the book.

I might badger you about it from time to time, but I won’t fill more whole columns pleading with you and your fellow readers to satisfy my deep craving for attention. Dave and I hope you enjoy the book and, more important, find it useful. We won’t know, though, until we read your review.

Comments

|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