IT should always serve business goals.
To be able to do just that we have to make sure we provide the right solutions for the right costs and at the right time.
Let’s take a taxi company as an example. It is only possible for our drivers to do their job properly and provide services to our customers if the fleet of cars is well functional, tuned to the customer base, amount of rides, peak hours and such.
So for the company to do well there is someone who will take care of buying and maintaining the fleet, make sure there are enough qualified mechanics, make sure the tools are the ones that are needed, provide training for new hires and whenever there are new tools acquired, oversee the innovation in regards to the tooling, keep employees invested and happy. In short: keep the shop in order so the business can thrive.
Back to IT. The same principle goes: the shop needs to be in order. It is the main responsibility of an engineering manager/development manager/IT lead. You have to make sure that business requirements are delivered as fast and often as your company needs by taking care of the people, processes and tools.
“But I am not a tech person”. This is something you might hear from IT managers. Who often are entering the era of DevOps after a period of more traditional type of management. And that could be a big problem. As a leader in tech you should at least know the essence of things. You need to at least know what your people are doing and understand the bottlenecks, opportunities, frustrations and desires in order to provide them with some leadership. One risk in not deepening your knowledge is that you constantly have to rely on others and their knowledge. Another is that you will never really connect to the rest of the department.
Luckily for us there are a couple of tools that, when used in the right way*, will make sure both you and teams know why they are doing things, how to improve the ways they do it and what they need from you as their facilitator. With these tools you can embed a way for continuous improvement and making sure we make sure we have the same view on things.
* With using these tools the right way I mean that the most powerful thing you could do is to make them together and have meaningful conversations about the things you find. So instead of implementing them as a reporting mechanism by the teams, you make them about continuous improvement and teams learning to make the right decisions based on data.
Why are we doing this?
Tools: Event storming & impact mapping
Event Storming is a great tool to quickly find out what is happening in the domain of a software program. Impact mapping is a lightweight, collaborative planning technique for teams that want to make a big impact with software products.
Both techniques will give a concise overview on what is needed from a business perspective without the need to talk about technology or architecture. These will follow according to the business requirements.
What do we need?
Tools: Value stream mapping & Skills matrices
As mentioned earlier, the people, processes and tools in the shop should make it possible that business requirements are delivered as fast and often as your company needs. These two tools are focussed on the quality of the delivery process and whether we have all the resources needed to improve this quality.
A value stream map gives you direct insight into all the steps there currently are to get an idea to end users and where there is waste in this flow. The main things you measure here are the value adding and the non-value adding operations.
A skills matrix gives an overview of what skills are needed to get an idea to end users. I personally use the skills matrix to see if a team has all the required capabilities and not if every person is something like T- or M-shaped. A validating question about a skills matrix is “Can anyone go on an unplanned holiday?”. If not, what is needed to make this possible?
How are we doing?
Tool: Growth model retrospectives
The goal of a growth model is for a team to assess the current effectiveness and to figure out what capabilities they need to step up their performance. These models mostly address the processes and different levels of them. Sometimes teams have processes that lack behind and for some it is just the next level they want to reach.
How to measure the shop’s performance?
Tool: DORA metrics
In regards to the quality of both software products as DevOps processes there are four main metrics that can be considered to be leading:
- Mean Lead Time for changes (MLT) – lower is better,
- Mean Time To Recover (MTTR) – lower is better,
- Deployment Frequency (DF) – higher is better,
- Change Failure Rate (CFR) – lower is better.
With these metrics as a way to monitor our current status, trends and ways to uncover the underlying bottlenecks there is no big change program, agile scaling or DevOps revival campaign needed.