Tom Hume

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

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.

Barriers, Robert Hamilton, Google

Why we need to be open in the way we design and do things. People think mobile is open. (asks how many people have SIM cards).

If mobile was created by Internet folks, there'd be no SIM card - you'd just login from anywhere, on multiple devices, like on the web.

SIM is supposedly great for identity, but is that really necessary for security purposes, given what most people buy using username and password over iTunes, Amazon, etc?

(Shows picture of a ticket gate in Japan)

There's no barrier here. It only closes when someone tries to get in without a ticket - it presumes innocence. This saves electricity, wear and tear, and avoids penalising people who aren't doing anything wrong.

Japanese built a transport network to move people, not to create queues. Don't hinder people who are trying to use your service correctly.

Consider ebay: you're buying from a total stranger. That's fine. Drop £10 in a bar. You'll usually be given it back. This is the world we live in, and it's the world we create.

Put barriers in the way and you force out a different sort of product. Twitter didn't consider "people might want to make Tower Bridge tweet" - they're just open, and people use them in interesting new ways.

"Build a climbing frame, not a cage" - it's the same structure, just a different mental model of what you do with it.

Look at app stores: some people pick winners (e.g. Apple). The web wasn't built this way. Another example: network operators wanted to charge 10c per lookup. People didn't want to pay, so it sat there. Google decided this was fundamentally useful to users and have released a location API, Google Gears, WebKit, etc.

Our philosophy: build things people want to use. Google Wave is a bit weird - we want other people to come onto this.

Q: Where does Gears for Mobile fit?

A: We're more about standards in the browser than getting Gears out there. We're now getting geolocation APIs in W3C standards. Gears got us in there, but has done its job now.

Q: How do you see widgets fitting into the web?

A: Define widgets. The Palm Pre is all widgets - the dialler is written in Javascript. Widgets have a place because users don't think about using a browser. Showing things in a browser isn't the end use case of everything. They let users build their own climbing frame, rather than going to a full web experience. Widget platforms will become browsers.

Q: Should I be worried that all my passwords are the same?

A: SIM is solving a problem that doesn't exist.

Q: Why not do away with passwords?

A: You still have to authenticate. You have to have reasonable barriers for privacy and reputation. Larry says "the internet is too anonymous". If you can authenticate more easily then this might be addressable. The SIM is not the answer.

Q: Should I have to login to execute a google search? Even creating a username is an intolerable overhead.

A: No.

Q: I agree with the philosophy of open. It's great for users, but lots of businesses aren't making money from it. So what's the future of it?

A: It's a truism that people will pay for good things. We don't have micropayments. It's hard to do things at that level. We had 10c payments with AOL but got rid of it. It's easy to do it with a good product. Small app developers will do well. There were lots of mom'n'pop shop writing Newton apps and doing quite well. If you don't have to do distribution, you can make a living selling things for $5. Recurring payments is a key one - most of us are too lazy to hit cancel on that.

Symbian? What's that? Barbara Ballard

Nokia has 6% penetration in the US, maybe lower.
60% of US subscribers now text, but email a lot via Blackberry - because we like email. But we do more mobile web than European. In the 90s we stayed online all day using dialup, so email was always available... but not 2-way SMS or operator interop.

RIM put together an ecosystem for email as sophisticated as Apple's for music: consumption, servers, Exchange integration, fast setup, works well on 2G. Some US people call any candybar phone with a keyboard a Blackberry.

By comparison, it takes 77 clicks to set up email for Nokia.

Until recently BB had no Javascript, CSS or stylesheets activated.

30% of US iphone users were carrying a second device last year, frequently RAZRs (still). The whole federal government carry BBs. So our mobile web world is Blackberry, iPhone, RAZR...

So, Internet vs Telco: a framework for understanding company behaviours. Not here to slag operators, most problems are a result of silo thinking.

When SV and Bay area companies approach Little Springs, they want iPhone stuff. It used to be they wanted to run anywhere. Nowadays, if it's not Android/Palm/iPhone it's irrelevant. But Internet thinking like this misses 96% of other devices.

Telco thinking: Sprint is not a bad telco from a UX experience, hiring UX since 2007. AT&T hired their first one in 2007!

