Engagement Beats Handoff and Jargon

October 28, 2007 by
Filed under: Leadership, Process, Teamwork 

Quite often when we talk about challenges in this industry, we lament that our customers don’t get it, or that those hardware guys seem to live in their own little world (that is, if we’re in software – for those in that hardware world, the shoe is often on the other foot). If we dive into the majority of those communication issues, one of the problems is that we have not really engaged with ‘the other side’ – we have been busy confusing them with our jargon.

A few weeks ago, I wrote about a company that has had great success in developing systems working to a fixed price where others have failed, and delivering on expectations. One of the critical strengths they bring to the table is an uncanny ability to understand the problem space through strong analysis techniques, but there is more here than meets the eye. If we look closer, they are not just building up a massive class diagram and passing it back to the client for validation. They are doing something that gets to the essence of successful collaboration – they are building the model of the problem space along with the engaged client, in close collaboration, in real time.

This serves a couple of purposes. First, as the client is engaged in the effort and can see their contributions affecting the outcome of the analysis in real time, they are more involved, and have a stake of ownership in the results. This is absolutely critical, and is a technique that can strengthen the production of any artifact that involves a number of different stakeholder communities. Everyone can say “this is my product”.

More importantly, though, is that this is a situation where the client is getting their first exposure to the notation being used to produce this model. It is pretty safe to say that until this point, UML has not been part of their vocabulary. Indeed, they probably still have no idea what UML stands for, and don’t know any of the back story of how this set of notations grew out of an industry consortium that finally got together to produce a standardized way of modeling aspects of software systems (instead of each guru having their own perspectives represented in a set of views named after them). I’d say they really don’t care even now about all this, and shouldn’t be bothered with it – they don’t need that knowledge to do their job.

Instead, they had someone approach them and ask questions about their system, their way of getting the job done, and the challenges they have had in the past. As they explore the situation in this conversation, this outside person started to capture their responses on a whiteboard (virtual in this case), with a few boxes, some lines between these boxes, a few labels, maybe some annotations about how many of these things could exist. As each new type of element appeared on the screen, it was done in the context of what was currently being discussed, and had immediate relevance for the client. It was clearly a way of capturing exactly what they were expressing, and they could provide immediate feedback about whether it made sense or needed adjustment. Very quickly the model grew, and it formed the basis for discussion and continued growth. Inconsistencies appeared where they were hidden before because of this new way of looking at the system as a whole, the client quickly identified where there were holes in the model, and the analyst could see whether they could develop the system from this understanding of what the end point should look like. A couple of hours (literally, in this case), and the client still does not know what UML stands for.

Compare this to how we often conduct business with other communities. We will often develop our understanding of the system, using these same diagrams, but based on our understanding of what we think the system should be. We’ll then hand the client this completed view, maybe even reference UML or call it a class diagram or database schema, and ask for feedback. Put yourself in the shoes of the client at this point. You might recognize a few of the labels, and with some effort be able to infer some of the rules governing cardinality or relationships between the symbols, but the overwhelming feeling you experience is just that: you are overwhelmed. It is almost impossible to provide deep, insightful feedback, as there is just too much to absorb at one point. From here, as analysts, we take this shallow feedback as either our model is pretty good, or the client isn’t that interested in providing useful feedback at this point. We forge ahead and build the system, and we get stressed when the feedback at the end is essentially that the system is wrong. If it wasn’t for our client, we’d get a lot of work done around here.

You’ve probably been there. We do this all the time in software development, and it is not just with the end user. We have developed a vast array of terminology shortcuts, of notations, and of patterns that allow us to express ideas within our community in a concise form, but we stumble when we try to communicate our message elsewhere. We often fail to recognize that even within the software development world, communities that can share a short form of expression often have to be trained or grown over time: there are still many software developers that don’t know what UML means, or don’t understand the distinction between an ‘extends’ and ‘includes’ notation on a use case diagram (hence the suggestion by many that we should keep things as simple as possible). Most people would have to refer to the Gang of Four (the authors, not the musicians) to understand the nuances of a Decorator Pattern (I know I would). Throw on top of that the acronyms that most shops develop for their products, and from outside the software arena, we have moved quite a distance away from commonly applied English. Use this with other groups and feedback will sound a lot like “huh?”

If that Gang of Four reference flew by you, you’ve just been victimized by this very problem.

We need to use our terminology only when it serves us to facilitate communication. As we expand our engagement to other teams, we need to drop the jargon and collaborate in a manner that will allow us to get the information we need (and to provide the information back as necessary, without the clutter). If we see that use case analysis is probably going to help us understand the problem, it can be dangerous to approach a user group and say “Let’s do a use case workshop”. Indeed, I experienced pushback against use case terminology this week from a technically savvy hardware person – it was seen as ‘software-speak’.

Instead, engage them in a conversation about their systems. Keep your understanding of the structure of use cases in your back pocket, but talk in their space. “So what are some of the goals you would want to achieve using this system? What other people or systems would need to be involved to? How would you go about working with the system to achieve that goal?” All the while, you are building a use case diagram, explaining that box as the system boundary, what an actor is, and capturing their goals in those funny ovals inside the box.

Over to another flip chart. “Okay, lets take this first goal. How do you see working with the system to achieve this goal?” Start drawing swim lanes, maybe use some post-its to capture the initial flow of actions and responses. Explore some alternatives, add other lanes as necessary as other actors get involved in the use case. More flip charts, more use cases. Ask about what could go wrong (exceptions), or what order things need to be done in (pre and post-conditions) along the way, but park the jargon at the door. Your client will love you for it.

We’ve developed a powerful set of notations and terminologies to express the different perspectives of the systems we build, but we need to recognize that this is a language that we have developed for ourselves, an internal shorthand that will only fluster others that have not been indoctrinated (and many have no interest in the indoctrination at all, they have other things to do). If we learn to read our audience and use these notations as a means of sharing understanding and engage others without the noise of our own jargon, we will all be much better off. – JB


Feel free to leave a comment...

  • What’s Happening

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.

    Contact Jim if you would like to connect around any of the upcoming dates:

    • Blissfully at home in Vancouver, BC over the summer!
  • What People are Saying

    Jim is a true professional. His expertise in software development and project management is outstanding, but perhaps more important is his commitment to his clients and his own personal learning. Working with Jim is a pleasure for me – and will be beneficial for you.

    — Kevin Eikenberry, Owner, The Discian Group