As you may now, I am working on a new book, which will be called Succeeding with Agile. I recently finished writing a chapter for it on the impact of the human resources and facilities groups on an organization that is transitioning to an Agile project management approach. While writing that chapter, I put together a list of all the things that I think should be visible within the ideal agile workspace:

Big Visible Charts. Alistair Cockburn coined the term “Big Visible Charts” to describe the charts that agile teams like to hang on their walls. One of the most common of these is the sprint burndown chart, showing the number of hours remaining as of each day of the current sprint. Charts like these provide a strong visual reminder of the current state of the project. What is shown on these charts will get the attention of team members so display charts showing the most important information for that sprint. Ron Jeffries suggests considering big visible charts showing the number of passing customer acceptance tests, the pass/fail status of tests by day, sprint and release burndown charts, number of new stories introduced to the product backlog per sprint, and more.

Additional feedback devices. In addition to big, visible charts, it is common for an agile team to use additional visual feedback devices in their workspace. One of the most common is a lava lamp that is turned on whenever the automated build is broken. I’ve also worked with teams that use flashing red traffic lights to indicate exceptional conditions such as an issue on a production server. Also popular are ambient orbs and Nabaztag rabbits, which are wireless programmable devices that can also be configured to change colors, speak messages, or wiggle their ears as a team desires. Devices like these make a workspace more dynamic, unobtrusively bringing into it information the team may find helpful.

Everyone on your team. Each person on the team should ideally be able to see each other person on the team. This absolutely includes the ScrumMaster and ideally includes the product owner. I do understand, however, that product owners often have responsibilities to other groups outside the development team and so may sit near them instead. Still, in an ideal world the product owner would be visible to everyone in the team workspace.

The sprint backlog. One of the best ways to ensure that everything necessary is completed in the sprint is to make the sprint backlog visible. The best way to do that is by displaying the sprint backlog on a wall, ideally in the form of a task board A task board is usually oriented in rows and columns with each row containing a particular user story and one index card or sticky note for each task involved in that story. Task cards are organized in columns, minimally including “To Do” “In Process,” and “Done.” In this way, team members are able to see work progressing across the task board during the sprint and all work to be done is visible at all times.

The product backlog. One problem with running an endless series of sprints is that each can feel disconnected or isolated from the whole of a planned released or related set of new capabilities. A good way to reduce the impact of this problem is by displaying the product backlog somewhere clearly visible. This can be as simple as keeping the shoebox full of user stories written on index cards on a table in the middle of the team’s space. Even better, tack the index cards with those upcoming user stories on a wall where all can see them. This allows team members to see how the user stories they are working on in the current sprint relate to others that are coming soon.

At least one big white board. Every team needs at least one big whiteboard. Locating this in the team’s common workspace encourages spontaneous meetings. One developer may start using the board to think through a problem; others may notice and offer to help.

Someplace quiet and private. As important as open communication is, there are times when someone needs some peace and quiet. Sometimes this is for something as simple as a private phone call. Other times it can be to think through a particularly challenging problem without being interrupted.

Food and drink. It’s always a good idea to have food and drink available. These don’t need to be fancy, and they don’t even need to be provided by the organization. I’ve worked with plenty of teams that buy a small under-desk refrigerator and share the expense of buying water bottles or soda for it. Other teams buy a coffee machine, depending on team preferences. Some teams rotate bringing in snacks, both healthful and not.

A window. Windows are often a scarce commodity and are doled out to an organization’s favored employees. One of the nice things about an open workspace is that windows are shared. Even if the view is only of our parking lot and can only be seen across three messy desks, at least I can see the window and some natural light.

It's unlikely that every one of these will be visible from your workspace, but the more of them visible, the better. Let me know what else you think should be visible from within the ideal agile workspace.

Would you like to include comments?

Tagged:

About the Author

As the founder of Mountain Goat Software, Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a founding member of the Agile Alliance and Scrum Alliance. He is also the founder of FrontRowAgile.com, an online agile training website. He can be reached at [email protected] or connect with Mike on Google+.

I just came across this post and the comments about the workspaces at Microsoft P&P and Ultimate Software. What I wouldn't give to pick Adam's or Ajoy's brain for a day on these amazing workspaces! One thing I'd love to hear a comment about is the balance between an individual's flow state (favoring the private office) vs. the team's flow state (favoring the team room). Are individuals able to get into their own little zone within the shared space, or do they need to retreat to the escape pods often to get "real work" done? Or does the use of pair programming make people more immune to possible distractions in the team room?
Also, do people using these team rooms still have their own dedicated offices elsewhere, or do they no longer need those? What happens to things such as the office phone line for those people?
And finally, how much time was needed to convert the workspaces to the new design? Was there a particular architecture firm that was consulted (both the Microsoft and Ultimate Software setups look really similar)? And how much arm-twisting was needed to get senior management to pay for the changes?
Our own office setup is a lonnnnnnng way from anything like this, but it's very inspiring to see other companies that do "get it" when it comes to a investing in a workspace that facilitates team communication.Posted by Rich Dominguez on 2009-07-29 21:20:28

