“Oh, yes, we’re using Agile,” my client’s two CIOs told me.

Their company had engaged us to assess their IT practices and effectiveness. In addition to consolidating to one CIO (some recommendations are easier to figure out than others), we also suggested IT should adopt Agile to guide its application development efforts.

Their situation wasn’t all that unusual. The road to Agile is replete with forks. Travelers should avoid many of their tines.

My client had chosen a popular one: They were practicing, not Agile, but Haphazard.

Sadly, they ignored our 12-step App Dev recovery program, the two CIOs presided over a calamity, and eventually our former client became a division of a larger non-client.

Astonishingly, many business and IT leaders continue to misunderstand Agile, and that doesn’t include last week’s advice about applying Agile thinking to business situations beyond application development.

In some cases the misunderstanding is willful, grounded in distrust that Agile’s open-endedness can lead to useful results. If you share this distrust, a question: When you were a child, did you draw up a roadmap for your growth and development that would take you, step-by-step, through your adolescence, remaining education, personal relationships, offspring, careers, retirement, and demise?

Please say you didn’t. I recall, as a teaching assistant back in my grad school days, talking with pre-meds who discovered, in their junior or senior years, that they really didn’t want to become physicians after all, but felt trapped by the choices they’d already made.

I’ll leave the analogy there for you to explore at your leisure. Here, for your edification and amusement, are some other popular misunderstandings about Agile:

Agile isn’t Haphazard: With Haphazard development, project team members wake up each day figuring out what they should do to move the project forward. Or, nearly as bad, the project manager wakes up trying to figure this out.

No matter which Agile variant you use, the project is built around an organized list of Things the Application Should Do — the Backlog.

Agile testing isn’t haphazard, either: With Agile, testing is, if anything, more planned than with its Waterfall alternatives: Those developing a chunk of functionality — usually a module defined by a User Story — know when testing should start on their work. Even more important, every module includes, as part of its definition, a test plan.

Agile isn’t Scrum: It’s a squares and rectangles thing. All Scrum is Agile; not all Agile is Scrum.

Scrum, the most structured Agile variant, is especially popular among IT folk who, schooled in Waterfall development, need control structures and formal governance. There are, however, worthy alternatives.

Especially, look at Kanban, in which developers, when they finish work on a User Story, pull another one out of the Backlog, usually the one (1) with the highest priority, that (2) they’re qualified to develop. Alternatively the project manager assign a user story to them instead.

And, especially if you’re implementing a COTS (commercial, off-the-shelf) software solution, look at “Conference Room Pilot” (CRP) or its close relative, Acceptance Test Driven Development (ATDD). They’re good choices for packages because they’re built around business users trying to do their jobs using the package.

They try, that is, with a real-life business transaction. Wherever they can’t process it, they tell the developers locked in the conference room with them what the problem is. The developers, using the configuration tools built into the package, adjust it to make the problem go away. Rinse and repeat.

Agile disrespects architecture: Developers don’t just write code however they’d like. They develop in conformance to a well-defined application architecture — probably a microservices architecture, but what matters is that, early in the project, the team will, collaborating with the Architecture Review Board or equivalent, establish architectural standards to guide development.

Nor do developers modify the data model whenever they face a situation that calls for it. The project’s consulting data designer reviews the suggested data model change with the developer and, once the two have converged on the best approach, makes the changes happen.

An equivalent set of conversations happens with any other developer solutions that don’t fit the company’s architectural standards.

What doesn’t happen is the developer filling out a form to request a change, for review by some governance committee or other.

That would be decidedly not-agile, as a key Agile principle is that individuals and interactions are more important than processes and tools.

It would also, by the way, ignore a key KJR principle: That there is no process so glacial that it can’t be slowed even further by involving a committee.

I’m giving myself a Memorial Day break. I didn’t post anything yesterday, and today is a re-run, from, as the Beatles might have sung, 20 years ago today.

