Overcoming Language Barriers in Project Communication
Margaret Rouse at IT Knowledge Exchange continues our conversation on PMOs. We started by talking about how a PMO relieves pain, then the PMO’s role in dealing with the dreaded mythical queue of projects, and now language barriers in agile software development projects .
My post on how previous experience with lean manufacturing might overcome some of the barriers in language and acceptance of non-intuitive concepts related to agile also comes to mind.
Here’s Margaret’s language issue followed by my response. Sensei at ActiveEngine! I expect you to get involved with this:
Margaret: I’m going to think more about how language remains a barrier to effective communication when the business owner is trying to articulate what they need to developers and the developers speak Agile.
Bob: Now you’ve got me thinking. I’ve been on the sales/project scoping side and the delivery side of projects. In selling and scoping my initial goal is to understand the client’s challenges in their terms and language . I try to resist the temptation to begin defining solutions until we have a solid agreement on what the problem is. Thereafter, as much as makes sense, the solution, and more importantly the value, should be in their language.
There is obviously a point where new terminology/concepts/approaches need to be introduced- the more we understand the business, industry, and the problems the better we will be at developing a conversation with common language to introduce these new concepts. This up front work and emphasis smooths out a lot of bumps in the road. Easier said than done because of all the temptations and distractions along the way.
*****************
What we are really talking about is developing the “salesman” in all of us; these concepts and approaches are covered more in a book about value selling which relate my experiences selling and scoping large business solution projects (see below).
What challenges do you have in developing communication with your customer (internal or external)? How much does the customer/client have to know about your processes (e.g., agile software development) in order to benefit from them?
Don’t miss a post! Subscribe by RSS or EMAIL.
FREE eBOOK for EMAIL Subscribers!
If you subscribe by email I’ll send you my eBook for free! Here’s how: subscribe by email in the right hand column PLUS send the email post that you receive to bob.turek@b5media.com. (Sorry for the extra step- we don’t have this automated yet.)
To preview the book, or to order a hardcopy, go to my publishing web site by clicking the book cover.
I had the feeling that you might be needing me and lo and behold you summoned me in your post. :)
You may be aware of a movement within agile called Domain Driven development. The basic idea is that you allow the “problem domain” drive the efforts of your technology development and implementation. As opposed to developing the database first, then creating the business logic implementation, in Domain Driven development the starting point is the business processes and logic, and the database and screens become secondary considerations.
However – and this is a big however – the domain must be defined in very clear terms. Many developers differ in perspective from when I say that they must be able to write, in English, what the problems are using the business units language. It is also critical that it is written clearly so that the intent can never be misunderstood. Some may argue that UML does this, but most customers’ eyes will glaze over when presented with Use Case diagrams. When the problem domain can be described succinctly in common terms, your problem solving sessions will be more effective.
On a side note, my theme lately with the development teams I work with is to build a working vocabulary; that is, pick one term to describe a process and stick with that term. In these sessions I have had literally ask “And the word we use this process is …?” It may controlling or masterful, but if you are jumping from problem to problem, or worse, from project to project, you need strong definitions to keep things straight.
Sensei- excellent, well done comment! This is a great discussion that proves the point. Can you elaborate by getting more specific with an example of the business process your are working with? More examples would help readers understand this better. I’m really enjoying the parallels to “selling” also.
I just posted a summary of Eric Evan’s interview on Dot Net Rocks. You may already recognize the name, as Eric has published a book on domain models and patterns in the enterprise.
This is about 70 minutes long, and you can skip past the first 11 minutes as Eric doesn’t started until then. This is a great discussion of the different skill sets that each team possess and deploys for problem resolution.
http://activeengine.wordpress.com/2008/01/14/thats-the-cool-stuff-well-be-doing-on-the-mission-together/
Alex Howard from whatis.com put together an agile glossary for me to post.
http://itknowledgeexchange.techtarget.com/overheard/agile-development-glossary/
Looks like we need to add a definition on whatis.com for Domain Driven Development.
Sensei- I scanned the Eric Evans interview; easy and good reading for non-technical people to understand that software developers should want to work on valuable system changes; i.e., very interesting in that he justifies domain expertise as enabling focus on valuable-to-the-business processes which can be much more complex than the other areas because they tend to be revenue producing and customer facing. I enjoyed the discussion about new system complexity requiring an “anti-corruption” layer to interface to the legacy system that could take as much resource as the new system. Also asking “why are you buying this” to get at where to focus modeling efforts. The multi-language (technical model, user model, reconciled language) issue sounds just like what happens when two people speaking different languages begin to understand each other- my last experience like this was in Korea. Excellent insight into the minds of software developers! Thank you.
Margaret- I would encourage you to read the Eric Evans interview that ActiveEngine talks about at http://activeengine.wordpress.com/2008/01/14/thats-the-cool-stuff-well-be-doing-on-the-mission-together/. It contains not only some definitions but a good discussion about how to team up and deal with the multi-language problem. I attempted to summarize main points in my comment above but it’s definitely worth the read.