You've been there. A new client signs on, asking you to build them a website. They tell you what they think they need. You listen, nod and then tell them what they actually need. You shake hands, sign on the budget, translate the client's question into a language the programmers understand, set up your Kanban board and start working.
Oh but you made a mistake signing on that budget, didn't you?
Before long, you'll find that your backlog isn't clearing (in fact it seems to be growing) as the client keeps coming back with feedback, that your developers are taking 60 minutes to fix a bug instead of 30 and that dear god you wish you had asked for a bigger budget.
It's OK, you're not alone in this. This happens all too often, when teams think "organization" and not "time".
Kanban boards are superb tools for organising development workflow.
It’s the flexibility that makes Kanban a better method for agile teams than, say, Scrum, which (in it’s simplest form) relies on highly target oriented sprints to develop software in an incremental way. Don’t get me wrong - Scrum is great if you don’t need to worry about interruptions (or if you have staff in place to deal with interruptions), but if you can’t afford to run fully dedicated teams against highly specific goals, Kanban is probably a better option.
At its very core, a Kanban board has three basic states - "To Do", "Doing" and "Done".
For smart business leaders, however, the states read "How much to do?", "Doing for how long?" and "Is it really done?"
Using these Zaps, you can automatically bring your Asana projects and tasks into Toggl Track & track how much time you're spending on each.
Tracking your time spent on different projects and tasks will help you see the big picture when it comes to project planning and spot potential bottlenecks in the development cycle.
So why is time so important? For two reasons.
The first reason is a tactical one (yes yes, tactics and strategy are intertwined, but bear with me here) - you need to watch your lead time.
Lead time is basically the time it takes for a ticket or an issue to go from being added to the backlog to being done. The shorter the lead time, the more efficient you are - if you're working off a fixed budget, you'll be more profitable and if you're working for hourly rates, your client will be happy too (well, for obvious reasons).
While not all Kanban teams use time tracking, I would argue the time factor is nonetheless a core part of the Kanban philosophy - though it is not always so overtly stated. A major (and known) benefit of using a Kanban system is its ability to point out bottlenecks in the development process, usually by way of imposing a limit on the number of active tasks a team can have open at any time - if the number of active tasks is too high, the team will have to identify the problem and solve any issues.
But bottlenecks are the last symptom of an organisational issue. Having an accurate overview of your lead times will point to inefficiencies much sooner. Oh and by the way, inefficiencies don't necessarily mean that your developers are too slow - rather, you might find out you've bitten off more than your team can chew and that it's time to look for extra staff to manage the growing workload.
OK, but that's just the time tactics - things get a whole lot more interesting when you start looking at time costs on a strategic level.
If you’re charging your client solely by the hour then, well, congrats! Because however long a project takes, you'll at least be compensated for all your hours (though yes, get a reputation for being too slow and expensive and pretty soon you'll be swimming in a very dry client pool, alone).
But that's a story for another time - where strategy gets really interesting, is when you have to work with a budget.
If you’re working off a retainer, you’ll want to have really good estimates in your back pocket - sell your services for too cheap, and it won’t be long until you’re dealing with an angry mob of underpaid and overworked developers, slipping deadlines and bug-riddled deliverables. Coming up with a budget that satisfies both you and your client alone is a science. Add to that the fact that development never goes exactly as planned, and boom - we're in quantum mechanics territory.
So, here's your core problem - how do you account for all the potential unexpectancies when coming up with your price offer?
You might say the answer is “experience”. This is basically correct, with one amendment - it has to be “measured experience".
Any software development project is a sum of many different moving parts. In addition to variations in technical difficulty, you’re also dealing with tasks of varying complexity as well as your different employees and their different work skills and habits. You might even need to bring in extra help midway, in the shape of a freelance developer with a very particular skillset.
The problem is, while you might have “experience” with how long one task or the other should take, or how long one employee or the other takes to complete something, it’s nearly impossible to add it up into an accurate big picture. This is where “business intelligence” comes in.
Successful companies never “wing it” - they act consciously according to a plan based on measurable metrics.
So kill the guesswork. It's not in your business vocabulary anymore.
The only way to have good estimates is to know exactly how long specific tasks have taken to complete in the past. The only way to know how long things take is to track them. Why so?
Because time is a treacherous thing - how we perceive it is highly subjective and depends on many different factors. Imagine, for example, the following scenario. You go to the cinema and see two movies of equal length - one you absolutely love, and the other one so agonizingly dull that makes you wish you were dead. Without knowing their exact runtimes, you would most likely estimate that the film you liked was shorter than the second, boring one.
We don't really have a sense of time - rather, we perceive time through a myriad of external factors. As such, our internal clocks aren't terribly reliable.
The effect can have a catastrophic effect on business decisions, as lost minutes here and there slowly add up to horribly distorted data and grossly miscalculated estimates.
In the worst case scenario, these estimates turn into "official statistics".
In short - accurately.
Because our brains are terrible with time, you can't really leave them unattended for even a second. This is why we made damn sure that the timer in Toggl Track is as simple to use as possible. It does a lot of compiling, reporting and analysing under the hood, but we knew from the start that the UX had to be absolutely, ridiculously and uncompromisingly simple.
The reason should be clear to any software developer - if an app is difficult to use, people won't use it.
If time tracking is difficult to the user, they will likely resort to filling in their hours later, which decreases the accuracy of your reports. There's no sense in getting a time tracking app and using it like a timesheet. That'd be like buying a chair to go jogging.
By the way, this qualitative difference between tracking in real time and filling in timesheets isn’t something we’ve just made up. We recently did a survey among 1,000 business leaders using Toggl Track (you can see some of key results on Slideshare), asking about their business models, work methods and the role time tracking plays in their business.
Going through the results, we found that teams that typed in their hours manually saved on average $3,519 per year thanks to increased efficiency (not bad!). But - get ready for the kicker - teams that tracked their hours in real time, saved a whopping average of $15,064.
But enough about the savings, the point here is this - real-time tracking is accurate, but if it’s not simple to do, people get lazy, the money dries up and everybody loses their job.
We've managed to build some impressive reporting, exporting and integration features into Toggl Track - if you want to learn about how these can work for software teams, hit that neat little CTA button after the jump.
For now, let's spell out what you get from tracking time on a strategic level. Namely this - having good business intelligence means you can walk into a meeting with a new potential client with a very clear understanding of how much your time costs, and how much of your precious time the new client will be asking for.
Chances are they will say something like “yeah, and I guess if we have some suggestions you can make some changes later?”
Now, there’s nothing wrong with that question - for agile teams, development is about constant cooperation and feedback. But when you’re armed with accurate time tracking data about exactly how long different kinds of development work takes for your team, you’ll be in a much better position to judge how your client’s requests and ideas match the offer on the table.
Also, you’ll be in a much better position when (re)negotiating fees - it’s hard to argue with an actual minute-by-minute report of your work. We’ve also seen a few cases of people sending out regular Toggl Track reports as a preemptive strike (you know, to avoid that pesky “how hard can it be?” question).
Just make sure you’re tracking time with discipline - but also, with respect towards your team. Your developers must know that time tracking isn't used for penalizing them for their inevitably varying work methods, but that it serves a more strategic purpose.
Remember that time tracking isn't about putting people in boxes - it's about knowing the boxes you work with.
Teams of 10+ are eligible for a personalized demo to see how Toggl Track can meet your time tracking goals