Perhaps a prerequisite practice would be team members’ regularly sharing reflective learning (thoughts prompted by your later reflective journal post.

Anway, thanks much for the response.

You are both right. Of course this idea does not fit all projects and all teams. If you read my FlexDev article (http://blog.qualityaspect.com/2006/05/10/flexdev/) you would notice I argue that no methodology/practice can possibly fit all projects.

Having said that, I must say that generally, the higher the cost of maintaining such a dictionary is, the greater the benefit is. If you are having a hard time deciding what some terms mean, your team members will probably be confused by these terms. Not making a decision is just putting off the problem until a later phase in development. This is risky.

So, in my opinion, investing the time in defining these concepts is probably cost effective in most cases.

Of course, you should always stay alert, and make sure you are not wasting too much time on isoteric details. It’s your call: you should know when enough is enough.

Lidor

1) It has the potential to suck up a lot of time. And even though it’s “up front” time, and for the sake of avoiding wasted time later on, I’m not sure the trade-off is worth it on a lot of small-to-medium sized projects.

2) People are willing to go to disturbing lengths arguing over the silliest things, technical people moreso than most. And the meaning of critical (and non-critical) terms used in the management of a project is far from trivial. The frustrating arguments and dissent normally encountered in the long term may not be avoided, but just moved up.

But tempering those worries are two other considerations…

1) Everyone knows (or should know) that such rules aren’t one-size-fits all. Small projects and small teams have different dynamics than big ones. A small project would be more impacted by the up-front time, but is probably less likely to suffer from serious miscommunication issues, so the extent to which this advice is followed can probably vary from project to project, providing more ROI as project size increases.

2) Even if the frustrating verbal fallout is not avoided by this strategy, at least it can prevent the technical consequences that result from misunderstandings and miscommunication that goes unnoticed or untreated.

As a qualified professional, Mr. Wyssocky surely has experience with this strategy or he wouldn’t be recommending it. What has been your experience implementing this strategy in teams and projects of varying sizes?