I had a first play with the Guardian APIs yesterday, and was pleasantly surprised by how simple and effective they were. I'm not one of those Ruby-on-Rails kids who mashes Google up with the Facebook in between grinding a fat half-pipe on an ollie; even I found them really great to work with.

And, being the kind of childish individual who still gets kicks out of looking rude words up in the dictionary, I decided to use the API to examine changes in obscenity in the last 10 years.

To do this, I took a group of common swear-words, and searched The Guardian archives for the number of articles containing each one for each of the last 10 years. This gave me an idea for the prevalence of the word, without being overly affected by, say, the vulgar rantings of Mr Brooker. I then divided this number by the total number of articles available for that year - giving the percentage of Guardian content containing each profanity, and accounting for the fact that the total volume of digital content, and by extension UK liberal coarseness, has grown year on year.

I present the results below. Good news! The y-axis runs from 0 to 0.9%; even a liberal rag like the Grauniad seems to be pretty resistant to the tidal wave of filth which some might have you believe is flooding the English language nowadays.

A few observations:

1. Swearing is growing slowly year-on-year, across the board;
2. Unusually, in 2001, swearing stayed more-or-less level. Bastard declined after 2001 - probably an after-effect of 9/11, after which most other swearing grew;
3. Wank is massively underperforming over the last decade, whilst cock is flat;
4. Shit has grown disproportionately and steadily since 2005, whilst fuck has gone as far as it can;

Shock Therapy: Self-organisation in Scrum, Jeff Sutherland

Jeff started scrum 1993, CTO of 9 companies. Rolled out Scrum in 5. Works 1 week/month with VC group, 12 companies w/investments so far: "each one is a laboratory for how you work with Scrum".

Scrum is not a methodology, a defined process or set of procedures. it's an open dev framework. The rules are constraints on behaviour that cause a complex adaptive system to self-organise into an intelligent state... enabling an average team to self-organise into a super-intelligent team that goes 10 times as fast as normal teams. The goal: high quality, productivity, fun work. In the VC world, a company has to be 10x better to be worth the investment.

Scrum scales linearly across geographies.

Double speed of coding = 5% improvement end-to-end. You need more than a productivity improvement to see end-to-end gains.

The challenge is to understand self-organisation and how to avoid destroying it. Teams entering this state are often surprised at themselves. There is a common strategy for reaching this state. Management frequently systematically destroys most such teams.

The good news: reaching this state is like learning to ride a bicycle. Once you've learned to do it, you can do it again... given the right conditions. People are not "pluggable resources".

Scrum consists of roles (PO, SM, Team), meetings (sprint planning, daily scrum, sprint review, retrospective), and social objects (impediment list, burndown chart, product backlog, sprint backlog).

It's a pull-based system - practically everything you learn about lean manufacturing can be applied to a Scrum team.

PO needs to deliver really valuable stories at the front; otherwise garbage in, garbage out. If teams get to DONE well, velocity doubles and defects go down 40%. Next doubling occurs when the backlog is in a good state and there is zero in-sprint churn. Next doubling occurs with team self-organising in sprint.

Most companies are more like a Dilbert cartoon: drop planning and docs, just write code and whine. This is ScrumButt! Nokia had the habit of writing 300-400 pages of spec before doing anything, they broke through this cycle but still had the right amount of docs.

In a show of hands, half the people in the room doing Scrum admit to passing the first 3 questions of the Nokia Test.

