Doing UXD with Scrum - an experience report

I recently saw a Tweet from Özlem Yüce (@OzzieYuce) calling out for books or blogs that talk about mixing UXD with Agile and Lean. As I have been doing that from time to time I though I write something down.

The last project I did where UXD was involved was a short device project. We started this in May 2011 and the project ended on June 2012. We spent quite some time in doing market and customer research before setting up the development teams for software for this product program so it was not until fall 2011 we got some UXD people on board. At that time we were doing different alternative designs and some quick prototypes to get material to use in the deep dive interviews and market research we wanted to do with real mockup devices. That gave us the initial vision on the UX for the device and in the beginning of 2012 we got first SW teams set up.

For the UI framework and apps SW setup we decided to use Scrum. We coupled UXD tightly to the SW cycles and as often happens the initial sprints were done without UXD that was to be final. This was the whole point of doing things in Scrum: we start with something, see how it turns out and make informed decisions what if anything to change. 

The team location setup was not ideal. The Development Teams were in Oulu and the UX designers were sitting in Espoo. To reduce risks related to Dev Teams and UXD not being co-located we got into practise to get the UXD team members visit us in Oulu and to do joint Sprint Plannings. After few Sprints in this fashion we converted to having the UXD team join in our planning session via teleconference. This proved to be somewhat suboptimal as the discussion was difficult to follow for those sitting in Espoo and they did not have much to contribute to the overall discussion about User Stories.

After few sprints the UXD had enough of design ready to be handed over to the Development Team. The team took the designs and tried to realize it with SW during a sprint. Quite often the SW turned out to be not as expected as the written specifications left quite much things open and then we had to rework the software in the next sprints. In effect, we were doing somewhat mini-waterfallish Sprints. It was pretty clear to me that this was due to lack of common understanding of what the details of the UXD was and how it was fitting together in the big picture.

Clearly this was not working as Scrum should. The things were not getting done. To help the situation I tried to pull the UXD team to work in concert with Dev Team in Oulu. This was unfortunately not possible. We thought of using Skype or some other personal video conferencing system. Those were not working for a reason or another. Then I decided to bluntly go against the rules and started booking our expensive but awesome tele presense system so that we could get all of UXD people and relevant Dev Team members to discuss open things and keep their common understanding better in sync. You may think that Skype would work just as well but there is not really any comparison. The telepresense system is a studio with negotiating table and four huge flat screen TV:s where the other side of the "table" is visible in natural size not to mention live-like sound quality. You just can't get this with a webcam and a headset. Using this system helped a lot. The designs could be discussed, things in progress could be demonstrated on live devices via the table camera and solutions to design challenges were quickly discovered. We tried to have at least 1 hour slot reserved for this each day. We set it up in a open space manner. Time was communicated to all and people could just walk in and see who was there and increase their understanding what was happening at the time in both locations.

In general the UXD and Dev teams were happy. UXD was particularly happy about the fact that they had very early live devices that had always working software available to review the software and communicate their views back to SW devs each day. Although some of the UXD was designed before the actual Sprint where it was to be realised this kind of daily opportunity was the key element for success. I dare to call this a success despite this could have been going even better if the working culture of the UXD team would have allowed for "unfinished" or "unpolished" designs to be floating around for Dev Team to pull in and do working software that was in the end the only measure of success.

We managed to deliver quite polished looking software for the consumer studies that were done with real devices. I am very proud to say that the software was also fully functional and well performing on the actual devices. It was so well functioning that the customers we showed the device to never suspected that it was just a "prototype" with minimal functionality. Not really a prototype but an increment of working software that was planned to be iterated upon several Sprints more. In the end that was not to happen. Stephen killed this product along with some others in June 2012 and that had career impact to me and many of my colleagues.


I will return to this topic "How to do UXD in Lean/Agile way" in the future.