I posted back in September that I'd been invited to join the W3C Mobile Web Best Practices Group, specifically to work in the Content Transformation (CT) "task force": which is every bit as macho and manly as it sounds.

The document we're writing is coming along (contentious though it may be), but abstract of the document, I've wanted to write a post about the process of working in the group. It's my first experience of being inside a technical standards body, so I've found the processes and tools interesting in and of themselves.

The CT group operates in public, mainly on the public-bpwg-ct mailing list.

Once a week there's a conference call, typically with anything between 3 and 8 attendees, and usually chaired by Francois Daoust. In tandem with the voice call, all participants are in an IRC channel; here, a couple of bots are active. Zakim is the one I tend to notice the most, providing a bridge between the voice call and the channel. So, when a participant dials in or drops off, Zakim recognises them and announces their arrival in the channel. If there's noise on the call coming from one participant, Zakim can tell where it's originating - that kind of thing.

On each call, there's a volunteer scribe; I took on this job myself on the most recent call. The scribe is charged with typing what's said on the call into the channel; another bot records these notes and uses them to create minutes which are published to the mailing list after the call is done.

One interesting little tweak is the use of a bot to substitute for gestures that might be used in face-to-face meetings. By typing

/q+ to say we should point our orbiting lasers at Italy

one places oneself onto the "speakers queue", maintained by one of the bots, with a reminder of what one was about to say. This queue can then be accessed and speakers popped off it as necessary, giving them permission to speak: so in this sense, IRC substitutes for the raising of a hand or eye contact. It's surprising how well this works.

Off-the-record comments and notes can be recorded using the "action" method in IRC:

/me thinks we should hurry up with the goat sacrifice

Another bot tracks the creation of actions and resolutions, such that the group can create tasks to be done and assign them to a member, and record decisions taken and voted upon.

Last Call comments are, in particular, tracked quite exhaustively into a web-based tool. Every one is assigned to a member of the group who is charged with summarising the issue, doing any necessary research, and then recommending a course of action. During the call these comments are discussed; typically this leads to either a resolution or a decision to gather more information (from research carried out by group members into the area being discussed, from other W3C groups, or elsewhere).

It's interesting. There's no monolithic tool handling everything, and there's a vague sense of duct-tape lurking in the background, but it all hangs together rather nicely, in a quirky way, and feels quite human - a bit like the web in general, I guess.

For another view of yesterdays retrospective, check out what Luke Brynley-Jones, Head of Product at Trutap, had to say.

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.