Agile should be yesterday\u2019s news. Really, yester-decade\u2019s news. The Agile Manifesto appeared nearly twenty years ago, and unlike Athena, who sprang fully grown and armored from Zeus\u2019s head, many of us had practiced or encouraged agile-ish techniques long before the manifesto made them official.\nAnd yet, some fearless holdouts have managed to keep agile, with its higher rates of success and business satisfaction, at bay. If you\u2019re among them and you\u2019re under pressure to \u201cgo agile,\u201d it\u2019s time to stop feeling like a dinosaur waiting for the asteroid to hit. Here are seven proven ways to take the offensive and surely prevent agile from happening to your IT organization without you gaining a reputation for being sand in your company\u2019s progress gears.\n[ Looking to make the switch to agile? Check out our switcher's guide to agile project management. | Learn agile's darkest secret and how companies fail at agile. | Get the latest project management advice by signing up for our CIO newsletters. ]\n1. Call it Agile. Make it haphazard\nAs you launch your next project, insist the project manager run it the \u201cagile way,\u201d with everyone on the team figuring out each morning what they can do that day to move the project in whatever direction they think is forward.\nTesting? When the team is ready to test a feature, let the product owner know today you\u2019ll need business staff to bang away at the feature tomorrow. If they won\u2019t be available tomorrow, that\u2019s okay. It just means that feature will have to slide into the next sprint.\nAnd if the product owner complains about the project not staying on schedule, well, this is the beauty part: Just explain that \u201cagile projects\u201d don\u2019t have schedules.\nAfter all, agile means \u201cNo Plan,\u201d doesn\u2019t it?\n2. Ignore architecture\nDon\u2019t waste time early in the project defining the application architecture. If agile means requirements continuously evolve, shouldn\u2019t the application architecture continuously evolve, too?\nSo don\u2019t constrain developer creativity by insisting on conformance to a bunch of abstract principles. Instead, empower your developers. Let them develop however they want to develop, structuring their modules and interfaces however they like. And if different modules from different developers don\u2019t plug and play together, or different developers write code that depends on different libraries, don\u2019t worry about it. That\u2019s what refactoring is for.\nHeck, if different developers want to develop in different languages, well, that\u2019s what containers are for, isn\u2019t it?\n3. The answer is Scrum. What was the question?\nAgile isn\u2019t a methodology. It\u2019s a family of methodologies, each suited to a different sort of project. Scrum has emerged as the most popular, not because it\u2019s \u201cbest practice\u201d but more likely because it\u2019s the most rigidly structured agile variant, making it closer to a waterfall shop\u2019s comfort zone than any of the others.\nEspecially, Scrum is poorly suited to the commercial off-the-shelf software (COTS) and software as a service (SaaS) implementations that constitute the majority of projects IT undertakes. A different Agile variant, conference room pilot (CRP), or its close relative acceptance test driven development (ATTD) are better alternatives.\nBut who\u2019s ever heard of them? In all likelihood, nobody who matters. Even your strongest political opponents won\u2019t criticize you for choosing the most popular agile variant, and that\u2019s if they know there are other agile variants to choose from.\nSo when things go sideways with your Scrum-driven COTS implementation, it won\u2019t be because you should have known better. Well, it will be, but you can claim the project failed because agile was never a good idea in the first place, and you can safely hint that anyone who argues otherwise is just nitpicking to protect themselves.\n4. Play leapfrog \u2014 from Waterfall to SAFe in a single bound\nAgile\u2019s charm, and its greatest strength, is its simplicity. Its greatest weakness is that it doesn\u2019t scale all that well.\nSmart businesses keep agile agile \u2014 so much so that they extend agile principles to encompass, not only software implementation, but all business change. Viewed from this angle, large-scale strategic plans are intrinsically waterfall in nature and fail for the same reasons IT waterfall projects fail: They\u2019re linear, with lots of interdependencies and single points of potential failure; and they\u2019re built on assumptions about the future that will change at least twice by the time the future gets here.\nBut never mind all that. The CIO\u2019s job isn\u2019t to make the business more agile. It\u2019s to support the business strategy, whether or not the strategy has any chance at all of actually working. And as agile doesn\u2019t scale to strategic-program-size plans, IT needs to adopt a methodology that sounds like it\u2019s agile but scales like it\u2019s waterfall.\nWelcome to SAFe \u2014 the so-called Scaled Agile Framework (where the \u201ce\u201d comes from is an enduring mystery). But whereas agile itself succeeds through methodological simplicity, SAFe is godawful complicated, with as many moving parts, potential points of failure, and assumptions about the future as waterfall does, with the added bonus of being unfamiliar.\nUnderstand, SAFe isn\u2019t intrinsically bad. But it requires experienced practitioners and quite a lot of program infrastructure.\nIf SAFe is what the business needs, SAFe is what IT will do, leaping across the Waterfall-to-SAFe chasm in a single bound, never mind the risks.\nThe program will fail, but your hands will be clean. You already warned that agile doesn\u2019t scale.\n5. Insist your development partners use Agile. Also insist they agree to fixed price bids\nOf course they have to use agile. It\u2019s better, isn\u2019t it? And besides, you\u2019re schooling every manager in the business in how to work with IT the agile way.\nAnd of course vendor bids have to have a fixed price tag. That\u2019s the only way to keep vendors honest. Otherwise they\u2019d have a \u201cperverse incentive\u201d to slip the project budget and schedule.\nAnd if a vendor has the temerity to point out that starting with a fixed scope and only changing it through rigid change control governance is the antithesis of agile, well, it\u2019s a good thing you learned how difficult that vendor would be to work with before signing a statement of work.\n6. Offshore agile\nIn theory, business planners set goals for revenue, cost, risk, and achieving the business mission. In practice, in most businesses, the projects approved for actual execution are the ones that cut costs.\nWhat better place to start than the rates you pay for developer hours?\nSo when you engage a development partner, make sure most of its team members live and work 11 time zones away.\nYes, agile principle #6 emphasizes the importance of face-to-face conversations \u2014 among developers and between developers and business users. No, offshore developers won\u2019t participate in them.\nThat\u2019s okay. Ignore it. It\u2019s just theory. Given a choice between saving money and abstract principles, those who save money are the hard-headed businesspeople we need around here.\nAnd when the agile \u201cteam\u201d delivers modules that, when they do hit a bullseye, hit one that\u2019s in the center of the wrong target, that\u2019s okay too. Those modules will have cost a lot less, and IT can always fall back on the tried-and-true explanation that \u201cthe business\u201d wasn\u2019t clear about its requirements.\nThat the requirements weren\u2019t clear because of too little face-to-face communication won\u2019t even occur to anyone who matters.\n7. Make it all about process\nYes, yes, yes, we all know that the Agile Manifesto prizes \u201c\u2026 individuals and interactions over processes and tools.\u201d\nBut if there\u2019s one thing management has learned over the past few decades it\u2019s that success in business depends on instituting well-defined repeatable processes. Success doesn\u2019t come from relationships, or from employees collaborating to figure out better solutions together.\nNo, success comes from employees following the processes, step by step as the swim-lane diagrams prescribe.\nAnd as every process designer knows, a good process leaves nothing to chance. It\u2019s up to you to make sure your agile process, like all other good processes, describes how the process flows from bucket to bucket to bucket, with every decision point described as a process branch while everyone involved turns their inputs into outputs that become the next employee\u2019s inputs.\nAdd enough complexity to the Agile process flow and eventually IT will extend the reach of the EPMO\u2019s project management process enforcement police so they keep a watchful eye on your agile coaches, just as they\u2019ve been keeping your waterfall project managers in line all along.\nRemedy: Get with the program\nIf the seven strategies outlined here strike you as unappealing, you do have one more alternative.\nYou could surrender to the inevitable.\nYou could, that is, acknowledge that agile really does work better than waterfall and give it an honest shot.\nIt will hurt, but think of it this way: knee replacement surgery hurts too.\nBut in both cases, in the long run, avoidance hurts worse than making it happen.