So, you couldn’t give an effort estimate (you had no idea how long it was going to take) and you hadn’t clearly (measurably) formulated the benefits the whole action would bring to the company and our customers, and still you decided to go for it? How could you do that? That’s very expensive for the business! I honestly don’t get it….
One of the Product Owners of the applications in my department told me that, after a session I held to all our analysts, managers and product owners on the value of moving away from a VM-based runtime architecture, to a Container-based one using the PaaS in-house offering of the company. The decision about migrating had been already taken by the time I joined the platform team. The migration was at a very early stage when I joined and there were still lots of preparations to finish before involving the product teams (we are talking about several applications, in the hands of 7 development teams). So I didn’t participate in the decision-making, and missed all the discussions/arguments. On the other hand, I was pretty busy (even overwhelmed) with managing the learning curve I put myself upon, so I didn’t have a chance to even question that decision.
But to be honest, even before joining the platform team, when I was working as a system analyst in one of the product teams and heard about the migration to a container platform, I could clearly see the benefits such an action would bring to our systems, to our development process and on the long run, to the whole product delivery. Maybe because of my technical background (I had started my career as a developer after all), or maybe because I had been quite actively involved in DevOps meetUps and conferences and had heard lots of success stories of such migrations, but I just never even considered questioning the decision.
I also found it annoying that some people wanted an estimate from us (the platform team) on when the whole system would be migrated. Luckily our management was clear on the fact that, technically, we could not provide such a number. The reason was: we are not a “DevOps team”, we prepare a basis and help the development teams to get into the new container world, write their new pipelines, and basically operate their applications themselves. Our strategy is to empower the teams, to give them ownership of the software they create. So at the end, it would be up to them when and how they would prioritize migrating the applications they were in charge of. Today, almost a year and a half later, the migration is not completed yet. Different factors like changing priorities in the teams, and fixing operational problems we’ve found along the way with the first migrated applications in production (we are all new to this technology after all!) have led to this state. But it’s not in our culture to blame. And so that wasn’t either my intention in the session I held, when I mentioned that factors like a steep learning curve and changing priorities in the teams were part of the reasons why the migration is not finished yet. Blaming is something that is just not part of our DNA. So I was kind of blown away when the same person who asked me the question from the beginning also told me he was surprised that I was putting the blame on the teams and their incapability, for the migration not being finished yet.
Anyway, to make the story short (it might be too late by now, but if you’ve made it this far, please bear with me), I had an “after-session” conversation with this PO where I believe I managed to defend the decision of migrating to the container platform the best I could, and had the chance to hear his point of view. Which left me thinking, and in the need of writing this post…
Now my question to you, who read the whole story:
Say you have no idea how long a big technological change is going to take (because it’s new for everyone) and you have not precisely quantified the benefit it will bring to the business (and the customers), but you do know the following:
The theory says, there will be improvements in the runtime architecture, and in general in the software delivery process.
It is possible to do this step by step. The teams won’t be blocked completely and there will be still capacity for delivering business features
Would you go for it?
Would it really be so crazy to go for it, as my PO thinks it was?
If you agree with him, then my next questions to you are:
How else should systems cope with technological advances and improve themselves continuously?
Would you rather hire some specialists who can provide a contract with a timeline and costs you can perfectly plan?
Is a better planning more important/valuable than giving your own people the chance to learn/master the new technology?
If your last two answers are yes, with whatever argument you might have, don’t you dare saying you work agile. You still have a long way to go.