Five years ago, a co-worker told me he wanted to get an ALM certification. I stared at him and blinked.
“What’s ALM?”
“Application Lifecycle Management.”
I don’t remember my exact reaction, but I was skeptical. I didn’t understand what that meant at the time. My focus was entirely on writing the best, cleanest code I could. All of the frustration with code that didn’t work–about sites that were down, about working late nights and working tirelessly to maintain customer satisfaction– that, to me, just came with the job. But this was before I finally figured out that it doesn’t have to be that difficult.
Looking back, I realized I had picked up some pieces of the DevOps puzzle in my career. When I started, we had no source control and I understood that once we started using it (TFVC), it became much easier to work. Then, after seeing TFS updates being a pain for our IT admin, we moved to Visual Studio Online and that pain point disappeared. When I saw frustrations about not everyone being on the same page as for as task priority, I pushed for tracking our work through work items in VSOnline. And again, the game changed. When we had issues with nightly jobs maxing out our RAM in the physical server box from Rackspace, I successfully proposed we move the applications to Azure Web Apps so that we could scale up and down as needed.
By way of intuition I was gathering the pieces of the DevOps puzzle, but I didn’t know what puzzle I was putting together at the time.
Opening the Box and Finding The Puzzle Pieces
For every pain point I had personally felt as a developer, I advocated and pushed for a solution. What I was missing was the complete picture on the box of what DevOps looked like, what it meant, and how the various pieces were put together. One huge regret I had was recognizing that people were the first step in this process. Without articulating the overall vision for what DevOps could achieve, every decision was piecemeal, and every decision required a new discussion to gather buy-in from stakeholders and make it work.
In many organizations I’ve seen over the years, this scenario is very common. Developers are focused on making new features, managers are focused on developing business value, and operations is focused on keeping everything alive. Since the process of collaboration and cooperation between these roles is left to chance, it’s often full of friction.
DevOps is a culture. It starts with the people. Often, it just starts with just one person and spreads like wildfire when the small successes start to add up to big successes.
Puzzles Are More Fun Together
If you want help putting the pieces together, that’s where New Signature can help. We can partner with you, helping you identify the state of your puzzle and what pieces you might be missing, and even can help you put a piece or two in, like creating a sample pipeline in Azure Pipelines.
Starting With The Sides Of A Puzzle
In life and in DevOps, starting with the middle of the puzzle is insanity. If you look at DevOps as a top-down initiative to be achieved with an iron fist, it can look like handing out random pieces of the puzzle one by one. “First we must do CI/CD pipelines, then we must do automated testing, then we must do…” This does not work.
We must do none of those things. We may choose, instead, to foster a culture where collaboration is king and where we are working together to deliver value. One of the easiest ways to focus attention on a common set of values is to start measuring things. Humans have an innate drive to improve metrics. Want proof? Come play a board game with my wife. She will get very upset if she doesn’t win. Although the points in Yahtzee literally mean nothing, we can get very passionate and work very hard to improve our numbers.
However, if you aren’t careful about what is measured, it can lead to disaster. I recently read about an initiative in China where average drivers can use their dashcams to capture traffic violations, and then send the footage in and get a financial reward. On the surface, this is a great idea! Now everyone will be more careful in how they drive just in case someone catches them on camera, right? Wrong! Now some drivers with dashcams are driving erratically to spur other drivers to react, catching those other drivers doing illegal maneuvers, and then collecting the reward when they capture it on tape. Be very careful about what you measure.
In the book Accelerate, four measures are shown to have a strong correlation with organizational success:
- Lead Time: time from a customer making a request to the request being satisfied.
- Deployment Frequency: how often do things get into production, per developer.
- Mean Time to Restore (MTTR): how long it takes to recover from a system outage or failure.
- Change Fail Percentage: how often a change introduces a bug, fails to fix the problem, causes an outage, or fails to deploy.
I view these as sides of a puzzle. If a puzzle piece doesn’t fit within these four measures, at least until you complete the puzzle, it can probably be ignored for now.
Filling in the Pieces
Once you know the boundaries, you can start filling in the puzzle. Handily, the pieces link up to each other. There’s often a natural order of things as you start to put the picture together. For example, if you don’t know how to measure Mean Time To Restore yet, maybe it’s time to put some monitoring uptime in place. Once you see how long it takes to restore, you can start to get to root causes when it fails, which means putting in something like Azure Application Insights to gather data about why it fails. Once you start to get a picture of why it fails, you can start fixing low-hanging fruit. If you find that delivering fixes takes a while once you know what to fix, you can look at your CI/CD pipeline or change request process. It all feeds into each other, and as you add puzzle pieces you start to get a fuller picture of how they all fit together.
Completing The Puzzle
Aha! This is where the metaphor finally breaks down. The puzzle is never complete. You will always be finding new ways to improve how you bring value to your customers and clients. At New Signature, we are very free with sharing information on how to add more pieces because we truly want you to be successful. I get out of the bed in the morning because I want to make a difference in how people work and see them be wildly successful. Also, putting together the puzzle is fun – each piece you slot in completes the picture a little more and makes your life a little less hectic.
If you feel busy but not necessarily productive in doing software development, we can help with that. We derive joy from seeing the lightbulbs turn on when the pieces start to form a picture.
