A couple of chaps from Best Brains gave a talk on using Google Docs as a project management tool. We use Google Docs an awful lot ourselves, so there weren't many surprises here - and I'm ashamed to say my notes are pretty nonexistent, as most of the slides were video-demos or very visual in nature.

They had some lovely cumulative burndown charts which nicely showed the flow of work between development, testing and done - an improvement on the charts we've been using which I might steal^H^H^H^H^Hbe inspired by.

And they gave an interesting looking demo of how to use a Google Spreadsheet to operate a retrospective with a remote team - having individuals fill in and colour cells as a substitute for writing on post-its. As with many practices involving distributed teams, I suspect it's not as good as being in the same room... but it felt like it might have been significantly better than dropping the practice of retrospecting altogether.

The speakers are awarded 7 (seven) Hume Points for beginning their talk with Jazz clarinet.

I jumped at the chance to see Mary Poppendieck speak, and was well rewarded. Her talk seemed to bind together my work life, playtime and chunks of my personality. It was a bit scary how many buttons it pressed.

She started out by referencing the Malcolm Gladwell "Outliers" stories around elite hockey players being mainly born in Q1 of the year... the lesson being that talent is more nurture than nature, and that practice can be used to develop it in most disciplines (with 10,000 hours being the "magic amount" required).

How can we develop talent? Identify a skill that needs improvement, devise an exercise to improve it (or get one from a teacher), practice, and get immediate feedback. Focus on pushing to limits (such that you can expect repeated failures), and do it both regularly and intensively.

This is "deliberate practice", and I can see it writ large in my day-to-day work, and in my Aikido training. On an anecdotal tangent... I'm surprised by how many folks I bump into in agile circles who have an Aikido connection.

So what are the four elements of deliberate practice?

1. A mentor, knowledgeable and involved, who can hire and review, set standards, guide, and ensure excellence;
2. A challenge - do it frequently and it gets easy (in a software context, look at deployments: force yourself to do them fortnightly and you force yourself to lower the pain of doing them). Don't do easy stuff, find something challenging - and given how hard it is to match tasks to a large pool of people in such a way that all are challenged, perhaps this precludes assignment of tasks. Focus on constant improvement, which means regular feedback, which means keeping developers close to customers. Focus on what's not perfect, so it can be improved: look at problems first;
3. Feedback, which might be design reviews, TDD, Continuous Integration, or visibility through common code ownership. Customer feedback every iteration improves the system, its capability to deliver, and motivation;
4. Dedication: skill development takes time, spent in one place, uninterrupted. We need career paths for technical development - Toyota have a 6-10 year apprenticeship for engineers which takes them across the business to experience different aspects of the company and supervision from a senior engineer;

Mary also came out with a lovely quote from Katsuaki Watanabe of Toyota: "The root of the Toyota Way is to be dissatisfied with the status quo". See that? That's my personality that is.

She also quoted Dijkstra's challenge: "Those who want really reliable software will discover that they must find means of avoiding the majority of bugs to start with, and as a result the programming process will become cheaper. If you want more effective programmers, you will discover that they should not waste their time debugging - they should not introduce the bugs to start with." - and asked how much of release cycles is typically spent "hardening" software, i.e. bug fixing. 30% is apparently typical.

And finally, she showed off the software craftmanship manifesto. I loved the way it build on the values of the Agile Manifesto and took them in its own direction. I couldn't help wondering if something similar might serve the UX community - which, from what Johanna related earlier today, is trying to clarify its identity within agile.

5 Users Every Friday was a charming and heart-warming case study of a design team within the e-commerce division of a retailer, finding their feet as the company moved to Scrum and adapting their expectations and process.

An overriding concern seemed to be keeping up with the pace of development; once Scrummed up, the dev team were rocketing away whilst the designers, who'd previously have planned 3 week chunks of user research activity, struggled to follow. This led to UX work being separated out from development and an "us and them" feeling between the teams.

Initially, they played with adding 2 designers to the Scrum team: one to sit within the team and do day-to-day design work and another to sit outside the team carrying on research. Even so, the research was taking too long. There was no question over the value it could bring, but it needed to be available in time - so the team resolved to run 5 usability sessions a week, every week. This had shades of Mary's talk in it, for me - the team were getting better at doing research by forcing themselves to do it more frequently than they were previously comfortable doing.

The weekly schedule was:

• Planning (Tuesday): identifying what to test;
• Preparation (Wednesday/Thursday): getting prototypes, comps, users and facilities ready;
• Testing (Friday): 1 hour per user of testing and interviews, held in a conference room, with designers and sometimes developers present. No flashy one-way mirrors, crude models: all happily lo-fi;
• Analysis (Friday/Monday);
• Recommendations (Monday/Tuesday);

All the above was roughly 1 full-time designers work. Changes arising from testing were discussed with the whole team. Recruitment of users could take *ages*, so they used a market research firm to find very specific people approximating to their market segments.

Analysis had to be lightweight, too - no more thick reports, the aim was to identify serious problems quickly by scanning through data rather than mathematical analysis. At the same time they had to be careful not to dismiss findings. Annotated screen-shots were used to create "WANTED" posters, with the aim of provoking discussion.

Everyone pitched in, everyone crossed the lines and helped out elsewhere. But... long hours were worked, morale suffered and fatigue became an issue (perhaps because of the process, perhaps because the company was in the process of going out of business).

I'll finish with one lovely quote from Tom: "your lab is anywhere you're collecting data".

