Tom Hume

Joh and I ran a dry run for our Agile2009 workshop tonight, held at the mighty Skiff in the North Laine, Brighton... and after a frantic day of last-minute prep, I was quietly pleased with how it went.

The session opened with a few slides setting the scene about mobile. These definitely need some work - whilst I know the material quite well, I hadn't prepped them and it showed. I waffled somewhat, but fortunately at such a speed that it was over quickly for the audience, and we could get on with the meat of the workshop: exploring how an iterative design process can help address the kind of constraints that mobile inevitably entails handling.

We split into two groups - with 9 attendees this gave us teams of 4 and 5 respectively. Persona in hand and product concept in mind, one team headed upstairs and the other stayed downstairs, each spending 15 minutes designing a product with the aid of copious amounts of card, post-it notes, the ubiquitous Sharpies and some rather natty 1.5x sized replica mobile phones my dad and his girlfriend had put together for the session. After 15 minutes we halted the groups and swapped one member between them, to act as a test subject for a 5-minute usability test... after which the groups convened to show off their work, and the results of the test, in a short demo session.

Constraints were introduced, with each team having to transpose their product to a new device and form factor. Then rinse, repeat: another 15-minute design session followed by 10 minutes of demos, and a 10-minute run through to discuss learnings.

After the shaky start of my slides, I was pleasantly surprised by how things went: both teams managed to produce a useful design and test it within 25 minutes. One team definitely received worthwhile feedback from their test subject, the other got some but were less sure of its value. In any case, the notion that a group of people could go from zero to a coherent and in some way tested prototype in such a short space of time was both heart-warming and genuinely impressive... and I couldn't point at domain knowledge or mobile experience as being the cause of this success, with both Ribot and Mary (the participants with a background in mobile) located within one team, and no mobile experience in the other.

Learnings from the session displayed a comforting level of consistency between the two groups, too: both felt that moving to a smaller screen lent their design more focus, and that working within tighter constraints contributed to their creativity, rather than detracting from it. Time limits were clearly a problem (how could they not be?), and whilst one group found cross-platform consistency to be a tough trick to pull off, the other observed that their design changed less than they'd have anticipated in the move from iPhone to clamshell.

Both groups then consented to exchange beer for a pile of incredibly useful feedback, which we'll be using to further hone the session before running it in Chicago. And one comment which really chuffed me up was overhearing participants moot that firstly, this format might be an interesting way to open up a Hack Day type of event; and secondly, that he'd really like to see the product he'd worked on *actually get built*.

As always, thanks to Jon Markwell of Inuda and the Skiff for hosting, to Joh for gently stamping on some of my more ridiculous ideas and her rock-steady facilitation, and to everyone who came and participated :) There's a photo-set, yellow-hued thanks to my grotty HTC lens, here.

Update: slides from the warmup are here.

"In Sprint 41, I invented the bun... I invented the bun, in Sprint 41..."

What we learned:

1. You need to be disciplined to get acceptance tests written before development starts on them;
2. You need many strategies for communicating with remote teams: not all of them will work in any given situation;
3. Retrospective actions need following up, or the whole exercise is of moot value;
4. The current UK heat-wave causes problems and opens up opportunities :)

Another write-up of one of our planning days; Glastonbury having abducted our facilitatrix, I was running the review and retrospective sessions. This is undoubtedly a good thing for me to have more practice doing, but I worry about my ability to remain objective when wearing MD and Scrum Master hats, and having some opinions about the Way Things Ought To Be.

Worryingly (scrum smell ahoy!) there was little in the way of production software to show off at the review. Both teams had been working on one project (predominately), and in both cases a couple of large features were nearly-done, but not done done done - mainly due to dependencies on a third party which we're having trouble sorting out in a speedy manner, though in the case of Tonberry they had everything done for one story bar the automated tests. I'm hopeful that this means at the end of Sprint 42 we'll be inundated with new features to show off - i.e. that over 2 2-week sprints we'll have averaged out a little.

