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 :)

Why (So Many) Testers (Still) Hate Agile, a presentation from Simon Bennett of EMC and Malcom Beatty, a "career tester", talking about how moving to an agile environment changes the role of testers in a development team... and talking about what this means for them.

Traditionally testing uses the V model - with testers validating specification by looking over documents from the business, deriving test cases and then verifying that a product conforms to these cases. Most communication with developers is done via bug reports, leading to an adversarial relationship with developers and a sequential structure to the project... but hey, at least it's test-first development in one sense.

Why do some testers hate agile? Early XP implementations advocated that developers do their own testing, thereby making the role of tester redundant - you can't blame testers for resenting this, and it's unwise given what else they can bring.

Other classic dislikes are that "there's no point in automating stuff that might change", and "working in sprints is too bursty" (both points that we've had raised at FP - which I find comforting :)).

There was also a point raised about bugs going into a bug tracking system, rather than a backlog. We've been managing both systems over the last couple of years, and I can see why this might cause problems - you end up with 2 sets of priorities, effectively... and there's gaps between these two sets of priorities through which things can fall.

Simon and Malcolm had surveyed testers to ask about their aspirations, likes and dislikes. A good day means raising good bugs, closing them, having a final say in getting product launched, and preventing disasters. A bad day involves trying to grok poor documentation, reported bugs not getting fixed, and "bug noise" - i.e. poor bugs which are typically feature requests raised by a customer.

Testers surveyed typically hated planning poker, testing unfinished work, and having conversations with developers about bugs which had been opened and well reported already.

We then broke into groups to discuss how different aspects of the Agile Manifesto might cause problems for traditional testers. My table (on which I think I was the only non-tester) chose the manifesto point preferring "Working software over documentation". We came out with a few reasons why traditional testers might dislike this:

1. Testing stuff that isn't fully done is frustrating;
2. The definition of done might fall outside a story definition (with e.g. bugs found through destructive testing and button-bashing);
3. Documentation can provide good proof of effort which might be helpful in an adversarial dev/tester environment;
4. This proof of effort might be helpful to show ones contribution to a project, or personal ownership of a section of it;
5. Documentation of bugs opened/closed in a bug tracking system can provide metrics to demonstrate quality of the dev or testing team;
6. Too many bugs in a backlog could make the backlog unmanageable!

Interestingly, lots of testers at the table I sat at were pro using the backlog for all bugs. One girl mentioned the use of STrac for backlog management.

There was then talk of the ideal tester/dev ratio - it seemed to vary between 1:2 and 16:1 depending on project.

Constant testing throughout the project (as opposed to a test phase at the end) means that the test phase can't be "shrunk down" under schedule pressure, to move the live date forwards or to accommodate complexities in implementation. Interesting, I see the same thing in our use of regular Gold Cards for R&D purposes - if we'd set aside a week or so in the future for such activity, it's the first thing to be cut, but if it happens a little at a time it's much easier to justify.

So what's the role of testers in an agile environment?

• Help with requirements definition and acceptance criteria, by taking sometimes vague statements of intention from the product owner ("must be user friendly", "must be high performance") and clarifying them so developers can usefully create code that meets them...
• ...thereby making developers lives easier;
• Use automation to free up tester time, to do exploratory testing;

The last point grated with me. We've really struggled with automation of our testing over the last year and it's been a point of contention within our team for some time - providing questionable value at a disproportionate cost. This is something I want to think about some more, I struggle to believe that automation couldn't deliver some value, but we haven't cracked it yet.

Enjoyable session. Like the distributed teams one, it's comforting to hear that so many of the issues we've had at FP aren't "just us"... and I have a few tweaks to suggest when I get back :)

Ade Miller of Microsoft on Distributed Agile: things the platforms and patterns group has learned running distributed teams.

The slides should be on his blog, but a few points jumped out at me:

• Colocation not only lowers the overhead of communication, but also removes all that thinking you otherwise have to do about how to communicate;
• There are many types of distributed team - from completely distributed (a level playing field, no-one colocates with anyone else) through distributed-by-function (builds walls between disciplines, loses bandwidth, trust and availability), to ad-hoc distribution (e.g. everyone colocated except one guy "who will hate you") and teams distributed across time zones (often doing "follow the sun" development where stories are handed off as working days start and end);
• Were they not distributed, many of the practices of distributed teams (handing over work, communicating by email only) would be considered dysfunctional!
• Trust is easy to lose in such teams, generating a "them and us" atmosphere; dissipate this by relocating teams periodically, humanising remote team members using photography, or actively building a shared sense of humour across teams;
• Many agile practices assume everyone is together - e.g. pairing, story cards as placeholders for conversations, standups. "You need to step back from the practices and look at what they're trying to achieve";
• Conway's Law: your software will start to resemble your organisation, if you let it;
• Bandwidth is important for distributed projects, poor availability of bandwidth will preclude options like videoconferencing;
• Travel at the start of projects builds trust, but also do it before large releases, at the very end of the project (for retrospective and ship party), and maybe on regular rotations;
• Got one remote developer? Use a "buddy system" - assign someone specifically to represent them and look after their interests within the team;
• Tools can make it harder for you to modify your practices; they tend to be set in stone. They're more important when you're distributed, but aren't the be all and end all;
• Continuous Integration is more important with distributed teams, where it's tougher to keep things in sync. Use widgets or system-tray resident tools to replace Big Visible Charts and promote the state of builds to developers;
• DO adapt. DON'T follow stock practices. You're breaking the rules already by not colocating, so you may need to break others to get it working;