Yesterday afternoon we invited the Trutap team down to Brighton, for a post-project retrospective. It's the first time we've done one of these with a client - normally we run them every fortnight with the whole FP team. On top of learning what we could from our largest Scrum project to date, we wanted to lift a bit more of the veil.

I won't go into the full details of how we ran the day; aside from anything else, the festivities afterwards have blurred much of my memory, but I do have a good set of notes regarding our learnings. As is traditional for us, we split these into things that went well, things that didn't go so well, and things we'd do next time. There was also an opportunity for us to call out individuals for particular appreciation, which I liked.

So, here's some of what we got out of it:

What went well

1. Porting has been extremely smooth this time around. Within 10 days of completing a reference version of the product, we've fully QAd and released the new Trutap for around 150 handsets, with more following as I write. Most of the credit for this rests with our fine development team, who've been leading us away from the industry-wide nightmare of maintaining hundreds of different versions of the product, and towards a rosy future of fewer SKUs. There's another post about this on its way, and I mentioned how we've done this in my Future of Mobile presentation. Suffice to say TT version 1 had more than 30 SKUs, all built from a single code-base but targeting different devices. TT version 2 has a single binary, and comes in 4 flavours for different screen sizes.

2. Shared documentation and tools, in particular the product backlog (all work remaining to do) and our bug tracking system, really helped. We were operating very transparently; I do wonder whether a less technically capable client would be as interested, but for those who want it, we'll do this again.

3. The relationship between the development teams at Trutap and FP was strong: we like each other and we got on well. 'Nuff said.

4. Weekly meetings were very useful, though we only started holding them a couple of months into the project.

5. Change was handled smoothly; we were able to accept change, addition of scope and iterate aspects of the product as necessary throughout.

6. We worked at a sustainable pace; we week before launch there was an eery calm at both Trutap and FP. Tthe product was there, the bug count was close to zero, and we hadn't had to work evenings and weekends to get to this stage. Compared to the period before previous launches I've known (even for Trutap), this was incredibly calm. I don't think our adoption of Scrum can take all the credit for this - the project involved a skilled team at FP and TT who'd worked together before, for one thing - but I certainly think it's helped.

What could have gone better

1. Wireframes were a poor means of specifying the product, requiring a lot of clerical maintenance and attention from both sides and offering an ambiguous level of detail: too much in some areas (e.g. screen layouts), too little in others (e.g. error states and flows).

2. We started the project haphazardly at both sides, and had to act to bring it back on track a couple of months in.

3. The design process had "too many cooks" and could have been more focused.

4. We should have spent more time explaining our approach, from both a project management and a technical perspective. We never actually sat down with Trutap and said "this is how we're going to work", instead keeping the details of our process to ourselves. With a large successful Scrum project under our belts and a bit more self-confidence, we'll do this next time. Equally, from a technical perspective we had a clear idea of how we broke down the work (into screens and UI components) which we could have shared earlier on.

5. Using version 1 of the product as a catch-all default was a mistake; where not otherwise specified, the product was to "work like version 1" which led to some scope being missed off planning at the FP end, and some confusion where new features didn't dovetail with old behaviour.

6. We had many means of communicating: Google docs, Basecamp, Fogbugz, a Jabber chat-room, email, face-to-face meetings, etc. This sometimes led to a lack of clarity and nervousness: when a chat-room had been set up but our dev team weren't available in it (because they were getting on with work!), the client worried. Next time around we should clarify communications methods: different tools seemed good for different jobs.

7. Early in the project, we weren't as good at making collective decisions as we were later on. A looming deadline always helps focus the mind ;) but we'd try to get this focus earlier on future projects.
   

Next time around...

1. We'll prototype more and wireframe less. We may invest time into tools to support this. Wireframes don't cut it.

2. We'll plan to iterate from the beginning, allowing contingency in timescales and commercials (in fact the latter was planned for, as it turned out ;))

3. We'll introduce any change at fortnightly sprint boundaries. A couple of times we had mid-sprint changes which led to the dev team at FP thrashing and progress slowing. Lesson learned: we should be more disciplined here.

4. Towards the end of the project, we had a day we called the "UI Sweep", where the TT product team sat with our developers and worked through final bits of polish. This made a difference to the product quality disproportionate to the amount of time spent. It's quite gruelling for the developers, and relies on good tools and practices that let you make changes there-and-then, but was ultimately very worthwhile. The idea of an on-site customer is classic XP.

5. We'll have weekly meetings from the beginning, with everyone engaged and involved.

6. We'll get everyone to the pub more often :)
   

And the role of honour: called out for particular thanks were Ali, Tobias, Luke and Rob @ Trutap of Trutap, and Thom, Doug and Serge at FP. Thanks again guys, we built something fantastic :)

None of this would've been possible without the able and entertaining facilitation provided, as ever, by Joh Hunt - cheers Joh :)

It's that time again... another pile of software-related articles I've found interesting enough to keep in the Link Larder:

• The XP team room
• Shu Ha Ri by Alistair Cockburn
• Unified Theory of Bugs
• The in no way inflammatorily titled Men Write Code from Mars, Women Write More Helpful Code from Venus
• Kanban, flow and cadence
• Five Whys
• Scrum: the product management challenge

  Hopping across the pond

  November 23, 2008 | Comments

  So, it looks very likely that Sergio and I will be in the US (west coast) briefly during the first week of December. Whilst we're about, we'd like to make the most of our time there. So if you're interested in getting together for a chat, do drop me an email or leave a comment.

  Jakob Nielson on Agile

  November 21, 2008 | Comments

  Jakob Nielsen has put out an interesting Alertbox post on Agile Development Projects and Usability. I was going to write a little about what I thought of his post, but then I found that Alastair Cockburn had managed to do a much better job of it than I could. Basically: all fantastic, bar the us-versus-them split that the article sets up by saying "Agile’s biggest threat to system quality stems from the fact that it’s a method proposed by programmers".

  Google Voice Search

  November 21, 2008 | Comments

  Google Voice Search is, frankly, amazing. Not because it works well. Most of my searches so far have been comically misinterpreted, though I note that (for research purposes only you understand) "Britney Spears" has a 100% success rate, even when I don't employ my appalling California accent.

  No - to me, it's the sheer chutzpah of doing something like this, and the laser-like focus on reducing the time between deciding your wanting to know something, and Google giving it to you. I touched on this topic briefly in my talk on Monday at Future of Mobile, and Tim O'Reilly has a nice post about mobile being the lynchpin between humans and the cloud - spot on.

  Can you imagine what sort of world we'll live in in 5 years time, when improvements in voice recognition (probably based around brute-force techniques rather than smart voice recognition algorithms - scale's just another tool to these guys) put an increasing percentage of our species' collective knowledge even closer? Beautiful.