Collaborate! But not with you…

Posted by Keith McMillan

June 19, 2008 | 2 Comments

Why is it so difficult to get people to collaborate? When coaching agile projects, we always advocate that people collaborate rather than try to find ways to avoid talking to one another, such as by writing documents and making people read them.

The development teams are usually all over this. They want to collaborate with people who they need things from, such as the business owner in order to better understand the requirements. They’d rather just ask questions of a live body than read a document. Oh, sure, occasionally at first they don’t really want to talk to “those other people,” developers do tend to be introverts after all.  Usually once they try it they think it’s much better than the old ways.

Why, then, is it so hard to get the developers to collaborate with people who want the things they produce? I’m thinking specifically here about the usual suspects, I suppose, the database organization, the testing organization, and any sort of compliance/oversight organization. These are the same organizations who usually have a dim view of agile to begin with, for reasons I’ve talked about before. Why is it so hard to convince an development team (and I’m intentionally not saying a ‘project team’ because they don’t have all the right people) to invite someone, such as a tester, to one of their meetings, when in turn they want to be part of requirements meetings?

You could be forgiven for thinking that once they’d seen the value of working collaboratively, rather than focusing on documents and hand-offs, they’d naturally want to start doing more of it, extending that approach to people down stream from them in the development process. Strangely, that doesn’t seem to be the truth, I get a great amount of pushback when I suggest this type of thing.

I don’t think this is a case of “you should change, but I don’t need to,” since the developers are  already changing the way that they work. To me, a more compelling explanation is that they don’t want to confront someone who may be hostile to the way that they’re working. This is probably particularly hard when they’re new to agile, and they’re not used to working this way yet. But you’d think that having seen the advantages, and wanting to maximize the amount of work not done, they’d push the envelope more than they seem willing to.

Even more surprising is when it’s suggested, I get pushback on collaborating! “We don’t want to waste their time,” they tell me, or “It’s not their meeting, it’s ours.”

I guess life is just full of people behaving in ways that seem harmful to themselves, and that surprises me.


RSS feed | Trackback URI


Comment by Andy Kailhofer
2008-06-19 14:32:22

My biggest concern is that a talking process that is not a documenting process leads to misunderstandings and you really need to write it down anyway (and have everybody agree that was what everybody meant) so you can be clear as to who meant what after the fact. I can’t hold all the requirments in my head, I know I can’t. I suppose I shouldn’t expect people to be able express what they mean in written english any more than they can express it in verbally…

Comment by Keith McMillan
2008-06-20 06:46:21

I understand your concern. It’s one of the reasons that you delay talking about something until you’re ready to do it, so your understanding is “fresh”, and get frequent and early feedback, so you avoid “that’s not what I meant.”

What we find is if you need to write it down, you should do so after you’ve discussed it, and that’s only if someone who’s not part of the collaboration needs it (like, say, the guy who will someday in the future support it).

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.