The process of building processes!

I always kept looking for some topic that would be cool to write about. Then I realize that nothing would be better to talk than what I spend lots of time working on, our “process of building processes”, not without a little history about it.

Last October (2019) the team completed 10 years of it’s creation, we had a lot of transformations, just to mention the most remarkable, the 24×7 operation, squads and Devops consulting.

Back to 2009 when the current team was created, or the idea of it, I was always worried to make it impersonal, the first step was to create documents about the installation and/or maintenances that has being done. Looking for that today, it was our first kind of idea to make it repeatable and impersonal or what I can call “process”!

Since then we always had some kind of process, which for good or worst, wasn’t something too much tied, the team always had enough freedom to do more than what was “defined”, allowing them to progress faster in their career, not always was it successful, but I can say that we’ve done right more than wrong!

Just to explain why I quoted “defined”, until 3 or 4 years ago, we have our main processes implicit, so they weren’t written down on some wiki page, or anywhere else. That’s because the team wasn’t growing too fast and we had enough time to transmit our culture and processes to each new person that joined the team. That was good, we tighten ties, promoted the partnership, but we also always forget something, and that usually ended in some mistake, or bad situation with extra explanations.

Back to our process, It’s kind of democratic and inclusive. We usually start drawing or updating the current version of the process which we wanna change, yes, the drawings sometimes neither exists nor are updated. Then with the drawing we schedule at least one meeting to discuss the “as-is“, and from this we usually have some points to adjust or steps to detail.

When we’re done with some “stable” version of the “as-is“, we start what I consider one of the most important things the Value Stream Mapping, yes I know that is pretty basic for DevSecOps culture, but totally essential to demonstrate the weaknesses.

With VSM in hands we start the “Dreams Phase” in a land where the dreams come true and everything is possible and nothing costs extra money, we set the first goals! By the way, set doesn’t mean feasible, they’re just goals that works as a starting point.

The next stage is the “reality shock”, where based on our dreams we decide what and how it should start to be improved. We make the plans, and choose some changes that we can see some quick changes and measure it to check for real improvements, or we should go back to another changes, none of those are big enough that could cause some kind of disruption on our current work.

We should never stop thinking on improving our processes! Even that being a good advice, unfortunately this is rarely in our attention for too long, usually only during the time that we’re working directly on it… and we go back after we’ve wasted too much time doing something, “deprecated”, or trying to updated the drawings to reflect our reality.

At the end, we’re also working on our process of making processes as our goal is to simplify and optimize at the maximum, some times we add some tools, robots and a lot of automations based on our evaluation but mostly of the time is the small changes on some task that really makes the difference.

What I like most is dream phase, we have the impossible defined and if wasn’t it, the team wouldn’t not grown two times in the last two or three years, the juniors would never become seniors, they would never have chance to be in the middle of fire (meeting with an angry customer) to explain how to fix an environment or app. Hope that in few years/months this model is completely different than what I’ve described today, meaning that we reviewed and reworked on our process of building processes!