Ok, I get all the arguments against not doing time registration; "It's too cumbersome", "It takes too long", "Don't you trust me", "We've never done that and we're doing ok!"
I have been running development teams both with and without time registration and in general I agree that both approaches can work. But - it depends a lot on the situation.
The key point is that as a software development leader you need to know what your team is spending it's time on. And you need to find a good way to obtain this knowledge.
For smaller teams - and/or if you are doing part of the work yourself - it becomes easier since you can be very close to each individual in the team. If you have largers teams or multiple teams it gets a bit more complicated to understand the details of efficiency.
let's start taking a look at some of the things a software development team is usually spending time on,
You don't necessarily want them to spend much time on this but it is unavoidable. You decide yourself what to categorize under administration, but some common activities can include vacation, sickness, department meetings, celebrations, education etc, career dialogs etc. Some of these you may want to detail out separately.
- Product Development
This is where you want your team to spend their time. This category will typically include aspects like gathering requirements, writing spec's, design, coding, test, documentation, sprint planning, retrospectives, project management etc. All the things that are absolutely necessary in order to get the software done. If you are very specific you may want to drill down into the ratios between the different aspects...
Your team is writing the last bit of code before all features are finally complete for the next release. However, for many good reasons you need a bit of time to test and fix the last bugs before shipping. For some teams this becomes a never ending death march...
- Maintenance and support
The version you have released to your customers may have flaws...they need to get fixed. Bugs are found, incidents are logged. In general time spent on this should be minized. Some teams have found they spend as much as half their time on fixing old stuff...not optimal.
- Assisting others
So your team is incredible knowledgeable. In fact, sometimes they are the only ones who knows and can answer questions from others in your company. So they spend a lot of time on this. Time, which is taken from the time they could have developed the next version...
Understanding how time is spent is a pre-requisite to understanding how to optimize. You will often find interesting correlations. As an example low customer satisfaction is often correlated to either low time consumption in the requirements, speficication and design phases (pre-release) or high time consumption in maintenance and support (post-release).
High complexitiy in the solution architecture can be accompanied by high time consumption in stabilization and the examples goes on and on.
If you have been tracking time spenditure for some time you will eventually be able to start optimizing the different aspects of software development and at the same time monitor whether the changes actually works as intended.
Planning future work also gets a lot easier if you gradually develop rules-of-thumbs for your team based on historic performance.