XPDay 2009 - Fostering collaboration between developers and UX

I convened an Open Space session at XPDay 2009 on the subject of fostering collaboration between developers and UX in an agile environment. Participants in the session were invited to tell a story about their experiences of working in an environment where software developers and UX professionals worked together to deliver a product. The stories could describe a positive or negative experience, and anything in between. We then pulled out and recorded positive and negative properties from these stories. These properties are recorded here.

None of these stories were thorough experience reports, but they were, to the best of my knowledge truthful and an accurate representation from the perspective of at least one person.

Negatives

Solutioning stories too early

An emerging pattern when integrating UX and Agile development is to have the designers work as part of the customer team to help drive the prioritisation of what gets built. This was a common theme for most of the stories, and seems to work well. However one story highlighted the need to be wary of performing too much design work before passing the user story to developers to implement. The developers in this story started to feel disenfranchised with the solution and unable to make suggestions for changes to the design.

UX is a more volatile resource

Another story told of having UX practitioners working in sprint with developers, only for the UX resource to be frequently pulled out of the sprint to work on other tasks with the customer. This had the effect of obstructing the flow of work as the developers were unable to complete the story without help from the UX practitioner.

BDUF was a source of conflict

This is a more extreme example of a UX team solutioning stories too early. In this case the UX team would produce large amounts of design documentation for each feature to be implemented, and then hand this documentation over to the developers to build. This ended up being a source of conflict between the developers and the UX team as the developers did not want to read through lots of documentation to build the feature. To get round the problem business analysts would 'paraphrase' the documentation to let the developers get on with building the features, which understandably, caused a lot of friction between the various groups involved.

Positives

UX contribute to definition of 'done done'

UX practitioners on the team contributed to the definition of the 'done done' criteria for a story. This means the values and the overall integrity of the experience of the product can be controlled by UX practitioners on the team. In addition, every single person involved in delivering the product is acutely aware of the standards that each and every feature needs to be delivered too.

UX sitting with devs and working in sprint creates a good flow of work

More than one story told of successful working environments when developers and UX practitioners sat together. One story in particular told of a transition from the UX members of the team moving from sitting with the rest of UX people in the company to sitting in the same space as the developers. While this transition was difficult in the short term the team experienced a much improved flow of work as it was easier to coordinate the different tasks that needed to be performed by developers and UX for the completion of a story.

UX working in sprint improves understanding and empathy

Having UX and developers working together throughout a sprint to achieve a common goal gives a real opportunity to gain a deeper understanding, even a level empathy, into the effort that is required to deliver a story from both the perspective of developers and UX practitioners. The specific example given in one story was that, by being involved in the estimation process, UX understood better the amount of developer work required for certain solutions.

Allow developers to collaborate on design without forcing it

We were fortunate enough to have Jeff Patton with us in the session. He relayed the story of an experience report at Agile 2009 Feature Teams - Collaboratively Building Products from READY to DONE. This company moved from a process of designing and planning work separately from the development team to what sounds like a 'by the book' scrum process of performing all activities necessary to define the work, design and deliver the required features within a single sprint. This allowed the developers to be involved in user interaction design as it became just another activity to be worked through on the road to delivering a feature within the sprint. The interesting point for me in this approach is that not everyone had to be involved in the UX work. For example, developers that were happy not to get involved in the solutioning of stories were free to work on repaying technical debt while the solutions for the stories were being worked out. Thus giving the opportunity for design collaboration if the developers wanted to provide input, but without forcing the issue.

Innovation Sprint \ Dream Week \ FedEx Day

Three ideas around the same theme, giving a delivery team more ownership of a solution and improving collaboration and innovation all tumbled out at the end in quick succession. The innovation sprint is something that people at Yahoo were toying with, please correct me if I'm wrong here. Every fifth sprint is an innovation sprint where the team get to decide what to work on. The idea being to try and introduce innovative, potentially risky ideas, that would not normally be prioritised by the product owner. I'm not sure if the result of this work is committed and deployed or if the work is all prototypal in nature to feed future stories? Interestingly the amount of time this takes away from delivering customer features, is 20%, the same amount of time as the Google Innovation Time Off.

Dream week is something that the team I am currently working with has come up with. The idea being that, at the beginning of the week anyone in the team can suggest an idea for something to work on that will add to the value of the product. These ideas are pitched to the product owner who prioritises them to be worked on and delivered within the week. Keeping the time available down to a week increases the focus of the solutions and reduces the risk.

Taking the focus on innovation company wide, another company would hold FedEx days. The idea being that you had to deliver something at the end of the day. The entire company would be arbitrarily grouped into pairs for the day. Each pair had to deliver something of benefit by the end of the day, The pairs can choose their own thing to work on, or can pick ideas out of a hat. The pairings are arbitrary so you can end up with anything from product owners and developers pairing to sales people and UX practitioners pairing. Of course something of benefit may not be software.

Explore many ideas up front

Another suggestion for improving the collaboration between developers and UX practitioners was to follow an approach of exploring more options up front, together as a team, and then focusing in on one option for delivering the solution. I believe this was given as an alternative to gradually iterating towards the solution through frequent delivery.

I would like to express my thanks to everyone who participated in this session. I thoroughly enjoyed hearing all of the stories and your experiences. I was glad to hear of so many positive experiences working on products with heavy UX and development involvement.

A number of the stories come back to what I have been learning over the past couple of years, which is, there seems very little cause for irresolvable conflict between agile developers and UX practitioners and in fact, the solution to many of the problems can be found by taking a step back and reviewing the principles of the agile manifesto and tailoring the implementation of these principles to your own environment and context.

Here are a few of those principles that I see as being particularly relevant to the positive experiences that were reported during the session:

* Business people and developers must work together daily throughout the project.

* Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

* The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Take a moment and have a look at the rest of them.