Tom Hume

If you're interested, there's a piece on J2ME fragmentation and our recent approach to it from Thom and Doug, our Lead Developers, over at Glider Gun...

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

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 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 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.

At the Future of Mobile this last Monday we launched a new version of Trutap, one of the projects that's been keeping FP busy over the last 6 months. It's been a large project, involving 11 our our folks at various points through its lifecycle and a similar number of people at Trutap.

The brief was to rework and adapt the user interface of the original product, reusing the existing storage and communications components which we had developed in 2007 as part of version 1. Trutap wanted the new UI to support searching of their customer-base, increased emphasis on user profiles, and the addition of large numbers of third-party service providers. We wanted to push J2ME and our Cactus framework a little bit further, and experiment with a new approaches to addressing the problem of porting J2ME applications - but more on that another time.

The project started with a 1-month design effort, where we worked on some of the conceptual side of the UI (such as left-to-right navigation and a breadcrumb-trail like use of tabs) and started thinking about what components would be required to support this.

The former gave us the "big picture" which was bounced back and forth between FP and TT, iterating gently in the breeze. The latter allowed us to start making visible and worthwhile progress early. We started with a completely separate harness for UI components which let us develop and exercise them outside of the main MIDlet, testing them fully (even with edge conditions, e.g. "how does this contact look when their name is too long to show on-screen?"), before plugging them into our automated tests. As a side-effect, this enforced some good design principles: components are properly encapsulated, and we ended up reusing quite a few of them across the app.

This was the first large project which has started, run and finished since we adopted Scrum for project management at FP a year ago. It's been both a learning process, and confirmation (for us and our clients) that Scrum works "in the real world" on large complex projects... on the subject of which, if you were at my talk at the Werks a month or so back, you would have seen a diagram that looked something like this:

It's the burndown chart that we used internally to track the progress of this project. The blue bars above the X axis show the initial scope measured in estimated hours of work, whilst the red bars beneath the axis show scope added mid-project - and the black line shows the rough path of the original project plan. Each bar represents work remaining at the start of a two-week sprint. So you can see the project was originally scheduled as 12 weeks effort (sprints 17-22), the initial scope was completed in just under 14 weeks, and scope added - particularly towards the end as we iterated over the messaging section - added 6-8 weeks onto the overall timescales.

You can see that clearly some sprints went better than others (resulting in better progress); internally we tracked specific activities against these sprints, and it's no surprise that riskier activities (more technically complex ones, or those relying on third parties) tender to go slower than well-understood ones.

Only towards the end did we start sharing this chart with Trutap. I'd previously felt a bit self-conscious about filling status meetings with graphs and charts - it feels a bit geeky - but I learned a lesson here: I wished we'd done this earlier, they found it a really helpful way to represent and understand the progress we were making.

Most of the project proceeded on an incremental basis, as we gradually migrated sets of features over from the version 1 interface to the new look and feel. This proceeded section-by-section: signup and login first, then contact management, messaging, profile management, search, services, and so on. At the end of each iteration (i.e. once a fortnight), we released a version of the product to their QA team for formal testing, though we were conducting QA as part of our development too; I was pleased to hear that Trutap felt quality of releases had noticeably improved since the first version of the product last year. In the final sprints we were releasing more frequently: their QA staff had direct access to our build system and could pull off new binaries as and when they were ready.

We iterated a little on messaging, spending a sprint returning and reworking the interface once our customer had had a chance to see how the wireframes we'd all theorised about worked on a real phone; and in the final sprint of the project we had another run-through, with the Trutappers coming down to sit alongside our development team and get last-minute pre-launch changes made.

Design tended to be done "just-in-time"; sometimes we deliberately anticipated components that would be needed for the next sprints work and undertook design for them in the preceeding sprint (in a classic "design-one-sprint-ahead" model), but sometimes we were able to work a story or two ahead and keep design and development tasks in the same sprint.

I'm deliberately not writing much about lessons learned in this post; we're having a half-day retrospective with the FP and TT teams getting together next week. I'll follow up this meeting with a post here summarising the day; and there'll be another piece coming soon on our approach to porting, which I touched on at the Future of Mobile.

In the meantime: congratulations to everyone at Trutap and Future Platforms (past and present) who worked on this. I love launching :)

I really enjoyed Future of Mobile yesterday.