Alistair marches into the room behind a bagpiper: excellent entrance strategy. He then riffed on the funeral speech from Shakespeare's Julius Caesar ("I come not to bury Agile, but to praise him..."), incidentally mentioning Waterfall and Kanban as "honourable men", and launching into a really good keynote.

Basic premise: this agile stuff isn't anything special any more, it's common sense cherrypicked from good practice over the last 30+ years and is now dissolving gently into the mainstream. We're not the new kid on the block any more, and it's not all about small teams doing their stuff, but is opening out into new areas: life-critical systems, vast projects, etc.

He then went back to the roots of what we're all about - "people making ideas concrete in an economic context" - and likens software development to:

• A game, with positions, moves and strategies. Not an infinite game (where the point of the game is to keep playing it), though organisational survival, a product line, or a career path might be seen as such; not an open-ended game (like, say, jazz improvisation or IT systems); but a finite, cooperative game like theater (an analogy considered closely in Artful Making) or rock climbing. The game has two conflicting goals (deliver this round, and set up for the next), three possible moves (invent, decide or communicate), and always changes, with situations never repeating themselves. So what must we do? Set up projects so you can tell what's wrong with them as soon as possible, make sure people care, and ensure they can pass on information smoothly. These are the "people issues" of a project;
• A craft, with discipline envy of "proper" engineering (which in turn has discipline envy of applied physics). So we need to pay attention to our skills and the medium - at this point Alistair talks about Shu-ha-ri (the number of folks sitting in the intersection of the Aikido/Agile venn diagram is starting to scare me);
• Lean processes, with the unit of inventory being the unvalidated decision, whether that being at the feature level, a UI decision, a style choice or untested code. In manufacturing, rework is troublesome, in software, less so. Alistair talked about rework leading to 2 queues of stuff-to-do - in our world this would be features and bugs. In such a situation work can get disruptive or batched up - so minimise outgoing bugs and aim for continuous flow of minimal features.

A few other choice nuggets:

• The role of a tester is to check and clarify requirements, a test being nothing more than a highly refined requirement;
• The role of software architectures is to sequence technical risk such that it's spread appropriately throughout a project;
• Alistair worries about kanban leading to a continuous flow of work which humans can find depressing - "we need peaks and troughs", he says. I think anyone who's lived in the Fens might agree ;) He talked about use of R&D and Gold Cards to achieve some of this, or at least break the monotony of constant development.
• Retrospectives aren't post-mortems, they're tools for steering the project throughout its life

So before I get caught up in the helter-skelter that Agile2009 promises to be, I must hurl up some words around UXCampLondon, which ran last Saturday at the offices of eBay in Richmond.

I didn't do my usual trick of obsessive note-taking - I'm experimenting with listening instead of transcribing at the moment - but a few choice morsels made their way into my notepad.

Adrian Howard did a good session on "Why your development team needs to do User Experience", making a few lovely points:

• A small amount of design education can both empower a dev team to make good decisions and simultaneously free up UX folk to work on the tough design problems;
• It's not enough to tell developers what to do - they need to know why. This again helps them make correct micro-decisions during implementation, and I like to think it's a bit more collaborative. I likened it to the often-missed final clause in user stories: "As an X, I want to do Y, so that I can Z";
• Code is a design tool: it's an expression of abstractions;
• Technical authors can act as a good input to user experience; they have to document the how-to and frequently feel pain points and inconsistencies;

Adrian also helped, with Leisa Reichelt, facilitate a session called "Agile UX Moan". Held in that dangerous post-lunch spot, it gathered a pretty decent crowd of folks at various stages in their adoption of agile, and with positive and negative experiences to draw on. My only note from this one is a point around Product Owners acceptance of work: frequently it's tempting to accept the minimum, when a story has been delivered that matches the words on the card. Acceptance ought to come not when the minimum has been delivered, but when the card has been implemented to a requisite level of quality - and this should include a desired user experience.

Alred Lui did a nice talk on "Emotions and Design", hung off the peg of Mobile UX. He's a designer working for Motorola, and spoke about using emotions to differentiate otherwise similar products. One memorable example was audio tools: whilst a waveform editor might be the most efficient and easy way to manage editing audio files, for certain uses things like virtual effects pedals or sample-triggering soundboards themed around hip-hop actually make more sense. And he won me over with a slide proclaiming "Never underestimate the power of fun and cuteness" :)

And Cath Jones did a great skit on user journeys, which I'd really like to see repeated under looser time constraints. She did a nice job of breaking journeys down into six types: A-Z, Desperately Seeking, lattices of contextual content, Rooted To The Spot, Away We Go, and Are We Nearly There Yet. Cath - get the slides online and please rerun this one soon :) In particular I liked a metaphor she used a couple of times around having users feel like they're accelerating towards their goal - getting faster the nearer they are to it.

I ran a very short session at the start of the day, a meta-piece on the workshop Joh and I are conducting here on Thursday. I was interested in other design practices that we could plug into this, perhaps as part of retasking the workshop for a more design-literate audience. It was fantastic to have a pile of useful feedback from a group of smart, enthusiastic designers. In particular they wondered about:

• Having teams manufacture personas based on transcripts, then presenting personas back to the room to highlight differences in emphasis or interpretation;
• Thinking carefully about the wider context of use;
• A rapid concepting session early on, getting as many ideas out and discussed in a first iteration;
• Taking some of the activities from these trading cards and plug them in;

A really top day: great talks, a crowd of (mostly) new faces for me, top venue, solid wi-fi, and everything seemed, as a visitor, to have gone like absolute clockwork. I know these things are hard work, particularly when they're made to look so effortless, so can only offer thanks and hearty congratulations to the organisers. I'm already looking forward to the next one :)