Agile User Experience: If you have a silo, knock it down

Noel Rappin, Tuesday, January 29, 2008 @ 3:20 pm

In many development processes, team members are organized by functional group. A project might have a team of developers building the code, and then down the hall or across the globe, a separate team of designers working on the visual and usability aspects of the application. The two sub-teams are walled off in their own silos, and communication between the two sides is minimal.

This structure is not compatible with an Agile software process -- it's too hard to get rapid feedback between the teams that make a process truly Agile. Worse, if the two teams are separated, the odds that they will have a common conception of the project, or even a common set of terms for discussing the project.

The most important step in tearing down the silos in your project is just switching your mindset from function-based teams to project-based teams. Continuous integration spreads from being just something the developers do to a way of making sure that all aspects of the project are in synch.

At the most basic logistical point, the designers and developers should share a common code repository. There's a certain amount of overlap in the tools used for web applications on both sides. If designers can see the latest version of the application when making CSS or HTML changes, then developers can see those changes and work with the most current design as quickly as possible.

In order for this structure to work well, each side needs to move out of its silo and toward the other. Developers need to have an awareness of usability and design issues, and be able to discuss potential problems with the designers. Developers also need to be willing to do any rework that will be needed as the design changes.

Designers need to be willing to work at least some of the time in the developer toolkit, working with source control, able to make CSS or HTML changes directly in the code files (even better if the designers and developers can make it easy to make tweaks at the JSP or ERB level). Not everything that a designer does can be captured this way, but using common tools and files where available increases the team's ability to work together. Sharing knowledge makes the team more able to notice potential problems, and makes teams more stable over time.

Last week, I wrote about how a user proxy can help integrate Agile and User Experience Design.

Once again, let me mention the upcoming book Professional Ruby on Rails. Available mid-February.

agile ajax

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   I couldn’t agree more with your views on ensuring that workers in separate areas of a project need to be able to collaborate interactively. My company has designed a framework that facilitates this team collaboration in a distributed fashion from the ground up. The key lies in allowing the creation of implicit workflows that span individuals across different work groups. It allows individuals who may not necessarily have edit or publish permissions to view and comment on change requests between workers in other areas. This allows issues to be identified and eliminated before they become a problem while ensuring total visibility into the running of the process.

   Comment by David SL, Wednesday, March 12, 2008 @ 11:15 am

Leave a comment