Softwareproject Management

Everything about software projects - management: done right or wrong

Time Reporting: a Waste of Time?

TAKE SOME TIME TO REPORT YOUR TIME. Or just simply stay dumb. Even with the most talented and k
WASTING TIME?
How can you find time to report on your time? And why you should.


Even with the most talented and knowledgeable software development team working on a project, it is impossible to work effectively without being specific about the time spent on work. 

Though some teams prefer to work on a loose schedule, and planning or reporting "officially" in an Agile environment aren’t the easiest of endeavors, time reporting can help a team to be smarter in the long run than without it. Furthermore, keeping track of time can help your team optimize its processes, saving money and reducing time to market, while helping you streamline your process for future projects.

Dividing Tasks of Your Project Into Clear, Actionable Items with Precise Deliverables

From the start of your project’s planning phase, it is critical to think about what needs to be accomplished (let us emphasize the importance of the age-old tip: define your requirements as clearly as humanly possible!) and how long these tasks will take to complete. However, especially with Agile teams, sometimes there is a tendency to dive right into the work, estimating schedules and approximating the order of micro-projects along the way. It is only natural that this tendency takes place during project development: with the burst of initial energy, many team members are less inclined to pause and plan before beginning their tasks.

 

Nevertheless, this excitement eventually fades, leaving a project team without a plan keeping them on task, or energy driving them forward. An initial investment of time dedicated to the organization of the project from the beginning can prevent an exponentially larger amount of time from being wasted throughout the duration of a project. Even if you choose to replace traditional Waterfall processes with those of the Agile framework, it pays to devote some time for planning your project.

 

By dividing projects into tasks that are time-based, your team members can be held accountable (but not necessarily punished or “incentivized”!) for producing deliverables on a particular timeline. Tasks that are typically described in vague “umbrella” terms can be broken down into specific, enumerated actions, tracked using Love-PM’s Gantt Chart feature. When clients or your own supervisors later ask about how your team has spent time available, or how long it might take to process any requested changes, you will have documentation to back up your work and to be able to pinpoint the exact timeline and pricing necessary to move forward with adjustments to your product.

Measurement without micro-management

Tracking time in an effective and ethical way can help your team discover information about how hours are spent within a project team, as well. In the software development field, many developers feel forced to forge their timesheets in order to earn appropriate pay for coding production and troubleshooting tasks. This behavior can lead to poor management decisions in the future, and can promote dishonesty among team members about how their time at work is spent. 

In a service provider / developer setting (where you are a consulting or software development services provider) however, tracking time can lead to increased efficiency – increasing your team’s amount of billable hours. This tactic brings more profitability to your business.

 

But be careful: time tracking is not really meant to catch workers when they are not being responsible with their time. Expecting to happen so will surely fire back. Smart workers will be able to fill out they time. Just remember the old Parkinson's law that is still brilliantly valid.

So how to sell time tracking, then, to your team members? Appropriate time tracking can help your team members plan their work better. What’s more, it helps support your team members on projects that require a lot of small tasks, each, but otherwise has work that is hard to be estimated in advance. If documentation of hours and work performed demonstrates that workers are at maximum capacity and they need additional support, you will have the historical information and current proof necessary to make decisions about bringing on more staffing to support the team.

Planning Future Projects: How Time Reporting Can Lead to Major Future Gains

When planning future projects, it is especially important to keep in mind how time was spent during the course of your team’s previous projects. Looking back at historical data of your team, it is possible to pinpoint where time could have been used more efficiently, and to be able to develop a realistic timeline for what needs to be accomplished by your team on a current project. Considering what a difficult task effort estimation is (especially so with Agile teams), this is an important benefit offered by time tracking and reporting.

 

Reviewing time reports from past projects is a good way to keep your business accountable and thriving despite challenges and setbacks that future projects may pose to your team. In many cases, wasted time may not be the result of anyone acting irresponsibly. Rather, team members might be encouraged to dedicate time towards portions of the project that can be determined, in hindsight, to have little impact on a product’s profitability. Though it might not seem to be an important task in the moment, logging time can provide critical insights that can lead to major project redesigns in the future for your company, department or team. 

