3

Fixing Agile

Consultant (n) A form of management advisor specializing in fixing what’s broken by breaking what’s fixed.

—Sheldon Seymour Jr.

Interlude: AgileShock

Not too many years ago we had to replace the core applications that ran a large portion of our business. The applications did what we needed them to do, but they were built on a last-generation platform that was quickly becoming a no-generation platform.

Some analysis revealed that trying to shoehorn a commercial package into our business was a nonstarter for the specialized services our company offers. Rewriting was our best alternative, no matter how expensive and risky it seemed.

My team was used to operating as a craft shop, which made sense on the old platform. We had a clean architecture and seasoned programmers. The combination let us handle as one-programmer enhancements what would have turned into small projects in most companies.

On top of this, our programmers weren’t shy about talking things over directly with the business users. I figured we were already halfway to Agile. Scrum seemed to be the most popular version, so I figured, how could I go wrong?

The project nearly failed within a year.

Here’s what went wrong.

The techniques needed to rewrite a major application were outside our day-to-day experience, so I brought in some very talented developers who knew the new technology and had extensive experience with Scrum. My plan was for these experts to train my existing staff on the new technology and on Scrum. We recruited product owners, and the project was off and running.

It turned out our hired experts had no interest in learning our company’s collaborative business culture. For that matter they had no interest in learning our IT culture either. Scrum was as much a religion for them as a set of techniques, so within a few months my internal staff started to revolt, claiming the outside experts didn’t respect their knowledge and expertise. For their part, our hired experts told me my internal staff were behind the times and refused to change.

I had to make a critical decision. It wasn’t hard. I liked our culture— business and IT—and if the outside experts thought it needed to change, there was only one possible answer.

So out they went, and we went in search of a way to fit Agile into the business instead of forcing my business and IT management… and I’m including myself… to adapt to textbook Scrum.

Then, my team did what my team did best: they figured it out. We discovered there’s more to Agile than Scrum, and a different version, called Kanban, fit our way of working quite well.

The result: after losing six full months of actual development time, we brought in the project under budget and ahead of schedule.

Not to mention getting terrific reviews from our business collaborators.

Projects are the way organizations make tomorrow different from yesterday. Project management is the practice (not process) of understanding what work has to be done to achieve the project’s goals and making sure that it does, in fact, get done when and how it’s supposed to get done.

Within the overall realm of projects and project management, IT projects in particular have acquired a reputation for delivering disappointing results. And those are the more successful ones. Many deliver no results at all.

Which gets us to the subject of this chapter: Agile project management.

There are two types of IT organizations: those that have embraced Agile and those that continue to suffer from a high rate of project failures.

Okay, that’s a bit strong, but just a bit. According to the Standish Group, in an analysis of more than ten thousand projects, Agile projects were more than three times more likely to succeed than their Waterfall equivalents (see figure 3).¹

FIGURE 3 Project success comparison, Agile vs. Waterfall.

Agile is a big honkin’ deal. In case you’ve heard of DevOps* and are wondering, it’s both important and badly misunderstood. It’s one Agile variant among many, and while not a big honkin’ deal, it’s certainly a midsize one.

But it isn’t different enough from other Agile variants to warrant a separate discussion in this book. In this chapter we focus on the whole family of Agile methodologies, how and why Agile is superior to the Waterfall methods it’s replacing, and why Agile needs fixing if it’s going to survive the transition from IT-as-vendor to IT-as-collaborator-in-intentional-business-change. Just about everything we’ll say applies to DevOps too.

What Are These Waterfall and Agile Things of Which You Speak?

In case you haven’t bumped into Agile or been bumped by it, it’s a way to design and build software that’s proven vastly superior to the traditional way of going about it.

The traditional alternative is called Waterfall, because it divides the process into phases; and once you finish a phase . . . once you go over the Waterfall . . . it’s expensive and disruptive to go back to the top.†

Waterfall methodologies typically divide application development into Feasibility (a silly name, as with rare exceptions the actual programming is always feasible), followed by Requirements Gathering, External Design (what it’s supposed to look like), Internal Design (think block diagrams), Specifications (blueprints), Development, Testing, and Production.

Waterfall techniques aren’t limited to application development. Any project that divides work into sequential phases, each of which must be completed before the next one can start, is by definition Waterfall.

Which means what follows matters even if you don’t ever expect to have anything to do with implementing information technology (which probably means you’re a year or less away from retirement, but who are we to judge?).

