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.