Keeping my Firefox wide this week:

• Applying Scrum to offshore teams: "some of the practices I though worth mentioning for any other offshore team out there who find themself struggling with their projects": +1 to all of them;
• How to be a program manager;
• Using Big Visible Charts from Ron Jeffries: "Here's the real power of a chart. It goes along peacefully, minding its own business, tracking events. Then, when a pattern of events looks bad, the chart shows it, and triggers people to come together and solve the problem"
• UI personalities, an interesting post from Andreas Constantinou. I think we'll see more of this stuff happening, particularly as handset designers focus more on the internals. If we're to rely on the middle layers Andreas talks about, I'd agree with him on 2010 being a date by which we'll start seeing this stuff... but there's a lot that can be done now;
• Jakob Nielsen got his mobile on: "Sites (including intranets) must develop specialized designs that optimize the mobile user experience. Today, few sites have mobile versions, and those that do are usually very poorly designed, without knowledge of the special guidelines for mobile usability";
• RIP EMCC :(
• Nice interview with Alan Cooper on the similarities between Interaction Designers and Agile Programmers;
• Limericks for user stories?
• Agile is like teen sex: "Everyone wants to do it, many say they're doing it, only some actually are, and very few are doing it right."
• My IPhone App Submission Journey;
• Doodle launched an API. Doodle is a lovely, focused, simple web service I use all the time.
• How do you plan for unplanned work? This has been a big one for us over the last year - we maintain quite a few services and need to be able to react quickly to problems;
• Siftables: "cookie-sized computers with motion sensing, neighbor detection, graphical display, and wireless communication. They act in concert to form a single interface: users physically manipulate them - piling, grouping, sorting - to interact with digital information and media. Siftables provides a new platform on which to implement tangible, visual and mobile applicationsn". Lovely in and of themselves, but a wonderful display of imaginative uses of simple tech too.
• Nat Pryce on the Dunning-Kruger Effect: "Have you noticed that you grumble (even if only to yourself) about code quality when you join a project and want to change stuff to improve it? And have you noticed that those improvements are seldom as easy to make as first thought and, once started, are often never completed successfully?"
• Mike Cohn on the relationship between story points and hours. I have an as-yet-unsatisfied urge to move us from hours to story points for our long-term planning...

If you're one of those rare souls with an interest, patience, and time to devote, you may have been following the various ongoing debates about content transformation. It's been a big problem in the mobile world for a few years now, where some network operators have been modifying web traffic between a mobile phone and a web server.

In some ways I'm surprised the conversation hasn't spread wider. As we migrate from strands of copper or fibre optic buried underground to mobile networks, more and more web access is being carried through this same infrastructure, with the same effects. As James wrote last October, Vodafone appear to have been running Minify on full-web traffic, sometimes with unpleasant results. Michael Dominic K has observed similar behaviour with Orange 3G in France, and I've Orange UK do the same for many years now.

Transformation of content is nothing new; the original specification for HTTP, RFC2616, mentions it as a possibility and provides a means for content providers to opt out of transformation. This doesn't mean it's the right thing to do, of course - there are lots of unpleasant or illegal things one can do whilst conforming to the letter of the HTTP spec - but it does mean it's there as a possibility, albeit one that doesn't seem to have been used much until recent years.

But in any case, it seems that the troubles we've been experiencing in The Merry Land Of Mobile are being quietly visited upon the wider web, and it'll be interesting to see what the reaction is. My predictions for the next year or two?

1. There are a comparatively limited number of mobile ISPs compared to the fixed Internet. The impact of a single ISP deploying transforming technologies is therefore much worse, and more noticeable. As a result, more light is shone onto deployments of such proxies as they affect a wider audience. Efforts like the W3C Content Transformation Group, on which I sit, and the Manifesto for Responsible Reformatting get more attention.

2. Deployments of transforming technology tend to be more responsible as a result of the above. Some operators may feel the benefits of deploying, say, technology to insert navigation headers into pages outweigh the negative impact of doing so, and launch it anyway. If it's a problem, the customers of these operators vote with their feet.

3. The security impact of such deployments come to light after a high-profile story in which a cross-site scripting attack (or similar) is enabled by a deployment of a transforming proxy.

4. Developers of web sites start to code defensively. The "no-transform" header becomes a standard part of AJAX libraries or sites which explicitly don't wish to be messed with, as the wider world of web development wakes up to the possibility of transformation.

5. Deployments of transforming proxies become rarer as more designed-for-mobile services arrive, removing the need for transcoded content. A few transcoders remain, perhaps not deployed by operators, to allow mobile access to full-web sites for those who need it.
   

It's a while since I last wrote about how we're getting on with Scrum, and we've had an eventual few weeks... so here goes.

We're doing This Thing, right, and I can't tell you anything about it at all, except that 9 of the Future Platforms team flew into Hong Kong a few weeks back and spent a fortnight working on-site for Microsoft in China, to kick off the project we're doing with them...

It's been quite an experience in many ways: travelling abroad as a team, working across cultural and linguistic divisions, and fitting our processes in with those of the worlds largest software company. We wanted to colocate ourselves for all the classic reasons: tackle risky elements of the project together, put faces to names, and build relationships which can weather the inevitable highs and lows of a collaborative project. And of course, we're running things in the way we always do - I hope I'll be able to write more about this in time, I think we're going to be learning a *lot*.

For those of us lucky enough to go, it was definitely an adventure: hard work, thanks in the main to the sheer dedication of the FP team who were heads down for a full working day and frequently carrying on back at the hotel... but we had a lot of fun, too - as our various Flickr feeds will attest - and our hosts took great pains to make us feel welcome.

We landed back into Heathrow at 4:30am on Monday, and have been collectively fighting jetlag ever since - at the same time reuniting with the crew who remained in the UK whilst we travelled abroad, and our newest hire, James Hugman - who I'm maxi-chuffed to have working with us.

One thing we've been conscious of in recent months is that our team size is starting to become a bit cumbersome. Stand-up meetings feel less relevant when there's 10 people working on a few projects, retrospectives become harder to run with so many opinions to bring out and discuss, and it's easier to lose focus when planning. And personally I have always cherished the times when I worked in a small (3-5 person) team - it's when I've had the most fun as a developer.

So before we flew to China, we'd held an end-of-sprint retrospective where we agreed that now might be a good time to split the company into two teams - and on Wednesday we did just that. It was quite involved, and in the course of the retrospective we covered:

• Make-up of the two teams, ensuring they were balanced from a skills perspective and that they allow for continuity. We want to keep folks who'd just built relationships with Microsoft carrying on the good work, for instance;
• Office space, making sure the teams are colocated and have control over their own environment (they've already chosen radically different desk layouts), and that both have space to meet around a task board daily;
• Running planning days; I was keen to bring the whole company together for reviews so that we all get to see what we're collectively up to, but we eventually decided to do the same for retrospectives (with a view to learning as much as we can from our experiences even across teams), whilst separating planning out into two per-team 90-minute sessions in the afternoon of planning day, and running separate daily stand-ups.
• Naming the teams :) Anjuna and Tonberry it is!

The day went surprisingly smoothly and was unusually calm. Mary, our Product Owner, has been doing an excellent job of pre-planning preparation (grooming the product backlogs of our various clients into sprint backlogs efficiently), which pays dividends, and we were finished by 6:30pm tonight even after office rearrangement and a 90-minute lunch break, in which we introduced Mr Hugman to the delights of E-kagen.

The main problem we've had is that of accurately predicting a velocity for the two teams. In China our productivity was unusually high (greater than it's ever been, in fact), which we ascribe to working long hours with an unusual level of focus on a single project. Some of this (the focus) we can try to carry forward - in fact, the two-team split should assist us in doing so. But with the company split, we're not in a position to accurately estimate what one of the new teams can get through, until the end of this sprint.

