After a post before Christmas where I expressed a little surprise at the exceptional response rates which Blyk were reporting, I had an email from Jonathan MacDonald, their Sales Director - and today spent an hour or so up at their offices talking about what they're up to.

I've found Blyk unusually opaque so far - being outside their target audience (which is strictly 16-24), I've not been able to sign up or try out the service, which means that most of what I knew of them was gleaned from press releases, blogs, and a presentation at MEX 2007.

Some of what I was told I've agreed not to write about just yet - so in the interest of objectivity (as if you can expect any here - you can expect this site to reek of my personal biases), I'm not going to comment on any of that side of things, positively or negatively. As for the other stuff: all the stats quoted below are from Blyk; they seem acutely aware of the too-good-to-be-true nature of these and are getting them audited by an independent third party.

The business is much more about targeting than I'd previously assumed. Their offering to advertisers is the same thing which folks like Tomi Ahonen have been writing about for years, and which the mobile industry has largely failed to deliver on to ate: aggregating vast amounts of information about subscribers and using this body of data to deliver relevant advertising. To do this, they're gathering information in three ways:

1. A lengthy sign-up questionnaire which is filled out when members first join; Blyk see a pattern of behaviour where members who've not initially signed up return once they see the coupons, ads and promotions which members who have filled out the questionnaire fully get;
2. "House messages" delivered from Blyk to its members once or twice a week, asking simple questions ("what's your favourite band", that kind of thing). They reckon that responses to these questions (which get a response rate greater than 29%) are almost a form of vanity publishing or self-expression - but they deliver useful data for targeting purposes;
3. "Dialogue" ad campaigns: i.e. those which don't just involve sending a message out to members, but asking a question and then delivering a message depending on the response. So "Do you want a cheap holiday" might be the opening message of a "Dialogue" campaign. If a member replies "yes" then two things occur: Blyk get useful information about that member for future targeting, and their advertiser can opt to deliver a useful, targeted promotion at that point;

As for commercials: 6 (according to their research) is the number of campaigns customers will bear per day (it feels high to me but with decent targeting I can see how that might work), and a campaign might consist of several messages. There's lots of possible variance here but I can see their argument that a campaign is not just a single message.

They don't seem to be being abused by their members. 75% of Blyk customers don't use their monthly allowance of (the bizarrely chosen) 217 texts and 43 minutes of talk time.

They do see a phenomenon that we've observed with services we've run in the past: a small (5%ish) percentage of responses to Dialogue campaign questions seem to be free-text answers, and Blyk see members messaging them directly and spontaneously with conversational texts. The geek in me is really curious to see what they do with this phenomenon - how they manage communication with these ardent customers... and whether they meet the expectation these enthusiasts have for human communication.

Overall: I have to say I'm less sceptical now, and once the figures they publish have some credibility (which could be achieved by a trusted brand backing them publicly, or via the transparent and open auditing they plan) I they'll get a warmer reception (and the rest of the mobile ad industry a bit worried, given their respective response rates).

If that happens, I'd expect to see other operators look to get their houses in order and start to do the same tying together of customer data that Blyk have achieved, in order to supplement their ARPU with revenue from the ad industry. After all, if Blyk prove the model there'll be an awful lot of mobile subscribers out there who *aren't* signed up with them.

I dashed back from class last night (courtesy of a lift from Ms Trchalik) and rushed over to the Komedia to catch the last two-thirds of Poets vs MCs with James, Soph and Ruth. I'd expected it to be a fairly quiet affair (having been to a few low-key Brighton poetry events which tended to max out at around 20 people), and was amazed at how busy the place was. The Komedia was unusually packed out - with a strange crowd, split down the middle with everyone identifiable as a support of one group or the other.

The highlight for me was Spliff Richard - I'm not sure why he wasn't considered an MC, coming as he did from the slam poet side of the fence and out-rapping quite a few of the rappers - with Robin and Chris Parkinson coming a close second. On the MC side, Dr Syntax really stood out too :)