So even if you’re entirely uninterested in application development, PAY ATTENTION to . . .

Waterfall’s Wrong Assumptions

Anyone who has ever planned anything by dividing the work into sequential stages has, knowingly or otherwise, made use of Waterfall techniques.

Waterfall seems so logical. But logical or not, Waterfall techniques rarely work—not because of bad execution but because Waterfall is built on several wrong assumptions, which matter no matter what you’re dividing into stages. They are:

•   Constancy: For Waterfall to work, the assumptions, conclusions, decisions, and designs you made yesterday will have to fit the world as it will be tomorrow. That’s fine for short projects, short meaning certainly no more than six months; three is better. Beyond that, as everyone knows,* change is the only constant in business and the rate of change is accelerating.

Whatever decisions a design team makes, many will change from right to not so right long before the time comes to put whatever it is the team is creating to productive use.

With Waterfall, whatever goes into production is designed for the world as it used to be, or maybe for a three-year-old three-year forecast of how the world should have turned out. See “Procrastination is a virtue” below.

•   Envisionability: Okay, we made the word up. So sue us. Waterfall means you design everything before you build anything. For this to work out, designers have to correctly envision, in detail, how whatever it is that’s being implemented should work.

Good luck with that. Someone a long time ago² researched people who designed their own homes. It turned out that most of them designed, built, moved into, and then sold or tore down the first two because they didn’t like living in them.

When envisioning even something as familiar as living in a house takes three tries to get it right, why would anyone expect developing software or implementing a business strategy to be any different?

•   The SSC ratio: This is the “Stay the Same/Change” ratio.³ It’s how long whatever you’re implementing will continue to be relevant and useful—how long you and it will be able to stay the same—compared with the time needed to implement it. Think of it as how long food you grow and prepare lasts before it becomes too moldy to eat.

The acceleration of change means the time-to-mold metric is getting shorter, but the time needed to plant, grow, harvest, and cook isn’t.

Okay, we lied. These assumptions aren’t always flawed. Quite the opposite. Consider the case of the successfully constructed office building. You’ll find the above assumptions fit construction projects quite nicely.

Which shouldn’t be surprising. A lot of project management theory started out by looking at successful construction projects. Then the analogists got hold of things, and, as is usually the case, it all went sideways: “Designing and building software must be just like designing and building a skyscraper, you see, because both of them have to be designed, then built.”

If we’re going to use construction as our metaphor, designing and building software is more like designing a building for a piece of land and then having to build the building on a different piece of land, in a different climate, with building codes that change halfway through the project.

So no, the one isn’t just like the other.

Agile’s Essence

Agile methodologies, and there are at least a half dozen of them, don’t make these assumptions. At its core, Agile is built on a few key principles that, with apologies to the Agile Manifesto,⁴ are, for our purposes at least:

•   Programmers don’t need translators. In chapter 2 we talked about the business analyst of the future. Now let’s be honest about the business analyst of the past. Much of their trade was based on the utterly preposterous premise that programmers need someone to listen to business users, translate “UserSpeak” to “ProgrammerSpeak,” then listen to programmers’ replies, translating their words back into UserSpeak.

We’ve worked with hundreds of programmers and other technical professionals throughout our careers, and what’s amazing about them is how many have friends, spouses, children, and pets who aren’t also technical professionals and yet are entirely capable of communicating with them.

In Agile projects, developers talk with businesspeople, and they do so frequently and informally. They also learn the business to the point that they can assist in envisioning solutions that are both creative and realistic, as the developers have their toolbox in mind as they talk.

•   Programmers often do need reorientation. Programmers can and do have conversations with business managers and end users right “out of the box.” That doesn’t mean they automagically acquire empathy for what their change collaborators have to deal with every day.

A technique that works in many situations is to reassign the development team to work in the affected business areas so that they have to do the actual work using the actual processes and systems targeted for replacement. They’ll get to know the end users and managers as actual human beings, and they’ll experience their frustrations firsthand.

•   Big solutions that work start out as small solutions that work. Even big legacy systems obeyed this rule. Look at their history and you’ll find each one started out as a small system, the result of a business manager asking a programmer, “Can you make the computer do x?” And, once the programmer got the computer to do x, asking, “Now can you get it to do y?” Y built on x, z built on x and y, and after a year or three a big system was up and running.

This worked for two reasons. The first is envisionability: small enhancements are easier to envision than big systems.

