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?

Over the last year we have refined this process. Firstly the retrospective now happens at the end of the day before. We start iterations on a Tuesday, so the restrospective is 5pm on the Monday, with the demo first thing on the Tuesday morning. Secondly, and most importantly, we have taken estimating out of planning. We set aside a 30 minutes time-boxed slot every day, and if there are unestimated stories on the backlog we use this time to estimate them in priority order until they are all done or we have used up our 30 minutes. This means that the core iteration planning meeting can be done in well under an hour. We have two teams taking working from a common backlog, and everyone attends the planning meeting. Each team says what they think their capacity is for the iteration (looking at previous velocity, and planned absence etc.); we then go through each story on the backlog in priority order, with teams volunteering to take them on, until neither team has capacity to take on any more. At least one person in each team has seen the story before, so there is no need to discuss the details at this point; this means that it really does take 30-45 minutes, including a bit of time to rebalance stories between teams to make sure the teams are not dependent on each other, and there is a suitable UI/back-end development balance in each team.

Once the meeting is done, each team will elaborate the stories they are assigned, breaking them down in to tasks, and planning the work within the iteration. But this is something that each team does by themselves at their own pace after the main planning meeting, rather than a big formal meeting with the whole development team present.

It’s just worth a quick note on attendees for the daily estimating session. Obviously it’s a big drain on time to take everyone out for half an hour a day, so we have a rota. We have to balance total time taken up with continuity, so our Systems Architect is in every session, along with a rotation of two back-end developers, one UI developer, and a QA analyst. We have learnt that it is worth noting who was in the estimating session on the story card; there have been been a few cases where the team working on it have said “who the hell estimated this”, and it’s been handy to be able to answer that question!

Finally, bringing forward the estimating process means that the estimates can inform our Product Manager’s prioritisation more easily. Obvious we need to balance this against spending too much time estimating things that we don’t plan to do for a very long time - in the spirit of Lean, there is a lot to be said for, “just-in-time” estimating, and we do our best to strike a sensible balance.

First up, we use story points to estimate stories, and our scale will be different from yours, so don’t take the actual story point size too seriously - you will need to map this back to your own scale. For reference we use a slightly mangled Fibonacci sequence for our estimates: 1/4, 1/2, 1, 2, 3, 5, 8, 13, 20… We currently have 9 developers and 3 QA analysts, and our velocity (for a two week iteration) is around 36. Which means that at the moment (and don’t ever tell the development team I did this calculation!) a point represents a bit over 3 man-days of effort. This is for production ready code, so includes test planning, test execution, bug fixing, to-ing and fro-ing with the customer to clarify requirements, and customer sign-off.

When we first started with our agile process, we scheduled an 8 point story or two. Big mistake. It turned out that estimating a story as an 8 just meant “really very big” and some things that were estimated as 8 turned out to be clearly impossible in one iteration. We were young and naive, but quickly learnt from our mistakes, and made 5 points our maximum.

Over the next few iterations it turned out that 5 point stories tended to be ones that involved some reengineering, and regularly expanded to keep a few people busy for the entire iteration. There was a major tendency for scope creep (often architectural scope creep rather than functional) and analysis at the start of the iteration often revealed that there was a bit more to it than we had thought. Noticing this trend, we decided that our maximum story size for inclusion in an iteration is 3 points; anything larger has to be split down in to smaller stories.

The 3 point maximum has worked well, and we have stuck with it for probably 9 months now. 3 points for us is roughly 10 man-days of effort, with probably 3 or 4 people working on it during the course of the story. In drawing conclusions, I think it is more useful to look at this absolute size of the story rather than the size relative to the iteration as a whole: i.e. 10 man-days is a more useful measure than the fact that at the moment our maximum story size is < 10% of our usual velocity. The maximum size of 3 points served us well even when we had a team of half the size. Having said that, having too few stories (fewer than 8?) in an iteration starts to make delivery of the iteration very “all or nothing”, and gives very little flexibility for descoping stories if new requirements emerge or circumstances change (see Colin Grossman’s excellent post on the Huddle blog covering our approach to this). As an example our current iteration has 25 stories in it, ranging in size from 1/2 point to 3 points.

So in conclusion, I recommend picking a maximum story point size at a point on your scale that represents no more than 10 man-days of effort, and reducing this further if your team size or velocity mean that you would regularly be planning fewer than 8 stories.

