Those that Tend the Store need Dialogue 3
I’ve been keeping my eye on a series of blog posts by Chad Fowler, which he calls The Big Rewrite.
Today, Chad posted an entry titled, Who’s Tending the Store? He writes…
“the experts keep the old system running while the new system is being built. So, who builds the new system? Not the experts, that’s who. Usually, it’s people like me: technology experts. And while we’re banging away at the existing system’s UI, trying to figure out what needs to be coded, the domain experts are doing their jobs. Unfortunately, this means the domain experts aren’t watching the Big Rewrite very closely. Regardless of how good the team, if communication is impaired between the domain experts and the technology experts, things are going to move slowly, and wrong software is going to be created.”
I wanted to follow up on this issue as it’s an area of great interest to me.
I feel like this issue runs deeper and while it’s important to be mindful of the communication between domain and technology experts, it’s a good idea for each of us to take a break every few days (or everyday) to assess our perceptions in all areas of the project. More specifically, I’m suggesting that in order for us to be effective in our communication, we must make time to refactor our perceptions about the state of a project. From the design, to the development, to team communication, to the schedule, and all the way to customer satisfaction… or what Martin Fowler calls, Customer Affinity. These things are not static and we must see them as extremely dynamic variables… much more dynamic than our wonderful language of choice.
When Brian Ford and I started discussing Dialogue-Driven Development (d3), we were initially focused on an area that always seems to come up in projects. Client communication. From managing expectations to delivering the right product, d3 has become an essential tool in our team’s tool belt. We refactored our entire Design and Development process (and it’s always evolving) to focus on the things that we felt were the most important to a successful project. Clients come to us in search of expertise and guidance so that we can build them innovative solutions. When it comes to this process, clients deserve simplicity.
For starters, we’re misguided
If there is one thing that I have learned, it is that our initial perceptions are often misguided. We have to work really hard to think critically, not only of the problem we’re trying to build a solution for, but also of how we, ourselves, are actually looking at the problem. It’s easy to fall victim to tunnel vision. I often find myself having to take a step back from problems on a very regular basis. While I have no scientific proof to back this, it seems to feels natural for us to keep firing once we pull the trigger. It’s important to re-aim.
Chad raises a very important topic and leaves readers to think about the problem. After thinking about this, it’s my opinion that in order for the domain and technology experts to be effective, they need healthy collaboration. But, I feel like this applies to many other areas of our process as well.
Is there even a problem?
So, what is the solution? Better yet, what is the problem? Is there even a problem?
How can we avoid situations where communication becomes impaired? We’ve all been there. We know how to spot impaired communication, but how can we spot it… before we perceive it as too late? How can we recover from it? What causes the communication to break down? What if… it were possible to repair the situation?
These questions don’t have easy answers. These are complicated problems that reach far beyond the development community. These are the same problems that all members of organizations, communities, countries, and planets all face, each and every day.
Take action!
While it’s important to make sure we’re engaging in healthy dialogue through a project, bad things will happen. They are inevitable. As Agilists, we’re accepting this as a fact of (project) life and should be prepared to take action. If you see communication being impaired, it’s time to step up and help the team out. Otherwise, you’re only hurting yourself… and your colleagues.
“Be the change you wish to see in the world.”—Mahatma Gandhi
If these sorts of topics are of interest to you, I encourage you to join the Dialogue-Driven community and help us figure this stuff out!
Enjoying the content? Be sure to subscribe to my RSS feed.
In regards to perceptions, are you suggesting that if our perception is negatively impacting a project, we should reevaluate it? What if the negative perception is warranted?
I couldn’t agree more. Communication is at the heart of everything we do in software. Even the software is all about communication. The real trick is to detect when there is a miscommunication. This is something that is very difficult to do. All people see the world through the rose colored glasses of our own perspectives, and most of us are just waiting for our turn to talk. This is human nature. It takes a lot of effort to avoid misunderstandings, we must always be analyzing and reanalyzing in real time, not only what the other person is saying, but also what we are saying, are we choosing the correct word, is our facial expression expressing the intended emphasis or emotion. In short, the reason is communication is so difficult is because it takes a lot of awareness, training and effort to communicate well. Most people aren’t even aware when they are miscommunicating assuming that when they say the word ‘set’, that their listener(s) all understand which set they are referring to.
You make some very valid points. Out of seven people in my development team, there are maybe two people who don’t come to work with a negative perception towards the projects that they work on. We have a great work environment but there are people who just do not excel in some environments. We’ve had projects come in under budget, on time, and still have issues where developers feel the need to moan about the client even long after the issues that originally pushed a developer to be upset with the client have been resolved. It’s as if their trust is broken and they cannot change their perception of the situation.