Sophie Freiermuth(@wickedgeekie)) from Baguette UX gave tonight’s talk on how lessons learnt from operating as a UXer within an agile environment. I thought it was a great talk. When at Mendeley we always faced the problem of trying to square the challenge to fitting an inherently creative process into the systems that emerged while we attempted to adopt agile processes, in my time there we learnt a lot, we had some success and some areas where we obviously needed to learn more, so I was delighted to hear a very thoughtful presentation from the perspective of someone who it seems has worked with quite a few teams implementing agile in a variety of flavours.

My notes below are pretty much a transcript typed out while listening, but as usual, any inaccuracies and typos are mine.

Agile

Remember that Agile remains a manifesto - it was created by developers and is aimed at solving problems that developers have in attempting to build products.

The agile manifesto is now over 11 years old, over that time it’s been adopted by teams of all sizes worldwide.

At Agile 2013 - the recent agile conference - there were lots of stories about agile at companies of all sizes.

Nokia and Spotify are two of the bigger companies that have adopted it, and Sophie talked quite a bit about Spotify’s experience. Spotify say that for them agile is still a work on progress.

One of their big secrets is that the spaces need to be managed to enable collaboration. They have built the 3-wall rooms. The 3 walls allow enough space to pin up work, but the 3rd wall makes the work visible to people outside of those rooms, and also the work in action visible. Each space has enough room for people to co-share, to have meetings, and to collaborate.

They need a large space - they needed more room to allow people to collaborate, and move around. (need more space than is usually assigned by facilities). Line management bought in, but the big blocker was getting facilities management to agree to the space requirements.

Points that worked in this setup - needs to be flexible - self sufficient - 3 walls only - mix of desks and meeting spaces - self organised, a team of up to 12 people.

Spotify have been experimenting with team size, there is a magic number of about 12 people. 12 includes all the people that are needed to get the work done - design - front end - ux - qa - Product Owner. When a team gets to larger than 12 they break the team up, and split the work streams. The team needs to have all of the skills required. Every team is responsible for how they work, there is no company-wide process. They are allowing teams to self-organise around how they manage their work.

They are trying to allow functions across the teams to get together in structures they call guilds, to share function specific know-how.

The PO’s job is to ensure that the right jobs get into the room (Many problems just should never enter the dev room, and should be answered in other locations). The PO has this responsibility. Some POs don’t want to know how the team tackles problems, some POs are interested - each team is finding it’s own way.

Another interesting thing is the role of the agile coach. In one instance mentioned the agile coach helped the business feel that there was oversight, however some people in the agile community think that coaches can disrupt the natural learning cycle of a team can be disrupted. In the story presented here having an agile coach helped the presenter. We used a couple of agile coaches at Mendeley, and my experience was generally positive, but I was standing on the pointy hair’d side of the desk, so I had some sense that I was bringing control to a situation. Some of the people who did some of the coaching liked it, and some didn’t.

How has agile worked for this UX person?

Sitting with a dev team can be invaluable, seeing the thing being built as it goes along is invaluable. It also helps to ensure that the quality stays in place, conversations can happen about shortcuts before they get backed into the product, and optimal decisions can be taken, rather than being laboured with decisions that have taken place on the fly.

The walls are an amazing resource. Placing the user journey on the walls as a print out, next to the stories can really help the developers. Developers can also comment on the user flows when they see that there might be a technical issue. By doing the work on the board, and making the process apparent, this leads to collaboration, and to reaching a solution faster, it also brings confidence to the team that UX can bring a lot of value. (Sophie mentioned in the Q&A that where she had drawn a user journey on the whiteboard, when explaining it to other people she would erase it and re-draw it. By making them a participant in the bringing out of the journey onto the whiteboard they got it a lot faster, and could often ask critical questions that she might have overlooked, she described this as something like “sharing the deliverable” rather than “arriving with the deliverable”).

When a UX person is placed with a dev team, often the UX person will have invested in the idea that the developers know what they are doing, however the developers often don’t have trust yet in the UX person. That person has to prove value.

The UX/Design/Copy team - how this fits into the sprint cycle has not been cracked. Smaller tasks can be easier to fit in within a sprint cycle, however you need to be clear on the work that needs to be done, what the request means - e.g. we need to improve conversions - is not often clear - is it page speed, does the flow need to be improved - is there a code issue, does some user research need to be done?

Tools

Taking tools from agile can be very helpful, for example using Kanban to display where a bottleneck might occur, even when the work is flowing through one person. (At Mendeley we discovered that our bottleneck was not in UX, where we had thought it was, but rather downstream from UX in the front end development side of the product).

Another big tip is lower the definition.

You can say that you need to release > test > iterate within the UX cycle. Give a definition of done. Done is easy to say, but impossible to define within UX. What is the definition of done within UX - a sketch - a full spec? Try and find the lowest definition of done as possible, it’s a win for everyone, as long as the developer can work with it, and you don’t lose information. This will serve the team better, to make this work you need to be sure you are collaborating, you need to have trust with the team, you can’t start with scribbles from day one - but you can get there.

Lean

The lean manufacturing process defined by Taiichi Ohno has a lot of value. You eliminate waste, you empower people, and you introduce Kanban. The more you adopt the thinking that one thing can only be in one place at one time. Agile is not faster, but it does show pieces of the solution earlier. The overall time spent may not be less than the waterfall process, but you will see parts of the solution earlier - (In my opinion you should in theory be able to reduce waste, and make invisible work more visible). Lean is human first, it’s about people.

Firefighting

Often the dev team is going full speed ahead - surfacing problems that were not identified earlier. If you drop into a team, you won’t be able to just shout “STOP”. The best way to firefight is to know the technology as much as possible - have accurate technical knowledge. Agile is all about people people people. Empower people, make them feel successful, make them feel valued. UX people naturally tend towards being empathetic, so people relations should work well for them. Define what success looks like. Often the question of what success looks like surprises the stakeholders. If you can get this question out, you can get the steak-holders to commit to what the success should look like. Be Michael Schumacher. This is not about being the fastest, but about cutting the right corners in the right way - e.g. can you get away with a low fidelity sketch, can you get away with shorter stand-ups in the morning? It’s not about making time to squeeze more work in, but rather making the time you have count, and making sure you have a life.

Side competencies and Agile

Refuse the absurd (or at least point it out) - when you see these issues crop up in user stories. Make sure the stories have a target, a requirement for success. Every team is unique. There is no generalisation, everyone is trying to make agile work. No one has fully cracked it, but it seems to work. Every case is different. Agile is for people who can deal with constant change, with people who like experimenting. This is a method of working that suites outgoing people. Apply top skills first, and refine later - reach wide, try and solve problems where you can, then refine later. You need to learn the value of getting things done, rather than getting things perfect. In agile teams there is the rise of the unicorns. A UX who is a developer, a great copy writer - these people do not exist. It’s OK not to have unicorns on the team. Fight the battle with the troops you have, not the troops you wish you had.

What is the future of agile?

Agile has guardians! The people who designed the agile manifesto are still out there, still communicating. There are lots of flavours, we have had scrum, lean, XP … there will be something coming along next. One big problem with agile is when will something be done, what will the stakeholders get. In agencies it is really difficult. When you go agile you need to work with a client who understands this. Each team has it’s own process. Are we all in harmony towards a common goal? Is agile the promised land? This still needs to be cracked. Could there be a riot of fed-up UXers brandishing sharpies and stickies? Yes! UX and design cannot sit perfectly in harmony, but agile is going to stick around, and the future will be interesting.

Remember that agile was developed by developers, take the spirit, but don’t take it as a cookie cutter approach.

Great talk!