Friday, March 12, 2010

Feeding Body and Mind

Software development is an ever changing field. Some might even say volatile. Languages, tools, methodologies, paradigms, philosophies, manifestos. Structured programming. Functional programming. OO programming. Agile principles. Extreme Programming. TDD. Continuous integration. Acceptance testing. Automated testing. SOA. Pascal. ADA. Lisp. C. C++. Java. Python. PHP. C#. Ruby. Grails. Haskell. Scala. Cloud based computing and more...

How can one keep on top of this?

Well one very effective way the engineers have applied over the last few months is a regular "lunch & learn" session. The idea of something like this has tended to go in and out of vogue for years in Perceptive. There's always been plenty of topics that would be interesting: "Talk people through the latest work you've done," or "Show us what you've learned about the new technology your last project employed."

The big barrier of course is the substantial investment of time required to deliver a coherent and valuable session. And then to do that regularly, even monthly, even if the task rotates...well it just seemed really hard.

A few months back though, we hit on the solution. Google (amongst other sources) post a huge number of fascinating presentations and talks on a multitude of topics. And they're delivered typically but top thought leaders in the software development field. And they're free too...they're just a click or two away on Youtube.com or similar.

So we started running lunch & learn sessions. We'd start with watching a video that someone had picked out as interesting. Pizza would arrive. And when the presentation was done we'd sit and chat about it. We found it to be a really easy way to get exposed to new ideas and technologies. It required very little preparation effort which has allowed us to keep this up regularly, and in fact there's so much value coming out of this we're increasing our frequency from once to twice a month.

Wednesday, March 10, 2010

What's the point of points?

One of the earliest changes we tried out that got the agile snowball rolling was estimating using points rather than hours or days (or weeks...)

Estimating in points though is a weird thing. It doesn't seem to make a lot of sense at first. It's really quite hard to explain and has a rather abstract quality about it. Look at some of the things you hear or read when you go looking for an explanation:

"Points are a measure of effort more than duration"

"Points are relative, not absolute"

"Points aren't a measure of time, don't think of them in hours"

"Whatever you do, don't set up a conversion rate like 8 hours = 1 point"

And this "estimating in points" idea is meant to help?

When I started to read about points and their advertised benefits I sort of thought I got it. I wasn't certain, but I found myself ready to try them out and take a leap of faith.

Initially I was skeptical. After all, it's pretty easy to pick away at some of this stuff and claim that it's just another pointless (pun intended) change as one sees so often in software development. (Software development is, after all, partly a fashion industry.)

Take the claim that points are relative. Well so can hours be. For instance, if "feature X" took 100 hours and is estimated by me as approximately twice as hard as "feature Y" then, relatively speaking "feature Y" is gonna come out at 50 hours. So big deal.

However, here's the thing. Points alone are not that special. They do address some of the issues of estimation such as it tending to be fractal, i.e. at some point the more detail you break down your work into the more complexity you unveil and less less accurate your estimates turn out. But by themselves they are not going to solve any major problems.

Points + team based estimation + tracking team velocity on the other hand is very powerful.

Together these concepts work like the legs on a three-legged stool: it'll fall over if any one of them is missing, but together it's rock solid.

So how do these three things work in concert? Easy...

  • Points really do provide a nice simple unit that discourages over-analyzing things and are very easy to to perform math on (twice as hard, half as hard etc.) They're very quick so there's no need for tedious marathon estimation sessions.
  • Team based estimation encourages full understanding and participation by the whole team. It also limits the likelihood of the most experienced people providing unreasonably low estimates that other team members have to abide by. It also equalizes the understanding of effort between software and QA engineers.
  • Finally velocity, that is the measure of total points of work completed per iteration, provides a team with an easily understandable measure of their capacity, i.e. how much work they can get through in an iteration. This is incredibly useful because it allows a team to guard against being asked to complete an unreasonable amount of work in a certain period of time. Moreover, with a list of features estimated in points one can now easily predict how many sprints are likely needed to get them all done. Much easier than estimating in hours...

Those three points (pun intended, again) are pretty good for me already. But there's more. We now have a much more customer friendly language to speak in. It makes for easier negotiations. It turns the conversation away from "can you just get it all done by June" to more of a dialog where they understand capacity and can make comprises over features to hit their preferred deadline.

And that, for me, is the point of points.