Mike Sutton on how to become a better agile practitioner by learning from other sources; my notes are a bit slapdash here because much of the session was practical or participative. So only a few bits and pieces:

• "Curiosity propels you to excellence";
• Mike talked a bit about NLP; in particular "well formed outcomes" - achievable actionable realistic goals which can be tested;
• ...and also "submodalities", "words as windows to primary representation systems". So, for instance, some people might talk "visually", saying things like "see what I mean?". Engaging with these people using the same language and metaphors that they use would be useful;
• We then did some improv exercises, having a group of "directors" tell a volunteer what to do repeatedly, with the aim of telling a story... whilst a second group, the "audience", vote on how well it's going. A few people noted how different it felt to be a director vs being in the audience in terms of pressure to deliver;
• Mike talked (rightly I felt) about how interesting it was to see software industry folks connecting to other disciplines and bringing something back - the idea that we can learn a lot from other places. In a chat afterwards, he likened this to his Aikido dojo where they're encouraged to go and learn another martial art after a little while, to better further their practice;

Ambassadors and Carrier Pigeons was another session about ways and means of making distributed teams more effective.

• Distributed teams are frequently created from business constraints (e.g. low perceived cost of outsourcing, distributed expertise);
• It's best to avoid splitting teams by function (e.g. having testers in one location and developers in another);
• Challenges include being "out of sight, out of mind" with little tacit communication; having a product vision that evolves without being communicated across teams; and being reliant on documentation and technology;
• Cultural differences can include language barriers, varying expectations of appropriate levels of communication, cultural and linguistic divides, and in particular differences over the words "no" or "yes" - which can have opposite meanings in certain contexts. As an example, the speaker highlighted the lack of smalltalk before meetings in Israeli business culture, contrasted with the importance they place on eating together;
• Working across time zones can lead to staggered work days, times when the other teams are asleep and thus unavailable, and jetlag post-travel affecting performance;
• Cross-team dependencies can include shared components, collective code ownership (and how to manage code reviews), daily sync-ups, and cost/budget constraints;
• Deep specialists can be a problem: they're typically limited in number, localised, and be trouble to work with;
• The "Ambassador model" was suggested: using individuals to bridge the gaps between teams, having a single team member visit the remote location whilst serving on and acting for their original team; other models proposed included...
• "Touring rock star", typically a Product Owner/Manager who travels to share the product vision;
• "Visiting professor", a temporary team member taking a tactical role to bring a specific skill or serve a specific need;
• "Foreign exchange worker", swapped with a counterpart across teams; ideally an extrovert. This can be palatable from a funding perspective (no-one loses a member of staff), but works best with one person at a time moving (so you don't have pairs who are less inclined to socialise with their new teams);
• "Paratrooper", deployed to address a tactical issue and who gets in, fixes it, and gets out;
• The audience also suggested whole-team relocation (I brought this up, drawing on our experience) and the "whip cracker", who turns up to put the pressure on. A few raised eyebrows around that last one...
• We had a brief discussion around tools for collaboration... all the usual stuff, IM, videoconferencing, project management tools, engineering tools, testing, modelling, etc. I brought up something I noticed the guys do when Thom broke his ankle - having an open skype audio call to give a bit of ambient chatter between office and an out-of-office worker;
• Eclipse apparently has some pair programming tools; CodeStriker was also mentioned to help with code reviews;

Ow. 23 pages of notes to write up - I fell a bit behind preparing for the workshop. Of which more, later...

Agile at Yahoo from the Trenches was a good first-hand look at an organisation going through an agile adoption. I'd read the paper that Gabrielle Benefield wrote a few years back on this, so was curious to hear some more personal stories. My notes:

• Yahoo! was a business that grew through acquisition, so ended up with many "city states" of different cultures;
• Senior leadership tried to rationalise these by introducing a Product Development Process, heavily waterfall, which dev teams paid lip service to but didn't buy into;
• The first experiences with agile had an emphasis on processes and mechanics rather than principles; engineers were reluctant, UX teams wary, QA were doubtful. Only product management and upper management were sold on it, and it quickly made some organisational dysfunctions visible;
• In 2005, an Agile coach was brought in and 4 teams volunteered for a pilot of Scrum. The coach ran voluntary training classes;
• Teams that didn't volunteer felt that their product was too complex, heavy UX was required, that agile couldn't meet their needs for global simultaneous launches and that it introduced too much risk;
• The pilot succeeded in that pilot teams delivered on time, that they were cross-functional teams integrating staff from across the business, and that some of the teams were doing technically complex or UX-heavy work;
• External dependencies were still a problem, and integrating UX was tough;
• By 2007 they had 150 Scrum teams globally; successes built trust and agile was soon mandated by the business;
• This "agile boom" led to a dearth of coaches, so teams struck out on their own;
• In 2008, staff cuts led to the coaching teams being disbanded, which in turn led to many mash-ups, a lot of cherrypicking of practices, and flawed adoptions. These in turn led to severe micromanagement, "Scrummerfall", and "meeting hell"; the conclusion from this is that bad agile is worse than no agile at all;
• Between 2008 and today, top-down mandates have led to continuous integration being adopted across the board, global product roadmaps, and a balancing out of product management (Yahoo! had too many product managers unevenly distributed throughout the business previously). Meetings are also now much leaner, with meeting discipline being focused on;
• But... bad implementations had incurred technical debt, management time is scarce, management trust isn't unconditional, and the word "agile" has a bad rap within the business: it's an overused and diluted term. There's also a sense that something needs to be added to it, for it to work well: "agile with stability". (The speakers found this ridiculous);
• Third party dependencies are still a problem, particularly when dealing with open source projects like Hadoop: how do you get commitments from volunteers working on Open Source projects?
• Thoughts on how to make agile adoptions stick: understanding and trust; visit other teams in action; and talk to experienced practitioners;

Johanna Kollman presented on the importance of identity and vision in agile projects. Waterfall didn't work for her, agile methods seemed attractive; but how could designers get involved? She did a series of interviews and observations to find out.

Fitting research into an agile process is hard. Some outsource research to satellite designers; others make it much more lightweight in order to fit it in.

Interviews threw up some consistent feedback around how designers see themselves fitting into an agile environment. Active participation in the process definitely helped, as did adoption of the mindset or philosophy (flexibility and lightweightedness) over and above rote adoption of practices. Designers frequently took up a position as "communications hub", engaged closely with the Product Owner, acted as an advocate for end-users and took on the task of educating developers. This can be a tiring set of responsibilities! The agile mindset of constant improvement, as expressed by the notion that a product "will never be quite right" seems counter-intuitive to a design mentality focused on identifying a perfect solution.

Many felt that losing the original vision of UX was a risk with agile projects; some felt that an interim sprint zero (of which more later) was a means of retaining this. It was particularly tough to establish a project vision for larger projects. But having said all this, sharing the vision (which agile methods seem to promote) was felt to both communicate and protect it. Mutual understanding was important. One tactic a team used was that of a "question board" - whenever a question was asked, it was stuck on the board and its answer added. This led to visibility of issues and clarifications, and visible documentation of their resolution. Having the board out and visible also provoked discussion and highlighted clashes in understanding.

UX attitudes to agile matter, a lot. Colocation bridges gaps and avoids functional silos, but there's a risk of designers becoming bottlenecks in communication, and subsequent stress; poor sizing or structure of design teams can also lead to compromised UX. "Sprint zero" felt insufficient to establish a vision, so perhaps there's a role for earlier research.

In an agile environment, designers become design facilitators, helping with planning and backlog work. Regular product testing was felt to be important, which presupposes the building of user databases which can be used for such testing, and the exploration of lightweight methods and tools could help.

I asked a question about the role of mid-project sprint zeros, which I first encountered when tea spurted through my nose as I read Cennydds A List Apart Article (sorry Cennydd! :). Such a beast sounded like a classic smell to me: a tacit acknowledgement that whilst the aim might be to have your product in a constantly releasable state, the product might be expected to have departed from its original vision. In this sense such a departure feels a little like technical debt - letting it build up, as opposed to dealing with it as the project goes along, is risky, and a sign that something is going wrong.

Johanna clarified how and why these mid-project sprint zeros occurred: they weren't being used to reset design assumptions or revisit design. Rather, the project employing them was divided between multiple teams, where there was a risk of design consistency being lost between the teams. The teams undertook these activities (frequently not entire sprints, but a couple of days) to re-sync design across the product. I can see a role for such synchronisation; it sounds reasonable and realistic to do this between teams throughout a large split project, and there are many ways this might be achieved. The "scrum of scrums" pattern seems to assist with this on a technical level, and I wonder if it might be adapted for UX usage by having design representatives from each team meet around planning time to review consistency. I'd be worried if I heard about a single-team project adopting this practice.

A nice talk, and really good to hear about the diverse ways in which design teams are getting their agile on.

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.