How does a project leader balance the needs of delivering software projects on time with a commitment to customer satisfaction? Chris Chandler, senior director of product experience, UX and Innovation team leader for Fandango, and formerly of Walt Disney Company’s Parks and Resorts Online (WDC), discusses how he changed his way of working to successfully manage a team of thirty staff responsible for delivering digital assets to globally distributed scrum teams.

How did you come to agile development in your work as a UX designer and developer?

I was introduced to the concept of Agile at a conference in 2003, but I didn’t start seriously incorporating into my UX practice until 2009, when I was working at Disney. The tech team transitioned to Scrum, and almost right away I noticed that the quality and timeliness of their delivery improved. It took several years of conversation with peers to understand how the same principles of the agile manifesto applied to design in general and UX design in particular.

How did you come to realize that agile development would help you work globally?

I think the first aspect is the core of most agile methodologies — timeboxed iterations (i.e., set “sprints”) with working code delivered at the end of each iteration. Coming together in short intervals to see actual working software to judge your pace and what you’re going to do next is crucial.

The related concepts of test-driven development, continuous deployment, and automated testing are also very important pieces. These practices help ensure that teams can concentrate on delivering value and containing the risk of defects and unrecognized dependencies from slipping through.

What problems were you trying to solve with the agile development process?

First, it’s important to recognize that high-quality software can be created using any number of methodological approaches. Too often “agile” is offered as some kind of panacea, which it is not.

The biggest problem in a typical waterfall-style project is managing change, because changes force work back upstream: A change to the design means updates to the requirements, which then flows down and changes pieces that may have already been built. To be successful in a waterfall process, you have to commit to your decision points, and manage any change hard — typically with formal change-control processes and the like. The need for such tight oversight can be a real drag on efficiency, but you have to do it to ensure quality.

Most agile methods take a quite opposite approach. They concentrate on adding value and worry less about the final delivery date. It’s easier to incorporate change if you only work in small increments. If something becomes critical, or conditions change, you can literally turn quickly to address that new priority. The solution you come up with may look very different than what someone would have spec’d at the beginning of the project, and that is actually expected and embraced.

What transformation did you go through as a team lead and designer during this process?

The biggest change, and it’s a doozy, is to learn to pare back to essential values and work on the thinnest slice of functionality you can.

So, for example, in UX, instead of spending a lot of time trying to identify all the screens and fit them into a system that might be captured in a site map, you have to quickly decide what the most valuable and critical portion is and work on getting a small vertical slice of functionality launched quickly. This can feel very uncomfortable compared to how people are used to working.

Did you have any resistance to the agile process (especially working globally), and how did that change over time?

Giving up on being able to solve everything before you begin created a lot of resistance to the concept of being agile, and I think you see that in many ways this is still a controversial topic in the world of design today.

The biggest issue with working globally is trying to figure out how to maximize the autonomy of the teams. To be most effective, software teams need to have access to all the resources across any discipline. They need to be able to optimize a series of small, local problems. Having to wait for clarifications or decisions is an absolute killer of team velocity, but even more [a killer] of team autonomy and ownership of the work product.

Can you walk us through what your design processes and delivery were like “on the ground”? What challenges did you encounter?

Most of the time we work in a method known as “two-track agile” where we have a design squad that works a sprint or two ahead of a development squad. This has proven to be superior to our previous big-design-up-front method, but it still causes lots of coordination and handoff issues.

It is my much-preferred method, because in some cases, I’ve been able to embed design resources directly into the teams doing the work. UX Designers spend less time dreaming up solutions in a vacuum and updating documentation based on feedback given during reviews. They can concentrate on collaborating with the people writing the code as it is written.

What advice do you have for other project managers and leads who are implementing agile processes for a globally distributed environment?

I think the most important thing to concentrate on with distributed teams is communication and transparency. I think you have to expect that the transition will be slow and that progress will be gradual. So you really want to focus on creating an environment of trust. It’s super important that people are allowed to struggle and not be perfect at things, and that they feel they can freely share those challenges.