Ali showed off some of the widget work he's been doing recently for a new client (more on that in due course, I hope), and we had a good clutch of gold cards: Doug's produced another mobile application for alcoholics ("wake me up when my train gets home"), Chris had been doing some investigations into persistent storage efficiency using our Cactus database components for J2ME, and Tariq had some work on an Android app.

I've been worried about following up actions agreed at retrospectives - or rather, my not following them up as diligently as I should've been: there's little point in regularly agreeing to do stuff if it never gets done. So I kicked off the retro with a review of actions from the last time, highlighting the ones we've done and not yet gotten around to. I get the sense the strike rate was slightly higher, but I need to concentrate more on this in upcoming sprints.

Then the retrospective proper. I returned to a fairly standard format: each team member calling out 4 memorable moments from the previous sprint and getting them up onto a timeline. This brings out areas of common opinion or feeling from the team - unsurprisingly, many of us were pretty worried when one of the guys was taken into hospital at short notice, but environmental concerns about office temperature in the current heatwave were also a common theme, as was the visit a few of us made to Berlin on Monday. Some bug-fixing on an oldish project provided a boost to a few of us; stories not being finished provided a more sombre end-note to the sprint.

Having reached and discussed a group consensus on the previous 2 weeks, we moved onto actions, with each team member voting for something we should do in the immediate future, something we shouldn't do, and something we just don't understand. We then grouped these, discussed them and came out with a few to follow up on this sprint:

• We're becoming one team; with much of our work over the next couple of months being on a particular large project, we're combining the two development teams into one and sharing stand-ups and planning. A particular hope of mine is that this will encourage a lot more pairing up - 6 people can form many more combination of pairs than 3 - leading to a bit of variety, and a quicker path to getting those new to the project up to speed with i.
• We'd slacked off on a practice everyone had agreed had value, and worked well for us: writing acceptance tests for a story at the start of its development, and involving developers, QA, designers and the Product Owner in this session. Efforts are accordingly being redoubled in this department.
• A hot working environment is unpleasant: Thom was tasked to look into possible coolants.
• The speed of communication with a remote customer was highlighted as an issue by the team. I'm quite proud of the quantity of work we've done in the past, working with teams in London, Denmark, Helsinki or China... and past post-project retrospectives have highlighted the value of shortening decision times, so we've lots of little tricks we can use to ease the pain here. Recently we'd hit some problems which they weren't helping with, so we opted to raise the issue with the customer.

Other things we discussed included ways to improve our test automation (with some interesting suggestions floating for ways to document and improve test coverage of the user-interface elements of MIDlets or other mobile apps), and the need (or otherwise) to re-estimate stories before planning. The latter ended up with quite a long-running and heated debate (of the type we try and avoid having normally in retrospectives). I'm not convinced we got to the end of it but it feels like concerns have at least been aired. I posted round a Mike Cohn blog entry on the topic afterwards, which summed up the way I felt, but much more eloquently than I could put it.

Other observations I'd have: sprint burndowns don't seem to be so handy for us. They don't often get referred to and in some cases haven't been updated too frequently. I'm not sure what to do here: I think our story sizing relative to team capacity might be a bit off, and perhaps a larger team will make a difference.

We're Googly as fuck nowadays - we don't tend to move without creating a spreadsheet or document about it, and seem to have settled on it as our standard means of electronic collaboration.

And finally, we're holding standups outside for this sprint - partly to deal with the heat, and partly to recognise that with a team of 8-10, finding a board we can cluster around and actually refer to is tough with our current office configuration...

So, it's that time again. We're exceptionally busy and have won a few new projects and clients in the last month or two - with no sign of business slowing. So we're on the look-out for staff again. We're after a few different souls:

