I can feel the frustration in your post. As someone who made the transition from a PMO to an Agile role I can understand both sides of the coin.
Your question has multiple components which I will take in turn but all of them have effective communication at their core.
Why are management more interested in logging hours?
This could be a number of things but management absolutely must track hours of work accomplished. It could one or a combination of the following reasons.
- The company must account for shareholder value being invested. Effective delivery is only one way of tracking value, it is also necessary to ensure that the delivery is roughly allied to the amount of predicted hours of effort.
- External auditing and governance compliance. If your company is a PLC then the auditing and regulatory burden increases and logged hours are a critical component of that process. Remember; when someone gets their monthly salary that is someone's shareholder investment being transferred across and that shareholder expects a minimum level of return on investment for paying that salary. It is not unreasonable to simply log hours worked is it?
- Timesheeting. If you are attached to a PMO it is likely the development team have multiple project or programme workstreams coming in. The department is not a free resource, your developers need to be apportioned to a cost centre for the work they do so that projects can be tracked to ensure they are on budget.
- Resource Demand. Do not underestimate that the primary way management decide to scale up and down resource is by contrasting planned effort in man days / man hours against a fixed dead-drop timeline. If the resource demands exceed the deadline they will bring resource in. Logging hours is a critical part of ensuring that planning is effective and accurate. You get additional developers and testers if required but logging hours is critical to making that business case.
- Trust. Right now it appears management have some trust issues regarding the department. It is possible you are a fledgling Scrum team, the process is new to them, it was not sold in the right way or they need to control the full time resources of the department. All of these symptoms are a lack of trust.
The hard truth is, I would never allow an employee to forego tracking his/her hours if he cannot even manage to track his hours. Does that make sense?
In the military we used to have a saying -
"When you can administer yourself, we will give you a rifle. When you
can administer your rifle, we will give you a vehicle, When you can
administer a vehicle we will give you subordinates..."
If your team cannot even accomplish hours tracking then why on earth should they be released from the task? It's a simple item that takes less than 5 minutes. I am surprised management has not taken more stringent action already. If your team want independence they have to earn it.
Why are my team not logging hours?
This is partially a psychology issue but it also indicates they have not had the value of hours tracking explained to them. If they have had the value explained and they continue to discount a process that Management feel is valuable then you have a dysfunctional team, possibly centred on one or two strong characters who are driving the rest of the group.
In that instance you must take action to instil discipline in the team. A Scrum Master is the master-servant of the team. Most people focus on the servant part to show humbleness but do not forget the master role. Impose your will onto the team to ensure they understand exactly what will and will not be tolerated.
Communicate to the team that
- Hours must be logged at the end of each day
- You will consolidate all logs daily and report on those missing
- Consistent offenders will have it reported on at their annual appraisal
- Consistent offenders are letting the team down because the sooner they comply the sooner management may trust the team and remove the process
It is always easy to blame the management process rather than do a root cause analysis; in my experience most managers have sound reasoning for the reports and processes they request. Also, in the future if you need to scale up or challenge planning estimates and you don't have logs supporting your business case then expect the resources to go to a department head who can enforce logging.
Good luck, even raising this issue in PM.SE indicates you have some excellent qualities to fix the issue.
This answer represents a snapshot in time of where I worked and how I approached Agility. I should say that, nowadays, I absolutely do not support time sheeting and timesheeting itself is symptomatic of a project smell which requires root cause analysis. It indicates lack of trust in a team or resources split across deliveries. It is, in short, a terrible way to facilitate software development.
In addition, working software is the primary method to demonstrate value. All other artefacts are smoke and mirrors.
I stand by my answer as it shows the journey that we all take towards the Agile values but I no longer support it as advice to the development or project management community.