What is your software development team spending time on?

Let's face it - many software development teams gets really annoyed when asked to register their time on a daily basis. But how do you know if they are working efficient if you don't know what they are spending time on? And - how do you know what they are spending time on if they are not registering it?

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,

• Administration
  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...
• Stabilization
  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...

For all development teams the objective has to be to get the most output with the least effort. With that I do not mean that more is better. This assumes the team is doing what is right for the user and the customer considering functionality, quality, usability etc.

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.