So we've just started our fifth two-week sprint since we adopted Scrum at Future Platforms; it seems like a good time to write about the things we've learned so far (and the stuff we still don't get).

At the end of each sprint we devote a day (which Joh ably facilitates) to reviewing the previous two weeks and planning out the next two; in the morning, we first review what was produced in the previous two weeks, then have a retrospective where we talk through what went well, what went badly, and what we still don't understand. The first review lets Devi, our product owner (a role which seems to map well with account manager) and the team themselves get a good view of what's been done, while the retrospective lets us all identify what's working and what needs to change. Typically we end the retrospective with 4 things which we aim to concentrate on in the following sprint; these have included items like "reducing interruptions", "try pair programming", "manage contacts with clients via correct routes", and so on.

Having spent the morning reviewing the previous two weeks, we spend the afternoon of the planning day looking at the next two weeks: taking stories which together make up a product, prioritising them, estimating them if necessary, and getting them up onto the task tracking board. In the early sprints we found the estimation of tasks to be an horrendous burden, and 3-4 hour sessions of estimating tasks were (understandably) unpopular. Nowadays this seems to take much less time, mainly because we're breaking down projects into stories and estimating them during our pre-sales process (i.e. in a fairly piecemeal way) rather than doing it all at the planning meeting. We've also found that planning poker speeds up the estimation process significantly, focusing debate where it's needed most - i.e. where there's most dispute over the scale of a task. Nevertheless these planning days are still quite gruelling for everyone involved.

At the end of each sprint, we tot up how many hours of planned work actually got done, and I calculate the ratio of total available hours to hours of planned work. This tells us how much time each hour of estimated work actually takes us, and I'm quite surprised at how consistent this number is; over the course of 4 sprints we have a *very* consistent picture of how long an hour of planned work takes us, and this picture is useful - both in showing that there's room for us to improve, and letting us make commitments to clients based on evidence, not prayer.

In the early sprints, we had a lot of work which "just had to happen" - like many companies of our size, I suspect - and we consciously planned in more than our initial figures showed us we could realistically handle. Overcommitting in this regard didn't actually get more work done, even when the team visibly felt the additional pressure. This sprint, we've taken care to not repeat this pattern and have planned in what we know to be an achievable quantity of work, based on what we achieved over the previous few sprints. To try and increase our efficiency, we've reduced the number of simultaneous projects we're running - as a service company it's unusual for us to focus the whole team on a single client, but reducing the number of projects for the team from 4-6 down to 2-3 per sprint might make a difference. We'll be able to see if it's made a difference in just under 10 days time, when we look at figures for work completed, of course. As the owner of the business, I like being able to measure this sort of thing empirically - though it does mean that we have to spend a bit more time on release planning, to ensure that if we have 5 active projects over a 3-month period, we're devoting an appropriate amount of time to a few of them in each sprint in order to meet milestones.

Release planning is something we started doing at the beginning of this year; some clients give us a predictable monthly workload, but for most we're working on a project basis. We know how much work we can get through in a single sprint and we know how large upcoming projects and regular commitments are. We use this information to plan out the next 3 months and see early on where we might need extra resource, where we have windows to fit in new work, and how busy we're likely to be.

Two things I have noticed, which we've yet to work out: how to fit design into this process more snugly than we currently do, and how to ensure that the daily stand-up meetings are relevant when you have a team that may spend the entire sprint doing different projects.

For the former, we're looking at incremental design instead of iterative (i.e. build the skeleton for the whole app, then fill in visual elements later) - but even so, there's an up-front task to get the skeleton together.

For the latter, I'm unsure: we certainly have some clients for whom we only carry out a single activity (e.g. handset customisation), which our developers have little to do with. We've started using a burndown chart which plots design and technical work separately (as well as a unified total), though we've not noticed significantly different patterns in the chart so far - so this may not be something which is helpful in the long term.

I've certainly not covered everything we've done in this post, but I'll follow it up in a couple of months time...

2008 is certainly kicking lots of new sand in my face; with Tom lending moral support to Mark's new venture, Integration Training, I've been taking the Tuesday classes at our aikido dojo. When I first started training I kept a diary online (much of which was lost in the Great Hard Disc Crash of 2005 - and may yet be restored); I may end up doing a similar thing for a little while now.

Whilst I've taken two classes so far (and they've both been rather small, with 2 or 3 students each), but a couple of things have stood out for me:

1. I have a sudden appreciation for how much I daydream or "tune out" when I'm normally training; in the classes I take, this isn't an option, and I really felt the additional attention I was giving it. The first time around the difference was striking, by the second it wasn't such a problem. But still: I've been spending far too much time asleep and am kicking myself (ineptly);
2. Having 3 other people in white pajamas copy your every move is a bit surreal. We were stretching this last week, and I became suddenly aware that, as I moved from rotating my left ankle to concentrating on my right, 3 others were doing the same. It's slightly sinister...

As for what we've been doing: really simple stuff. 20 minutes of makko ho stretching, a few warmups, and then taking a single idea and seeing how it's applied in a few of the simplest techniques. So the first class was looking at the circular kokyu arm-shape in ikkyo, iriminage, shihonage and suwari waza kokyu ho; in the second we went through the same set of techniques but concentrating on ukemi and stretching.

Russ posts about a federated Twitter. Here's an unformed half-thought, partially drawing on our experience with measuring progress in Scrum: maybe it's better in some circumstances for something to be 100% down than 95% available.

Case in point, from the software development angle: it's easy for software, or parts of software, to be 95% done. For about 95% of a project. Getting something to that it's-nearly-there stage is easy, it's completing it (working out those "last few integration problems") that causes all the heartache and pain.

So it is with a messaging system. If 5% of my emails aren't getting delivered, I'm not in a 5% worse situation than 0% of my emails not getting delivered - it's *way* worse than that. Suddenly email is rubbish, because I have to consider that my email might not arrive.

Same with free software: 1p for a download is a radically different price to 0p, because I have to think about paying.

And ditto with a federated messaging service: I'd rather Twitter (which I love but have never paid a bean for) was totally dead, than kind-of-working (maybe delivering my updates to most of my readers, say... or giving me updates from some readers but not others).