Categories: agile, capex, Enterprise Awareness, Financial, Governance, Kanban, lean, metrics, opex, Scrum, time tracking
One of the key aspects of a disciplined agile approach is to be enterprise aware. The fundamental observation is that your team is only one of many in your organization, except in the case of very small organizations, and as a result should act accordingly. This means that what your team does should reflect your organization’s overall business and technical roadmaps, that you should strive to leverage as much of the existing infrastructure as possible, that you should try to enhance the existing infrastructure, and that you should work with other teams appropriately so that your overall efforts are complimentary to one another. This is a straightforward idea conceptually, but in practice acting in an enterprise aware manner can prove more difficult than one would initially think.
Over the years we’ve been asked by several customer organizations to help them to understand how to account for the expense of agile software development. In particular, incremental delivery of solutions into production or the marketplace seem to be causing confusion with the financial people within these organizations. The details of accounting rules vary between countries, but the fundamentals are common. For public companies capital expenses (CapEx) are preferable because they can boost book value through the increase in assets (in this case a software-based solution) and increase in net income (due to lower operating expenses that year). On the other hand, operational expenses (OpEx) are accounted for in the year that they occur and thereby reduce net income which in turn reduces your organization’s taxes for that year. Furthermore, in some countries you can even get tax credits for forms of software development that are research and development (R&D) in nature. In order to get properly account for the expenses incurred by software development teams, and potentially to earn R&D tax credits, you need to keep track of the amount of work performed and the type of work performed to develop a given solution. Time tracking doesn’t have to be complex: at one customer developers spend less than five minutes a week capturing such information. The point is that the way that a software developer’s work is accounted for can have a non-trivial impact upon your organization’s financial position. This in turn implies that the need for agile developers to their track time is a fairly simple example of acting in an enterprise aware manner.
So, I thought I’d run a simple test. On LinkedIn’s Agile and Lean Software Development group I ran a simple poll to see what people thought about time tracking. It provided five options to choose from:
- Yes, this is a valuable activity (33% of responses)
- Yes, this is a waste of time (39% of responses)
- No, but we’re thinking about doing so (2% of responses)
- No, we’ve never considered this (18% of responses)
- I don’t understand what you’re asking (5% of responses, one of which was mine so that I could test the poll)
The poll results reveal that we have a long way to go when it comes to working in an enterprise aware manner. Of the people inputting their time more of them believed it was a waste of time than understood it to be a valuable activity. When you stop and think about it, the investment of five minutes a week to track your time could potentially save or even earn your organization many hundreds of dollars. Looking at it from a dollar per minute point of view, it could be the highest value activity many developers perform that week.
The discussion that ensued regarding the poll was truly interesting. Although there were several positive postings, and several neutral ones, many more were negative when it came to time tracking. Some comments that stood out for me included:
- It’s a colossal waste of time unless you’re billing a customer by the hour.
- We record time spent on new development work (as distinct from other tasks such as bug fixing in legacy code and so on) as this is capitalised as an asset and depreciated.
- I think the *most* pointless example was where the managers told us what we should be putting in.
- One day we will move past the “just do it” mentality and have some meaningful conversations and the reasons for what we do.
- In my experience time tracking is a massive waste of time. It’s a poor substitute for management.
- Why do you need to know more than the info available through Sprint Backlog, Sprint burndown and the daily standup?
- Some of my teams (I am SM for three teams) are skeptical about this. They do not think that keeping track of task hours this way will be any more useful than the daily standup reports. And they do not believe that Management can resist the temptation to use task hours as a measure.
So what can we make of this? First, it’s clear that delivery teams need a better understanding of the bigger picture, including mundane things such as tax implications of what they’re doing. Second, it’s also clear that management needs to communicate more effectively regarding why they’re asking people to track their time. To be fair, management themselves might not be aware of the tax implications themselves so may not be making effective use of the time data they’re asking for. Third, management needs to govern more effectively. Several people were clearly concerned about how management was going to use the time data (by definition they are measures) which could be a symptom of both poor communication as well as poor governance (unfortunately many developers have experiences where measures have been used against them, a failure of governance, and no longer trust their management teams to do the right thing as a result). Fourth, some of the team-focused agile practices, such as burndown charts (or better yet ranged burndown charts) and coordination meetings may be preventing people from become enterprise aware because they believe that all of their management needs are being met by these practices. Finally, many organizations are potentially leaving money on the table by not being aware of the implications of how to expense software development.
In Summary
Disciplined agilists are enterprise aware. This is important for two reasons: First, you want to optimize your organizational whole instead of sub-optimize on project-related efforts; second, you can completely miss opportunities to add real value for your organization. In the anecdote I provided it was clear that some agile developers believe that an activity such as time tracking is a waste, when that clearly doesn’t have to be the case. Worse yet, although someone brought up the issues around capitalizing software development expenses early in the conversation a group of very smart and very experienced people still missed this easy opportunity to see how they could add value to their organization. It makes me wonder if some of the agile rhetoric is getting in our way of being more effective as professionals (and, BTW, there are light-weight options for tracking time available to you).