The day started a little sluggishly with a well-qualified panel discussing the future of mobile operating systems. I didn't feel I learned much here - revenues of the panelists businesses weren't particularly exciting, and aside from an interesting conversation around runtimes I didn't feel I learned a great deal.

For me, things really started to take off with the presentation from Doug Richard of Trutap (disclosure: they're a client of ours). Doug was talking about the rise of a middle class in the developing world that shares aspirations with the middle classes everywhere, and quietly pointed out our arrogance in assuming that it could be otherwise. I particularly liked his notion that Western operators would adopt defensive positions and hence take fewer risks (and be less innovative) than those coming out of India.

I didn't devote much attention to Matt Millar from Adobe, I'm afraid - sorry Matt, but I was doing last-minute panicking about my own presentation. I've not watched the video yet, but whilst I'd spent more time preparing than I ever have in the past (and felt the slides were reasonably polished), I made the mistake of over-planning what I was going to say. Normally I work from bullet points and just chat around them (something I'm comfortable doing) but after my hour-long overrun at the Werks talk a month or so back I tried to restrain myself by planning what I'd say in great depth. The upshot was I felt like I was working from a script, and had to keep checking where I was, staring at a screen instead of talking to the audience. Lesson learned there, but at least I managed to get my macaroons-as-analogy-for-porting slide out.

The bloggers panel was a really good format: 6 bloggers, 6 minutes each, mirroring blogging itself. Really nice to hear Vero Pepperell evangelise a human approach to communication - as an industry we ought to know that stuff, but I can't help feeling we need someone to gently beat it into us on occasion. Helen was righteous - nuff said.

A lunch, or non-lunch, followed. If there was a weak point to the day overall, I'd say it was the facilities. I heard plenty of people complain about a lack of wi-fi (though as a 3 USB dongle owner I managed OK), there was no lunch provided, and no coffee in one of the coffee breaks. Fortunately Kensington is full of restaurants and cafes, but it would've been nice to hang around in a throng during all these breaks. The auditorium itself was excellent - a lovely space, good sound, and power to most seats.

Rich Miner gave a great talk in the afternoon, filling in a bit more detail around Google and their plans, and drawing on his own history launching the Windows SPV Smartphone when he was at Orange. He gave a good if negative insight into the world of operators when he talked about product managers feeling threats from new product developments and derailing them.

Interesting also to hear about his take on mobile web apps - that they fail for reasons of network latency, lack of local storage, and access to device capabilities. Whilst you can see efforts in Android, PhoneGap and OMTP Bondi to address some of these, it's a little way from the "web apps as future of mobile" angle which I'd heard Google were adopting.

And similarly it was good to hear Rich quizzed on the topic of Android and fragmentation by David Wood (who's more qualified to talk about this than he?). Rather than espousing the rather bland "we don't think fragmentation is in the interests of the industry" line I've heard from Google before, Rich talked about the value of having a reference implementation by which to judge others; a conformance test being introduced for OEMs; and the use of challenging and popular reference apps to provide a "Lotus 1-2-3" style evaluation of an Android implementation.

Tomi Ahonen was hilarious and upbeat as usual - full of detailed and slightly threatening stats on the hold that mobile has on us, and case studies of fantastic things launched elsewhere (usually Asia). The Tohato "worlds worst war" was my favourite: purchasers of snack products fighting one another in vast virtual armies, wonderful.

And the day finished with another panel discussion: lots of disagreement from qualified folks who've been doing this stuff for years, including two of our clients. We had some kind words said about us by Carl from Trutap and Alfie of Moblog fame - thanks guys! - and it was particularly interesting to hear the pendulum of fashion swing back towards applications, away from the mobile web. I wonder how permanent this effect, which is surely down to the iPhone App Store, will be?

The evening party followed, carrying on the upbeat atmosphere :)

My slides from the day are online here. The lens-tastic Mr Ribot took video footage of the talk which you can see here, and I heard a rumour that the official footage from the event may go online some time too.

Thanks to Dominic and all the team at Carsonified for the hard work they put into the event - I know all too well from Sophie how much this takes, and they did a cracking job. And a particular yay to Mr Whatley, who stepped in as compere at the last minute and did an excellent job of keeping the audience engaged, even in those sleepy after-lunch slots ;)