• Developers, ideally with some commercial experience of mobile (J2ME, Android or iPhone), and familiarity with or experience working in an agile environment (if you read this blog you'll know we're a quite formal Scrum shop). You'll have a strong appreciation for the role user experience plays in the software development process. You'll obviously be excellent.
• Mid- to senior-level designers; we'd be open to considering someone without commercial mobile experience, but you'll definitely need a strong background in digital media and a genuine enthusiasm for mobile. We're after someone with a mix of visual and interaction skills - we think the line between the two is blurred, and we like it that way. You'll have to be willing to get your hands dirty and learn a little about how your designs are actually implemented. Strong communication skills will be vital.
• QA - and specifically, someone interested in QA as a career path in its own right, rather than seeing it as a stepping stone to a development job. Over the last couple of years we've developed a huge appreciation for thorough, pedantic, devious, downright cruel QA folks who can find obscure bugs with which to taunt our developers, all in the nicest possible way of course. Someone with experience of both manual and automated testing would be a bonus; double points if you've worked in an agile environment before.

For all roles, you'll be working from our offices in central Brighton, and be very comfortable working in a cross-disciplinary team. You can have a look at our site to get a feel for what we do if you like, though I'll warn you that it's horrendously out of date and gives only a vague feel for where we're headed... We offer good salaries and an opportunity to work on *huuuge* software products which touch the lives of literally millions of people, for a global client base. We like to travel - earlier this year most of the company spent 2 weeks camped out in Shenzhen, China, kicking off a project for Microsoft - but it's not in any way compulsory. We also make a point of allowing time for personal development and R&D, and do some reasonably off-the-wall projects: birdwatching, ghost hunting, and location-based gaming have all decorated our portfolio. Drop an email to recruitment@futureplatforms.com if you're interested, and we'll have a chat. Unless you're a recruitment agency of course, in which case stop reading right now and please avoid the temptation to get in touch, even if you're completely unlike all the other agencies and incredibly special in a way that you can't quite describe without sound like just another bloody recruitment agency. Honestly - every time I post a job advert and politely say "no agencies please" I'm assaulted by a tidal wave of dull phone calls from recruiters who seem to think that by ignoring me completely they'll somehow persuade me to pay them fees, and it's all gotten a bit boring.

So, it's been a week since I got back from Mobile 2.0 - and therefore highly remiss that I've not written about it yet.

I really enjoyed both the Developer Day and the main event. The former seemed to be focused around mobile web - with widgets in particular getting a lot of prominence. Whilst I'm not convinced that widgets are the future of all mobile apps, it's an area where - until recently - I've let myself lag behind a little, so I got a lot out of the sessions. And one quote from the very beginning has stuck with me - Dan Appelquist remarking that applications are nowadays being consumed more like songs than software.

