The hidden benefits of activity and time tracking for a DevOps transformation
Continuous Delivery and DevOps might be the most significant trends in software engineering in the last 10 years, and developers have always loved the automation of repetitive tasks like deployments and releases.
Who invented these practices?
As with all good things in Software Engineering, the DevOps practices were not invented by a single individual.
All best practices are a result of teamwork and evolution through experiments and improvements by dozens of teams in different organizations.
The classical book to understand the essence of DevOps is the “Continuous Delivery” book. One of the most interesting stories from the book is the evolution towards continuous delivery by the HP LaserJet software development team.
The transformation started from a simple and challenging question:
How can we improve productivity and delivery of new value to users?
A simple question set a clear mission for the team and kicked off an advanced experimentation process to improve productivity.
The team evolved through a Kaizen process of incremental improvements over time which compounded into a process that is very similar to the stereotype of DevOps.
Three steps to improve productivity
How to implement incremental improvement towards a highly efficient organization?
There are three fundamental steps to create a highly productive team and automate repetitive work:
- Measuring the current state (baseline) of value delivery via activity tracking
- Having clear goals (KPIs) to understand the target condition
- Giving the team autonomy to do experiments and incremental improvements to improve the KPIs
The end goal is an increase of flow of delivery of features that can make an impact on real users while reducing activities that don’t create new value.
Measuring the current state of productivity
The first step towards Continuous Delivery is similar to a scalability test since we measure baseline performance via detailed tracking to understand what types of activities block the value creation and delivery flow inside the team.
What we want to get is insights like “We are spending 24% of our time on bug-fixing” or “Only 30% of our team is working on new features”
We could easily conclude that specific types of activities are creating overhead for the team, and quantify time spent on those activities. The goal is to increase value production and minimize overhead and time spent on less important activities.
This is called Activity Tracking and it might be one of the smartest things a team can do to optimize continuous delivery and flow of new value through the system while minimizing activities that reduce value creation (e.g. support, maintenance etc.).
The truth is, proper activity tracking is impossible without time tracking.
I would argue that it’s impossible to achieve what the HP LaserJet team did without having a baseline work distribution chart. This chart can’t be computed properly without detailed time-tracking of activities.
Even though most developers consider time-tracking an evil and useless activity, it might be useful for one thing after all ;)
After you diligently track time for team members for a period of time, You can put together a baseline work distribution chart that looks like this:
Once you have a clear measurement, the next step is to set goals and start with incremental improvements.
Setting goals for improvement
Setting SMART goals is the key part of this process since we need to know what is the end-state that we want to get to.
I believe OKR’s to be a great framework for setting measurable goals.
An example of an OKR could be:
You will notice the key result having a number (5%) and a date (Q3 2018), which makes it measurable.
OKRs might be the best tool available to focus the team to understand what is the target condition and enable a smart experimentation process.
Having a clear goal unlocks the possibility to create tasks and sub-tasks to achieve the end result.
Experiment to get to the goal
A good experimentation process is not prescriptive. There is an end goal, but the activities to come with a solution are very much open-ended.
Regardless of the process, it is important to implement Kaizen and incremental improvements towards the end-goal, by quickly learning and adapting over time.
This means that a key requirement for experimentation is autonomy to make experiments that impact the KPIs, but also having a measurement process to be able to determine if there is an improvement or not.
How can we measure accurately if we have improved towards our goal?
Again, We need time-tracking.
If our baseline measurement of time spent on “debugging activities” might be 25% and our target is 5%, we might decide to run an experiment to do more pair-programming in the team during bug-fixing / stabilisation sprints based on a hypothesis that it will improve the KPI.
After we run this experiment we could extract time-tracking data to measure if we met the target condition.
The result might be that we decreased time spent debugging to 14%.
Understanding that we haven’t met the target condition allows us to collect insights and design the next experiment.
This is one more example of data-informed decision making which advocates for having data before planning, prioritisation, and execution to make better decisions.
This is the same methodology that drives nice practices like Lean Startup, Design Thinking, A/B testing etc. The data is the key asset to make better decisions.
Next time you think time-tracking is evil, remember that all great things start from a measurement.
“You can’t manage what you can’t measure.” — Peter Drucker
