Timesheets

I spend around 10 minutes a day entering my timesheets and you can’t but wonder if this time could be spent any better. Based on what I have described in my previous post about MVP and the way business value relates to time and money, we can calculate how much time we should be spending on this. The value gained in timesheets is mostly data which can in turn can be used to:

  • Help determine if the project is still on target to reach its deadlines and make sure it’s delivered within budget.
  • If you are on a time and material basis, your timesheets will probably be used for billing.
  • If you are working on a product, timesheets help to determine the expenses involved to create the solution.
  • Compare how efficient developers are on their daily tasks.
  • Check how much time is spent to support the application in various parts of the product life cycle.
  • Be able to do better predictions and estimates when you do similar tasks.

From the above I hope you agree that timesheets are a vital source of information for a company and in some cases are as important as the work you do. The main question is, how detailed should they be, or to put it differently how much time should be spent on this? I think the answer depends on the quality of the data you require. The following are a few questions that people responsible for configuring timesheets should be answering:

  • Do you need to do a timesheet item per module?
  • Do you need a timesheet item per feature?
  • Do you need to enter a comment with a timesheet entry?
  • Do you need to record timesheets to the minute? (Or if you approximate to the nearest 15 minutes it’s enough?)
  • Do you need to know the exact time during the day that the task was done (e.g. from 10am – 11am were sent doing xyz) or is the total hours per day enough (e.g. 1 hr was spent doing task xyz)?

Assuming the process of entering timesheets is manual, the more “yes” you answered to the above questions the more time-consuming the process will be. Arguably, this also means that it will be harder for employees to record precise data.

“I make it a point to be accurate with my timesheet, said no employee ever.”

I would like to conclude by sharing some tips that I use when entering timesheets:

  • First of all I try to be as descriptive as possible and avoid words like “bug fixing”.
  • On the other hand I do my best to keep the description as concise as possible.
  • I always enter my timesheets directly in the program. I feel it’s a waste of time to write them down somewhere (notepad, paper etc…) then copy them over.
  • Enter time sheets daily or twice daily if possible. I tend to forget what I was doing 2 hours ago, let alone what I did the previous day or week. I personally prefer to enter my timesheets just after lunch break and before I leave the office.
  • I take advantage of idle time, for example waiting for the guy who I had a meeting with to show up, to enter my timesheets.
  • When I’m not too sure what I spent my time on, I check source control check-ins, emails sent, calendar appointments, team task list and my personal task list.
  • I use email subjects and check-in comments as a description in the timesheet comment field.

If you didn’t learn anything from this post I hope that at least I managed to convince you that the time spent entering timesheets is well spent and crucial data for the company’s survival.

Minimal Viable Product

Here is something you don’t hear that often: estimation is hard! It’s so hard that people almost never get this right, and probably they shouldn’t because after all it’s an estimate:

“An approximate calculation or judgement of the value, number, quantity, or extent of something.”

I have a suspicion that estimation is hard for most trades not just for software development, because people are generally quite reluctant to give you an estimate. So generally people tend to either:

  • Overestimate and risk losing the job to someone else OR
  • Under estimate and risk working after office hours to catch up

This of course is inconvenient for everyone and tends to create a bitter relationship between the two parties.

Is there another way?

Yes .. avoid estimating.

First of all let me start by pointing out the obvious, everything has a value, and when I say “value” I really mean a “price”. So first we need to understand how much a client is willing to pay for a product. To give you an idea on how to calculate the price, general IT provides solutions to problems which we could categorize into 4 main categories:

  • Solutions which save time. For example searching and retrieving previously saved documents more efficiently. 
  • Solutions which help mitigate risks and solve legal issues – which would avoid you fines or losing clients.
  • Solutions which entertain.
  • Solutions to record data which in turn give a business value. 

In any of these we could work out how much a product is worth paying for. For example if a company, Strawberry company LTD, doesn’t have a document management system and employees are spending 30 minutes a day searching for documents you can estimate how much time is wasted in a year. An average employee working at Strawberry happens to be Bob, who works 8 hour days and earns €30,000 per year. When you deduct the time that Bob spends on leave and sick he works for 220 days in a year, which means that almost 14 days (220 days * 0.5 hrs / 8 = 110 hours) per year are spent searching for documents. Roughly €1909 per year. Apart from Bob there are 20 other employees and assuming that generally an IT system lasts for 5-10 years, Strawberry shouldn’t spend more than €190K – €381K on this system. From this simple calculation Strawberry can get a rough idea on how much money they can spend to at least break even.

The next step is to come up with the least amount of development tasks required to make Bob’s life easier. You come up with a MVP:

“The minimum viable product (MVP) is the product with the highest return on investment versus risk.”

mvp
On the left we see products that have too little features to be used, while on the right are the products that users would like to use.

Your initial aim should be to produce a product which contains the least number of features yet is still viable. You start to remove any additional features which are not used that often, for example any ability for users to manage their account, change passwords, change lookup values. You also remove the nice to have features such as being able to search by extension or document type. You only concentrate on the basic tasks that get the job done, in this case type in a keyword and get some results. Like this Bob gets to try out a very basic version of the product and checks if its enough to get his work done. From here we can either decide that what we have is enough and thus stop development or do another iteration. The beauty of software development is that we can evolve the first release and produce a better product. This process is repeated until everyone is satisfied. I have to point out that the minimal viable product is not limited to features but should also be used as an approach for software architecture.