The second is a human characteristic: people, including developers, stay motivated when they see progress. Building a big system one small piece at a time means progress is constantly apparent.

Agile turns this into a formal methodology.

•   Procrastination is a virtue. More precisely, delaying decisions as long as possible, so that you’re relying on your ability to predict as little as possible, is a very good idea. If the future you have to be right about when making a decision is one year ahead, you’ll base your decision on a more accurate forecast than you would looking three years ahead.

Don’t, however, procrastinate so long that your decision becomes irrelevant. Also, don’t procrastinate about building flexibility into the application’s core architecture.

Without this, Agile can result in teams painting themselves into a metaphorical corner. With it, they can change direction quickly as business situations change.

•   Small chunks are less risky than big chunks. The word is “incrementalism,” and in terms of both risk per chunk and bang per buck, incrementalism wins every time.

It must be said: in proportion, small bangs deliver bigger bangs than big bangs, and deliver them more reliably.

The challenge is getting the small chunks to come together, jigsaw puzzle fashion, to make a picture that works when viewed as a whole as well as in the details.

The secret to this is . . .

•   Iteration. Imagine you’re playing miniature golf. The hole presents the usual mini-golf challenges of slopes, obstacles, caroms, and such. Waterfall means hitting balls from the tee box until you get a hole in one. Agile’s iteration principle means playing miniature golf as we’re accustomed to it. We start in the tee box and then hit each shot from where the previous one ended up until the ball falls into the hole.

At least, that’s part of the secret. Agile does have its own challenges IT has to address, most of which have to do with coherence. Coherence challenges enter into Agile projects at two levels.

The first is technical, a matter of making sure all the different pieces are built to a single set of engineering standards. The second is aesthetic, a matter of making sure different developers adhere to a common user interface style. Both are manageable enough that for the purposes of this book we don’t need to explore them in more depth.

But if your IT organization hasn’t yet taken the Agile plunge, it will need to explore these challenges in more depth.

One other point: if your IT organization hasn’t already made the shift from Waterfall to Agile, you’ll need that to happen. This isn’t a book about accomplishing the IT Waterfall-to-Agile transformation. If you do need to head down that path, keep one point firmly in mind: as with any other shift that entails changes to core and often hidden assumptions, culture change is the lead story, not process, and in fact it’s fair to say many of the unsuccessful attempts at this transition failed because they focused on process and not culture.

But

Agile as usually practiced has three . . . well, they aren’t fatal flaws, but they’re still serious challenges.

Flaw #1: Agile projects are still IT projects. Agile projects deliver a software product to IT’s “internal customers.” Agile violates the no-such-thing-as-an-IT-project rule.

And it’s quite explicit about it. It starts with Agile’s insistence that there be a “product owner” in the business who has the authority and expertise to make decisions about product features and priorities.

It ends with how Agile practitioners express the items in their to-do lists . . . as “user stories,” which are descriptions of what the software should do from a user’s perspective, and why.

It’s about the software, not about the business change.

Flaw #2: Agile methodologies address what IT does least. A problem that might appear trivial but that actually matters quite a lot is that most IT shops follow a straightforward principle—they buy when they can and build when they have to.

It’s a logical consequence of simple long division. When a company builds an application, it pays the entire cost itself. When it buys an application, it shares that cost (indirectly) with all of the other customers of the company that sells it.

Also, when a company decides to buy, whether it’s software installed in the company’s data center (COTS) or software that runs in the cloud (SaaS), the design and programming are finished, while when IT builds from scratch the design and programming haven’t begun.

As you’re buying a finished product, business benefits should show up more quickly than when you build from scratch.

So while there are trade-offs, in most enterprises, most of the time, the buy/build principle provides valid guidance.

And yet, most Agile variants are about building software from scratch, even though what IT does the most is install, configure, and integrate packages. Not only do most Agile practitioners ignore this little fact, but when companies install, configure, and integrate packages, the way they go about it, as described earlier in this volume, often intentionally minimizes the value they get from their effort. They do their best to make their shiny new system behave exactly like the old, tired one it’s replacing.

Flaw #3: The strategy-to-action impedance mismatch. Truth be told, few businesses are competent at turning their strategic intent into an actionable plan of any kind. All too often, the so-called strategic plan is little more than a touchstone—a description of the hoped-for future, to which all proposed projects should “be in alignment,” which is to say, they have to be consistent with the strategy.

