Verbal Combat

And here is where the decision is made. Do I retreat to my established viewpoint? Do I dig in my heels? Or do I consider the alternative, offered by my combatant? And suffer the indignity of being judged wrong?

Why Blog?

I recently had an extended conversation with a group of about 10 folks who lamented the poor understanding of the value their particular functional role brings to a software development team.

One question I posed: how many of you blog on the topic of your profession? The answer was zero.

Why don't they blog? Here is my interpretation of the reasons for not blogging:

• Not enough time - working 40 to 50 hours per week leaves little extra time to spend composing and presenting ideas in a professional manner, much less having a reasonable social life.
  
• Lack of original ideas - there's not much I can think of to write about that hasn't already been addressed somewhere - whether in another blog, in a book, or in conference presentations.
  
• Confidentiality - many of the examples from my work are proprietary; obfuscating the details takes time and can cause loss of message fidelity.
  
• Low readership - the effort to reach a small number of readers, given the size of the blogosphere, has a low RROI (readership return on investment?)
  

My blogging is sporadic. I understand the effort required to wrap ideas in a digestable format. I also edit articles for an online IT journal (alphaITJournal.com). Editing is hard work. Blogging doesn't require the depth of perfection that articles do.

Sometimes you're better off taking a stab at it and clarifying the concept through further blog entries than simply waiting to start.

Who reads my blog? According to Google Analytics - about 15 - 30 people. That's the volume of hits I generally get with a new post. It's not much, but size isn't everything. Every once in a while a link to your post will get posted to an aggregate someplace (digg, reddit, Developer Zone, etc.) and will generate more traffic and conversation.

The benefits to blogging:

• Personal brand promotion. As your blog is read by others, your personal brand improves.
  
• Clarifying thoughts. Organizing and writing about a topic forces you to develop clarity on your topic.
  
• An idea portfolio. When you apply for new jobs or try to sell to new clients, your blog serves as a portfolio of your ideas and promotes your depth of thinking on your profession. It also serves to show off your communication skills.
  
• Writing skills. Most of us need to communicate through the written word in our lives. Blogging is great practice.
  

Here's a technique I use to generate blog entries. Whenever I get an insight or a flash, I start a blog entry in a text file. Sometimes it's just a thought (one file - pragmatism.txt - has the following: "Pragmatism vs. agile").

When I have down time (waiting in the airport, sitting on a plane), I take a look at my partials and figure out what I'm in the mood to explore. I happen to be on a plane as I type this.

Your topics will rarely be entirely original. What will be original, however, is how you shape your message with your unique perspective and background. Combining this uniqueness with the topic at hand is what renders insight.

Low readership is not an issue. The benefits of clarifying your thoughts, having an idea portfolio, and improving writing skills are all independent of the size of readership.

So go ahead and start. Create a blog and type "Hello World". You may be surprised at how the ideas start flowing. Start recording things you want to explore ... and start blogging !

Receiving Feedback

My last post on feedback was on giving constructive feedback. Here, I'll focus on receiving feedback.

In the question of feedback - what, where, when, why, and how - the receiver of the feedback may not have control over many of the elements. To some extent, your ability to receive feedback effectively is determined by how effectively the provider shares it. But you do have some control.

If you have a regularly scheduled one-on-one with someone, or performance review meetings, you should always be prepared for feedback. Prepare yourself for these meetings with an attitude adjustment that suggests "I am open and willing to receive feedback constructively so that I can improve". If you enter meetings with this mental preparation, you are way ahead of the game.

