All Posts by Bob Lewis

|In: App Dev Methodologies|Last Updated:

“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.

Comments

|In: Strategy and Tactics|Last Updated:

Businesses that adopt Agile often miss out.

Don’t misunderstand. I’m all in favor of Agile development, although I’m less than sanguine about its ongoing evolution from simplicity and charm to complexity and excessive proceduralization.

But the missing out comes from a failure to recognize what Agile isn’t, namely, it isn’t limited to application development. Agile is a way of thinking, not a series of steps. And its way of thinking applies to any situation where an organization needs to address some set of problems and opportunities with a design and a plan, but the problems and opportunities are deeply fluid.

And oh, by the way, those whose opinions about the problems and solutions govern decisions are in flux as well.

Start by imagining, just hypothetically you understand, your boss calls on you to charter and launch a new department. It will be called the Math Department and its purpose is to solve math problems for the rest of the enterprise.

Any and all math problems.

Tell her when you’ve finished the assignment.

Hoo Hah! Say what?

Further imagine your professional career began in IT, where you were schooled in Waterfall methodologies.

And … you’re doomed.

To design the Math Department you need to understand Math. Which you start out to do, reading everything you can get your hands on about Math.

But the more you learn about Math, the more branches of mathematics you learn about. The subject is, as Einstein … using math, by the way … pointed out about the universe, finite but unbounded. So you go back to your manager, explain the impossibility of carrying out your assignment, polish your resume, and don’t look back.

Or, you could apply Agile methods.

You’d start with a few Epics … say, basic arithmetic, algebra, and trigonometry. These would comprise your initial Backlog.

You’d then take the simplest and, happily, most needed of the Epics from the Backlog … arithmetic … write user stories (yes, you could turn story problems into user stories), and write a position description to hire someone who can solve all the user stories. Which is how you come to hire Michael Vincent Peterson. You nickname him MVP (did I really need to spell this out?) and the Math Department is off and running.

Well, walking anyway.

Once Arithmetic Services is stable (are stable? No, it’s a thing — “is stable”) you follow the same pattern for algebra, and follow that pattern for trig.

It’s right about here you discover that just having experts isn’t enough. The Math Department has become popular enough that it needs some level of management — enough to decide how to process requests and set priorities. How should you handle this?

The same way: You add an Epic to the Backlog, this one for designing and implementing Mathmanagement (catchy, eh?), just as you’d do if one of your executives came along to tell you he needs the Math Department to handle differential calculus.

If you boil Agile down to its essentials, you’ll find principles you can apply to a whole lot more than application development, for example, the principle that there’s little point spending time designing solutions you won’t be in a position to implement before they become irrelevant.

So the moral of this story is that more often than not, businesses can achieve important large-scale change one small change increment at a time. And they can do so with far less disruption and risk than trying to design a comprehensive solution.

Which gets us to two consequential and immutable universal laws. The first, articulated by my college roommate Jack Buckmiller states, “If a meal takes longer to cook than it takes to eat, you’ve done something terribly wrong.”

Add Lewis’s corollary: “Buckmiller’s Law only counts the time I spend cooking a meal, not the time someone else spends making one for me.”

I’m pretty sure these are relevant to the subject at hand. You’re welcome to disagree.

In any event, a second, contemporaneous but somewhat better known rule is Gall’s Law: “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.” (John Gall, Systemantics: How Systems Really Work and How They Fail (1975))

To which I suppose we should add one more non-business-derived business principle. It’s something I learned in Driver’s Ed: Don’t over-drive your lights.

Comments