It's been a while since I've done an update on how Scrum has been going for us, but last week we completed Sprint 13, which seems as good an excuse as any for some news.

We've had an interesting time over the last few months. As I mentioned before, a few of our development team have been seconded to a client and working on a top-secret project managed by said client. There's been a fairly disconnected feeling between the rest of us and the guys doing this work, and at the same time we've had a few projects come in which were purely design-focused: handset customisation, concept work and UI development with no implementation phase (yet). So the design team have also been scheduling their time separately, until Sprint 13 when they returned to the fold.

Planning day followed the now-familiar pattern: an hour or so to review work from the last fortnight, the same for a retrospective, lunch, a short gap whilst Mr Falletti and myself prepare for planning, and then the planning itself.

The reviews have become more useful since we had our Product Owner (currently Sergio, but Watch This Space) ask to see what's most of interest to him. Before this the meetings were show-and-tell, and seemed to be more around individuals showing elements they were particularly proud of rather than highlighting what was most important to our clients. Shifting the emphasis slightly from what-we've-done to what-our-clients-value made a disproportionately large difference to how useful this felt.

This weeks review was particularly good from the point of view of connecting the dev team with the work that the design team had been doing - which I found fascinating from a process point of view (Buxton is practically dripping out of our walls right now), and which is about to become extremely relevant to the developers when we move design projects into to production. It was also a good opportunity for the guys who'd been working for the Other Client to show off what they've been up to.

The retrospective followed. Our burndown chart from this sprint was the best yet, I felt: we made clear and steady progress from the start of the sprint to the finish. I was pleasantly surprised to note that, without much in the way of conscious effort, most of the actions from our previous retrospective had been err actioned. Joh has sharpened the format of the retrospective sessions down over the last few sprints and given them much more focus - what were previously very useful but slightly open-ended discussion sessions now seem to surface successes and failures from the previous fortnight very quickly. Once you see 3 people in the room independently bringing something to our attention, it's hard to ignore it. In particular we've had a lot of appreciation shown for a new member of staff: it's really nice to have a forum for everyone to make their feelings clear.

Problems raised this time around tended to be more at the level of client relationships, planning and time management than around specifics of development practices (though as always, a few points along these lines were noted). Actions included:

• setting up formal fortnightly lunches where we'll take turns to do a talk on a topic of interest to the group. I've done one this sprint on unit testing, we have more scheduled on threading/concurrency, design processes, transactions & Hibernate, automated testing tools... and much more;
• looking into lightweight ways of getting code reviews into our development process;
• scheduling a bit of slack between projects to absorb slippages, prevent knock-ons and provide polishing or research time;
• some operational items like getting more SIM cards in place for testing and fixing an unreliable office router;

Lunch followed: e-kagen, enough said. :)

Then planning, which was extremely painful this time around. Despite Dougie returning to the team-at-large we were back in the same old position of having not enough resource available to meet the commitments we wanted to, and making hard decisions on what should be reprioritised. By the end of the day it's fair to say we were all quite worn and out of steam, but looking at it more positively we were dealing with this problem at the start of the sprint, not the end. We have eerily consistent information as to the accuracy of our estimates and I like to think it's better to use this information accurately to make better decisions than it is to ignore it and deal with the fall-out later on.

This sprint we returned to planning in design work, with the design team estimating tasks they'll carry out and providing stories for the process. Interestingly our design velocity is quite different from that of our development team. I put this down to our design team being composed in the main of much more experienced individuals than our devs (I include myself in the latter category); but over and above this I'd note that most of the design tasks we break down projects into are time-boxed. I think there's something really interesting here: design work having a tendency to be more subjective, I think it's harder to consider a given design task completely done, but easier to justify them as done if it's in the interest of the project to do so.

So, 6 months in and where are we? It's happened slower than I had at first expected (I thought we'd get the hang of this in 3 sprints, then 6 - how wrong I was!), but taking a step back I'm happy with what we've achieved so far:

• We have a defined way of working, which we follow. I remember reading a lovely quote a while back along the lines of "your process is what you do when things go wrong" - riffing on the idea that lots of folks will say "yes we have a way that we work", but when problems occur then it's panic time and all that goes out the window. I couldn't claim that we don't have problems (in fact Scrum seems to make them more, not less, visible), but we do have a way of working that we follow all the time - one we can measure, defend, and speak confidently about. And the management overhead for working in this way is minimal (though it's also fair to say we're overstretched at this very moment at that level);

• We know pretty accurately what the ratio is between how long we think a task will take, and how long it actually takes us; variance from 1:1 including poor estimation, natural interruptions, scope creep and so forth.

• We actively criticise ourselves and take actions to deal with this criticism - there's a forum where issues can be (and are regularly) raised by anyone in the company. Equally, we celebrate the successes of individuals or the group. I'll stop before this sounds any more Californian.
  

There's a thousand things for us to improve on, of course, but it's nice to occasionally look at where we are and realise that it's a significant improvement on where we were 6 months ago; and I'm looking forward to where we are in another 6 months :)