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

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

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 from 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 were 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.