Many start-up companies in the cloud use software engineering methods like continuous delivery or DevOps
right from the first line of code they produce.
By using such methods high software quality can be ensured while doing high frequent deliveries which
provides those companies with a fast return on investment (ROI) as new functionalities hit the market early.
This is their DNA.
For more traditional IT companies such methods are way harder to implement, as they are used to work
completely different.
When we came up with the idea of doing daily deliveries at twogo.com many in the company thought this
could never work at SAP.
At SAP we produce business software, which is in many parts mission critical. If certain modules of your
SAP system fail for a longer period, the existence of your complete company can be endangered.
In addition, we sell "standard" business software. Now what does that "standard" mean?
To put it very simple: standard software must be customized on customer site. Otherwise it's quiet likely
that it won't fit the customers need. That's why implementing SAP software often comes along with an
implementation project to customize and fit your SAP software to your company.
As a result, an oil rig, a hospital and a car manufacturer are all running the same software core,
while doing a complete differerent business.
So managing huge diverse critical software projects is what we do since decades. This is our DNA.
As we started our journey towards continuous delivery about two years ago, we were directly confronted
with the companies DNA.
We tried to adopt a company release process which has been in place since several years and which
has been created to ensure 1-2 shipment per year. Not 365+ shipments per year.
Now the process itself is one side of the thing we needed to adopt. On the other side, processes in large
companies often come with their own ecosystem.
Complete departments exist only to hatch, manage and control processes (mind the plural on departments).
Often department A controls one part of the process, while department B (which is, according to the org chart,
located in a galaxy far far way from department A) controls some other part and so on...
Given that you're not only adopting processes, you’re also touching the dedicated labor of many persons
which work along this process.
Confronted with such a situation, ensure that these people understand you're not approaching them to tell
them their work is completely nonsense and should be stopped immediately as the whole process is crap (and always will be).
That might sound funny, but there's much truth in it.
Most likely when you first approach them, you won't understand the complete picture of their work (and the
processes they govern and/or run). Keep that in mind.
Try to understand what they do, and why they do it this way.
Once you got that, tell them how the whole process should work for you in an ideal world, so they understand
where you're coming from (and where you're heading to).
Also don't try to change the whole company at once. Start with your little share. Try to position yourself/your team
as a pilot/front-runner/playground to experiment new ways, of which their department can benefit as well
('cause if you succeed, they'll get their share of the glamour and they will be seen as an driver of
innovation inside the company).
Try to surround yourself with people that see value in what you do and that support you and your ideas.
That's the good side of working in a large company, there'll be always persons who trust in you and support your ideas.
Make sure to have enough staying power.
For us the journey for daily deliveries using continuous delivery and DevOps methods, took ~2 years.
When turning the steering wheel of an oil tanker, it takes a while to see it's moving.
