Johanna Rothman’s take on estimation

Here’s some sage advice from Johanna Rothman’s “Managing Product Development” blog:

  1. Never, ever, ever provide a single date for a project or a single point for a budget without a range or a confidence level.
  2. Expect to iterate on the release date and on the budget, and train your managers to expect that from you.
  3. If you get a ranked feature set, you can provide working product in the order in which your managers want the work done, while you keep refining your estimates. This has to be good for everyone.
  4. If you can say this without being patronizing, practice saying, “Remember, the definition of estimate is guess.”

I urge you to read the whole of the post – it’s a good précis of the difficulties in estimating budgets and timescales. I’m looking forward to future posts in the series. The home page of her “Managing Product Development” blog can be found here.

Update 3rd November

Johanna has posted the second part of this series.

Update 8th November

Johanna has posted the third and fourth parts of the series.


Wanted: PHP in the Cloud


Currently researching moving a suite of  hosted PHP (well, LAMP) applications to a cloud-based infrastructure. Particularly interested in:

  • One-click deployment
  • Infrastructure as a Service (IaaS) – flexibility, performance, scalability, load balancing
  • Metrics
  • Resilience

I have discovered phpfog and would be interested in feedback:

  1. From people who use phpfog – is it good/bad? Ease of use. Cost effective?
  2. From people who use something that is not phpfog – What do you use? Your experiences.

If you have anything to offer to support my research, I would be really grateful if you would leave a comment. Also appreciate (re)tweets in order to spread the net.

Many thanks in advance,


Help me become Agile

Hi everybody,

I’m looking to find a software company in the Sussex area (or London) that is using Agile development methodologies, and which wouldn’t mind accommodating me for perhaps a day to look at their processes in action. I’m particularly interested in:

  • Scrum-based development
  • A company that is not Rails/Grails based
  • Is managing, to some extent one or more of the following:
    • Automated testing,
    • Automated deployment,
    • Database migrations,
    • Development management software (such as Pivotal Tracker, but not necessarily)
  • Brighton area, but anywhere in Sussex or London would be great

I’m hoping that there are altruistic, sharing companies out there that will take me in and show off their practices. I’m keen to move our development further up the ladder to full ‘agility’ and would appreciate the time and others’ experiences in making the right choices.

Many thanks in advance.

Please contact me directly through any of the contact points on my about page.

Also, if this is not for you, but you know of someone who may be able to help, please send them a link to this post.


Gathering KPI data

A long time ago I said that I would be talking about Key Performance Indicators (KPIs) for Software Development departments. What with various other commitments, holidays and the rest, it’s not happened, and looks likely to be happening on my company’s blog when it does.

That said, I do want to put down some thoughts regarding my experiences so far in trying to consolidate data from ‘the top’ (roadmaps & strategies) and ‘the bottom’ (timesheets) and getting them to meet in the middle (KPIs).

Operator error

The essence of what I want to do with KPIs is measure accuracy, efficiency and cost. In order for any measurement to be done we need to capture ‘actuals’ – time accrued against work packages – and compare that to what we (I) estimated they would take. This necessarily leads to the need for all relevant parties to complete timesheets. Fortunately, this has been accepted in good spirit and, although I do have to provide a gentle reminder once in a while, I’m receiving completed timesheets. (Timesheets are paper-based. This was by choice, as we couldn’t find a suitable application that would meet our requirements and also because we wanted to trial and streamline the process/data before committing to any particular system.)

On the other side – the estimates – I have a rather natty spreadsheet on which I put requirements, break them down into work units / stories (with estimated effort) and assign them to staff. I can then assign each requirement to a Year and Quarter and watch pretty graphs go up and down with estimated capacity / slack in the department, which allows me to rehearse ‘what if’ scenarios in scheduling meetings. (Our strategies and roadmaps are ‘agile’. Are yours?)

My problem is getting the twain to meet. My experience thus far is:

  1. I can’t read other people’s writing.
  2. People aren’t necessarily following the instructions about how to fill out the sheets.
  3. Mistakes are made.

(The last one of the above is not specific to paper-based timesheets, but mistakes can be made in writing the sheet and in me reading the sheet. With an application-based solution there would only be one human in the process.)

So far, getting the timesheet data into my all-singing spreadsheet has proved both time-consuming and though-provoking; the main thought being “there must be a better way”.

Another way

In a nutshell, I really need to get it all automated. This is not going to be easy as I don’t think there’s anything in the market that will do everything I want, and even a mash-up will need a central co-ordination hub. I would love to be able to piece already existing applications together and will be investigating solutions for each tier of the process, but I do believe that there will be large chunks that won’t be available or, if they are, won’t be suitable.

First step

