Robby on Rails

While reviewing some articles related to small business management, I came across the following post… titled, Note From Boss to Employees, by Michael Wade. As a young business owner, who only 16 months ago was working in his attic… to now trying to figure out how to run a company with over ten employees (and growing), posts like this remind me that we all have so much to learn. :-)

Here are a few that I appreciated…

“I may not have been given a huge amount of training before being named to a supervisory position. As a result, I’ve had to learn through trial and error. That’s not always bad. Many of my responsibilities can only be learned through practice.”

Yep… that’s me! The only difference is that I promoted myself instead of being promoted by someone else. I’m still not sure what I got myself into sometimes. ;-)

“I will make mistakes. Please give me the same understanding that you’d like me to give you when you blunder.”

This reminded me of a blog post from last year, titled, Avoiding the most common software development goofs, which points out that things like ignorance and stress are often to blame for mistakes in development. I feel like these are reasons for goofs in just about any environment, especially business. Let’s face it. We’re not perfect and we’re going to make a lot of mistakes. Once we’ve agreed on this, let’s take the next step and see what happens.

“If I do something dumb or am on the verge of doing so, please tell me. Don’t hint. Tell me.”

Perhaps this is a common problem for most small business owners. Are employees afraid to tell me that I’m doing something dumb?

“If either of us has a problem with the other’s performance, let’s talk about it.”

As they say, real friends will be honest with you about your faults. Not because they want to make you look bad, but because they care.

Each of the points that I have listed here are pointing to is… healthier Dialogue, which is always a challenge to accomplish… in any relationship… whether with clients, coworkers, bosses, or employees.

I’d like to add a few to this list.

• It’s easier to ask for forgiveness, than to ask for permission.
• I’m still trying to get the hang of this GTD stuff, so.. you might remind me if I forgot something.
• Ask yourself on a regular basis, “Am I having fun?” If not, make time for some.
• Please make fun of the boss! :-)

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!

This was from a discussion a few weeks ago on the Dialogue-Driven Development mailing list.

Bob listed five things that promotes dialogue.

1. Active Listening
2. Agenda Control
3. Trust
4. Follow-Up/Follow-Through
5. Don’t Over Promise

“Don’t Over Promise; In business, it seems about half wait until the last minute and the other half hasn’t a clue about what’s really involved in making any sort of quality effort at something (look at the dismal record on software project performance in the CHAOS report and others). If you overpromise/underdeliver against expectations; you’ll damage both trust and future dialogue. Don’t commit to situations where there’s any doubt in your mind regarding your ability to perform. It doesn’t matter as much about capability (since we all like the challenge) as much as it does about raw capacity (in terms of time) to perform within the established timeframe.”

The list has been about as dormant as my blog has the past several weeks. I’m currently reading through King Arthur’s Round Table, by David Perkins, which focuses on different conversation styles and Dialogue: The Art of Thinking Together, by William Isaacs. I hope to share some of what I learn on my blog and with the list. :-)

I missed a week… but last week, Brian wrote about one of the Principles of d3: simplicty.

“As a principle of d3, we want our client interaction to be simpler. So we want to talk about problems with our clients. We want these to be the concrete, explicit elements we dialogue about.” (read more)

Today, I asked on the Dialogue-Driven Development mailing list, “What are some elements in group interaction (clients, colleagues, users) that prevent healthy Dialogue from taking place?”

“The biggest element that I’ve seen that harms dialogue is an emotionalattachment to some idea or decision… ...When people are emotionally attached to one particular point of view, they have a difficult time making objective, rational decisions.”—David Goodlad

---

“The biggest problem that we have is semi-literate users thinking too soon about implementation details about the solution, rather than considering the true nature of the problem instead.”—James Adam

This resulted in me thinking up a new term for this horrible infection… implementitus.

---

“One of the biggest problems I’m continuously having to overcome is physical proximity. I’m a firm believer in kicking off a project with a face-to-face meeting, but when working remotely, and not having an on-site customer to easily communicate with your skills has a communicator must be greatly increased.”—Josh Knowles

---

“Fortune-telling the user’s reaction.
“The user wouldn’t like this.”
“This user wants this button there.”
“That would confuse the user.”

Of course, user opinion should be critically important, but in my experience it’s often used as a veto that doesn’t have to be explained just because someone doesn’t like an idea. I’ve done this, myself.”—Brasten Sager

---

I’m really excited to get the interact with other people who are facing the same types of obstacles that we are. Being a successful developer requires a lot of discipline and it’s our goal to enhance our communication skills… so that we can reach shared meaning with our colleagues, clients, and users.

If developer to client, developer to developer, or developer to user interaction is important to you… come talk with us in the Dialogue-Driven Development project.

A few weeks ago, I was explaining some of the concepts behind Dialogue-Driven Development to Michael Buffington and when I said that we were working to create patterns of Dialogue... his immediate thoughts were on code. I don’t remember the exactly how he worded it.. but he basically thought we were working on a parsing tool for grabbing requirements out of emails, messages, etc. I quickly explained that d3 had nothing to do with actual code and was merely a practice that we as developers and consultants are using to think about our interaction with clients, users, and amongst ourselves.

Just last night, I was chatting with a friend of mine about d3… (names changed to protect the guilty)

context: Harry works in a development team¹ of about ten people and Paul is one of his “team”mates.

  Harry: i guess it prevents discussion domination
   me: yeah, that happens as it is sometimes
  Harry: and ensures equal contribution
  Harry: paul does that 
    and he's not very polite about it either
    and will often raise his voice and speak over you
    which is crazy
    kindergarten stuff
  me: hah
  Harry: need a talking stick!

This happens all too often amongst ourselves. While we’re striving to improve our client interaction… we often overlook our own internal struggles to achieve healthy collaboration. It takes discipline by every individual in a collaborative environment to really think together.

So, how does d3 address this? Well, it’s our goal that through mindful dialogue, we can cultivate healthier collaboration in all of our professional (and personal) relationships.

I would also like to point out a few common misconceptions about d3.

• d3 is not a methodology… nor a replacement for Scrum or XP. d3 is a thoughtful practice that focuses on the collaboration between a group of individuals, whether they be clients, developers, managers, or users.
• d3 is not a Silver Bullet, but it can be used as effective ammunition.
• d3 is not something you learn in a weekend, but you might be able to find a good book on Dialogue and have a new perspective on how you communicate with others.

Dialogue-Driven Development is about being in the conversation as it is happening… and really listening.

The next time that you’re getting ready to interact with your teammates, ask yourself:

• Am I contributing something meaningful?
• Am I listening to others well?
• Is everybody contributing an equal share of information?

If you’re quiet, try to speak up more. If you talk too much, be mindful of how much you may dominate a conversation. If you’re not participating at all.. why are you there?

¹ You’ll be happy to know that Harry also gave his two-weeks notice yesterday.

A few weeks ago, Brian Ford was in my office and we were discussing BDD and how we can make this process even easier for our clients to understand… much less our own internal staff. With all concepts, each person has their own idea about what it is, why it is important, regardless of whether or not it’s accurate. This can cause some people to not find a good need for some practices.

During our discussion, Brian grabbed one of my whiteboard markers and drew diagrams to explain how he saw BDD vary from TDD. He has since posted an article on his blog titled, what’s it worth to me, and discusses his circular view of Behavior-Driven Developent and the importance of using Dialogue to evolve shared meaning.