Wayne Allen's Weblog

I agree frequent releases will catch miscommunications earlier than having every developper working in a corner for months, though I think it's a misconception to think formal process as a big "drop box". Validation occurs in both approaches!

Miscommunication happens regularly, but at the moment we sit and start coding, it's already late for realising. That's what UML and diagrams exists for.

Though, I must admin that even if you write down "We need to use this shopcart system in this other system, so we must build it as a different standalone DLL with documented APIs", if the message isn't cleary passed and validated back, well... always better to start lacing your shoes right.

Miscommunication is a people "problem" not a process problem, so no process will fix it. I do believe that the agile preference for "Individuals and interactions" helps force miscommunication out into the open earlier than prescriptive processes.

>That's what UML and diagrams exists for.

Assuming they are correct in the first place. UML is primarily a tool for technologists who build them based on interpreting needs/wants from customers, so they are just as likely to be incorrect as any other form of communication.

I do think that things like a common vocabular and reckognized demonstration forms can prevent communcation issues. I've had a lot of communications issues, as anybody else, and it still happens, though having a common understanding of terms did reduce them significantly...

Finally, perhaps you're right and it's not processes that improve communication, but simply the fact to know team members. Seen this way, personnal free time with other team members can be seen as a business efficiency approach? What do you think?