So, I’m going to start a ‘hobby’ project, concentrating on the aspects that are most pressing – getting timesheet information into a database that I can use to compare against what I already know from my spreadsheet. This will involve investigating the timesheet facilities available in other intranet applications we use (our CRM has timesheet functionality, for instance).

And then

If I can borrow or build the timesheet functionality I’ll expand upon that to incorporate stories, requirements, products etc. into a coherent, strategic software development management application, again integrating external systems (Pivotal Tracker / Lighthouse / our CRM) where possible.

My head’s buzzing with ideas, but I need to stay focussed on the essential. I’ll keep you up-to-date with developments.

In Defence of Timesheets

Photo of a calendarThere is a lot of resistance to timesheeting, and this appears particularly to be the case amongst development teams. As an ex-developer (and still occasional developer), myself, I remember being in the same camp. But as I’ve progressed (upwards, for the most part) and have to start accounting for my department’s cost, I have concluded that the only sensible way to gain useful metrics is via employee timesheets. Timesheets, alone, however, don’t provide all the information that I (or my superiors) require, and so should be used in conjunction with other systems and tools.

Having moved from being dead-set against timesheets in my early career, towards understanding their benefits and, ultimately, near-evangelising about them, I believe that the single most common reason why they are not so readily adopted is a matter of communication.

So what are the detractors saying? Here are some of the most common issues that I have encountered:

  • It’s big brother – I don’t want my every move recorded.
  • At the end of the day I can’t remember / don’t have time to record everything that I did.
  • It will show that I don’t do a full day’s work & I’ll be penalised / pay docked / flogged.
  • It will highlight the days when I am late for work.

I can understand all of these – I’ve felt them myself.

So what’s good about it? Here goes, in no particular order:

  • No-one (at least no-one who understands how people work) expects you to put in a full day’s productive work. It’s not possible. You make tea, have a cigarette, read emails, attend meetings, get distracted by a conversation that someone else is having. These are all times when you are not ‘being productive’. But, it would be an awful place to work where you couldn’t do any of the above and were expected to be productive from the second you sat in your chair until the second you could go home. That would be a Victorian work house; you don’t work there.
    In the more progressive working environments, bean bags, pool tables and games consoles are available; it’s understood that people are more effective when they are able to step away for a break – they get more done during their ‘productive’ times.
    If I see a timesheet and on it Bill says that he’s spent 8 hours developing ‘Product X’, then there’s a problem; it simply can’t be true.
  • So what if you get into work late? We don’t expect you to be 100% productive (see above), so the odd half hour here or there isn’t going to break the bank. If it’s going to be a regular occurrence, make an arrangement with your line manager. (The issue is not that you are late – it’s that other people see you coming in late and ‘getting away with it’. If you have made an arrangement with your manager then they can rebut any ‘tuts’ etc.) The one thing you absolutely must do, though, is apologise for being late (in the case where it’s not pre-arranged), but that’s just politeness.

As an aside, I think it’s worth stating at this point that there are two ways of implementing a timesheet system. One that tells you what a particular person was doing at a particular time of the day; and a second that simply tells you how much time was spent on each task during the day. It’s the latter that I would always advocate; It resolves a lot of the issue with people remembering what they did when the end of the day arrives and it’s quicker to enter information in this fashion. It’s true that the information entered is likely to be less accurate than ‘at the time’ recording of the information, but these things average themselves out in the long run. It also depends a lot on the granularity of your system – whether you record by the hour, half hour or quarter hour, for instance.

To a certain extent, timesheets are big-brotherish. That’s kind of the point of them. However, I see this as a good thing, rather than a bad thing. To the person who says to me “It’ll show that I didn’t work full-time on ‘Project X'”, I’ll say, “Yes, and it’ll show why.” – When my boss says “You said you’d deliver Project X by today – why is it going to be 2 days late?”, I can say “Because Bill spent 10 hours working on that little side-project you insisted on chucking into the mix.” (Although, as a good manager, I would have flagged this far sooner than d-day, of course.)

I need to know what my team are working on. I can’t sit over their shoulders 24/7 cracking a whip, I certainly don’t want them to have to work like that, and I can’t be a constant gate-keeper, making sure that nothing off-piste gets added to their work lists. But at the end of the day (both literally and metaphorically) I want to know that these things have happened and how much of a distraction they were. With this information I can better estimate timescales, costs, schedules, etc. And that’s a good thing. It’s the very nature of needing to know all these asides and distractions that makes the implementation of a timesheet system so compelling.

What’s Next?

Rather than a conclusion, I thought I’d share my thoughts on where this is going. Firstly, I’ll be looking into ETT – Emergent Task Timing and will feed back on whether that might provide the compromise between accuracy and efficiency with regards to timesheets.

Next up will be about metrics, statistics, and KPIs. Timesheets and other tools will be involved.

You have been warned.