November 21
Great Design and Agile Development
I was recently part of an internal panel here at Microsoft where we talked about the creation of user experiences for
Agile development processes. We had some great discussions going, and I had a lot of fun having some public debates with various people. I'm not one to shy away from vigorous conversations - in fact, I kind of enjoy them. My wife thinks I should do something with that, like get a law degree or something. But I digress.
Here's my standpoint on Agile. I don't believe that Agile methods enable teams of people to produce world-class design for most types of software development projects, and that the various methods can't successfully scale very well to large ones. If you've got a product that is already well-defined in terms of branding, design principles, customers/users, and vision, Agile may work for you. However, I would argue that having all of those would already put you ahead no matter what process or methodology you use.
There's an assumption with Agile that a programmer's time is worth more than anyone else's. It does everything it can to reduce coding down time. Unfortunately this puts a tremendous amount of pressure on designers, program managers, testers, and everyone else in a multi-disciplinary team to scale up. In the case of user experience people, a friend on mine whose judgment I highly respect estimated that it would take about 2x to 2.5x the number of user experience resources to adjust successfully to Agile. This guy's a UX director at one of the world's largest software companies, and he's been around the industry for much longer than I have, and he's just an all-around smart, well-read guy. He's not one to exaggerate. One reason for this estimate is that many UX activities can be done serially, so a fewer number of people can do them and they roll from one thing to another. With Agile, you would need to do many of the same things in parallel, so you would need more people to do them.
Another person who is quite well-known in UX circles told me that UX folks can be successful by adjusting. He's had success with doing shorter, more targeted UX activities that could fit within the month-long Agile period. I don't disagree you could do some things well in this way. In some cases the reduced timeline could provide some necessary pressure to find efficiencies in a team's process. However I don't believe that you can be strategic when all you can do is think in one month cycles, especially if you're starting something big and brand new that requires a high level of design to be successful. Yes, you can be nimble and find ways around the problem. It's still a problem.
A number of people told me that Agile would help or has helped their teams overcome issues that they've had, like executive management not being in touch, devs not talking to PMs, testers being out of synch, etc. What that tells me, however, is that the team has a fundamental problem with their team culture, and without addressing that the team is doomed to fail. Now if a process can help the team change its culture, great. But simply following a process for process' sake isn't a recipe for success. Don't confuse culture with process.
At the end of the day, a team needs to have a culture that is design-led if they truly want to deliver world-class user experiences and products. I don't believe that Agile is a tool best suited to this task.
A friend of mine made this analogy. Communism, in theory, is good too. See how well that worked out. ;-)
Tools 
