“Codermetrics” – could be the solution I was looking for

I’ve just got my copy of “Codermetrics: Analytics for Improving Software Teams“, by Jonathan Alexander. I’ve had a very quick skim through and initial thoughts are that this is going to be an interesting read and a worthwhile purchase.

I’ve been struggling with the best way to measure the efficiency and effectiveness of software development teams, having tried a number of approaches and found them lacking. The approach presented in “Codermetrics” is a novel approach and one which I am keen to evaluate.

The Codermetrics principal is not based on performance reviews (though the metrics can be used in performance reviews) – it tackles the issues at a lower level and in a way analogous to how the performance of members of sports teams is measured. As well as concentrating on individual performance, it includes metrics for an individual’s contribution to the team, their flashes of genius and their responsiveness to issues.

The metrics are grouped into 3 areas:

  • Skill metrics (measuring core skills);
  • Response metrics (analysing the ‘fall-out’ from a product release);
  • Value metrics (combinations of the above to measure the values that individuals bring to the team).

The choice of skill metrics is, well, unique, in my experience, and this is where the analogy with sports teams is most obvious. I like the analogy, the metrics and the reasons given for choosing them.

Once I’ve had a good read through, I’ll provide a more thorough review. Suffice it to say that I’m really quite keen to try this out.

Ady

Becoming Agile

A man climbs a staircase

Photo by tanakawho. http://bit.ly/cBOklT

Well, it’s been a busy few weeks at work, and now that I’ve got a little free time I thought I’d get down to writing about it.

3 weeks ago we released V1.0 of CitizenScape, our latest product, to our Virtual Town Hall pilot group and we’re just about to release V1.1 for testing on the staging server. It’s been very busy, but we’re working hard to get tagging and taxonomy support into the product, which, we feel, will enhance the product enormously. More on that another time.

We’ve also launched our EuroPetition product; a project that takes our E-Petitioning application and enables it to be used Europe-wide to create and promote petitions to the European parliament / council. There’s still a little bit to do here for some of the territories, but on the whole it’s done and dusted.

With all the busyness, we’re having to tighten our processes and manage our time a lot better. We’re developing using the Scrum methodology – one of the Agile software development practices; and trying to work pragmatically.

We’ve recognise that, in the past, we have been poor at meeting deadlines. Sometimes this hasn’t been our fault – the deadlines have been set by a third party and we’ve not had the opportunity to provide an input; and sometimes it’s been that we’ve simply been bad at estimating the time that things will take.

We’ve adopted the Scrum process because we wanted an iterative process – one that would enable us to meet deadlines and plan the detail more; I’ve always felt that the more ‘traditional’ waterfall methodologies plan for the ‘big picture’ in an all or nothing way. If you run late you miss a deadline with little or nothing to show for it.

We’ve redressed this in a number of ways:

  • We’re working in fortnightly sprints, and ensuring that we have working products at the end of these sprints.
  • We’re prioritising the features so that we have the most useful application sooner, rather than later.
  • We’re asking for client feedback sooner, so that we fix issues or misunderstandings at the earliest opportunity. (Although we need to get clients more involved, still.)
  • We’re releasing little and often, and to a published, public schedule. Having the dates out in the wild means that we are more determined to meet them.

I wouldn’t say that we’ve fully adopted Agile or Scrum – we’re using what works for us and will review how effective it is over the coming months. Where there are inadequacies, we’ll introduce new methods to fill the gaps. Measuring our success at developing to the timescales and feature lists will be paramount to ensuring we can properly analyse our success (or lack thereof).

Things we need to do now to make life easier:

  • Align our release timetable to the sprint cycles. Currently the release (for client test) falls in the middle of a sprint, which isn’t ideal; it makes sprint planing a little difficult (for someone who is relatively new to such things).
  • Reinstate morning scrum meetings. We used to do these when we were using index cards for development stories but, since we’ve started using Pivotal Tracker, I’ve neglected to hold these on a regular basis. This is very remiss of me; not only do they help me to understand how we are doing compared to our desired progress, but they also provide a mechanism for the teams to discuss issues and resolve problems that may otherwise be overlooked.

So in conclusion, then, we’re getting better and there’s more to do. Having to release two major applications almost simultaneously has brought home the need for tighter development processes that allow maximum flexibility. We believe that Agile development and the Scrum methodology are appropriate for the work we do and the way we work.

Next time I hope to be able to introduce our thoughts and solutions to tagging, taxonomies and the semantic web, some feedback on the applications we’re launche,; and an update on our progress with Agile and Scrum. Until then, good night.

Square Pegs and Round Holes #2

I’m sure you’re all on tenterhooks wondering how things have been going since my last post on this subject?

No?

Tough. I’m going to tell you anyway. If nothing else, it helps me clear my head and check what I’m doing.

To start with, not a lot happened – other things got in the way. Then I got down to creating the DB architecture, and then refactoring the DB architecture as I realised I was making it way too complicated. The core business data is now in 5 tables.

Then I got down to work with Code Igniter and Ocular – always a good starting point, if you ask me. I’m developing pragmatically, capturing the major requirements first, and things are moving on apace.

Today’s major task will be importing over the libraries and helpers I haven’t already taken (from our other Code Igniter based projects). I need to do this in the office just in case I need to ask about their integration; I can’t be left trying to work it out for myself over the weekend if things don’t pan out right.

Once the libraries are imported and working, I’ll continue building the business logic into the models based on the prioritisation of the features.

I need to leave myself a good 3 – 4 hours to ‘prettify’ the application, but I’m marking it all up with HTML ids and classes, so that shouldn’t be too bad.

Finally, on Monday, deploy to the Staging Server and make sure the DNS is hitting it. (Which reminds me – must get the DNS names sorted out tomorrow.)

Later,
Ady