Of course more important that all of this is to remember to inspect and adapt. Use retrospectives to change what isn’t working and keep what is.

At the core of agile development is the delivery of small increments of production ready code that have meaning to the customer. Each of these user stories is not considered done until it has been coded, tested, any necessary documentation written, refactoring done, and the customer has approved it. It is in fact this incremental approach that makes agile development agile. When you are 6 weeks in to a 3 month waterfall project, you have a fully written spec and some half written code, none of which is tested. That doesn’t give you much scope to change your mind on anything: changing the scope is hard work because the final requirements document is the one thing that you *have* delivered. And if you cut the project short after 6 weeks you have delivered precisely nothing of any use. With agile, 6 weeks in to the project you will have produced the highest priority 50% of your original requirements to production quality, and could stop the project there if you wanted to (subject to the overhead of a release of course). Or the requirements for the second half of the stories can be updated to reflect real user feedback from the stories delivered so far. For me this is the essence of agile, and why organisations that continue to do waterfall, but chop up the development phase in to two week iterations and think they are “doing agile” are completely missing the point. As are organisations that think testing is something that starts once development is finished.

In my experience, here is what happens when QA testing is a phase that starts when development have finished, and is executed by a team that don’t sit alongside the development team (on a different floor or across the world). The development team write code for a month or so. They don’t really care about whether it works or not because that’s QA’s job, and anyway, they are under pressure to hit “code complete” on time not to produce production quality code. The release then gets thrown over the wall to QA, who run it, say it’s junk and then throw it back again. After this has happened for a couple of days, there is a kind of workable version of the application to test, and QA test and raise loads of bugs. Developers then reject them all. And QA reopen them. And developers say it must be an environmental issue as “it works on my machine”. This conversations is of course happening via comments on the bug tracking system with each side fuming at their keyboard at the incompetence of the other. They are on different sides after all, and never actually speak to each other. In the end it turns out that QA had written a bunch of test cases in isolation from the developers writing the code, and both had a slightly different interpretation of the requirements specification, and both think that they are right. An exaggeration? Well, maybe, but I am sure you recognise bits of this.

Agile testing is an integral part of development, and QA work alongside developers to produce quality code. They are on the same side and are jointly responsible a quality and timely delivery. Misunderstandings of the requirements are resolved by an actual face to face conversation (including the on-site customer as necessary), and this conversation happens well before the code is finished - preferably before it is even started. Of course, developers and QA analysts are coming at it from slightly different angles (which is why both are necessary in the team). Developers like creating things of beauty, and once created don’t like poking them too hard in case they fall over. They like thinking of exciting ways what they have written could be used or reused, not of ways that someone may break it by doing something they didn’t expect. QA analysts on the other hand are good at exactly that: analysing all possible paths through the functionality, not just the “happy path”, and defining test cases that will ensure a quality product hits production.

Integrated testing is a fundamental part of agile, and QA belongs in the development team, and in the iteration. Moving QA to a different time zone to the developers is simply not compatible with this.

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

So the two week iteration cycle means that we have the option to release every iteration, but we do not always do so. As well as product inconsistency, the other reason not to release every iteration is the overhead of a release. Almost always, live application problems are introduced by change. It does happen that issues can magically manifest themselves without a software release - e.g. load hitting a certain threshold, running in to resource limits like disk space, or encountering time-based conditions that trigger a bug, like not handling daylight saving time correctly or crossing year boundaries - but almost always problems are caused by introducing a new version of the software.

This is what makes regression testing and post-deployment testing really important - in order to reduce the risk that you put something live that breaks stuff. At the end of an iteration we know that all new stories are fully tested, but regression testing is there to ensure that we didn’t break something else while we were about it. So for a production release we run a one week regression test before releasing, that runs in parallel with the development of the next iteration. As our regression testing is currently a manual process (everyone in the office helps out) this is quite an overhead, and not something we want to go through unless there is a business reason to get the last iteration of stories in to production. We are actively looking at automating our regression testing (more of this in a future post) but we will never completely eliminate the need for some manual testing (to check UI layout for example) both before release and immediately after it.

