Last night I talked a little bit about how the UX and engineering teams work together on Visual Studio Code (our newly released cross platform, lightweight editor - https://code.visualstudio.com/). We follow an Agile process and I was asked afterwards if I could write a little bit more about this as finding a good way to get UX integrated into an Agile process can be a challenge.

I don’t think that we have reached nirvana yet but on the whole, what we do at the moment seems to work. To explain what we do now, it might help to describe what we tried to do in the past and how that failed. It might also help to understand that our team is distributed geographically between Redmond (USA), Edinburgh (Scotland) and Zurich (Switzerland).

Back when we started working on Visual Studio Online Monaco (our browser based editor which was the precursor to Visual Studio Code) we initially thought that it would not be possible for the UX team to design an experience in the same sprint that the engineering team would implement it. It wasn’t that we had tried this and found that it didn’t work, it just seemed obvious to us that it couldn’t work. How wrong we were…

Anyway, to begin with, we thought that the best thing to do would be for the UX team to work on a design in one sprint and then have the engineering team implement that design in the next sprint. That way we would have enough time to work through most of the design issues so that the engineering team had something solid to implement.

We were very conscious of not simply ‘throwing stuff over the wall’ once our design was complete. So we made sure that we interacted regularly with the engineering team while working on our designs. We would meet at least once a week and share what we were working on and listen to feedback.

Then once our design was complete at the end of the sprint we would meet and present our designs to the engineering team.

And then our designs would get ripped apart. We would hear lots of valid and well reasoned objections - “Have you thought about this?”, “This won’t work, it can’t be done”, “That doesn’t seem like the best way to do this” etc. It ended up feeling like we had to defend our designs from attack, rather than sharing them. We were on the defensive and indeed, before some of these presentations, we would even discuss what the main objections might be and how we should respond. This didn’t feel like we were one team, working together.

It wasn’t that the objections were unreasonable. In fact, they were more than often really good objections that helped us improve our designs. But because they meant that the designs needed reworked, that meant we had to spend the next sprint on the next iteration of the designs and the engineering team would spent the next sprint on something else, rather than implementing our original design. And at the end of the next sprint, we would repeat the process.

It wasn’t fun and we weren’t making anywhere near as much progress as we wanted so we had to change how we worked.

Why did it take until the end of the sprint when the design was complete to hear the detailed feedback from the engineering team? The problem was that while UX and engineering were working on different things during the same sprint, each time we met to discuss what we were working on, the discussions were superficial at best. We were each focused on different objectives. It was only when the engineering team and UX team were focused on the same objectives (implementing this design) that we had a richer and more meaningful conversation about the design. But this happened at the end of the sprint. How could we make sure that these conversations happened during the sprint?

What we had been doing was what is euphemistically called a ‘staggered sprint’. It’s really waterfall in disguise I think. We were kidding ourselves thinking we were being agile. We had to instead think about ways we could build a team focused on delivering the same outcome in each sprint. We had to face our fears and see if we could design and implement an experience in one sprint.

As we learned, key to making this work is carefully defining what we are going to do in one sprint. It’s all about small batch sizes. We had to be careful about scoping what could be done in the time we had. We were constrained both by what could be implemented and what we could design. But whereas before these had seemed like constraints that would needlessly hold us back, it turned out that they actually helped us. We were able to focus on tight, well defined outcomes. UX and engineering were very clear on the desired outcomes we wanted to achieve. We didn’t have to try to design everything before we could start implementing anything. We could start small and grow from there.

At the start of the sprint, we have our planning meeting where the whole team discusses and reaches agreement on what we are going to work on in this sprint. Then we get working.

For the stories that UX and engineering will work together on, we discuss what we are going to build. We talk about the customer problems that we want to solve (often these have been identified in previous UX studies and other forms of feedback that we have received) and different ways we might solve these problems. We might walk through some quick rough mockups that UX has created or some quick prototypes that the engineering team has. From these discussions we generate a list of action items that we need to do – UX needs to detail out some aspect of the design for example, while engineering might need to build some back end service that the experience depends upon.

We meet frequently during the sprint and discuss progress. Since we are all focused on the same outcome, we have rich conversations about what we are doing. We learn quickly about what is technically feasible and why it is important that the experience be designed this way. We work together as a team because we are focused on the same outcome.

This way of working is a lot more fun than how we began. We don’t get defensive, we don’t have a ‘them and us’ situation – it’s not UX against engineering. We are all working together on the same team.

One of the challenges though is keeping an eye on the bigger picture, making sure that all of these little steps we take in each sprint are driving towards an overall vision of the product and the experience we want to build. We aren’t completely there yet but we are making use of Lean Customer Development to increase our understanding of the customer, the problems they have and the outcomes that we think our product will deliver. As we develop our skills in this area, we think that we will be able to use this to better shape the direction of the product so that the small steps we take in each sprint lead to a great end to end experience across the whole product.

You'll have to sign an NDA to participate as the prototypes are confidential.  It's a great opportunity not only for an early look at some ideas we have, but more importantly for an opportunity to significantly influence the direction we take.

Please let me know if you are interested in participating and I will arrange a suitable time with you.

Windows 8 For Application Developers

Tuesday, May 1st 2012, 9.00 - 17.30

In this event, we’ll deliver developer-level, demo-driven sessions that give you an accelerated entry into what it means to design, develop and publish exciting, modern, polished, world-ready applications for next-generation devices running Windows 8.

https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&EventID=1032507164&amp%3bculture=en-GB

Visual Studio 11 Application Lifecycle Management:

Wed,13^th Jun  2012  9:00-13:00

Microsoft UK invites you to join us at the Microsoft Offices in Edinburgh for an overview of the  Application Lifecycle Management capabilities of Visual Studio 11 Beta and  Team Foundation Server 11 Beta. This session will demonstrate a slice through an agile iteration starting from our product backlog through development,  testing and release.

https://www.microsoft.com/visualstudio/en-gb/visual-studio-events 

Did I mention it's free? You even get a special free pass for an Azure subscription that will let you do the training even if you don't already have an Azure account.

It's free training, with a free Azure subscription. Can't get better than that.

Start watching around 27:21 if you want to jump quickly to the preview tab and solution explorer stuff. It's an entertaining and incredibly informative talk all the way from start to end though so you might want to watch all of it.

I work on the user experience design for the preview tab and solution explorer and would really love to hear your feedback about this experience.

You can even play around with this yourself. Go to https://www.microsoft.com/download/en/details.aspx?id=27543 to download and install the Visual Studio 11 Developer Preview. You'll then be able to use the preview tab and new solution explorer.

There are some more details about the prevew tab in this post: https://blogs.msdn.com/b/visualstudio/archive/2011/10/07/improving-developer-productivity-with-visual-studio-11-developer-preview.aspx

https://www.neverworkintheory.org/

Anyway, this all came to mind when I saw this today: https://www.classnamer.com/. It made me laugh.