The main event was pretty decent. On both days some panel discussions had a tendency to get a bit angels-on-pinheads - the one where 4 people debated publicly about who was most "open", each using a slightly different definition of the much overused word, didn't really hold my attention. But the off-track talks really shone for me - Tom Raftery berating the industry for its at best token gestures towards environmentalism, and Regine Beatty and Atau Tanaka one-upping each other with wonderful examples of mobile frivolity. And outside of these, Ted Morgan of Skyhook talking about their business (200m location searches a day, vs 300m or so Google searches per day!) and Priya Prakash's talk on Beyond Free (an evolution of the last few sessions I've seen her do) were particularly memorable.

The venues (Barcelona Activa and ESADE) were both excellent (modulo the temperature of rooms in the former, which got quite stuffy). Now I've experienced the double-whammy of rock-solid wi-fi and power at every seat, I suspect I'm going to be a little spoilt.

More than this though, on a personal level I got a lot out of the event. It seemed to have a perfect mix of 50% familiar faces and 50% new (and friendly) ones - I'm not a natural networker, but felt very comfortable at the event. And in particular it was great to finally meet Dom and Francois of the W3C and Mike Rowehl - all of whom I've known for a while, but only in a virtual sense. It's nice to have that corrected :)

I did a couple of sessions; one on Mobile User Experience for Developer Day, which was well attended but missed the mark a little, I felt. I emphasised how we run UX alongside development at FP over and above the specifics of mobile UX, and whilst my audience seemed happy to engage on this, I think I could've either been clearer in the title for the session, or put more emphasis on tactics than on process.

The "play" panel I sat on at the very end of the event was a different matter: really good fun, and an utter privilege to talk about location-based gaming, ghost hunting, shitting and sex, generative music and digital rights issues with Professor Tanaka, Gustav Soderstrom of Spotify, Akhil Monappa of Atlas Venture, and Michael Breidenbruecker - the lovable nutter behind Last.fm and RJDJ - all ably held together by Robin Wauters of TechCrunch.

And again, on a personal note I had a very interesting chat with Ted Morgan at the post-event dinner, learning exactly what it's like to get into work one day and find a message from Steve Jobs on your voicemail :)

Thanks to Rudy, Dan, and all the organisers and behind-the-scenes folks who made it happen. I'm already looking forward to next year, though I think I might give myself an extra day in Barcelona to help recover from Sonar...

Mobile 2.0: Tom Raftery on Mobile Sustainability

greenmonk.net

Drivers for sustainability: climate change (we're all fucked) and the business case (sustainable companies tend to outperform their competitors).

ICT could reduce 15% CO2 emissions globally: through 1bn PCs, 1.2bn landlines, 1.4bn internet users, 4bn mobile users. So mobile is the target for this stuff.

Handset manufacturers are doing sod all: they all have "a green phone".

Many carriers don't mention sustainability initiatives: O2 have a reasonable site, Telefonica and 3 don't.

What are developers doing? Clearstandards have an iPhone app to calculate carbon footprint. 3rdWhale, MobiMonster also get a mention - the latter reduces energy usage of phone. But nothing really significant.

What if:

• Manufacturers made phones to last 6y not 6m? 60% of a phones carbon footprint comes from manufacture. Rent phones, don't buy them.
• Phones were made from biodegradables?
• USB chargers were standard?
• Operators switched to e-billing?
• Operators shared networks?
• Developers used mobile platform to build apps which mae a difference?
• Grid computing client apps were made for mobiles?

I wonder... How does mobile compare to PC - are phones implicitly more energy-conservative? And what specifically can developers do?

• Nice video interview with Mike Cohn, including some lovely advice on how to start getting your Scrum on. I'd thoroughly concur - try it and do it strictly for a reasonable period of time before you start to adapt it;
• I'm sure I'll have posted this before, but it's worth repeating - Jeff Patton's 12 best practices for UX in an agile environment;
• Google Bets On Big 5 - old news as this dates back to last month, but I'm reviewing it after watching the Google IO Keynote video. Very interesting indeed, but I'd take issue with their presenting this technology as "all there" - a few experiments on Firefox, Safari and Chrome on the mac seem to show that some bits are present and correct on each, others lacking. Still, very exciting stuff whatever...
• Wave. Wow, double-wow for the demo of live translation at the end.
• A study on the effectiveness of using personas in product design. Really nice to have some evidence for this stuff, though the study involved giving participants pre-prepared personas. My take would be that personas are a useful tool when based on research, but as a catalysed form of assumptions about a target audience, they can be dangerous.
• Another study, on how price affects perception.
• Interesting presentation on digital inclusion in the UK, and preconceptions we may have. "It's a case of social equity: 93% of people under 70 who have a degree are online".

For several completely unrelated reasons, I've spent a lot of time looking at and thinking about maps this week.

• GeoNames, a database of places (as used by Dopplr)
• Vodafone have a cute map, Twitter-driven (obviously) of who's going on holiday where, this summer;
• A mind-expanding article on augmenting photographic data, courtesy of pitch/yaw/roll, GPS and OpenStreetmap;
• First person UIs - who'da thunk that a simple compass opens up so many possibilities? I note that whilst JSR179 has included compass support in the location APIs, compasses were the bit that most implementations of the standard failed to include for a long time...
• The Google static maps API - handy when you're targeting platforms that don't let you do all the usual Googly JavaScript stuff;

We had our planning day for sprint 40 last Wednesday, including a retrospective on the previous sprint.

What we learned:

1. If you take data from third parties, be sure to budget time to sorting out problems with it;
2. Keeping a team shielding from interruptions might be harder than you think;
3. Be disciplined about discussing implementation of user stories at the last appropriate moment - it's worth it;

Joh ran a quite nice format where we split into our three teams (Anjuna and Tonberry, our two production teams, plus Mocha - everyone else). Revisiting the objectives from the previous sprint, we'd had three things we wanted to do:

1. Don't overplan (we've done this quite a lot in the past);
2. Ensure no interruptions come to the team other than through the myself, the Scrum Master (the previous two sprints, Tonberry had been fielding all sorts of stuff coming from a range of people, and I'd not been shielding them from this adequately);
3. Propose an approach for automated testing; we do this at a UI level for MIDlets (as well as elsewhere) but it's sometimes seemed quite burdensome for the team;

On the "not overplanning", there was general agreement that we'd not repeated our previous errors. On the automated testing, we'd failed to do anything, though one of the folks with stronger feelings on this was on holiday, so I wasn't too fussed about this - I want to include him in any conversation.

But on the interruptions, we had a worrying difference of opinion. Management folks (including myself) had felt this sprint much better in this regard - we knew there were 2 urgent pieces of work which had come in mid-sprint (a client being messed about by another partner who needed us to do some urgent work to route around issues caused by said partner, and some urgent bugs in a previously released piece of software), but the team felt there was way more than this - and had (as we asked) kept a list of these items.

In a way, I found it more worrying to discovery my view of what was happening was out of sync, than to have seen problems and been aware of them. So this time around we're keeping a *muuuuch* closer eye on things. The team are alerting me instantly when an interruption occurs, and keeping a record of the impact of it: there's a difference between someone popping in to say "hi, how's it going", and someone slyly asking if you could just do a bit of analytics for them on the side...

Elsewhere, we had agreement across teams that we need to return to a practice we established 6 months ago, then dropped: meeting to discuss specifics of a story just before work on it begins. This one seems to already have paid off - a quick chat about a trivial detail on Friday morning unearthed some fairly serious issues, just in time.

Third-party dependencies were, as ever, another issue: in particular, getting hold of data or graphical assets in a form that's suitable for use. A difficult one, this - if we're working for a non-technical client then it's not fair to expect them to understand, say, the issues around character set choices when exporting CSV files from Excel. But equally in these situations, we need to allocate time and effort to managing problems which might arise.

I've put the slides from my talk at Mobile Web Summit 2.0 online - they're here, if you're after them.

My talk was looking at case studies of three mobile apps, two of which we'd done (Puzzler and the Ghost Detector), and one being the mighty Smule (which I've written about before). The main point I was making is that - as I was chuffed to hear Dan mention in his opening talk on day two - "all interesting mobile apps have some sort of social element". That said, this needn't involve all the classic paraphernalia of "social media" - i.e. conversations, contact management, or identity - and assuming that to be doing something social, you have to be building a branded Facebook, or a blogging platform, seems a little... crude. Audiences can be connected in more subtle ways, and as the examples of the league tables we launched for Puzzler, and the opt-in rate for Ghosty both show, these can lead to measurable increases in both uptake and loyalty.

We had fun in the panel session afterwards too, where I got to trot out a theory I've been nurturing around mobile advertising: on the web, the aim of advertising has been to drive users to useful web services, where they can get something useful done. On mobile, applications are a more appropriate destination for advertising.

Why? Mobile web sites tend to be more limited. There are a few really "sticky" ones (itsMy and Flirtomatic, I'm looking at you), but most destinations for mobile advertising are ad-supporting microsites with little long-term value for a visitor. As such, applications are a more natural and worthwhile destination for mobile advertising: give your prospective customers something genuinely useful they can carry with themselves and see value from again and again, rather than expecting them to return to a microsite.

If you're sceptical, I'd encourage you to look at iPhone app store statistics - the average free app is being run 80 times. This might not mean it's a great place to run advertising, but I'll wager that's roughly 80 times more traffic than most mobile microsites get...

ScrumFest is coming to Brighton! 8th and 9th July, at The Werks in Hove. Well worth checking out if you're interested in this sort of thing, also take a look at the WelfareCSM workshops Tobias Mayer is running just beforehand, with the dual aims of introducing Scrum to organisations beyond the software world, and getting training to folks who wouldn't otherwise be able to afford it. Lovely.