But any manager with a gram of creativity knows how to write a two-paragraph explanation of how whatever it is she wants to do is well aligned with the company’s strategy.

And even when a project really is well aligned with strategy, that’s very different from advancing the strategy.

Some companies are better than this. They do know how to turn their strategies into plans of action.

But their plans, while not bounded by IT delivery, are still Waterfall plans of action. They define strategic programs, which are composed of major initiatives, each of which consists of a project road map, all nailed down into a linear plan.

Organizing change like this is, we hasten to add, nothing to sneeze at. Building out this sort of plan requires vision, courage, and trust, not to mention quite a lot of cash and a willingness to say no to project proposals that usually are worthwhile, not to mention strategically aligned.

And yet, Waterfall strategy-to-action plans suffer from the same flawed assumptions as most other Waterfall-based projects. Courtesy of the SSC ratio, the methods that made sense when five-year or ten-year strategic plans were useful are no longer sustainable.

But imagine for a moment they were, that you could create a Waterfall-oriented five-year strategic plan and it would hold up for enough years to matter.

Now imagine that, as is the case with most other forms of business change, your business strategy depends on information technology to succeed.

As you’ve seen, Agile application development is far more reliable than Waterfall application development.

Which leads to a sort of impedance mismatch between how you’re organizing and managing strategic change and how you’re organizing and managing the application delivery it depends on.

Enter something called the Scaled Agile Framework (SAFe; the mysterious “e” at the end is gratuitous). Its purpose is, as its name suggests, to allow Agile to scale to strategic-program-size efforts. It is, regrettably, complicated where Agile is simple, high-overhead where Agile isn’t, and dependent on centralized oversight where Agile is distributed.

It is, to our eyes at least, Waterfall with a thin Agile skin on it.

It’s also probably necessary if Agile is to be synced up with strategic program planning and management, at least as it’s usually practiced. And yes, we do provide an alternative. Read on.

Fixing Agile

If you’ve managed to slog through all of the above, you’ll see that for Agile to go beyond product delivery to be the methodology of choice for achieving intentional business change, we have some work to do. Not overwhelming work, but work nonetheless. Specifically, we need to adjust Agile to:

•   Deliver business change (of course)

•   Deliver business change in tandem with COTS/SaaS package implementations

•   Sync up with strategic plans

What follows are sketches, not instruction manuals. Our hope is that you and your fellow organizational change drivers will find them useful as guides for developing and sharing your own techniques.

One at a time …

Modifying Agile to Design and Deliver Business Change

Good news! We mostly covered this in chapter 2. To save you the effort of skipping back and forth:

Step 1: Rank the six dimensions of optimization—fixed cost, incremental cost, cycle time, throughput, quality, and excellence—in descending order of importance.

Step 2: Decide whether any or all of the top three dimensions are unsatisfactory. If none of them are unsatisfactory, be happy and find something else to occupy your attention. Otherwise, any highly ranked and unsatisfactory dimension is called a pain point.

Step 3: Map out the business process. We’ve found that a combination of black-box analysis, which describes processes in terms of their outputs and inputs only, and so-called swim-lane diagrams for describing the actual process flow is a good way to go about this. In any event, process mapping is a vital skill for any business analyst who wants to become an internal (or, for that matter, external) business consultant.

Beyond this, as we already explained in chapter 2, this book isn’t the place for a detailed account of this well-explored discipline.

Step 4: Identify the worst bottleneck steps in the process map, with bottleneck defined as a process step that causes a pain point.

Step 5: Fix one of the worst bottlenecks. If you can’t fix a bottleneck without changing or replacing one or more business applications, as is the case more often than not, work with IT to change or replace them.

Step 6: Loop to step 4 until you reach the point of diminishing returns.

This process is intrinsically Agile: It’s iterative and incremental. It augments Agile’s Product Owner role to the status of Business Function Steward. We say “steward” rather than “owner” because owners say, “It’s mine!” where stewards manage something on behalf of someone else.

Characterize what applications have to do to support each bottleneck removal as user stories and you’re about done. Because you’re fixing one bottleneck at a time, priority setting is automatic; this greatly simplifies the backlog prioritization that can bedevil a more traditional Scrum team.

Agile COTS and SaaS