Telcos tend towards device-specific design... which made it expensive to get content providers involved. They're big on customisation and feature phones. They don't do anything to support smartphones, much - smartphones are the bastard stepchild generating 50% of data revenues. Content providers have to support everything, though, back to 4 years ago.

Hybrid thinking, now: thematic consistency. Not the same web everywhere; tweak slightly for devices. Avoid accesskeys on QWERTY phones. Add padding around buttons for touch devices. Dynamic number of results (5 on RAZR, more on others).

One or more versions (of page, sub-site, or site). Graceful degradation. Page "tweaks".

Q: How's Android affecting the US market?

A: It's on the 4th largest operator. We're expecting to see more.

Q: What about device APIs for things like WRT or Qt?

A: I'm anxiously awaiting data in large enough volumes for me to play with it.

Q: What about applications?

A: If the dev teams are silo'd, I give them separate specs. If they're more sophisticated, I use this approach. With J2ME Polish they can do 1 build a day (seems slow - Ed.).

Gestural Interactions, Younghee Jung & Joe Macleod

Joe: air-kissing is a headfuck.

YJ: We don't remember our first encounter with human beings, but we do remember our first interactions with computers. How do we interact with technology more naturally.

(shows photo of electronic cats)

YJ: Technology is poor at mimicking natural expressions. Verbal communication is only a fraction of how we talk.

JMcL: We fight over videoconferencing suites at work. We have good ones, but they're no better than iChat.

YJ: I pick up new body language easily.

JMcL: The gesture of fingers on lips travels well...

JY: ...but some are very specific.

(I had difficulty taking useful notes of what was an excellent presentation containing oodles of gestures).

Modelling the mobile experience, Bryan Rieger

Started out doing lots of animation, motion graphics. Worked with Buxton. Getting into Processing more recently.

"My journey playing cognitive connect the dots through a road in hell"

Wireframes are "layout, behaviour and flow" - that's a lot of stuff to be putting in a document.

Let's just deal with flow... you've written a wireframe for a screen. What happens next - you imagine what happens and your mind interprets, filling in the blanks.

What happens between the "frames" in wireframes?

Clients require more detail... too much detail.

End up in UML. Bryan shows a standard UML diagram for a light bulb. Standards require literacy. Now we're shipping huge wireframes and literary references... which are hard to manage, get less feedback, are never updated, are hard to change...

So it's too much. So we build a prototype.

Paper is lovely but limited. Requires interpretation, is hard to share. This leaves us with HTML/Flash/Python/Java - requiring programming. HTML works well for web projects tho.

Prototypes are challenging - need development resources, get hijacked by development, fail to find right level of abstraction, unwillingness to iterate from dev team, and suddenly: development is happening in design.

Iterations are opportunities for design. But what's the software equivalent of the cutting room floor?

Demos beautiful little modelling tool.