design_evaluate_develop

If I am a client asking any company to provide me with a service I would prefer paying per day rather than trusting the company to provide me with an estimate. Here is why:

  • If developers are taking too many coffee breaks instead of working I can terminate the project at any point.
  • If the developers are doing a lousy job I can terminate the project in the beginning since I’m not really committed. I only end up losing a small % of my budget.
  • I don’t have to pay for features which I’m not really sure if I need.
  • I don’t run the risk that developers cut corners since they under estimated.

Most of the time clients are strict on budget but don’t really care if the end product doesn’t have the fancy check boxes, thus we are able to prioritize between the features and get the most important tasks out-of-the-way first. I truly believe that this is the best way to mitigate risks for all parties involved and ultimately create a product which works better.

Did anyone try this approach? Any thoughts?

It doesn’t take 9 mothers 1 month to make a baby

First of all this post has nothing to do with babies. It is actually about an interesting phenomenon that affects house builders, software developers, the government and possibly all types of jobs. Without adding too much hype it’s about Brooks’ law, so those of you familiar with it can move on to the next post.

Let’s say you are a contractor and you currently employ 2 builders. Assuming the 2 builders work 40 hour weeks, you estimate that a house will be finished in 4 months’ time. However for some reason the client isn’t happy about this and would like the house to be built-in 2 months. In this case the contractor would employ another 2 builders thus doubling the productivity and finishing the house on time. If half way through the job one of the workers gets hurt the contractor puts more people on the job to make sure that the deadline is met.

Unfortunately if you had to do this in software development the results would be catastrophic. To understand this better we first need to understand the nature of software development. When one developer is in a team, let’s call him Bob, he is familiar with all the code, and if he is smart enough, any technical questions can be answered either by Google or by himself since he wrote all the code. When Sam, another developer, is introduced to the team he will need to become familiar with the code produced by Bob. Sam then starts to produce his own code and thus introducing some aspects of the system which Bob isn’t familiar with. In this case you’ll need both Bob and Sam to answer the technical questions. This also means that Bob and Sam need to constantly share ideas between themselves, thus periodically interrupting each other.

In order to get their job done Bob and Sam need to store loads of information in their short-term memory including:

  • Variable names
  • Method names
  • Commonly used API calls
  • Other parts of the system which might be effected by the code they are updating
  • Race conditions
  • etc…

This also means that when Bob gets interrupted by Sam, Bob has to stop what he is doing to reply to Sam, then needs to start getting himself back in “the zone” and makes sure he re-obtains all the required information i.e. time is wasted on context switching. Let us assume that Bob needs 4 mins to get back all the required information stored in his short-term memory and let us also assume that Bob has to interrupt every other team member 4 times a day. Plotting this information we get the graph below:

contextSwitching
Graph showing the number of hours on the y-axis against the number of developers in a team on the x-axis. The blue line shows the total number of hours of work per day, while the orange line shows time wasted on context switching.

As you can see when 31 members join the team no work will get done because everyone is getting too many interruptions.

But wait… this is not entirely correct first of all I pulled out the numbers out of a hat and secondly we are basing this on the fact that Bob had to ask all his team mates 4 questions a day. One can argue that you can limit the number of interruptions by adding documentation thus Bob can refer to the documentation instead of interrupting Sam. However when adding more team members this doesn’t only affect the number of interruptions, but also has an impact on:

  • Decisions that need to be taken as a team are greatly affected, sometimes it’s hard to get an idea agreed by 3 developers, let alone by 31.
  • There is a great overhead to induce 31 developers.
  • Time spent in meetings is also greatly affected. If 31 developers speak for 2 mins each, you get a scrum meeting which lasts slightly longer than an hour.
  • To create documentation you might need to consult with 31 developers.
  • And I don’t even want to think what a nightmare it will be to plan the tasks and manage a team of 31 developers.

Anyway you see it, adding more people to a team will not get the job done faster, on the contrary Brooks’ law states that:

“Adding manpower to a late software project makes it later.”

There is of course the optimal number of developers to get the right balance between the work produced and the time it takes to finish a project. This number tends to vary both on the nature of the project and the experience of the team. If you record sprint velocity it is always interesting to see what happens when someone is on sick or on leave for a sprint.

manmonths
Graph showing the number of months required to deliver a project on the y-axis against the number of team members on the x-axis.

In general, teams which require communication amongst themselves do not scale. For your reference the number of communication channels in a team can be found by using the below formula, where N is the number of members in a team:

Communication Channels = N(N-1)/2

For the non-developers reading this post, this is why the government is so inefficient because we elect more than 60 members of parliament (1770 communication channels, for those doing the Maths) who all want to get their ideas across and convince the rest of the members that their idea is the best.

To conclude I don’t believe that you should have more than 7 ± 2 (The Magical Number Seven, Plus or Minus Two) team members which amongst themselves do the required roles to deliver the project: planning, architecture, development, testing, project management, gathering functional requirements, documentation etc…