Who is Using 100% Agile. 80%? Seriously.

WHO IS USING 100% AGILE? 80%? SERIOUSLY. No - we are not kidding. When it comes to Agile, applic
WHO IS USING 100% AGILE? 80%? SERIOUSLY.
No - we are not kidding.

When it comes to Agile, application Agile is on the rise. Agile is the fancy stuff.  This is not only us saying it: year by year there are more and more companies using Agile. Just read this report: The state of Agile (9th survey).

(No, we are not their marketing people - Versionone is one of those vendors who provide you with an Agile software development software, but they do not have plenty of things we have, and surely they stick to pure Agile, so we are not afraid of you having a look at them).

When it comes to fancy things, people claim to use / own / like / seen (etc.) those things - even if the do not or they do but not to a full extent. 
E.g. when it comes to yoga - yoga is more and more fashionable nowadays. If you ask someone if they know what yoga is, s/he will tell you "of course, I practice yoga". When you ask them, what kind of, they will give you some answer - then: end of communication (no, it is not always the case, but it is the case just quite often). So more and more people know what yoga is, and after a while it will become just too uncomfortable not to know what yoga is, as everyone else is saying that it is just too good to be true.

We are wondering the real adoption and application of Agile and Waterfall - and the relating project management processes and methods (think of PRINCE2 and PMBOK) and we are wondering what these real adoption levels say.
By real adoption we mean that someone is using pure Agile (say, 80% of the tools, methods Agile is supposed to work).

And we are not alone, wondering - there is another study result here: what results in better code? Agile, Waterfall or...?

Side-note: When (and Why) is it Difficult to Go 'Pure Agile'?

Still there are situations when it is very difficult to imagine that the project is done in a 'pure Agile' way.  Why? There can be several reasons:
  • fixed budget - if there is a completely fixed budget, then harder to predict requirements can represent a risk factor some participants may be unwilling to take.  This will result in plenty of documentation and the need to clarify the requirements (a.k.a. stories) early on and discussions over what is in / out of scope.
  • client-vendor settings: if there is an external vendor in a project who is responsible for some major part (or the entire project) - again, learning what is needed later may be just simply not an option
  • what project managers and your technical people are used to: if they know better waterfall or they believe in it more, it may be very hard to get them going the 'Agile way'

What to Do If 'Pure Agile' is Not an Option? 

What to do in these cases? You have three options:

  1. Stick to waterfall. Do everything the old way.
  2. Or go ahead with pure Agile and take the risks - as there are, for sure.
  3. Or combine both: create the list of requirements (=stories) and define those requirements in a 'waterfall manner'. Then execute the project applying almost all the Agile principles.

We believe that, apart from the very clear scenarios, it may be very difficult or impossible to go 'Pure Agile'.

... and the Survey Results: Combine Agile with Waterfall

A recent study by InfoQ: 2014 CAST Research on Application Software Health (CRASH) concludes that:

"Consistently across all the structural quality characteristics—Robustness, Performance Efficiency, Security, Changeability, etc.—the mix of Agile and Waterfall methods had significantly higher scores. In fact, for Robustness and Changeability ¾ of the scores for the hybrid methods were higher than the median for Agile or Waterfall methods used alone. In addition, there was less variance in the structural quality scores on the hybrid methods. Remember, these are primarily large business critical applications, so late corrections to the architecture are very expensive and often constrained. Believing that a satisfactory architecture for such systems will emerge across numerous Agile sprints can be risky. However, not evaluating architectural decisions until system testing in Waterfall projects is also risky. Good structural quality was most often observed when the early architectural analysis characteristic of Waterfall methods was combined with continual testing of the emerging software in Agile sprints. We did not see significant differences between Agile and Waterfall methods in structural quality, it was really their combination into hybrid methods that made a difference."

Are you surprised?
After thinking over the above factors, the results should come as no surprise to you.

Why? Just re-read the highlighted text.