Beauty Is in the Eye of the Beholder
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.

Posted by Deborah Hartmann Preuss on Jul 24, 2007
Many think that Agile teams all work in “common rooms", but the truth is not so simple. We forget that the classic XP teamroom layout was called “caves and commons” and it explicitly recommended that people have access to some personal space, as well. Teams find out fast enough that some of the facilities and creature comforts left behind in our former traditional spaces were there for good reasons. When working with Agile, working close together and without interruption, it's more important than ever to affirm the needs of human beings for healthy and effective workspaces. To that end, this article shares the collected wisdom of dozens of teams, as collected by several experienced Agile coaches.
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Over time, traditional software teams can become oblivious to the time they dedicate to activities like making meeting invitations, reviewing email, looking for meeting rooms, and waiting for stragglers to finally arrive. These are the necessary evils of teamwork in large organizations. However as teams move toward a fully Agile approach, these inconveniences are raised to the level of major obstacles:
You don’t want to have to wait to find a meeting room that’s available in order to get some modeling done. You don’t want to have to worry about somebody erasing your whiteboards, or throwing your index cards in the garbage. I’ve worked in several companies where there was a severe shortage of space, where we would have to wait for days to find meeting rooms. Progress ground to a halt.
-- Scott Ambler [1]
The classic solution, and a key strategy to support and foster Agility, is co-location. The “osmotic communication” which buys Agile teams immediate feedback within the team relies on team members working within the same visual and auditory space.
The idea of teams working in an entirely new type of space often comes as a shock to the organization. But while some teams have trouble getting management to replace cubicles with tables and whiteboards, other teams suffer equally when eager (or scheming) managers remove not only cubicle walls but also other facilities long deemed important to team morale and function. This may be done innocently, not realizing what is lost; or with an eye to reclaiming space in a congested building, a sacrifice demanded of the team in exchange for the open space they need.
It's important to look around before eliminating an existing space. We can become so used to our surroundings that we no longer notice what's really going on. Take the time to notice how things work: where are people going when they are not at their desks? Not every absence is for a meeting. People run errands, take walks, confer with other departments, and reappear with drinks, markers, printouts, and new facts. Think of the entire calendar year if your location has changing weather: team members will bring their coats, gym bags, umbrellas and motorcycle helmets in with them.
Determine how much space each person really needs: both at their workstation and elsewhere in their team space. A single person's workspace, for example, probably shouldn't be less than 25 square feet. This calculation is especially important when two are pairing at a single workstation, where it's tempting to "save space", but people still each need their own space and teamwork will suffer if it's not provided, as people inevitably get on each others' nerves. In general, a collaborative team space accomodates no more than half the number people it would if arranged as a conference room.
As teams move to a collaborative style, consider the activities they'll need to handle in their spaces. People will still need to handle sensitive, or personal, phone calls and emails. New collaborative tools like flip charts, whiteboards, bulletin boards and projection screens require extra planning to remain unobstructed and useable. And when many people and computers share a single space, ventilation becomes more important than ever.
It's important that, at the beginning, someone be tasked with watching for and following up on infrastructure problems. This seems simple, but the team is sometimes so engrossed in learning new practices and working in unaccustomed ways that they neglect such details, not realizing that these are in fact contributing to their difficulties.
Common problems can be as simple as putting a programmer at risk for back pain or tendonitis by using a keyboard at the wrong height, easily resolved with an under-table keyboard tray. Some team members strain their eyes against window glare on their monitor – again, easily fixed by moving a workstation or providing filters on windows or screens. People will, at first, sacrifice their lunch hour to make important personal calls. As the team progresses and their work achieves a regular rhythm, these accomodations become inadequate and grate on the nerves.
Team self organization also means that food and drink are likely to appear in the workplace – by way of celebration or to facilitate collaboration at key moments. Over time candy tends to be replace with fruit and other healthy snacks that take up space. A cramped workplace that makes this awkward hampers the flow of teamwork and team building – a little extra table space is a simple device to foster team creativity.
Obstacle removal is a key function of the team coach, ScrumMaster, or PM. Obstacles related to the team space should be prioritized near the top of the team's obstacle list, and should be resolved early on. While it may be tough to quantify the impact of inappropriate working conditions, again and again we've seen significant increases in teamwork, and hence effectiveness, once these obstacles are resolved.
After so many years of using professionally designed work spaces, teams sometimes “throw out the baby with the bathwater” when they start over from scratch with their own designs. Elements like light, air, traffic flow, noise, refreshments and comfort are not negligible: high productivity teams still consist of people, not robots, and these hard working people can be enabled or discouraged by the spaces in which they work. It's true that motivated teams have been known to work in the weirdest, most disadvantaged locations. However, when a team commits to increasing their delivery of business value using Agile methods, it is appropriate for them to ask management to support the needs of their new collaborative work style appropriately.
Here is some advice on creating spaces that work, from coaches who have seen many and varied team spaces, in both successful and unsuccessful arrangements.
Mishkin Bertieg has blogged about 8 important areas to consider when creating a healthy and effective work space. While some of these may seem obvious, we've seen them compromised again and again.
Agile teams use a variety of methods to increase collaboration. A common one is the move away from formal intermediate documentation. This approach is worth planning for explicitly: when replacing heavy documents with models on whiteboards and other information radiators, teams suddenly discover the needs for lots of wall space, for example, or for different electronic aids.
Scott Ambler has written in depth about specific factors teams should consider if they are moving toward Agile Modeling. Here are some key points from his more detailed article:
Over time, organizations with many teams may want to formulate a list for the "ideal" team room, to help facilities staff in creating more team spaces. Resist the temptation to tightly define this: constraints and team needs will be different each time, and you must leave room for creativity. Any formula you create should focus on the goals, the needs to be met, not the means.
Here is list compiled by Joseph Little with a team of coaches for a particular organization, based on lessons learned after a dozen teams had struggled to create suitable spaces with varying degrees of success. This is specific to the needs of a given business: with its own hardware, teleworking, and space constraints. What's really important when reading this list is the human considerations, not the specific details.
Note the phrasing: it's intended as a basis for discussion, not a ransom note. And it is critically important to allow teams to participate in the design of their own spaces, which will naturally lead to new ideas and uniquely customized spaces. This last pointer is all too often skipped over in the name of "efficiency", so it's worth restating. Involve team members in the design of their own space, to eliminate obvious stumbling blocks that will hamper their work in early iterations. The gains in morale and productivity outweigh the cost of their involvement.
Here is Joe's list:
Our Agile Team Room Wishlist
Note that there are other ways of accomplishing the underlying goals; we can pursue other alternatives if we cannot have these ideal conditions.
Prepared by Joe Little of Kittyhawk Consulting [3], with ideas contributed by many (you know who you are).
- Room size: In one successful case, we had 9 monitors/docking stations (for laptops) set up in a room with a “maximum occupancy” of 20 people. The room is rather large and gives space for people to “live” together for an extended period. This seems about right and comfortable for a team that is almost 100% dedicated (ie, in the room most of the day).
- Team Privacy: privacy from, say, hall traffic. Constant outside noise distracts and stresses the team; this also suggests that team conversations are carrying outside the team room, not a good idea.
- Individual Privacy: Ensure there is a place to make personal phone calls or do sensitive work (ex: filing a health claim or writing a performance review).
- Light, Ventilation: the needs for these are much greater when the Team is in the room all the time.
- Fans: Teams want these for when the A/C goes out, which has happened again recently.
- Creative Space: This is hard one to describe, but important. At a minimum, the space should not be dull and depressing. Ideally the colors and other aspects should support creativity.
- Docking Stations: The docking stations add value, but also take up room. They need to work with all, not just some, of the team's laptops, and must have network connectivity. Think through exactly what the new team will need in advance.
- For teams using pair programming: we recommend large (23 inch) flatscreen monitors, connected to the docking stations.
- White Boards: The room should be covered with whiteboards. Magnetic whiteboards are expensive, but quite key. Obviously whiteboards require markers and erasers.
- Need at least 300 tiny multi-colored magnets.
- Flip Charts and stand: preferably with large “post-it note” paper, and space in the room for it.
- Polycom speaker phone: maybe two (if a large room).
- Land lines: several phones to allow people to make and receive phone calls, with speaker phone capability.
- Placement of phones should be balanced: at least two of the phones should be placed on the center table, others at the “edges” of the people space.
- Cards: Start with 400 cards in multiple colors. (25% should be 4x6”, the rest 3x5”)
- Outlets: We need network access (via the docking stations), outlets for land lines, and. electrical outlets.
- Remember that people will move around, we need more outlets than people.
- There are cheap ways to protect the team from tripping on cords running to a central table.
- Tables: A mixture of small and large tables (or small tables that can easily be put together). Usually arranged as one big table (for 6-8 people) in the middle, and several small tables around. One small round table, for small adhoc meetings of 2-3 people.
- Large Wall Clock: so all can see when the stand-up will start or when meetings will reconvene.
- Wireless Internet: so visitors from other departments can connect.
- Printer: A good laser printer should be in the room, or very close, including paper up to 11x17.
- Small Conference Rooms: either: (a) a quiet space within the Team room for conferences (eg, provide more space or one adjacent with low walls) – this works if it is a very large room compared to team size, or (b) two small conference rooms very nearby that are dedicated to the team.
- Place to hang coats and leave outer footwear (in winter).
- Space for storage of personal stuff.: could be under-desk filing cabinets or a large horizontal filing cabinet.
- More of this is necessary with contractors or other “mobile” team members who have nowhere else to put their things.
- Desktop PC: that can be used for miscellaneous purposes (developer testing, integration of code, etc).
- Calendars: a few big calendars (monthly views) that can be written on.
- Digital Camera: saves lots on documentation time. Can be shared with another near-by team. Must be easy to download pictures to the laptop.
- Small Fridge – A small refrigerator in the room (or nearby) where cold water and soda is stored.
Hopefully managers, team members and other leaders will collaborate to create the best team space they can, given their resources and perceived constraints. Of course, a month in the new space is sure to reveal surprises and errors in judgement. Don't forget to apply the "Retrospective Prime Directive" when looking back on what you've created: everyone did the best they could at the time. Continue to consider your workspace when each retrospective asks: "what should we change?" When you discover a better way, act on it quickly, and don't forget to celebrate your successful changes when the retrospective asks "what worked well?".
Remember that you don't need to imagine everything up front - you can tweak it with each iteration. But big, immovable and expensive items are definitely worth considering up-front to allow lead time - too often we see teams ready to go long before their workspace is.
Be aware that what you learn might just include: "we can't do this here". Be realistic, and be prepared to defend what your team really needs to reach high productivity. If you can't get it, you may need to design a hybrid, semi-Agile process - but be sure to make it known that the full gains of Agility probably won't be achieved.
It's just not worth it to have a high-performance team hampered by a poor workstation setup.
-- Mishkin Berteig [2]
I’ve seen lack of basic resources such as decent chairs, tables, food, drink, and top-notch workstations dramatically hamper software development efforts. If your project team is being nickel-and-dimed to death then I have to question if your project is important to your organization – if it isn’t, cancel it now and invest your efforts on something more productive.
-- Scott Ambler [4]
[1] Scott Ambler, Organizing an Agile Modeling Room, http://www.agilemodeling.com/essays/agileModelingRoom.htm
[2] Mishkin Berteig, 8 Team Room Tips, www.agileadvice.com/archives/2006/12/8_team_room_tip.html
[3] Joe Little is a freelance project management consultant, www.kittyhawkconsulting.com
[4] Scott Ambler, When Does Agile Modeling Work? www.agilemodeling.com/essays/whenDoesAMWork.htm
Deborah Hartmann is an Agile practitioner, trainer and coach based in Toronto and working internationally. Deborah is passionate about making work both valuable to the business and enjoyable for the team. She's coached both large and small businesses in Agile adoption, has been Lead Editor for InfoQ's Agile Community since April 2006, and has facilitated OpenSpace conferences for the XP and BarCamp communities in Canada and the US.
Image credit: "Pair-on Chair" image used with permission from Cenqua Pty Ltd.
Deborah
One thing my current company have is a computer in every meeting room with projector and network connection. It means that if we decide halfway through a meeting that we need a computer, someone can discreetly boot it up whilst the conversation continues rather than stop so someone can go from the room and get a laptop, fiddle under the table with wires etc etc. It seemed decadent to begin with but definitely a cost saver in the long run.
Docking stations for monitors but wi-fi for networks.
The key thing is to avoid the furniture/networks police whenever you want to move something/someone. That way the team can tune the area.
For Agile 2007 I have tried to contact Herman Miller and get them to send a designer into the Open Space. The idea being for them to design "Agile friendly" furniture... desks with wheels for example. Unfortunately they haven't got back to me and I've run out of time.
Love to see an open space on the topic.
Chris
Hi Chris.
> Docking stations for monitors but wi-fi for networks.
I totally agree - wired network connections are a big hassle for a team that doesn't know how it wants to work yet. Wifi is a huge benefit - teams can think about the work and get on with it, wherever.
> design "Agile friendly" furniture
Steelcase has done this, from what I can see. But it's SO incredibly pricey! A thin steel rail and some light weight whiteboard panels to hang on it, just an 8-foot length, ranged around $800 last time I checked! But the flexibility of taking a panel to your desk, the conference room, then returning and putting it in your workspace... nice. They have small modular tables - for example, a small oval one about 1x3 feet, that rolls under a desk when not used. You pull it out when you need to have a 2-person conversation and need somewhere to put a piece of paper. The steelcase stuff is perfect for Agile - if you have unlimitede budget. I can't imagine Herman Miller would be *less* expensive :-)
I've had the same idea as you... but is there a "do the simplest thing" designer we could team with to get some more pragmatically-priced furniture made?
One alternative to a digital camera for those magnetic whiteboards is a digital copyboard such as the Plus M-11W. We have two of them; they're essentially a whiteboard on a conveyor belt that feeds through a linear array scanner. You can use regular whiteboard markers to draw on them, and they can send their output to a colour inkjet printer or to a USB key.
On our "to do someday" list would be running a USB cable over to our Wiki server and rigging the copyboards to post their contents to the Wiki at the press of a button.
The down side: they're more expensive than regular magnetic whiteboards. You can wall mount them, but we have ours on floor stands with casters, which we can roll over to a boardroom or to the agile modeling area.
A great piece of software is whiteboard photo. It is a little pricey but well worth it. It takes a normal 3D photo of a whiteboard and cleans it and transforms it into a much more readable 2D image.
My new tiny Casio camera has a "whiteboard" setting. They do seem to come out pretty white (I've not shot many yet) - and it will crop the photo to include only the whiteboard, right in the camera (optional). Kewl!
I've never worked in a workspace as elaborate as that described in Joseph Little's list - although it sounds great!
This is a very useful article about an a topic that is not discussed enough. Is there any experimental evidence out there that we can use to sell our clients?
I saw a BBC documentary a few weeks ago that showed both Google and Microsoft have moved toward such workspaces. (They have $$$$ )
Finally, if I could only choose one idea from this list it would be:
Any formula you create should focus on the goals, the needs to be met, not the means.
So what, if I may ask, are the Goals of the collaborative workspace?
> what... are the Goals of the collaborative workspace?
At the highest level, the workspace serves team's goal, so: frequent delivery of working software. Of course, this requires a healthy team and effective process. Also, sometimes there are corollory goals like: create a visible case study for other teams considering Agile.
Keeping the team's overarching goals in mind (and I do think it's important to flesh these out early, perhaps using Managment Tests), Mishkin's list above offers a good way to measure the appropriateness of particular aspects of the space. Here I offer some paraphases:
I think a list of reminders is helpful because we all too often focus solely on the "collaboration" aspect, and sometimes not even that - we'll take any space without dividers, even if there is no sensible way to put up information radiators.
I'd tend to take a "sliders" or "dials" approach to this list: for our own team, which of these aspects are we most concerned about? On which other items are we willing to compromise in order to "dial up" the important ones? This gives some structure to a discussion with facilities management, and offers them a way to collaborate with us because they understand our objectives, rather than saying "no" to our specific requests.
In Jan 2007 the team I was working with as the Scrum Master decided to move into a team room. The room is a conference room and we do have some windows to the rest of the 'cube farm'. The conference room is designed for a meeting w/ up to 14 people. The room started out with six people in it. And it was feeling pretty full.
When we had eight people in the room, with dual monitors, laptops or desktop computers, phones, etc, the room became unmanageable.
In fact, the team spirit broke down. We had two people basically check out of the team. One checked back in later. The team really did not gel.
Also remember most prisoners in the USA get between 40 and 80 sq ft of living space.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.
Chris Richardson shows how he ported a relational database to three NoSQL data stores: Redis, Cassandra and MongoDB.
Jean Tabaka challenges the audience to reflect on what Agile practices they are employing, how they are using them, ending with the questions “Why have their organization chosen to go Agile?
8 comments
Watch Thread Reply