Remote scrums are hard work. The first clue that something was wrong was when our sole remote coder volunteered to stop attending the scrum because he didn't find it useful.

This is a danger sign. Further probing determined that it wasn't that the format was wrong; it was just that he couldn't hear anyone. We're using Skype video calls, with the laptop sitting on a chair in its place in the circle, using the Macbook's built-in mic and speakers. While the mic's okay for 1:1 conferencing, it's not sensitive enough for people standing a couple of metres away.

Read more...

Since we started this blog it has been running on the same Mephisto release (on Rails 1.2). Aside from being far from easy to upgrade and migrate the data to the latest version of of Mephisto, we were getting pretty bad comment spam and syntax highlighting was frustrating.

Classic blogging apps were never quite up to the job in my opinion. The editing interface is just a textarea or a broken wysiwyg editor and versioning is shoehorned into a database. Since moving our wiki from an app to simply markdown files on Github we haven't looked back, so why not the blog?

Read more...

Our Daily Scrums were taking over fifteen minutes. Even for eight people, that's excessive; it wasted two whole developer-hours and meant that the day started at low energy.

We tried rephrasing the questions - "Of what you did yesterday, what gotchas do the rest of the team need to know about?".

We tried aggressively intercepting conversations that should be taken offline, using postit notes as placeholders.

Read more...

One of our latest client products has slipped stealthily from private beta to being open to the public, so I thought I'd let people know about its existence.

Tourdust is a website for independent tour operators to advertise their diverse and interesting experiences for free. It is centred around the kind of activities which the packaged holidays don't offer; the real gems which lie slightly off the beaten track. Many of the people who run these tours have little access to a global audience, and building and promoting their own websites is often a problem.

Read more...

The best CMS I have ever used is a thick black sharpie and a wall.

"When I walk in here, I don't have to ask how it's going".

Our tech lead can walk in, scan the room, and see in seconds that we're slightly ahead of schedule, that the performance data is good but needs checking, and that we won't be deploying today until 4pm.

And because it's easy, and it's interesting, he does. "Write on the walls" is immune to the "ghost town" effect that afflicts most corporate intranets. Everyone likes drawing, and a bright red "WALL OF SPEED" is a much more fun way of communicating benchmark results than an Excel spreadsheet buried somewhere in source control.

Read more...

It seemed wasteful to bring the entire development team of four into the whole-day User Stories Workshop, so we didn't. I wanted to take half an hour to brain-dump the result into the two absent developers, but never got the chance. So we went into the estimation session with two developers who'd been at the USW, and two who were working only from the cards.

We tried Speed Poker without success; two developers were playing '?' cards or wildly varying estimates. The estimating took a half-day, using up all the time we'd saved at the workshop.

Read more...

Planning Poker is a basic part of the Agile process. We've optimised it.

We can play without cards. For short sessions, or when we need to re-estimate on the fly, fingers behind the back work perfectly. Big stories need both hands. Hands behind the back means "I'm ready to estimate", a crooked finger means "half a point", open palms means "I don't know". This works well in release planning when we're discussing descoping a card; the client agrees to a change, and we do a new estimate on the spot.

Read more...

Stakeholder availability is a problem for any methodology, but Agile gets hit particularly hard. The User Stories Workshop is most vulnerable; although the rest of the process uses a single Product Owner, the USW needs representatives from all over the client organisation. This, combined with a typical half-day duration, makes it very hard to schedule.

Above a certain level in the management hierarchy, nobody's ever really 100% present in any case. At our last workshop, both high-level stakeholders had mobiles out, dealing with incoming emails that are more polite, but not much less disruptive, than incoming calls.

Read more...

A few months ago we transitioned from hosting all of our apps in development on two Slicehost slices to individual Amazon EC2 instances for each. As much you want vendor frozen Rails and Merb to work (including all your app's dependencies) it's always plagued with issues. Having completely separate environment for each app clears up a lot of issues, including the all to often mistake of upgrading Rails only to find some old project isn't able to co-exist with it. Our EC2 setup involved creating a base image with the basic Rails environment, and whenever a new staging server was needed we would clone the Base image and modify it specifically for the app. Being able to startup new environments with a single command is wonderfully easy, but a dozen staging servers later, the cost certainly starts to add up.

Read more...

It couldn't have been better timed. Amazon has announced their forthcoming CDN service on the AWS Blog. Once released this service will be a perfect complement to Panda, allowing videos to be streamed to users even more efficiently!

You will start by storing your content in an Amazon S3 bucket and then marking the content as publicly readable. Next you'll make a single API call to register the bucket. The call will return a domain name that you'll use to refer to your content in your web page or application. When clients request the object via the returned domain name they'll be routed to the nearest edge location, for high performance delivery.

Read more...