Being agile or using Scrum does not mean sitting in the same room

I had a troubling conversation about Agile with project manager that is transitioning into a “Scrum master” role. I used the noun version of agile since I live in the corporate world and if we cannot fit it into a box, it’s not enterprise ready. What made me pause was his immediate reaction to impose his understanding and view of Agile on an existing and copasetic team.

First, let me talk about my view of agile and where I begin when I talk about it:

  1. Manifesto for Agile Software Development
  2. Scrum Overview for Agile Software Development

My takeaways are: “people (the team) over process”, “constantly make sure what we’re doing is what the customer wants (needs) and expects”, “make sure everything works, time after time”. Generally, if you can do that, I don’t care what you call the technique. Then comes Scrum, a malleable prescription for the agile process. It adds a little more structure to those concepts and makes sure everyone is on the same page and has a better understanding of where they fit in the world. It provides structure without being intrusive, which works for me.
Going back to my original thought and why I felt the need to write this. That project manager said one of his first orders of business was to get a room for everyone to sit together in, which prompted me to say “wait, what?”. Does he think that’s what being agile means? Or maybe he thinks that’s what Scrum is. Either way, I (and evidently my team) do not share that view of agile. I know the manifesto says “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation“, but that statement was written in 2001, long before video streaming and massive bandwidth was available, let alone the norm. We have so many options now: Skype, Google Hangouts, ScreenHero, GitHub, etc. Face to face isn’t a matter of proximity these days, it’s about availability and accessibility. It’s about being able to readily and effectively communicate.
Most of my team works remote on any given day. We’re all very accustomed to using other means to communicate without having to sit next to one another. I actually like this mode because I don’t have to worry or care about someone elses idiosyncrasies, and they don’t have to care about mine. I like to work through problems out loud. I’m not speaking to anyone, just myself. No one needs to see me make sausage.
Ok ok ok, so what is the point of this post? Basically, being agile is not a set of rules. It’s not people standing in front of a planning board. It’s not paired programming. It’s not about having a daily stand up. It’s not sitting everyone in the same room. These are not magic processes, but rather expressions of what works for some agile teams.  Agile is an adjective. Agile is the ability to react to change, deliver working software to a client so they can get their hands on it early (and often). Agile is what you become when your team works like a team and bureaucracy and process for processes sake takes a back seat. So the next time someone tells you how to be agile or tries to pull a “To be truly agile you must…“, just ask them to think about what they’re really saying. Chances are they didn’t think, they’re just regurgitating, which has no business in an engineering discipline.

Leave a Reply

Your email address will not be published. Required fields are marked *