This is a good list, and it's attainable.
In Tom DeMarco's Peopleware he addresses a similar topic about developer work spaces without specifically talking about Agile. I asked to rearrange our workspace to echo DeMarco's recommendations, and when we started doing Scrum the only thing we had to change was to add the visible product and sprint backlogs. (http://www.amazon.com/Peopleware-Productive-Projects-Teams-Second/dp/0932633439)Posted by Moss Drake on 2009-03-27 09:27:06

Mike,
I like your post. Most of these Scrum teams try to do, but I like the call outs to "Someplace quiet and private" and "Food and drink". Little things that help deliver a lot of value. Very nice!
If anyone is interested in a list of Scrum artifacts to go along with the Agile workspace, I recently posted about this on my blog.
http://onemoreagileblog.blogspot.com/2009/03/scrum-artifacts.htmlPosted by Richard Cheng on 2009-03-20 09:05:15

Hi Jay--
Thanks--I'm excited about the book too (or at least I will be once it's done!)
Yes, I do think that is a great question to ask to encourage self-organization. The variation of it that I ask if for team members to ask themselves every morning, "What is the most important thing I can work on today to contribute to our meeting the sprint goal?"Posted by Mike Cohn on 2009-03-18 13:15:05

Hi Mike - like so many, I'm excited about your new book and I'm enjoying reading your posted chapters - I need to read more.
One comment on your Sprint Backlog item in the list above...
In addition to the value of tracking progress on the team's Sprint commitment, I really value it as THE vehicle to answer one question for team members:
Ques: What do I do next?
Ans: Ask - 'What can I do to advance tasks to done-state on the highest priority incomplete story.'
I find this simple rule is a key to self-managing teams.
What do you think?
JayPosted by Jay Conne on 2009-03-18 11:31:30

Thank you so much for the distributed team chapter!Posted by Doug on 2009-03-11 10:11:42

Hi Ajoy--
Whoops. I knew that. My apologies to Ade. I'll chalk it up to having thought Microsoft was a one-man company. ;)Posted by Mike Cohn on 2009-03-11 06:21:43

I read your nice book on Agile Estimating and Planning and waiting for this new interesting one.
Regarding Distributed Scrum as readers are discussing here, I think mostly we talk about outsourcing companies with offshore setup in different timezones. I believe we should share more and more offshore experiences and actual viewpoints from real people and we need to feed those facts/data to make the Scrum more complete and meaningful. I wrote some of my experiences, challenges and workarounds with offshore based distributed Scrum, you may want to check [I hope to write more on this soon]:
http://evilword.wordpress.com/2009/03/06/distributed_scrum/
Thanks.Posted by M N Mamun on 2009-03-11 05:28:57

Glad you like the space.
BTW, the Distributed Agile Paper is written by Ade Miller, who leads the Development Team at patterns & practices. Great to hear that you are referring to this in your book. Cool.
ThanksPosted by ajoyk on 2009-03-10 23:24:40

Hi Ajoy--
That's some very nice space you have. Thanks for sharing those. I really like the idea of movable walls. I had an apartment in NYC many years ago that had these. The apartment was considered a "two-bedroom" which let the landlord get around some regulations but I could move the walls how I wanted and I made a larger one bedroom of it.
I can highly recommend that everyone check out your paper on distributed teams. I cite that often in my chapter in Succeeding With Agile on Distributed Teams.
Thanks.Posted by Mike Cohn on 2009-03-10 19:28:57

Hi Brian--
One of the things I'm doing in the Succeeding With Agile book is including sidebars / sections that raise and address common objections. There are also many sections called "Things to Try Now," that are intended to help ease the transition.
I've never found any of the Big Visible Charts referenced too time-consuming to create. Each should typically be updatable in no more than a minute a day. If you have something taking more time, I'd look for a replacement.Posted by Mike Cohn on 2009-03-10 19:25:10