It’s a bit esoteric, but even more relevant today than when I first wrote it.

Take a look and let me know what you think about it.

– Bob

# # #

If there’s one certainty in our business, it’s that useful, lightweight frameworks turn into bloated, productivity-destroying methodologies.

And so it was with considerable trepidation last week that I suggested we need another methodology, to do for Content Management Systems (CMSs — the technologies we use to manage unstructured information) what normalization and related techniques do for relational database management systems (“Unstructured data design — the missing methodology,” KJR, 5/17/2010).

But we do. As evidence, I offer many of the comments and e-mails I received suggesting we don’t: Most pointed to the existence of well-developed tools that allow us to attach metadata to “unstructured content objects” (documents, spreadsheets, presentations, digital photos, videos and such, which we might as well acronymize now and have done with it: For our purposes they’re now officially “UCOs”).

And many more pointing out that search obviates the need for categorization.

Let’s handle search first, because it’s easier: Search is Google listing 16,345,321,568 UCOs that might have what you’re looking for. It’s also what leads to (for example) searches for “globe,” “sphere,” “orb,” and “ball” yielding entirely different results.

Search is what you do when you don’t have useful categories.

And then there’s metadata — the subject that proves we don’t have what we need. Because while we have the ability to attach metadata to UCOs, we have only ad hoc methods for deciding what that metadata should be.

Some readers suggested this might be a solved problem. Books are UCOs, and librarians have been categorizing them for centuries. Between the Dewey Decimal System and the Library of Congress Classification, surely there’s a sound basis on which to build.

Maybe there is. I’m skeptical but not knowledgeable enough to state with confidence they won’t work. I’m skeptical because their primary purpose is to place books in known locations in the library so they can be readily found, which means they’re probably similar to the single folder trees we need to move beyond.

What we need, that is, is the ability to place one UCO in as many different locations as anyone might logically expect to find it. To use one of my own books as an example, Leading IT: The Toughest Job in the World would fit in at least these categories: Leadership, Information Technology, Staffing, Decision-making, Motivation, Culture change, and Communication skills.

The official name for the discipline of defining knowledge domains … what we’re trying to do … is ontology. It’s an active area of development, including the creation of standards (such as OWL, which puzzlingly stands for “Web Ontology Language” instead of “Ontology Web Language,” but let it pass).

From what I’ve been able to determine, though, it appears everything being developed thus far falls under the heading of tools, with a useful methodology nowhere in sight. This is, perhaps, unsurprising as it appears philosophers have been discussing the subject at least since Aristotle first introduced it 2,350 years ago or so, without yet arriving at a consensus.

It could be awhile.

Of course, philosophers are obliged to develop systems so universal they apply, not only to our universe, but to all possible universes. Such is the nature of universal truth.

We don’t need to be quite so ambitious. We merely need to categorize information about our businesses. To get the ball rolling, I’ll offer up the framework we’ve synthesized at IT Catalysts. It enumerates ten topics that together completely describe any business — five internal and five external. They are:

Internal

  • People: The individual human beings who staff a business.
  • Processes: How people do their work.
  • Technologies: The tools people use to perform the roles they play in business processes.
  • Structure: Organizational structures, facilities, governance, accounting, and compensation — how the business is put together and interconnected.
  • Culture: The learned behavior people exhibit in response to their environment, and the shared attitudes that underlie it.

External

  • Products: Whatever the business sells to generate profitable revenue.
  • Customers: Whoever makes or influences buying decisions about the products a business sells.
  • Pricing: What the business charges for its products, terms and conditions of purchase, and the underlying principles that lead to them.
  • Marketplace: The business “ecosystem” in which the company exists, including customer groupings, competitors, partners, and suppliers.
  • Messages: How and what the business communicates with its marketplace.

There you go — a free gift, if you’ll forgive the redundancy. Just break these topics down into sub-topics and sub-sub-topics. The result should be a workable classification scheme.

Let me know when you’re done.