Another attitude adjustment that helps you to receive feedback openly is to consider the alternative. That is - what if the person providing this feedback just stayed quiet? I assert that you always gain information and knowledge (even if it's simply an impression of the regard that the giver of feedback holds for you). Treat it as an information gathering exercise. You will learn

1. What that person thinks about your behavior - or even you


2. By extension, if that person holds that view, then others may as well


3. Hopefully - examples of the behavior that the reviewer deems in need of improvement


4. Suggestions of how you can improve

First, let's cover the "when" and "where" of feedback. I've already mentioned naturally occurring events where feedback will be shared. But it sometimes occurs (and should more often occur) in an ad hoc manner. If you sense that you are not in a good mental or physical place to deal with feedback at that time, it is well within your control to request a postponement of the discussion. Try something like this: "Adrian, I am very interested in hearing your feedback, but would it be OK if we schedule some time to discuss this privately - perhaps tomorrow morning? I feel like I will be in a better place to listen and take your feedback constructively at that time".

"What" feedback provided is primarily - but not exclusively - determined by the person providing feedback. If I tell Jeff that the coffee he has been providing me is too hot, that is the primary message. But if Jeff probes on what the temperature should be, what I feel the temperature has been and such, he can steer the feedback towards the constructive content he needs in order to improve. In this way, he can control the "what". In addition, he can use it as an opportunity to probe for related (or unrelated) feedback.

"How" the feedback is provided can be steered by the recipient as well. I mentioned in the "giving feedback" post that one should focus on the behavior and not the person and should provide specific examples of where the behavior needed improvement. If the feedback giver is speaking in generalities, you can steer him by asking for specific examples. If he can't provide specific examples, ask him to keep an eye out for instances in the future. Something like: "I appreciate your feedback that I'm often late for standups without providing advance notice. I can't recall an instance when I failed to notify you in advance - though I do remember the one time that I overslept, which I understand is not a great excuse. I will make every effort to be on time and to notify you if extenuating circumstances arise. If you find examples when I fail to do so, could you please notify me right away, so I can determine the root cause at that time". OK, I'm going on and on for a silly example; you get the idea.

Take notes. Sometimes - particularly if feedback is negative - our emotions cloud our ability to retain the information being provided. It is helpful to take notes to revisit once the dust settles.

Always receive feedback in a positive manner. Always thank the person for taking the time to give you the feedback - even if you disagree. We need to reward people with thanks for taking the time, effort, and risk of conflict to provide feedback. "Thank you, Adrian, for the feedback on the temperature of the coffee. Though I think I've been rigorous about controlling the temperature, perhaps if I find a thermometer for you to measure, you can let me know the temperature you find when the heat is unbearable. In this way, I can improve my coffee provisioning". (I'm getting tired of this example... from now on, no more coffee... this analogy has run its course).

Don't be defensive! Again, treat the feedback as a gift, not as an attack. You're not perfect. We all strive towards perfection, and the more input and feedback we receive from others, the more adjustments we can make on the path.

Don't fight back with criticism. "Yeah? Well, I think your burnup charts should be done in crayon, Adrian, because they're like the work of a 3-year-old."

Consider returning to the person who gave you the feedback after you've had time to digest and perhaps implement some change. "Thank you again for the feedback you gave me last week. I've been thinking about it, and have adjusted a couple of things. Can I share with you the changes I've made?" This shows a healthy dose of maturity, willingness to improve, and respect for the person who took the time to give you feedback.

I'm open to receiving [meta?] feedback on this post.

Giving feedback

Giving and receiving feedback is difficult.

Umm... well. That's not exactly correct. Giving feedback is easy. Giving constructive feedback is difficult.

For now, let’s focus on giving feedback

In my team blog, I used the example of one of my team members getting me coffee. It was meant in jest, but I won't use his name here... Let’s use that as an example in giving/receiving feedback.

Adrian: Hey Jerry… I want to talk to you about something. The coffee thing isn’t working for me. You’re not satisfying my requirements. The coffee is frequently too hot, and you’re always late with it. I’m really annoyed with you.
Jerry: I don’t know what you’re talking about. I always get that seam thing right… well, most of the time. And I can’t control the heat of coffee. And I’m not late with it. You must be delirious. I’m doing the best I can. I’m better at getting coffee than David was.
Adrian: Come on, I know you can do better. Please, let’s get that coffee thing fixed.

What’s wrong with this dialog - everything?

No. There is something good here…. There is a bit of specificity in the feedback. There are three things brought up here… the heat of the coffee, delivery timing, and the seam facing the right way.

There are many things wrong with the dialog. Adrian is making several common mistakes.

Adrian should give positive as well as negative feedback. We tend to speak up when something is wrong and focus on what’s wrong. We should find opportunities to give positive feedback in relation to the negative feedback. So something like

Adrian: Hey Jerry… Thanks for getting me coffee. The other day when I got in, I was so rushed and needed to get off to a meeting; it was nice to have my coffee right here ready to go. It made a huge difference in my day that day. One thing I’ve been meaning to mention – it seems to be too hot sometimes. Last Thursday, it burned the roof of my mouth. Was there something specific you did that day that caused it to be hotter than usual? Is there some way that we can get the temperature down a bit?
Jerry: Gee, I don’t know. It may be that you got it that day right when I returned from the coffee shop. I can’t control the temperature of the coffee they serve, but perhaps I could get some ice cubes and have them available for you. Would that work? Or perhaps if you called when you are 10 minutes away from work, I can get the coffee then, so the coffee has some time to cool.
Adrian: Those are great suggestions. I hadn’t thought of ice cubes. Don’t worry about getting them for me; I’ll just get one and pop it in if it’s too hot.

Notice the difference in the tone of the conversation. Adrian and Jerry are collaborating in finding a way to get the heat of the coffee right. Also – Adrian is being much more specific.

It is critical in giving feedback to find instances where the results were not acceptable. “Last Thursday” provides a very specific example that Jerry can think back to. Last Thursday is also relatively timely. We’re not talking about last month.

The coffee being “always late” is clearly not accurate. Again, by providing specific examples and focusing on the behavior or results rather than the person, you are more apt to get the results you seek.

Here are some attributes of effective feedback:

• Specific – rather than general. With specific examples.
• Sharing impact. Why is the behavior a problem? What was the impact of the poor performance to the team, to the company, etc.?
• Timely – both in relation to the incident/behavior, and in terms of the recipient’s receptiveness (e.g. not when the person is on their way out the door or troubleshooting a high priority production issue).
• Focused on the behavior, not the person

There are more, but this is a start.

Next time, I'll address receiving feedback.

What's in a blog? Facts? Or Insights?

I recently viewed the blog of a colleague who was detailing a vacation he took. Much of the content was around the facts of the journey - the cab picked me up, the plane was late, etc.

I get more out of blogs that reveal insight rather than sequences of events. We bloggers should seek to convey insights rather than facts... and relegate the details to a journal or something private (still not sure what value such a collection of facts would provide).

I promise to seek to avoid regurgitating facts in favor of sharing insight here.

Sausage Making

Otto von Bismarck – the “Iron Chancellor of Germany” in the 1800’s is said to have made this observation:

"Laws are like sausages, it is better not to see them being made."

The comment suggests that the making of sausage is a messy business. It’s better if you just avoid thinking about what goes into making the sausage and simply enjoy the results. Similarly, the making of laws is a messy business that can be unappetizing.

I use this reference quite a bit on projects. The extension to this in the software development world is:

"Software Releases are like sausages; it is better not to see them being made."

Software development sausage making includes our development approach (e.g. points, burnups, self-directedness) and in some cases, our technology choices. I have, at times, made the mistake of opening up the “sausage making” process for stakeholders to assess, critique, and well…watch. Sometimes this is appropriate. For example when getting into detailed conversations about cost/benefit analysis on technology purchases, or to determine whether those choices are in line with the corporate IT strategy, it makes sense to discuss them. Too often, though, I think we make the mistake of getting caught up in discussing the sausage making with stakeholders in many cases where, frankly (sausagely?), they might be better off not knowing how the sausage is made.

This is a classic mistake that technologists make. We get so enamored of our technology and our process, that we think everyone else must be interested in how we do our work.

We should focus stakeholder reviews more on the array of sausages we produce, rather than how they are made. Don't show iteration burnups, or discuss the nature of a "point" in the estimation process. Apply an adapter/interface on the information to convey only that which is appropriate to the audience. Consider this a sausage casing, if you will, that abstracts the detailed content regarding the inside of the sausage. So, rather than discuss with them that

"This sausage is almost done – it needs some fennel, and a little more pork fat, and a touch of lard."

we should be saying something like

"This sausage is almost done; we are 85% confident that it will be available for consumption in the mid-April timeframe and 98% confident that it will be ready in time for the Memorial Day picnic in May. If you want to increase the probability that it is delivered in time for April, we can eliminate one of the ten sausages we have slated for April and refocus on this one."

It is in these conversations that we provide our stakeholders with information that is suited to their digestive profile.

Laser pointer token

It is sometimes challenging in standups to associate the card to which the speaker is referring to the conversation - particularly for infrequent guests. A low tech solution that I recently implemented for my teams is to use a laser pointer as the token that gets passed around. As the speaker is referring to cards on the wall he/she is expected to point, using the laser, to the cards(s) in question.

An ancillary benefit to this approach is that it can be an early warning sign for scope creep when a team member has no card to reference. It can also be a warning that cards are languishing in the "in-play" section - if nobody is referring to those cards, they may not be getting the attention you desire.

They're pretty cheap too.... you can get a laser pointer for as little as $10.