(Thoughts: is it an issue of trust? wireframes are a tool for communication. within a team, face to face communication is high bandwidth, warm, works well. if a small team can work together and do it... we're ok. Problems come when we need to communicate or validate outside the team. In particular i've seen this when you're haing a client sign off... or when QA is involved to validate your work (whether external or internal))

If you're in Brighton and interested in this sort of thing, Joh and I will be running a dress rehearsal for the workshop we've running at Agile2009 in Chicago this August. It'll be held at The Mighty Skiff on Monday 13th July, 7:30pm onwards. The theme for the workshop is exploration of constraints within an iterative design process. That's a posh way of saying that we're going to get you designing stuff for phones in 90 minutes, and look at how how form factors affect what you make.

Expect measured quantities of chaos: we've not run this format before, and one reason for doing a dress rehearsal is to iron out the kinks and, guess what: note what works, what doesn't, and what we don't yet understand.

Despite the daunting quantity of work remaining to prep, I'm really looking forward to it. And a friendly carpenter I happen to know is already busy churning out some of the props for the evening:

Sign up here, thank you please.

So, I've been using an HTC Magic (the new Android phone that Vodafone have just launched) for about 2 days now - and so far it's been fantastic.

I'd had a little play with one when Voda first launched them, but in the few seconds run-through I received in the Vodafone store I'd not really had much of a chance to get into it - and I came away feeling slightly "meh". That all changed when Mr Hugman won one of the little beasties in a promotion that Vodafone have been running on Twitter, and I had a closer look.

I won't bore with a full review - there are plenty of those out there - but some highlights for me:

• Build quality seems good. It feels nice in the hand (I never liked the heavy and bulky feel of the G1), and is small enough for one-handed use;
• Flipping between horizontal and vertical use is extremely smooth, and most apps seem to allow horizontal use. In particular the on-screen keyboard works much nicer horizontally, with a bit of extra space to play with. That said, I find the keyboard usable in vertical orientation too;
• It's *fast* - subjectively, I think it's faster than an iphone. Switching between applications is very smooth, and I find myself doing this routinely to a degree that I never have with an iPhone;
• As you'd expect, syncing with Google is seamless. We're using Google Apps a lot at FP, and I had my contacts, calendars and emails on the phone within 5 minutes. They've stayed synced beautifully ever since;
• A decent camera, at last. Whilst the iPhone had me accepting a poorer-resolution camera in exchange for the rest of its loveliness, I don't feel that compromise here. Picture quality is good;
• There's some real innovation in the UI - the notifications bar which can be pulled down wherever you are to see recent emails, messages, alerts, tweets, etc., is incredibly helpful: no switching between applications necessary. I can be browsing, receive an email, and make a decision as to whether it's worth bothering with without breaking my flow of concentration in the browser. I suspect that this is the kind of thing the Palm Pre is aiming for, too;

Beyond the above points that stand out for me, everything else seems to work just fine.

It's not perfect, of course: battery life is poor, though post-iPhone I somehow accept that 1 day of usage is acceptable, and I'm told that if I disable GPS and 3G I can get massively improved battery life. In strong sunlight I can detect what looks like some faint burn-in of pixels (a ghostly outline of an on-screen keyboard), but only faintly. The headphone socket is mini-USB not a jack (remedied using one of these). And a flash for the camera would be nice.

But those are niggles; this is a lovely piece of kit which has already changed the way I'm using email (I find myself checking and reading email on the phone, even when I'm sat at my laptop). And I've yet to play with the development kit or get into that side of things, all of my experiences so far are as a consumer.

My experiences with the device, married with news on numbers of Android launches in the coming 6 months, are making me think twice about Android as a platform. Subjectively it feels about 90% as good as iPhone (though in some areas a little better, and there's lots of very visible improvements being made), and I suspect that Apple will maintain their position as the best overall product. Let's not forget that as a percentage of overall mobile ownership, iPhone is *tiny*, leaving plenty of room for Android to take a chunk of the rest.

The only two downsides I can see for Android as a platform are:

1. It may not be easy for vendors using Android to differentiate their products from those the competition are launching. AT&T appear to be doing a much more customised version of the OS than anything we've seen so far for an upcoming handset launch; it'll be interesting to see how deep this customisation goes. My gut feeling is that differentiation won't be difficult (or at least, it'll be cheaper and easier for a manufacturer to differentiate Android than maintain their own OS or license an alternative). And let's not forget that differentiation isn't much use unless it leads to a product which is at least as good as the competition - at a time when the telecomms industry is being redefined by new entrants, can we assume the alterations that incumbents want to make will be the right ones?

2. Anecdotally, I'm hearing that the Android Marketplace isn't generating equivalent sales of applications, when compared to the iPhone App Store. I think that this will improve over time; I don't see why, as it moves beyond early adopters, Android will appeal only to a customer-base who think everything should be free and won't pay for applications. But I also think Apple have done a great job of creating - and let's not forget, heavily promoting - the economy of the App Store. This is where I think Google may have more trouble; not all Android phones will include the Android Marketplace (many will no doubt include pale App Store imitations from operators), and unpopular though they are, the editorial decisions that Apple makes regarding what makes it into the store do act as some sort of quality filter.
   

In any case, interesting times... and once again I'm driven to kick myself into remembering that we're still at the beginning of something incredibly exciting.

Foliage has sprung up across Firefox. I burn it here:

• 10 lessons in bootstrapping from the founders of UrbanSpoon;
• ViaPost looks interesting: redefining the whole of the postal service as "the thing that sits behind a printer driver" tickles and terrifies me equally;
• Control/capability charts on Kanban: interesting, I think, though I'm finding that for me personally the challenge is not in gathering and visualising data, but in working out what to do with it;
• Six questions with Jack Schulze, who I suspect is so Ri it hurts. It feels a bit hypocritical to blog it, but I found myself nodding furiously to his advice that "talking about your work does not directly improve the actual quality of your work";
• Harrowing board games;
• Karl on Kanban, flow and cadence;
• The iPhone home screen can't scale, apparently. Personally I suspect that uptake of applications on this device has something to do with the fact that they're *not* hidden at the bottom of a folder hierarchy - and if users are anything like me, they sometimes disable or delete apps they've once purchased, so the assertion that they need to easily navigate 40+ is balls. Flat home screen is a feature, not bug, IMHO;
• Transitions on Nokia, if nothing else a nice guide to where and how to use these wee beasties;
• 10 things I have learned by Milton Glaser. Number 1 seems to have unpleasant implications for me;
• Why text messages are limited to 160 characters - a bit o'history;

There's an easter egg in our implementation of Scrum at FP: we call it "gold cards".

Summary:

1. Regular time for R&D benefits our business and our staff;
2. The system isn't abused; if anything, we have to persuade staff to take advantage of it;
3. Running the business in fixed timeboxes and tracking velocity is what lets us do this;
4. Why restrict it to designers, developers and QA?

Effectively, they're a watered-down version of the Google "20% time" scheme: in every sprint, everyone at FP gets to take a day working on something of their own devising; with 2-week sprints, this works out as 10% of our time spent on R&D. We factor the time they take into our velocity calculations, so these days are included in our planning and accounted for.

Doing this as a service business is something I've found tricky before, both at FP and in my past life at Good Technology. It's really hard to justify "taking a day" out when there's paid work to be done, and even under our current scheme we see gold cards being taken far more often at the start of sprints (when the pressure is slightly less) than at the end. Far from being a drain on resource, I find myself actually having to remind our team that yes, gold cards are still something available to them and yes, you really ought to take one this sprint. Even so, they're skipped more often than they're taken. Duncan, the agile coach who helped us introduce Scrum, warned us that this might happen: what do you know, people have a conscience and feel they ought to concentrate on "the day job" :)

Not only does it feel good as an employer to be able to put my hand on my heart and say we have, and actively promote, such a scheme... but providing an explicit time for playful experimentation scratches lots of itches, is good for morale, lets folks show off a little (in much the same way as a Hack Day), develops new skills, opens up possibilities for collaboration between folks who may not have worked together on a "live" project, and has resulted in all sorts of goodies, including:

• Our first Android and iPhone experiments, where we first started playing with these devices;
• A suite of simple, skinnable Android games which we're doing some experiments with - more on that soon;
• GPS tools which let us track paths and generally get familiar with co-ordinate systems and location technology - in the name of assisting a couple of keen geocachers, I suspect;
• 3D J2ME apps!
• A Faraday cage, still passing through QA;
• Dougie's entry into the 5k app competition;
• A couple of company-wide talks (on context-driven testing techniques and UI design for the iPhone);
• The worlds first accelerometer-powered spirit level for J2ME phones :)

We don't direct what a gold card day can be used for, but we do prefer to end up with something demonstrable yet sketchy, as opposed to "1% of something that will be amazing one day, but can't be seen yet". To steer in this direction, we make a habit of gold cards being demonstrated during the sprint review meeting at the end of sprints. We don't allow gold cards if you've taken holiday during a sprint or if you work part-time, and we've only explicitly cancelled them just once, during our trip to China earlier this year: it seemed a bit rude to be flown to the other side of the world and then take time out for R&D :)

I'm happy with the results. We have a flow of "new stuff" which is learned and shown around every couple of weeks, some early prototypes which we quite often end up demoing to prospective clients, and we've managed to accommodate all this alongside paid work for clients. I don't know how we would've justified the time without having fixed timeboxes and regular re-planning days; when we've tried to do this pre-Scrum, it's never seemed possible... there's always been a good reason not to take today for R&D.

Next steps? So far it's only designers, developers and QA who've taken advantage of this scheme; I'm curious as to what some of our commercially-minded folks might make with it. And I'm digging into what the tax implications of this scheme might be, in relation to the legendary UK government "R&D tax credits" scheme...

