If you don’t want anyone to read something, don’t put it on the slide.

The latest in PowerPoint fashion is to include complex graphics with unreadable labels.

It’s bad enough when a graphics designer decides to use mouse type to label the boxes in a graphic. But sometimes there are no good alternatives.

Take, for example, this well-known (in enterprise architecture circles, at least) representation of the TOGAF methodology and framework (The Open Group Architecture Framework, and don’t get me started about including “the” in an acronym).

TOGAFIf I was going to write about TOGAF and wanted an accurate graphic to help illustrate my points, my choices are limited. TOGAF has enough moving parts and interconnected concepts that any graphic describing it well is going to have a large number of elements to it, each of which is going to require a label so you know what it represents.

Which means small type. But you’ll notice, if you expand the image you can actually read everything. As a steadfast opponent of oversimplification, I’m okay with this sort of graphic. It isn’t what I’m complaining about.

This is what I’m complaining about:

TOGAF2When a presenter doesn’t render an image with a resolution high enough that the type is readable when expanded, it tells me there never was any intention to present actual information.

Whether or not it’s intentional or not, the message that’s being clearly delivered is, “I want to impress you with my sophisticated knowledge but don’t give you credit for having enough curiosity to want to understand this subject yourself, let alone the attention span you’d need to review the actual content.”

The message I take away: The presenter knows there’s sophisticated knowledge to be had about the given subject, hasn’t expended the effort to learn it, but wants you to think (s)he has.

Yes, I know. Most of the time you have no more interest in learning the details than the presenter has the ability to explain them. But don’t think of this as an opportunity for eyeball-glazing, mind-numbing boredom.

Think of it as a hobby. Some people collect stamps. Others collect coins, or rocks. You collect flustered responses to this phrase, inserted innocently into the presentation whenever you just can’t stand it anymore: “I can’t read the type. Would you please expand the view and walk us through this?”

Most likely, after apologizing for the poor resolution and some tap-dancing, the presenter will say something like, “Well, I’m not the right person to take you through the details, but I can bring that person to our next meeting.”

The second-to-last thing you want is another meeting (the last is to reward the presenter by agreeing to another meeting). So you say, “That’s okay. Just give me the high points.”

Or, “Will that person be working with us directly if we decide to do business with you?”

Or, “Maybe I’m misunderstanding the situation. Is that graphic on the page to provide information, or is it just decoration?”

Just keep in mind, this is a catch-and-release situation. Go ahead and play the fish until you get bored, but at some point you should let the presenter off the hook.

What’s even more annoying than this is that the trend toward unreadable graphics seems to be extending beyond face-to-face presentations to on-line and downloadable marketing, and even worse, to training material. There’s no defense — nobody to put on the spot and embarrass.

If you’re in a public service mood you might consider taking the time to send an email into the customer service black hole, to the effect that while going through the company’s on-line training course the graphic in question caught your eye, but its resolution was too low — could customer service please send you a readable version?

Maybe … just maybe you’ll eventually find yourself in touch with someone you can politely ask why on earth they’d include something that clearly does have text, but that just as clearly was never intended to be read, in their material.

But probably not.

Does Agile speed things up?

As we discussed last week, when it comes to IT App Dev, just defining what “speed things up” means is a non-trivial task.

And then there’s the definition of “agile,” which isn’t about speed in the first place. If we use automobiles as a metaphor, agility has more to do with a car’s suspension, steering and brakes than with the drive train.

If the question is whether Agile makes IT more agile, the answer is an unequivocal “Yes,” because with Agile, requested changes go into the backlog with no muss and no fuss, where with waterfall they’re submitted to the project steering committee as part of standard project governance.

A process step that doesn’t involve a committee is always more agile than one that does. Q. E. D.

There’s another way to answer the question, which leads to an even more emphatic affirmative. As pointed out last week, according to the Standish Group’s annual Chaos Study, across application development projects of all sizes, Agile methodologies yield higher success rates and lower failure rates than the waterfall alternative.

How does this translate to speed?

For a change of pace, this one is easy. If by speed you mean throughput, failed projects have no throughput. They deliver zero requirements — aka user stories — per month. And if by speed you mean cycle time, for failed projects the cycle time for delivering a user story is infinitely, or at least indefinitely long.

It’s Q. E. D. all over again.

But (you knew “but” was the next word, didn’t you?) …

There’s no such thing as an IT project, so whether you measure throughput or cycle time, if the units being delivered are software features you’re measuring what amounts to the production of work in progress, not finished goods, the finished goods being the intended business changes.

And it isn’t true that if you speed up the creation of work in progress you automatically speed up the process as a whole. For example:

Imagine a team of process re-engineering consultants has marched through a business, completely redesigning one of its core processes. Almost certainly a process change of this magnitude will require radically different or completely new enabling software.

Now it gets complicated, because to make sure the new software will properly support a process that’s been completely defined from one end to the other, for all major branches and contingencies, there’s no alternative than to design the software from one end to the other and for all major branches as well.

This is what waterfall does. To get Agile to do the same thing a business has to adopt what’s becoming known as “scaled Agile,” which defines software in terms, not only of user stories that are small and self-contained, but also in terms of “epics” that are, as the name implies, large and expansive.

You start with the epics, decomposing them into release trains, and release trains into user stories. Voila! You’ve turned Agile into waterfall, except for the design of user interface details and perhaps some underlying algorithms.

Which leads to the question, when it comes to large-scale business change is scaled Agile a necessary evil or a self-inflicted wound whose root cause is a failed change in culture — the retention of waterfall mental habits that relegate Agile techniques to the trivial.

I think the answer is, neither of the above. The view from here is that the root cause was the decision to re-engineer a process in the first place. Once a business decides to design and implement a large-scale process change in one big bite, there’s little point trying to build the supporting software in small increments.

Instead, businesses need to adopt the mental habit of incrementalism — to make a continuous stream of small changes the centerpiece of its management culture.

Because as Lao Tse once said, a journey of a thousand miles starts with a single step. What he didn’t explain is what IT and its business counterparts need to understand the most: Those who undertake journeys of a thousand miles and fail are the ones that, after they take the first step, try to cover the rest of the distance with one giant leap.

Those who succeed don’t take journeys of a thousand miles in the first place.

They take journeys of 2,100,000 steps, which they cover by walking briskly.