What this means is that when we have a larger project on (for example launching a major new feature) we would probably release after about 3 iterations (6 weeks), whereas when we are working on a number of smaller changes (especially when they need to coincide with dates for launching new partnerships) we will release every iteration. The average is probably every 2 iterations.

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:

Agile development is about delivering production-ready code every iteration, which means writing just enough of the architectural framework to get each story done and refactoring and improving it as required with each new story. This ongoing refactoring is essential to ensure you end up with an elegant and maintainable system, and to avoid building up technical debt. Refactoring can be a risky business - it can (and should) involve moving swathes of code in to another class or method, changing method signatures, interfaces etc. How do you know that the major surgery you have just performed on your code base has not broken everything? Answer: unit tests. These alert you to what’s broken, or give you confidence that everything is good. And when is the best time to write a unit test? Before you write the code! This makes you think about requirements and test cases from the very beginning, makes sure the code you write is in fact unit testable, drives sensible design, and gives you an easy way to debug as you go. Most importantly, though, it is the time the tests are mostly likely to get written. Who can be bothered to write unit tests when you have just finished your story and it all seems to be working fine? And even if you can, how can you be sure you are testing the right things? Unit tests written after the code are generally just a box-ticking exercise, to say you did it.

So to summarise, you need to refactor constantly as the payoff for “coding for now”; you can’t refactor with confidence without good unit test coverage; the most useful time to write unit tests is before you write your code.

With this in mind, we have been using TDD on all new development work at Huddle since last autumn. That’s not to say it’s easy of course - some legacy parts of our code base are just not designed to be unit testable - but we are slowly driving up test coverage, giving us increasing confidence in our refactoring, as well a our new code.

I guess next I should give a little background. I joined Huddle in March 2008, and introduced an agile development process. I will aim to describe various aspects of this process, and what has gone well and badly, in future posts, but for now I will summarise by saying we have adopted the universal “mix of Scrum and XP”, influenced particularly by Mike Cohn.

I have introduced agile in a number of circumstances previously, but this has usually been into an environment where the total number of developers was clearly greater than the maximum sensible team size, and in most cases they were distributed across multiple locations so it was obvious that the large team needed to be split in to smaller units. In the most recent example at Travelocity we opted for teams of 5 and this worked well. In some ways setting up the agile process at Huddle was a pleasing “back to basics” exercise. It was a small (4 people at the time) team, (nearly) all co-located in the same (tiny) office, with the product owner within touching distance rather on a different floor or different country. However, as you may have seen in various corners of the IT press, Huddle has been going rapidly this year: in users, in revenue - and in number of staff. The Technology team is eleven-strong right now, with 4 more people joining us the in next two weeks. So at what point is the team too big to act as a single agile team?

To begin with I was hesitant to suggest splitting the team, as we were still within the theoretical recommended agile team size range (an iteration team of 9). But in a recent retrospective, after an all-time low number of points delivered despite an all-time high number of people working as part of the iteration team, a few team members commented that the team “felt too big”, that “communication was difficult” and that they sometimes “didn’t know what they should be working on”.Taking a step back this isn’t that surprising. Agile teams are self-organising teams, that rely on high bandwidth communication between team members to acheive a common commitment and iteration goal. As the size of the team grows, the number of different communication paths between individuals increases with the square of the team size, so knowing what is going on gets much harder very quickly.

Takin this feedback on board, we decided to split the team in to two (5 + 4), with each team committing to their own set of stories from a common backlog. We said we would try it for a couple of iterations and see how it went, but from the very beginning is has been a great success. As James said in the retrospective at the end of the first iteration with two team, “All of a sudden work in a million times more fun. Communication is much easier, and I feel more like part of a team, and less part of a large machine”. The velocity bears this out as a good move too: following on from our lowest ever velocity, the first iteration after the split resulted in our highest ever velocity, with more than double the points delivered compared to the previous iteration. There are other factors that mean that this level of velocity may not be sustainable, but it’s a pretty good start! There are a few downsides to the split (some related to specialist skills - to be covered in a separate post), but in general things are going much better with the smaller teams

So there is no definitive answer to the optimum size question. But I can say that for us, nine was definitely too big, and teams of four or five have been very successful. As we look to add another four people over the next couple of weeks, we will have to decide whether we want to end up with two teams of six or three teams of four, but the general feeling so far is that small is better.