So we now have 2 development teams, each comprising 3 developers and a full-time QA - plus a design team of 3 supporting them. We're running design separately for the moment: we have a couple of large design projects, one of which involves no development at all, and will be bringing designers into daily standups for any sprint in which they're doing any work with the dev team.

Next steps: we'll bring in another Product Owner (we need to give our clients more love, and this will help - watch this space!); and see how well the team structure we've chosen works over the coming weeks.

It's a little personal anniversary for me today - exactly 10 years since I started practicing Aikido.

At my age that still feels like a long time, and it's passed frighteningly fast. What's also strange is how different my life is now to then. I can't think of many things in my life that have lasted more than 10 years: no employment, no educational establishment, no relationship. The only things that spring to mind are family, a clutch of treasured friendships, and general geekiness.

10 years isn't a long time in Aikido terms - my instructors have more than 30 each under their belts, and still emphasise how much they have to learn. I hope I've been quite careful not to bang on about it here (or elsewhere), but I've been promising myself that once I got to this point I'd give myself license to talk about analogies I see between this stuff and the other things I do. I think there are commonalities between all sorts of craft and I'm sure that if I were a musician I'd see them there; it just so happens that the two things I've done most deeply are software development and aikido. Be warned: I might start writing about them here.

(Mmm, software development and martial arts. Why don't I get invited to more parties?)

And on a side-note, this also marks a personal best in procrastination. One of those little jobs I've been meaning to "get around to any day now" - for TEN BLOODY YEARS - is setting up a direct debit to pay for my classes. I have to do it now... or hmm, maybe leave it another 10...

A huge thankyou to Tom and Maria Helsby, and everyone at Airenjuku Brighton who's put up with me over the last decade. Now, mouth shut, hands open...

• Using an Agile Software Process with Offshore Development by Martin Fowler;
• Industry trends in prototyping by Dave Cronin;
• Kaizen and Kaikaku, an analysis of where agile adoptions go wrong. Happy to report we went Kaikaku;
• Flaccid Scrum, for the title alone;
• Fascinating set of user interface principles for Palm WebOS;
• More wisdom from Jeff Patton on product owners and product design;
• Web Programming Is Hard, via ATobe;
• Dougie passed on Programming Sucks;
• Continuous Deployment: now there's a good target;
• One Free Interaction, a wonderful essay from the Cooper Journal;
• Recreating the Button, a painstaking investigation of the redesign of web buttons for Google;
• Scrum is not about engineering practices;
• Continuing the life tracking theme, BedPosted - a site for you to track your sexual encounters with;