Christian Manzella Rotating Header Image

Agile UX: Consider Seating

With the idea behind Agile being that interactions and individuals are paramount, everyone involved needs to buy in.  Without complete participation from the team, the concepts behind true Agile are lost.  There’s an approach to bringing the right individuals together that’s so simple, it can easily be missed.  And with this approach, there’s greater opportunity for defining a holistic user experience, defined and committed to by the entire team. Seating.

Where people sit… someone inevitably brings it up any time Agile is considered, but rarely is it seen through.  Organizations quickly see to creating cross-discipline teams and putting them in a room together, at least part-time.  Or they create a space for the team to meet on a regular basis that the team “owns.”  It’s their room, their table, their walls for post-its and ideation.  This has value, of course, but it only brings the team part of the way there.

Moving to a more flexible development system allows you to break free of the restrictions inherent to classic methods.  By extension it can also let you break free of long-held organization principles.  Putting together a cross-discipline team, made up of the people that will be working on a given project, is an important first step.  It also establishes the natural order that occurs in the project.  There is and will always be a natural, sequential progression to how anything developed by a team is created.

Special attention should be paid to that progression.  That progression represents the ideal way the team should sit with each other.  This allows those that need to work most closely together to do so, by seating them next to each other.

As an example, assume that my (incredibly simple and not real) process was to have a user experience strategist design a strategy, to hand it off to an information architect, to hand it off to a graphic designer and a content strategist, to a business analyst, to a web developer, to a database administrator, to a programmer, all with project manager oversight, who coordinates back with the user experience strategist on the appropriate approach to the project.  My process (Not intended to represent any actual process. Seriously.) might look like this:

 

I would expect people in the “steps” to work closely with those in roles that occur naturally as a tangent to them, before and after, and even at the same time as them.  I can identify based on my team’s needs and experiences who will need to work the most with each other.  This isn’t about popularity, or who gets along best with who.  No one should care about where they’re most comfortable sitting.  Identifying that the UXS is going to work a great deal with the IA, I want them sitting next to each other.  Knowing that the IA is going to work a great deal with the CS, I want them sitting next to each other.  The CS next to the GD, and so on.  My seating arrangement, around a large table, might look something like this, based on those I determined work most closely together:

When changes between iterations are identified and start, they can happen anywhere.  That’s another big part of the point of Agile; change. It’s best to not play musical chairs and have to set up meetings when they do start.  If the changes surround a design change because the copy is too large for the space allotted, the above seating allows the IA, the GD and the CS to quickly pull up and discuss the challenge.  Similarly,  the WD has easy access to the BA for any requirements verification, and the Programmer and WD are set up to be able to work hand-in-hand as they develop the interactions, together that correlate to the data set worked out by the DBA.

More importantly, the close proximity of team members to each other allow them to work together, during the planning and defining stages, to create a unified vision for the user experience.  Every person on the team has an equal opportunity to participate in defining the user experience, according to their role.  With everyone having a voice, and a part, the initial definition of the experience, and all the permutations that occur, are the result of an entire team working toward the best possible outcome.

The seating, like all things Agile, has to be defined by the organization, the team, and the projects at hand.  It may even vary from team to team within a given organization, based on how each of those teams best operate.  That’s okay.  It’s part of the point.  Each team has to make sense of what they do, and sit accordingly.  The key is to make sure you are actually taking advantage of what’s going to make working together more efficient.  Make sure your choices can be justified based on who you work with.

There is, of course, some sacrifice of “personal space” and “privacy” by people on the team. However, if your organization is flexible enough to acknowledge the merits of Agile and unorthodox seating as steps towards improved software, other policies can be adopted to allow people their sense of space.  Allow spaces for reflection or quiet/solitude time to work on intense personal tasks in places with scenic views.  Or set up smaller, working rooms, designed for one or two people to be in.  Let people work for an hour or two at the local coffee shop.  As long as no one falls into an abusive pattern or uses a space as a way to be apart from the team, this will work out really well.

While the greatest value for a project is collaborating with the other roles in your development iterations, it’s important to not lose sight of the value in working with others within your discipline as well.  If you work with an organization large enough to have multiple teams, it’s important for the common roles on those teams to meet on a regular basis.  This allows all of the Information Architects to share patterns.  It allows the Visual Designers to come up with common styles.  It allows the Programmers to continue working from a common class library.  And we tend to learn from and teach those who do what we do most often.

Agile can get messy and it’s easy to fall into the chaos that unchecked Agile can become.  Use research; you’re not the first to do “it,” whatever “it” is.  Gather data and make judgments. Rely on your ability to think. Every team will find the right level of organization to support their needs and their project’s needs.  Sitting with the people that you will interact with the most helps cut down on some of that chaos and establishes some order from which you can work more efficiently.

Comments are closed.