Lori and I were discussing DevOps and surveys the other day, and in what must be described a rare occurrence, we disagreed on the best path to undertake your first DevOps project. Her take is here , and well, you’re about to hear mine.

Lori proposes that agile projects are the best for a first DevOps implementation. Her rationalization is that by doing DevOps where it will come into play more quickly and frequently, the value of DevOps will be readily on display to add weight to requests for more funding/staffing to move on with a wider DevOps implementation.

This is all true, and certainly is worthy of consideration. Indeed, in a perfect world we would do all of the DevOps work as part of the overall project plan, hand-in-hand with developers, so that “finished” meant completely ready to repeatedly deploy, upgrade, and manage. Some shops are headed in this direction, and a very few shops that stand to gain the most from DevOps – highly dynamic environments like cloud providers that need to provision/change/delete systems at a rate that makes most of us think of alcohol – have already gotten to that point. But for your first project, such cooperation is unlikely.

There is a lot to learn in your first DevOps project. The primary perceived benefit of agile development is more iterations, faster. Are you seeing my concern yet? You’re trying to figure what/where/when for the very first time – not to mention the big ‘who’ part – and meanwhile iterations are flying by. For some organizations, there are enough automation bits already in place that this may be a feasible idea for a first project, but for most, let’s not fail to deliver, or worse, rush to catch up and deliver a massive failure, just because we wanted to be fast.

Learn first, rush later. That’s a reasonable motto to live by in DevOps. If an iteration of an agile project is bad, the dev team talks about issues in a stand-up, refactors the workload, and works on another iteration without deploying the broken code. In DevOps, if an iteration is bad, unless you have an entire mirror of your production environment, all of the customers will see it. That’s not good for selling the benefits. Indeed, it is the opposite of good.

So Lori is right, you could indeed gain some great mind-share by doing it right the first time in a high-iteration project, but doing it wrong in that same environment will kill the chances you can get the opportunity to do it more and better.

I’m not a cautious person, but I am realistic. When the cost of failure is high, and the probability of failure due to learning curve is accentuated, pick a project with timelines that will allow you to do an excellent job of showing off the power of DevOps. That means giving you time to digest the new processes, procedures, automation tools, and testing goals. Agile reduces that time, and while an agile project may fit your needs perfectly, chances are, you’re better off approaching the first project with extra time built in to learn.

Of course, neither Lori or I mentioned the real killer in first DevOps projects (though we both have in blogs before now). That’s complexity. Don’t go for the complex project first. The more there is going on, the more lines of control, automation tasks, hidden dependencies, and just flat-out gotchas you’ll find… And the greater the risk to successful delivery.

Even if you’re not trying to garner the attention of those holding the budget purse strings, successful delivery is certainly a key indicator to ability/willingness to implement more DevOps projects. And if making it all automated with lines of communication that facilitate rapid recovery of errors, and reduce call times are your goals… well success in the first project, even if not hugely visible, is important.

If you are lucky enough to be able to roll DevOps right into the development effort of an agile project, and grow the DevOps side as the dev team is adding functionality on the development side, by all means it is a worthy attempt, even for a first project. But if you are automating an agile project already well along in its lifecycle, think twice, consider the timelines for releases, and the issues that have to be considered for that particular project, before you commit to investing your initial (presumably limited) DevOps resources there.