Update: quite a few of the posts I write relating to our work at FP are lengthy. I'm going to try summarising them up top, to highlight points of interest and help you decide if the whole thing's worth reading.

What we learned:

1. Retrospectives work better off-site, when you have a projector handy for demos;
2. Two small teams work better than one large team;
3. QA involvement has been "bursty", leading to lots of pressure at the end of sprints;
4. Flat burndown charts could be a serious warning - some thought required!

Today was our first review and planning day with the new two-team Future Platforms, and to give ourselves a bit more space to stretch out, we tried holding the morning session at The Skiff - a coworking space run by the Inuda folks a couple of streets away from our offices.

The facilities there were excellent. As well as more space we had walls to stick postits onto with (and lots of visibility, room to walk around, etc.), a projector, and beanbags galore. All of this - plus being in an unusual space away from the usual workplace - made a big difference.

The review went well, with our two teams (Anjuna and Tonberry) demonstrating projects they've been working on for Microsoft and the BBC respectively. Compared to the limited visibility you get by passing a couple of handsets around a room, having 5 foot tall on-screen demos felt like heaven... and the demonstrations themselves seemed to "flow" a little more than in previous reviews. If only I could talk a little more about their content; as usual, NDAs have my lips sewn shut. Unusually, our design team weren't presenting their work this time around - much of it has involved supporting the development teams (and was therefore visible in the dev team demos), and South by Southwest had taken its toll on our design resource over the last fortnight....

I was really looking forward to the retrospective, and wasn't disappointed. The near-unanimous view from both teams was that splitting the company into two had been a success. Each team felt more focussed on their respective projects, had been less affected by context switching, and found stand-ups both quicker and more useful. Even better, we could see measurable and significant improvement in the productivity of the company split into two teams (vs all being in one team).

One issue which was surfaced by 4 different people was that of planning and testing time. We have a persistent experience where testing effort bunches up towards the end of sprints - so that at the start of each fortnight there's sometimes not enough for our dedicated testers to do, and at the end of the fortnights too much.

My own tendency is to attack this problem by trying to spread the load of testing more evenly throughout the sprint (encouraging units of work - user stories in our case - to be taken through development and testing to done before starting on others) and having other team members help out with some of the testing work when there's too much (whilst some of it demands the eager eye and magic software-breaking fingers of a good QA specialist, I feel there are areas where the rest of us can usefully pitch in). We had a fairly lively debate on this one, and didn't reach a useful conclusion. In particular I had hoped to bring in some of the limiting-in-phases techniques Karl Scotland covered in his recent Kanban presentation (also held at the Skiff), but we didn't reach consensus on adopting this - so I'll give it another go next time around.

Burndown charts also stimulated a bit of conversation. I'd experienced a worrying few days with Anjuna mid-sprint, when progress on getting stories to completion was minimal even as the team frantically worked on a core section of the product... and I'd found myself noting a problem but stuck on what to usefully do about it. In the end the team pulled through and delivered, but I'm left feeling slightly worried; we've had sprints in the (thankfully distant) past where a flat-lined burndown continued right to the end, thanks to my ignoring the signs. Putting a positive spin on it, the worst that we'll ever do is experience a single unproductive fortnight, but even that would feel like a huge opportunity wasted. More thought required.

Finally, on design; last sprint we opted out of planning it formally, this time around we're officially embedding the design team with Anjuna, where they can crack on with pushing that particular product forward together (and without distractions from other projects).

A solid day; we saw the juicy fruits of our work, had some productive discussions on how to get better, persuaded a sizable chunk of the company to come out for gyoza etc, planned in two teams' worth of work for a fortnight, and still managed to finish dead on 6pm. Considering that a year ago planning days were regularly overrunning and leaving us all half-dead, with a smaller team, it's great to see how we're improving. On that particular point, it's amazing what benefit an hour or so of working up a sprint backlog for each team the day before planning can deliver...

Thanks as usual to Joh for her facilitation of the retrospective, and to the Skiffers for hosting us!