Jonathan Howell

For those of you familiar with my previous work travel patterns, you may be a little surprised to to see me positively requesting to be sent to Texas. Well, it’s not DFW on this occasion; my proposal to present on Agile Development at South by Southwest in Austin has made it to the Panel Picker stage - where the community gets to vote on which of the proposed sessions they would like to see at the conference.

So please make sure European start-ups are adequately represented there, and vote for my session: From Fragile to Agile: Efficient Development for Startups. And while you are there, vote for Huddle co-founder Andy McLoughlin’s session too: Hiring 101: Building a Team of Peers. And maybe get yourself a ticket too?

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…)

I was disturbed recently to hear that a major internet company is planning to move their entire QA operation to India. I’m not against offshore development done right (I have seen in done well, badly and terribly in my time), but this is not about offshore development: the development team remain firmly in London. This is a change to QA from being on the other side of the building from development (bad enough) to a continent and several time zones away. This is craziness, especially for a company trying to embrace agile software development.

(more…)

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…)

In my previous post I mentioned that like most agile adopters, at Huddle we would describe our process of a “blend of XP and Scrum”. Expanding on that a little, I would say that Scrum has formalised the process side of agile and with a few exceptions (terminology, iteration length, and handling mid-iteration change) our agile process looks very like a Scrum implementation. XP on the other hand has much more to say about engineering practices (Continuous Integration, Test Driven Development, pair programming etc) and we draw guidance on development practices from XP.

Which brings me to the subject of this post: Test Driven Development. For me this is an essential, and often ignored, part of the deal with implementing agile development. Test driven development has many much discussed advantages, but for me there is one killer argument for TDD at is goes like this:

(more…)

This is an often asked (and often answered) question, but I thought I would share our recent experience at Huddle. It is important to bear in mind, of course, that an agile approach to software development does not come with rule book. It is important that teams do what works for them, in line with the principles rather than prescribed practices of agile. The retrospective is there for continuous inspection and adaptation: if something isn’t working well, change it; and if it still doesn’t work then change it again. And this is just what we have done.

(more…)