Destroy The Agile Clubhouse!

clubhouseI’ve seen a lot of team environments, and I don’t have the perfect answer for what’s right for your team. There. Got that out of the way.

But I do believe that if you want to maximize creativity and the ability to learn and pivot, you should work as directly in contact with each other as possible. Like sitting next to each other at a cafeteria table. Perhaps all working on the same keyboard. The closer, the better. (Even though as a developer, I find such arrangements abhorrent in terms of maximizing coding productivity and personal happiness. Such is life.)

This is my opinion. Everybody’s got an opinion. Like most Agile authors, mine is probably wrong to some degree. Form your own opinions and test them in your project with your team. Then we can compare notes :)

But that’s the key: whatever you want to believe, form your own opinions and test them. I have a theory of operations that I feel holds true most of the time. We can add in some definitions, then we can make my theory of operations testable for a particular situation. We observe whether it works or not. So many times I see Agile coaches and teams working without any theory of operations. Either they think there’s one magic way of doing things, or they don’t know, don’t care. They just want instructions. The lack of structure is seen as a bigger threat than getting results from the practices!

The sales and coaching process itself doesn’t lend itself to this kind of nuanced discussion. Instead of creating a principle that we can then test with practices, what I see are these right-wrong discussions that end in compromise. Everybody is somewhat happy, but nobody really gets anything. We get something that looks like Agile because it resembles what other Agile teams do, but it’s not much of anything.

The discussion goes something like this: should we work colocated? Yep, for you guys I think open plan is best. Well, we can’t do open plan. (Coach thinks for a while). That’s fine, how about you work in your cubes, then use this meeting room here for your team stuff?

Welcome to the Agile Clubhouse, where you can pretend you’re colocated for an hour or two each day.

Burn it down!

Seriously. Co-location addresses communication risk: the idea if we don’t work in close physical proximity to people, we avoid and don’t have difficult, natural, and creative conversations. Walking into a room for a stand-up and some Agile rituals isn’t going to address any of that. It’s just going to look a little bit “more co-located” than doing it some other way. As if the goal were for things to simply appear one way or another.

This is like teams with tools. What are storyboards for? The principle is that physical, tangible pieces of work, in a co-located environment, allow people to use different parts of their brain to work on common problems. Displaying the status and problems of the team in a big, public, visible way, all the time, and having the team talk about and physically move tokens representing those problems around? It allows socialization to occur, new ways of viewing problems to emerge, and the group subconscious to work on understanding and optimizing the nature of the work.

Could you put all the storyboard stuff in a tool? Sure thing! As long as you view project data as simply another form of data, like your bank balance. If that’s all you believe project data is, you can, and should, process it using all kinds of cool online tools. The thing here is that either you accept and understand the principle of tools being visible, public, and social — in which case you can test it — or you substitute it with another one — which you can also then test. Identify a risk. Come up with a principle to address it. Come up with a practice. Test the practice.

Many times, especially in big corporations, all we get is the practice part, and even then we’re not owning the practice, simply executing it for somebody else.

The Agile Clubhouse is a symptom that our head is in the wrong place. We’re trying to compromise recipe books, instead of testing out principles. So we understand that we need to “do some kind of co-location stuff”, but we don’t know why, and we don’t know what to expect from it. To us it’s just something we’re supposed to do — something some of us don’t like, or can’t do. At this point we decide that instead of optimizing our work, we view the problem as finding something we all like doing. So we get a clubhouse.

Compromise is a great thing, and we should always strive for it. But our goal in Agile isn’t to compromise: it’s to use empirical data to optimize and predict performance. It’s better to completely eliminate thinking about what you like or don’t like, as long as you can pick something that’s testable, than it is to adjust whatever you’re doing to make the most number of people happy. Guess what? The best answer for the team might actually be something that nobody likes!. That’s fine. That’s life. Sometimes things work like that. It’s your team and your work life. You deserve the best you can get. At the very least, you deserve to know.

Follow the author on Twitter

December 11, 2013

Leave a Reply

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

* Copy this password:

* Type or paste password here:

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>