This week I’m in Stockholm for few days. The goal of visit is simple – increase DevOps awareness in Sweden and align regional plans with local DevOps lead. In other words, talk with as many people as I can. One of discussions (I can’t tell with whom and about what) went like this (at least that’s how I recall it from memory):

Evangelist: so your client is doing DevOps?
DL: yes, somewhere more, somewhere less. We have some issues.
Evangelist: what kind of issues?
DL: client doesn’t really need true DevOps because end users can’t learn those new features that fast.
Evangelist: happens. What is your release cycle?
DL: in best projects we release once per month.
Evangelist: typically that means gap on “business” side. They could be too slow to train people on new functionality. More frequent training may help.
DL: makes sense. I’d like to know what is best practice to store code – in one repository or many?
Evangelist: depends on case and needs really. There are companies who store all their code in one codeline though that could be too crazy for your client. One repo per application is fine. What you really mean with repository? Folder for code? Repo? Project in GIT? VCS Server?
DL: (got confused, pause) I would need to check what they really have. Typically there are issues with deployments.
Evangelist: so I hear that frightening release weekends and overtime is a normal thing there?
DL: no, they are against overtime and do production deployments during work hours.
Evangelist: oh. And if it goes badly, end user is without his tool?
DL: yes, people are saying that systems are always down. They are also slow and can’t be scaled simply.
Evangelist: I see. I’m not surprised end users don’t learn new features if they don’t like the system they are forced to use.
DL: right…
Evangelist: who is deciding on what new features to make? Could it be someone who hasn’t been on “field” for 20 years and thinks he knows what end user needs?
DL: that could be the case as well…

Then we went to discussion about “doing good IT” basics, Agile principles, philosophical stuff. Discussed DevOps maturity roadmap and how important it is to have right culture and team setup at first. Fixing deployments doesn’t make much sense if Configuration Management is suffering badly and so on.

There can be no good DevOps if there is no credibility in IT system. Not a single DevOps/Agile/XP/ITIL/Scrumfall/whatever practice can magically fix that. First steps could be to have systems stable and faster but it will take time for end user to change his opinion. What projects sometimes miss, is that in some cases DevOps journey means making your releases longer to stabilize and only then start pushing for shorter cycles. It could be even cheaper to build a new system from scratch just because old one has failed in end-users eyes.

Why I keep reiterating this conversation in my mind is the very first statement – end users don’t like new features coming out so frequently. Go and ask the end-user “why” before making any assumptions.

DevOps Evangelist
Uldis Karlovs-Karlovskis