I'm technically on holiday this week, but some links anyhow:

• Jeff Patton on kanban. Really interesting, (a) because it's Jeff and (b) for the content, and I loved Karl's talk on this stuff at the Skiff a few weeks back. I profess quiet caution though; having seen how many folks misapply the relatively disciplined approaches of more formal agile techniques, I fear the line "yeah, we're kanban because we stuck some cards to the wall"...
• Wonderfully put call for a group hug from Bill Buxton to the engineering and design communities. I particularly like the specifics he goes into here: how design awareness, literacy and even thinking can, with effort, be adopted by anyone... and how design practice requires professionals "who have invested just as much to acquire their set of skills as the computer scientists have put in for theirs". +1, +1, +1.
• SmutOnRails, Martin Fowler on the recent CouchDB presentation that caused a stir: "My observation is that most men in the software business think that there isn't much sexism left in the profession - that this curse is a memory from a previous generation. Yet when I talk to women, I hear a different story". Interesting, particularly in light of the Geek'n'rolla debate where this view of the software/digital/IT industry was confirmed (by both men and women IIRC). Lots of further reading at the foot of Martin's article.
• VCs are struggling to see the sort of returns they want in a mobile apps business. Whilst obviously on one level I find this a shockingly short-sighted yadda yadda yadda, another part of me breathes a sigh of relief. App stores are a fantastic economy, but no guarantee of riches, and we tend to hear about the few successes well over and above the mediocre mass.
• Steve Blank continues to deliver some amazingly insightful posts, and "Four steps to the epiphany" will, I suspect, be re-read a few times this year.
• For fans of contention and BlogWar, "Is Interaction Design a Dead-End Job" asks none other than Bill Moggridge. More optimistically, Tim @ Cooper suggests that "the acknowledgment and appreciation of good interaction design has allowed the practice to evolve to include a broader mandate encompassing product and service strategy throughout the customer relationship lifecycle".
• Vodafone hint that future Android devices might be less Googly and more Vodafoney. /me whistles innocently, stares into space, quietly lusts after HTC Magic.
• GMail for Mobile got the "mute" feature, which I'd never heard of but am frantically using. Oh yes - I may have forgotten to mention that I'm now using GMail in the browser for *all* my email needs... I've fallen hard for the 'plex in the last few months.
• Interesting iPhone stats from GreyStripe: average app gets 20 sessions usage of 10 minutes apiece. I wonder how this, combined with the typical development cost of an iPhone app, compares in cost-of-attention that other forms of advertising or promotion might garner. Help me, lazyweb...
• GraphJam is my new favourite best thing in the internet ever.
• T-Mobile sold 1 million G1s - not bad going for a first-generation device with every conceivable input mechanism and a spangly new OS that *isn't* being marketed by Apple. But let's not pretend that the success of Android is predicated on the sales of any 1, or even N devices, eh?
• Whilst we're on big numbers, 1 billion iPhone downloads, eh? I put this down more to Longino's Revised Statute than Buckley's Law in this case (tho Buckley definitely applies elsewhere): the sheer ease of trying stuff out on the iPhone is what's had me (and others I've had the pleasure of observing close-hand) installing apps. When all I lose by downloading a new piece of software is a little boredom, I'll do it again and again...

It feels like I've only just written on this topic, but I've heard about a couple more events I'll be speaking at over the coming months:

• I'm triple-chuffed that the workshop Joh and I proposed for the UX track of Agile2009 in Chicago has been accepted: "Many Paths To The Top Of The (Mobile) Mountain" will be an exploration of the constraints of mobile as they relate to UX in an agile environment. We're hoping to do a dry run of this session at some point in Brighton before we head off to the USA for the real deal too...
• Before then, I'll be at Mobile 2.0 Europe in Barcelona, as part of the Play strand of the event. I'm not 100% sure what I'll be talking about - perhaps looking back at case studies of successful gaming services, or our adventures with Android and casual games.
• And more pressingly, I'll be presenting at the Mobile Web 2.0 summit in London, on the two-way-ness of mobile media as a channel. A whisper in my ear reminds me the early-bird discount runs out today, so if you're not a developer or startup (who get in cheap whatever the weather), best hurry...

• All this and BOGFest too :)