The most popular and best-known Agile variants, Scrum and Kanban, describe what software is supposed to do using three levels of focus: epics, which describe something the system should do in very broad terms (for example, create and edit documents); features, which list capabilities needed for an epic to be satisfied (for example, enter text, format text, store documents as files); and user stories, which describe something specific a user wants to do (standard form: As a document creator I want to be able to define styles that describe all formatting for selected text, so I can easily format document parts consistently).

Epics are composed of features; features are composed of user stories.

When you license a COTS or SaaS package, your friendly application vendor has already defined all of these for you as part of writing the package.

So when you’re implementing a business change and want to take advantage of the package’s capabilities, there’s no point in defining your own epics, features, or user stories. They’re already embedded in the package.

Which doesn’t mean you can just install it, train the users, and be happy. Far from it. You also have to convert and load data and integrate the package with your existing applications and data repositories—meat-and-potatoes activities mostly outside this book’s scope.

What we need, and what we’re about to provide a sketch of, is an Agile approach to package implementations that don’t stop with implementing the package. It’s using Agile principles to make the affected parts of the business run differently and better, synchronizing and incorporating COTS or SaaS package reconfiguration into the heart of the implementation practices.

The Agile way of accomplishing this is called CRP (conference room pilot), which has enough similarities to another Agile variant called ATDD (Acceptance-Test-Driven Development) that we consider them interchangeable.

Here’s the step-by-step:

Step 1: Hire or train an IT system guru or two. You’ll need someone who can make the package you’re implementing sing, dance, and play the tuba for what follows to work. While you’re at it, work with managers from the affected business areas to assign to the team several employees who are the most knowledgeable in their areas regarding the business functions the new system will be supporting.

Step 2: Installation. Install the package, convert and load the master data, and hook it up to whatever integration technology you use so its data stay synchronized with everything else lying around. IT handles this task on its own.

Step 3: Collect test cases. Either print out a stack of randomly selected business actions processed the old way over the past few months or use your knowledge of such things to create formal test cases.

Step 4: Lock the team in a conference room, along with the test cases and system access. Arrange to have coffee, other caffeinated beverages, and the occasional pizza delivered. We suggest you also establish plumbing allowances—there’s no reason to be mean.

If you can’t bring everyone together to a single physical facility . . . try harder to make that happen. This all works much better when everyone is face-to-face. But if you can’t, that’s where ATDD comes in.

Google it for protocols that fit your situation. We aren’t going to cover it in depth here, beyond recognizing that it is sometimes an issue. Deal with it as you deal with any other situation in which people who can’t be colocated still have to function as a team.

Step 5: Start processing the test cases. Whenever a business user can’t process a test case, she explains the problem to one of the system gurus, who then makes use of the package’s built-in configuration tools* to make whatever adjustments are needed to process the test case.

Step 6: Loop to step 5 until the application can process all of the test cases, except for those where it makes more sense to kick them out for manual exception handling. For those, document how to kick it out and how to reenter it into the flow of work once it’s been handled.

If all goes according to plan, the step 5/step 6 loop will take place in two very natural, overlapping phases. During the first phase, users won’t be able to process many test cases at all. Phase 1 is about making the application competent.

Phase 2 is about optimization—making the business function more effective through the use of the new application. During this phase, users won’t be explaining why they can’t process test cases anymore. They’ll be explaining that if IT could just get the application to do this (“this” being a placeholder for a bright idea the business user has), the process would run much better.

This is, by the way, why you need application gurus and the best and brightest business users on the project. Guru-level developers will know what the application is and isn’t capable of. Best-and-brightest business users will recognize hidden and correctable inefficiencies.

Synchronizing Agile Methodologies with Strategic Planning

As a reminder, the problem we’re trying to solve is that strategic planning generally results in Waterfall-style implementation plans that require information technology best implemented Agile style: iteratively and incrementally.

The most popular solution is SAFe or something like it.

Our thinking: SAFe’s proponents are looking at the wrong end of the horse. Instead of establishing all the management overhead you’ll need to scale Agile to strategic proportions, rethink how you go about planning and implementing strategy in order to make it Agile (and therefore, agile).

Here’s one way of going about it, what we call the 3,1,3,4 approach. By the numbers:

3-year vision: This is what you want your organization to be and to accomplish. You should be able to explain it in clear, direct terms. This isn’t the place for nuance.

And if you’re a loophole sort of person, sorry, run-on sentences are cheating.

An example, if you’re looking for one: “In three years, IT will be the company’s partner in designing change and a leader in making it happen.”