Only 10% of teams meet all criteria. (I'd say only one of our two teams is currently doing this)

Even ScrumButt brought a measured 35% benefit to teams using it.

Challenges for new agile developers:

1. They can't self-organise.
2. They spend weeks arguing about the format of the board and get nothing done.
3. They don't follow priorities - everyone does their own thing and the sprint fails.
4. They can't get DONE at the end of the sprint.
5. They allow not-READY things to enter the sprint.
6. They can take years to work this out. Some don't.

As investors, Jeffs VC group invests only in Scrum+XP companies. Scrum is driven at board level. Many run management team, marketing, client services and support with Scrum.

What's the secret sauce? They want to change the face of investment in the US.

1. Implement basic Scrum practices and pass Nokia tets
2. Involve management, understand velocity

Some companies see 300% improvement in 3 2-week sprints - it used to take years.

Waterfall : 2 function points/dev pcm.
Scrum: 17.8 function points/dev pcm (w/ Mike Cohn test)
SirsiDynix: linearly scalability of a distributed team, 15.3 function points/dev pcm with team split between Moscow and US.
Xebia: half the team in Holland, half India. 15.1 function points/dev pcm. Their definition of "done" is the customer doing acceptance tests and judging complete before the end of a sprint.

Takes MySpace as an example: 1/3 of the company is waterfall, 1/3 ScrumButt, 1/3 Scrum. They have hundreds of developers, owned by Fox News, have founders running development. Management doesn't understand Agile and isn't committed. They brought in 30 project leaders who tried Scrum and thought it was "getting in the way of controlling projects". They've been trying to get rid of it.

They've tried "shock therapy": a set of good practices, but no choice. In agile, we want self-managing teams, but when the team doesn't know how to do this there's a problem.

Leadership changes from directing (telling the team) to coaching (involving the team) to supporting (team takes the lead) to delegating (team does it all). The goal of a Scrummaster is to work themselves out of a job as fast as possible.

Shows Aikido picture.

It's like learning the tango. You need a coach. "There are many of us in agile practice who have worked in martial arts, and there are lots of similarities".

Scott at Myspace takes 2.9 days per team member to improve team velocity by 240%. He's not necessarily popular!

Scrum as a framework gives teams lots of options. In practice, this overwhelms many teams. Just as customers don't know what they want, many agile teams don't know what to do til they're doing it. Scott's rules stay in effect until a team meets their goals for 3 sprints.

• Sprints are 1 week long initially, to give good visibility of progress. Teams tend to stay with 1 week sprints.

• He has a strong definition of done: it's a thorny issue. Done means feature complete, code complete, zero defects, approved by PO, production ready. Testing needs to be done as near as possible to development. Testers need to sign off on "done".

• All estimates are in story points. Waterfall team took 8 hours, scrum team 10 minutes, same output.

• Scott uses physical information radiator. Scott places the board, he moves the cards so that they're not confused.

• Sprint meeting is 4h once a week. Myspace (and many engineers) consider Scrum has too many meetings. So everything is consolidated into a single 4-hour meeting - and every other meeting is eliminated bar standups. Meetings get shorter over time. They have 3h15m of meetings/week.

• Initial sprint meeting is a demo, retrospective, backlog presentation, and the team questioning motives, suggesting alternatives, etc. Improper backlog items aren't allowed to enter the sprint.

• Multi-tasking is forbidden. Work is done in priority order.

• Scott is polite but forceful. The beginning is rocky, things gradually relax.
  

Scott makes the largest, nastiest impediment go away in 2 days. This underscores the fact that he takes the team seriously and is there to make their world better. His impermanent placement with a team gives him the ability to be a bit confrontational. He tends to leave teams with a 500% improvement.

Teams using this quick format approach hit their velocity quicker. It's a culture shock, but "they only hate you for 2-3 weeks". Teams stay in touch :)

Teams estimate sprint backlogs in story points.

Gives examples of teams: one team dispersed in an office move. One got a command-and-control manager who removed the PO and split the team up, they want back from a 300% improvement to 100%. The fourth team lost their PO and have been looking for one ever since, they're not delivering much of value.

Gives an example of a team which did well, disbanded (lost all productivity), and regrouped (got it all back).

It's good to have an experience SM to hand; and a good senior developer with agile experience.

Shows video of Maori Hacka (sp?). "Most IT teams aren't like this".

My question: "As a service company doing work to order. we find that our customers have grown up with the notion that fixed-price fixed-scope contracts are reasonable. In our experience velocity can improve as familiarity with a customer or product develops, and can vary between teams and projects.

And what strategies are there for fitting a Scrum development process around a fixed-price fixed-scope contract?"

A: The "money for nothing, change for free" model where you have a standard fixed-price contract with an additial clause stating that (a) at sprint boundaries, customers can substitute equivalent-sized features for any not yet begun, with no penalty - encouraging acceptance of change, and (b) customer can walk away before end of project when they've realised the value they wanted, sharing savings with the supplier.

Jeff is seeing consultancies used to 15% margins chasing 60% margins by deliberately making customer aware of ROI cut-off points, and thereby ending projects after 3 months instead of after 20, seeing margins increase as a result.

Update: quite a few of the posts I write relating to our work at FP are lengthy. I'm going to try summarising them up top, to highlight points of interest and help you decide if the whole thing's worth reading.

What we learned:

1. Retrospectives work better off-site, when you have a projector handy for demos;
2. Two small teams work better than one large team;
3. QA involvement has been "bursty", leading to lots of pressure at the end of sprints;
4. Flat burndown charts could be a serious warning - some thought required!

Today was our first review and planning day with the new two-team Future Platforms, and to give ourselves a bit more space to stretch out, we tried holding the morning session at The Skiff - a coworking space run by the Inuda folks a couple of streets away from our offices.

The facilities there were excellent. As well as more space we had walls to stick postits onto with (and lots of visibility, room to walk around, etc.), a projector, and beanbags galore. All of this - plus being in an unusual space away from the usual workplace - made a big difference.

The review went well, with our two teams (Anjuna and Tonberry) demonstrating projects they've been working on for Microsoft and the BBC respectively. Compared to the limited visibility you get by passing a couple of handsets around a room, having 5 foot tall on-screen demos felt like heaven... and the demonstrations themselves seemed to "flow" a little more than in previous reviews. If only I could talk a little more about their content; as usual, NDAs have my lips sewn shut. Unusually, our design team weren't presenting their work this time around - much of it has involved supporting the development teams (and was therefore visible in the dev team demos), and South by Southwest had taken its toll on our design resource over the last fortnight....

I was really looking forward to the retrospective, and wasn't disappointed. The near-unanimous view from both teams was that splitting the company into two had been a success. Each team felt more focussed on their respective projects, had been less affected by context switching, and found stand-ups both quicker and more useful. Even better, we could see measurable and significant improvement in the productivity of the company split into two teams (vs all being in one team).

One issue which was surfaced by 4 different people was that of planning and testing time. We have a persistent experience where testing effort bunches up towards the end of sprints - so that at the start of each fortnight there's sometimes not enough for our dedicated testers to do, and at the end of the fortnights too much.

My own tendency is to attack this problem by trying to spread the load of testing more evenly throughout the sprint (encouraging units of work - user stories in our case - to be taken through development and testing to done before starting on others) and having other team members help out with some of the testing work when there's too much (whilst some of it demands the eager eye and magic software-breaking fingers of a good QA specialist, I feel there are areas where the rest of us can usefully pitch in). We had a fairly lively debate on this one, and didn't reach a useful conclusion. In particular I had hoped to bring in some of the limiting-in-phases techniques Karl Scotland covered in his recent Kanban presentation (also held at the Skiff), but we didn't reach consensus on adopting this - so I'll give it another go next time around.

Burndown charts also stimulated a bit of conversation. I'd experienced a worrying few days with Anjuna mid-sprint, when progress on getting stories to completion was minimal even as the team frantically worked on a core section of the product... and I'd found myself noting a problem but stuck on what to usefully do about it. In the end the team pulled through and delivered, but I'm left feeling slightly worried; we've had sprints in the (thankfully distant) past where a flat-lined burndown continued right to the end, thanks to my ignoring the signs. Putting a positive spin on it, the worst that we'll ever do is experience a single unproductive fortnight, but even that would feel like a huge opportunity wasted. More thought required.

Finally, on design; last sprint we opted out of planning it formally, this time around we're officially embedding the design team with Anjuna, where they can crack on with pushing that particular product forward together (and without distractions from other projects).

A solid day; we saw the juicy fruits of our work, had some productive discussions on how to get better, persuaded a sizable chunk of the company to come out for gyoza etc, planned in two teams' worth of work for a fortnight, and still managed to finish dead on 6pm. Considering that a year ago planning days were regularly overrunning and leaving us all half-dead, with a smaller team, it's great to see how we're improving. On that particular point, it's amazing what benefit an hour or so of working up a sprint backlog for each team the day before planning can deliver...

Thanks as usual to Joh for her facilitation of the retrospective, and to the Skiffers for hosting us!

I've been making a lot of use of Skype recently, both at home and at work. Maybe I'm a bit late to the party, but it seems to quietly plug a gap that's existed in the way I communicate for some time.

Cheap voice calls is only a tiny part of it; about the only place I use them is to cheaply dial into hour-long W3C conference calls, where it's nice to be using a headset and where I'm frequently listening more than talking.

No, where Skype is *really* making a difference for me is in its instant messaging. Even when FP was smaller and we sat around a single table, we evaluated things like IRC for use as a company "backchannel" - somewhere you could put stuff without necessarily interrupting everyone. It never seemed to really catch on, and neither did Jabber (though we used Jabber throughout the Trutap project to bring our team and the Tappers in London together).

Somehow where these other tools didn't catch on, Skype seems to be working for us. We've quietly settled on it as the tool we use for IM within the company, and use it in quite a few different ways: as a general company-wide conference chat-room thatlets anyone post interesting links, ask about lunch plans, etc. (particularly useful when some of us are working from home, out of the office, or abroad); for problem-specific chat-rooms which tend to get formed when an issue of interest to a subset of the company gets discussed, and hang around nearly-indefinitely in some cases, become "project rooms"; and for individual, private chats.

What makes Skype so good for these? I can't quite put my finger on it, but I suspect:

• You can connect from practically anywhere - it seems to route around lots of port blockers nicely, and we have clients for just about every desktop platform (and some mobile ones);
• When you join a chat-room, you get all the messages you've missed. Really handy for catching up on old conversations;
• Few people I know outside of work are on it (as opposed to MSN, where I have a pile of old colleagues, friends, etc. - hopping online on MSN seems to be advertising myself as available for interruption, sometimes);
• It's really easy to start a new chat-room, there's no cost to diving off and talking privately;
• Being able to change the chat-room topic opens up all sorts of possibilities for levity - the room feels like "ours", and regularly changes title as the whim takes us;
• IRC-style "actions" (e.g. "/me doffs cap") similarly open up a bit more room for expression;

We make zero use of Skype for calls as a result of this: at FP our communal use of it is entirely based on instant messaging.

And the last place I'm using it is for family communications. Since hooking my mother to the interwebs last year, I've found myself rather enjoying being able to see her, or my sister, niece and nephew, hop online and video-chat with them. It's a very different sort of communication to voice chatting (you can't get away with distractedly doing other stuff mid-call, for one thing) and has augmented, rather than replaced, my use of regular mobile voice calls. I'm not video-calling instead of this, but as well as...

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