Hi Mike,
Great to hear about this book. WRT to the team space, check out these vidoes of our work space at Microsoft patterns & practices:
A peek inside the p&p Team Room (http://channel9.msdn.com/posts/briankel/A-peek-inside-the-pnp-Team-Room/)
You have heard about the facility at p&p and how it’s built for agile teams. Now get a view inside one of the team rooms at p&p. In this video, Ajoy Krishnamoorthy and Ade Miller give you a walkthrough a team room and shows off the various features.
Tour: Patterns and Practices Lab (http://channel9.msdn.com/posts/Charles/Tour-Patterns-and-Practices-Lab/)
The Microsoft Patterns and Practices team renovated their development lab in order to better support their Agile development methodologies. Movable walls you can write on and “escape pods” are just a couple of the featured additions.
Lastly, here is a link to the paper on Distrbuted agile development: http://download.microsoft.com/download/4/4/a/44a2cebd-63fb-4379-898d-9cf24822c6cc/distributed_agile_development_at_microsoft_patterns_and_practices.pdf
Thanks and looking forward to your book,Posted by ajoyk on 2009-03-09 13:59:51

Hey Mike,
Can't wait for the book! Looks like it will definitely address some of the more real world aspects of doing/being Agile (it certainly doesn't happen overnight, IME!). One question: Do you address the work space transition in terms of what we can do to ease that transition as with all the other Agile practices?
Like the other Agile practices, implementing them all at once is virtually (if not completely) impossible. I assume that some of these work place items are easier to 'sell' than others such as the lava lamp or food/drinks.
Also, in reading about big, visible charts, I definitely agree with some of the basic ones, but when you get into some of the others Ron Jeffries mentioned, I would assume that the time it might take maintaining these would preclude it from being done. In your experience, has that been the case? Or are they not as time consuming as I suspect?Posted by Brian Shannon on 2009-03-09 09:38:20

Hi Derek--
It's good to hear from you. I loved being able to see your workspace. I encourage everyone to check out Derek's video to see the two things he thinks I missed. I'll give one away--interns--but watch the video to see why he thinks you should always keep an intern in sight!Posted by Mike Cohn on 2009-03-07 19:42:04

Mike,
I liked this list a lot. While I think we hit most of the items on this list, I still think we can improve. I created a video sample of our workspace as well as some items I think you are missing.
http://derekneighbors.com/2009/03/attempting-to-achieve-the-ideal-agile-workspace/
--
DerekPosted by Derek Neighbors on 2009-03-07 16:28:51

Thanks. Downloaded the Distributed teams pdf and will check it out.Posted by Michael on 2009-03-06 16:14:32

Brandon,
I think Michael's (and most agile) advice about being in the same room really apply to teams that conceivably "should" be able to go locate, but for some reason are always a couple of rooms away from each other, around the corner, on different floors, or otherwise out of sight.
I'm currently working on a engagement, where there are three separate agile teams, all located on the same floor, even on the same side of the building, but almost nobody is within line of sight with their own team members (my team excluded).
Last week when I suggested that resources should be willing to get up and move desks to be decided there team members, the response was nothing but blank stares and veiled hostility... (the development manager excluded, he saw the value in it...).
Of course in distributed teams, this isn't possible, but I think the point here is that a lot of teams are needlessly distributed...Posted by Jeff Anderson on 2009-03-06 14:47:06

Adam--
That new space is awesome! When I made the list above I was thinking that is ideal but I wasn't sure I'd even seen 100% of this in any one space. I didn't see a fridge in your space so add one and I'm ready to move in--you'll have everything in my dream team space.
FYI: Adam is the VP of Development at Ultimate Software and I encourage you to check out the team rooms they now have: http://tinyurl.com/avrwge
I remember the first time I visited you (back in 2005 as you point out). I came upstairs to your office and asked where are the developers sat. You pointed out to me that I had just walked past them all to get to your office. This was an office built on the old Microsoft ideas that every programmer needed an office with a closed door and to get to your office I'd walked down a corridor full of closed doors. I had no idea a programmer was in each and had thought I'd walked past a bunch of supply closets or something. I continue to hear wonderful things about the successes you and everyone are having their at Ultimate. Congratulations! And thanks for sharing the photos. I'm very impressed.Posted by Mike Cohn on 2009-03-05 23:24:22

Hi Brandon--
In this one particular post, I may be addressing teams within 4 walls but that is hardly how I've addressed agile through everything else I've done. I'm on record as saying that distributed teams will need tools--check out http://www.userstories.com for a list of user story (product backlog) management tools and reviews of them by users of them.
As with my message, to Michael, check out chapter 18 ("Distributed Teams") from my Succeeding With Agile book at http://www.succeedingwithagile.com I'm making that chapter available (in draft form) so you don't think that I think agile needs to be done by collocated teams in all cases.Posted by Mike Cohn on 2009-03-05 23:16:54

Hi Michael--
I've got a new book, Succeeding With Agile, coming out later this year and there is a chapter in it specifically on "Distributed Teams." The book is at http://www.succeedingwithagile.com My publisher only wants me to post each set of chapters for a month or two and then remove them to post the next chapters. And the Distributed Teams chapter was already on and removed from the site. But, I just added it back if you'd like to donwload it and take a look. Just don't tell my publisher ;)Posted by Mike Cohn on 2009-03-05 23:14:13

Hey Mike - check out our new space we just started moving into. This is certainly much different from when you first got us started on agile in 2005!!!
http:[email protected]/sets/72157614696825365/detail/?page=5
Full construction on pages 1-4.Posted by Adam Rogers on 2009-03-05 18:44:36

You speak as if Agile is only practiced within the confines of 4 walls. What if a white board and a lava lamp don't cut it because your 300 person dev teams are spread out all over the world and still need to share components, libraries, etc. etc.
Thank you.Posted by Brandon on 2009-03-05 14:38:43

Okay this is the "ideal" but what about development teams who have to deal with the reality of trying to be agile within a distributed organisation?
There are a huge number of blogs and books that repeat the same message about card boards & visible burn down charts on white boards but how do these agile practices work for distributed teams?
Your blog links to a picture of people doing something like this in Outlook Notes but did they succeed? What other tools could yield a successful team but in the context of distributed development?
Wanted to get that off my chest.
thanksPosted by Michael on 2009-03-05 14:38:39