Some have called colocation common sense among Agile practitioners, I state that it should be common sense that the requirement is not actually very Agile. What is more agile; picking a particular city and only having access to employees from that city, or having access to employees all over the world? The answer is – it depends on your situation, not on an Agile requirement.
“Agile is a generic or ‘umbrella’ term for an operational framework or methodology that strives to keep a focus on requirements by using adaptive approaches and continuous improvement practices.” – WHAT IS AGILE?
Here, I am going to argue that Agile does not have within its definition a requirement to be co-located, or any definition whatsoever about the required physical environment. Agile approaches may define some of the working environment conditions, Agile itself is more a way of thinking, than it is a way of doing.
One Environment to Rule Them All
People are different, teams are different, companies are different, cultures are different… and you want to shove them all into a cookie cutter open office co-located team room with a kanban board because…. Agile?
That doesn’t sound very Agile to me. A more Agile way would be working to define the environment based on your business objectives and the people you employ. Just picking a physical environment because you think it makes you Agile, is not very Agile. Agile is about adaptation, the environment should adapt to fit your needs.
- What are you trying to achieve?
- Who do you want to work for you?
- Is the required talent available in your area?
- What works well? Am I seeing expected productivity gains?
- Am I able to adapt to changing requirements?
And probably several more questions should be answered as you work to adapt your environment to fit your goals.
But the Agile Manifesto Says…
…nothing about the actual physical environment where work is to take place. It says nothing about scrum or kanban boards, timeboxes, or a colocation requirement. Even if it did, so what? Agile existed before the manifesto. (The Agile manifesto is also concerned with software, Agile is not exclusively for software.)
Environmental conditions have been stated within specific Agile approaches, those approaches are not a requirement to be Agile – they are just a requirement if you want to dogmatically follow a specific approach. I wouldn’t call the strict adherence to an approach that may not align with your business needs very Agile myself, you should go with what works best. Sometimes what works best requires learning what works best.
Shu-Ha-Ri is often floated about when dealing with specific Agile approaches and learning about them.
Shu: When you first begin, you are in the Shu stage. You follow the master, or you follow the Agile approach exactly. Dogmatism is okay here, you need to follow it strictly. It is the beginning stages of learning.
Ha: At this stage, you should be learning a bit about what works and what doesn’t. Branch out a bit, learn about approaches to Agile other than your chosen framework. You start integrating other ideas within your approach. You abandon the strict adherence and begin to adapt to suit the needs of the business.
Ri: You no longer need the guidance of the specific Agile approach and are learning by doing. Perhaps you have abandoned the defined office requirement in an Agile approach in favor of experimenting with cubicles to give each person some private space to work, or implemented telecommuting 1 day a week. Maybe your physical Scrum board is gone, and you replaced it with a software solution like VersionOne or Jira.
The more you try to restrict what Agile is, the less agile Agile becomes. These restrictions are not needed and not the place of Agile to define. Use co-located, use distributed, use teams all in their own individual offices or cubicles. Agile shouldn’t define whether or not you use co-located teams, studies that show open offices suck probably should.
Agile should be about agility, not about where we work. It should be about the ability to produce excellent output with minimal waste and aligning the objectives of the individuals to the goals of the organization.
Agile frameworks can be great tools. If the stated environment within a framework works well for your organization, by all means, use it (not that you needed my permission anyway). I would be cautious though, adhering to some environmental requirements solely because they exist may not be the best choice. You may have to play around with it, adapt your adaptive Agile approach.
Agile Manifesto for software development available at http://agilemanifesto.org/
About the Author
Joshua Render is the owner and writer for Agile-Mercurial. He works in the technology project space leading Agile teams to successful product actualization.