Consider this part one of several posts on my thoughts of the art of embracing chaos.
Don’t let the books fool you. The construction of custom software is an unmastered and volatile cesspool of chaos. I don’t adhere to the belief that there is a perfect methodology or process that will work for every project… as I’m sure many of you don’t.
Unlike bowling, you’ll never achieve a perfect score. Even in bowling, It’s unlikely that anybody will learn how to bowl a perfect score and do so on every game for the rest of their career.
You’ll never meet every expectation that a client has on every project.
You’ll never meet every expectation that a user has when they interact with your application.
Your project might get widely adopted and embraced, but you’re still trying to control chaos.
It’s chaos. Pure chaos1.
So, why do we bother? Why do we try so hard when the odds aren’t in our favor?
To be continued…
1 Chaos Theory, Wikipedia
It appears that Seth Godin is catching on to the concept of Dialogue.
Seth writes, “Some organizations are good at listening. Some are good at talking. A few are even good at both.”
I’ve been spending a lot of time thinking about how I listen to clients, employees, friends, and family. All of our relationships are a series of conversations. Sometimes we can have healthy dialogue, sometimes we just fall victim to debate. (see Dialogue vs Debate)
Recently, Seth Godin posted a short blog post, titled, Apologies, ranked, which points out several ways of apologizing. When you work in a service industry, it becomes very important to develop good apology skills. Let’s be honest for a moment. Not everything works out for the best in every customer experience. Sometimes it’s their fault and many times… it’s our fault.
It’s worth a read and definitely relates to the communication issues that we keep talking about within the Dialogue-Driven Development community and how that can translate to a healthy testing process with BDD.
This was from a discussion a few weeks ago on the Dialogue-Driven Development mailing list.
Bob listed five things that promotes dialogue.
- Active Listening
- Agenda Control
- 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)
“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 team1 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?
1 You’ll be happy to know that Harry also gave his two-weeks notice yesterday.