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.

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.