1-year strategy: This is the one-year down payment on your three-year vision. As is the case for your vision, you should also be able to express your strategy in one or two simple declarative sentences: “This year, our goal is to achieve a’culture of discipline’—a shared way of thinking and acting that means every employee makes good decisions instead of managers having to enforce them through oversight.”

3-month goals: Here’s where it starts to become real. Anyone can look out three years, or even one year, and articulate brilliant outcomes. Three months is another matter. Three months is urgent. It’s immediate. It’s hard to escape.

Developing goals for the next three months isn’t particularly challenging. What’s difficult is for each department to develop goals that fit together in ways that move you toward your one-year strategy.

Our best advice: Don’t worry about it at first. Establishing the habit of putting down any list of three-month goals throughout company management is an interesting enough challenge.

Once the organization is in the habit of setting and accomplishing its separate departmental three-month goals, that’s the time to establish a planning process that includes the fit-together requirement.

After that you can start to encourage goals that don’t just fit together; they call for active collaboration among multiple departments.

4-week plan: This is where the rubber meets the road. It’s what you intend to achieve each week for the next month to make sure your three-month goals turn into accomplishments at a steady pace.

We said “your vision, your strategy, your goals, and your plan,” but that’s wrong, for two reasons.

The first: if that’s all they are—your vision and strategy in particular—you’ll fail. Your management team has to embrace the vision; it has to be theirs as much as it is yours.

Your direct reports have to have their own strategies, all of which add up to moving your part of the organization forward toward its vision.

The goals have to be their goals even more than they are your goals, and fan out from strategy just as strategies fan out from vision.

Likewise, “the plan,” which is the composite of all the individual plans, should be shared so that everyone knows what anyone knows.

At the end of each month, everyone who owns a plan reviews progress and replans based on how much actually got done and on the extent to which situations and assumptions changed. Likewise, goals should be reviewed on a quarterly basis, and strategies annually.

It’s the frequent replanning that makes both the 3,1,3,4 approach and the organization agile: It expects and adapts to change naturally. It broadens ownership, collaboration, and consensus.

And it takes advantage of all of the knowledge about What’s Really Going on Around Here that exists throughout the organization.

What’s left is checking off the details as the organization completes them. That and all the hard work of making it all happen.

Don’t make the mistake of minimizing the hard work just because other people have to do it. Compared with their work, all of your planning is pretty easy.

If You Remember Nothing Else …

•   Agile is a way of thinking before it’s a set of specific techniques. It starts with high levels of direct, developer-to-user interaction and depends on iteration and incrementalism for success.

•   The bigger the project, the higher the risk of failure. Most multiyear projects fail, in part due to their complexity and in part due to their design assumptions being superseded by the business changes that have taken place since the project was launched. Success comes from singles, not home runs.

•   IT mostly buys, integrates, and configures COTS/SaaS packages, not in-house-developed applications. The best Agile variant for this work is CRP, not Scrum.

•   Agile as currently defined and practiced is all about software product delivery, not about achieving intentional business change. Enhancing it to “extend the goalposts” isn’t all that hard, but it does take more than just saying the words.

What You Can Do Right Now

•   Introduce all Agile project managers, coaches, mentors, and thought leaders to the idea that their jobs are no longer done when the software implementation has delivered all epics, features, and user stories in the backlog. Their projects must include everything required to achieve intentional business change.

•   While you’re at it, introduce the same group to CRP and/or ATDD as the starting point for implementing commercial software.

•   Introduce the company’s strategic planners to the concept of Agile business strategy formulation, including the 3,1,3,4 planning framework (3-year vision, 1-year strategy, 3-month goals, 4-week plans) as an alternative to Waterfall-style strategic planning and its intrinsic need to “scale Agile.”

* In case you’re wondering just what the heck is DevOps anyway, don’t worry about it. From the perspective of achieving intentional business change, it’s just one more variation on an Agile theme.

† No, it isn’t called Waterfall because once you go over it you crash onto the pile of rocks at the bottom and aren’t likely to survive the experience.

* Usually, what everyone knows is wrong. Not in this case, though.

* A hard-and-fast rule applies here: when processing requires the software to do something it doesn’t do out of the box, IT will make use of user-definable data fields, user-configurable business logic, and the package’s built-in workflow definition tools, and in extreme cases will program satellite applications that connect to the package through whatever integration technology IT relies on.

IT will never customize the application itself. The long-term cost of maintaining application customizations is hideous.