Jonathan Howell

Iteration planning meetings can be a real drag. I have been in meetings that have dragged on all day: with estimating in particular seeming to last an eternity. It is particularly painful when this is all happening on a conference call with a globally distributed team (more on that in another post maybe). This is what the process was like at Huddle when I first introduced agile. We would have Iteration Retrospective, Iteration Demo and Iteration Planning all pretty much back to back. Iteration Planning would start with estimating all the highest priority stories, and adding them to the iteration until the iteration was full. On a bad day all if this could take the best part of a day, and was the part of the iteration that everyone dreaded - not to mention the amount of time it took up.

(more…)

By popular demand (OK it was only one person who asked, but I am sure he is very popular), this post will cover our experience at Huddle on what makes an appropriate maximum story size for it to be planned in an iteration or sprint. Again this is a much asked, and much answered question, and this is not the right answer - just the answer that has worked for us (and a few that did not work along the way).

(more…)

The uptime of a site like Huddle.net is of vitally important, so I was pleased to see that recent performance hit 99.99%  - four nines. See my recent post on the Huddle blog for more details.

Last month I was press-ganged by a bed-ridden Andy McLoughlin to talk to the London Facebook Developers Garage about Huddle’s launch on LinkedIn last year. Very short notice and a packed schedule that day meant no time to prepare slides - well, PowerPoint is overrated anyway.

See here for a (5 minute) report on the January event, and here to find out what I had to say (10 minutes).

At Huddle, we run two week agile development iterations, and each iteration is a potential production release candidate. That means that the code developed is of a quality that could be released to production, but it may or may not make sense to do so from a product perspective. For example, when we developed the new meetings functionality within Huddle, the development of the initial release spanned two or three iterations, and to release after the first iteration would have meant releasing an unusable product: you could create a meeting but not delete it. Production ready refers to the quality of the code (meeting creation was implemented, tested, code reviewed, refactored etc.), not the completeness of the product.

So the two week iteration cycle means that we have the option to release every iteration, but we do not always do so. (more…)