Getting good people just to talk to each other within an enterprise is a difficult and common problem. We all know that retaining knowledge within an organisation is critical to its well being and for any given problem there are only a few people that can solve it, given the opportunity.

So, your team is on its Agile journey and you can more or less track a deployment from a story, through git commits, to an automated builder, to an artefact repository, into a container, and then onto the cloud. Or, in fact, any other of the many valid variants that lead you to believe your deployments are largely automated. What you can point to is that a business request comes in and the result is a service or a new app. Your purview seems to stop before your users can even respond though; is that good enough?

There is some healthy tension between a good DevOps team and the concept of continuous delivery. In the past, a simple Agile team would build products and let the delivery manager worry about what happens in production. With the coming together of Dev and Ops, as the portmanteau term suggests, things are different. The more operationally minded engineers will look closely at the performance of the product in the live environment, and push back on design assumptions that are contradicted when real people use a service or product. A good DevOps team will always make clear the risks involved with breaking changes and try to strengthen the processes that mitigate these.

One of the central ways to progress an agile transformation is to introduce continuous testing. With all such changes, it is cultural as much as technical. The expected outcomes are less broken builds and reduced time from break to fix, as well as a yardstick for measuring the team's ambition for improvement.

When presented with the case, it is hard to deny the allure of moving your nuts and bolts computing to the cloud. Everyone knows the arguments; computing is a utility, not a USP. There's no need to own the burden of supporting a server room. With network edge issues solved, time to market is reduced. Be flexible against peaks and troughs. Just taking the reductions on CAPEX alone can be reason enough - well, for those without a large budget to spend.

Good question. To get started on an answer - but not necessarily the answer - consider this:

Q: Who do you say "Yes, chef!" to in a DevOps team?
A: The lead engineer.

Not a project manager? Absolutely not.