A Common Vocabulary

A while back I asked if ignorance and close-mindedness meant the same thing. Admittedly, I asked this question to prove [to myself] that I was right and someone else was wrong. With the passage of time, that motive has all but vanished leaving behind a stellar example of a necessary component of communication: a common vocabulary. When this component is missing, communication can't happen. It's like taking your hair dryer to Europe and plugging it in with your converter set incorrectly. The appliance tries to run for a few moments and then the motor burns out because it's being supplied with the wrong voltage.

This all started on Facebook when an acquaintance of mine posted the following:

It struck me as odd that he should be so perturbed by ignorance. I have a very distinct memory going back to the start of my sixth grade school year. My teacher that year was quite the literary scholar. A few days before the start of school, the teacher held an informational meeting for all of the students and their parents. It was a means for everyone to get to know each other a little better and go through the daily schedule and other things about the impending term. I have no memory about the context anymore but somehow he was explaining ignorance. He said that there was nothing wrong with ignorance; it was simply not being knowledgeable about something. For some reason this has stuck with me all these years.

I asked my acquaintance if he really meant close-mindedness rather than ignorance and explained how I believe that those two terms express different meanings. This sparked a lively debate in which he contended that they mean the same thing.

This one word, just 9 letters, caused a communication impasse. This was just a Facebook post that had no weight of importance whatsoever. Just imagine though the implications of how a one-word communication misalignment can affect an outcome between a supervisor and employee. What about in a contract between client and vendor?

Verbal communication is a pretty complicated process and even though we start it at a very young age, it's still easy to muck it up well into adulthood. If my manager says she wants something done "right away" that could mean

1. Stop what I'm doing now and switch to that other task
2. Finish what I'm doing and then switch to the other task next

But it also has to be taken in context. Should I work through lunch or stay late? Is there a client call schedule for later in the day? Is the developer going to be out of the office tomorrow?

I think the key principle here is to eliminate ambiguity whenever and wherever it is perceived. Ask questions. Be explicit with expectations.

With my conversation above, six out of six respondents to my survey said that ignorance and close-mindedness did not mean the same thing. But there is that seventh person out there that has a different understanding, regardless of the situation.  He might be someone new that the client brings onto the project after the contract has been written. We don't always share a common vocabulary but by being proactive about the seventh person lurking out there and then being as descriptive as possible, even of that which seems obvious we can ward off problems before they happen.

Don't Judge a Book By Its Cover

We teach our children not to judge books by their covers. Literally, when they're young and start picking out books to read themselves, not to do this. A book may not have any eye-catching artwork. It could be worn and tattered. The plot introduction on the back might be unappealing. And so we try to instill in them that before forming an opinion about a book you should dive inside and get to know the full story. As children age, this proverb takes on a broader meaning that we shouldn't make snap judgements about other people. Just because someone has tattoos and piercings it doesn't mean he's a felon. Just because someone is clean cut it doesn't mean he's a nice person or trustworthy.

And so all our lives we're taught not to jump to conclusions. Then we grow up, make a career in software development, and that all goes out the window. "How so?" you ask?

Estimates.

It seems most our work starts with estimates. Someone contacts us wanting a new website. They want to know how long it's going to take and how much it's going to cost. If we told them we'd let them know when we're done, they'd get up and leave immediately, laughing all the way. A conversation is had. Likely several conversations are had. The potential client might even have a pretty detailed outline prepared of what they want. If they have an existing site that they want redeveloped into something befitting 2013, we'll do an thorough analysis of it. Nonetheless, we still have to make a judgement call based on a cursory amount of information.

Is this a bad thing? Nah. I don't think so, and I'll explain why in a second. But, I want you to realize that that is what we do all the time as a matter of practice. Think about it. Turn that over in your mind. Chew on it.

Despite what our parents teach us about making snap judgements regarding books and people, we're actually trained to do that sort of thing all the time. The light just turned yellow - slam on the break or step on the gas? Sweetie-Pie wants to know when dinner will be ready. A guy named Big Precious is selling iPads out of his trunk. We spend hundreds of thousands of dollars on a home and even though we have inspections, you still don't truly know what's hiding behind the walls.

Still chewing? Even though we get a lot of practice at making calls based on the information currently available, isn't it still just a little crazy what we do? Saying this is how long a project will take and this is how much it's going to cost? Software development is some complicated sh!t. Technology is constantly changing. Requirements have ambiguity. There are hundreds of things that can happen to cause the most accurate estimate ever to be completely destroyed. Quoting the wrong numbers can not only spell the end of a business relationship but the end of the company.

I think it's messed up but I realize the client is just mitigating their risk. They don't have unlimited money and they don't have unlimited time. It really isn't unreasonable for them to know how much and how long.

There are many ways we can mitigate our risk too including:

1. Gather as much information as possible
2. Use what you've learned from previous experiences
3. Add in ample wiggle room

The big thing though is to be painfully transparent with the client once you crack that project open and dig in. Let them know your progress. Alert them ASAP when reality isn't matching up with the assumptions initially made. If an unexpected complication pops up, sound the alarm. Let them get their hands on the product early so they're not surprised by anything either. Keeping the client informed gives you leverage to negotiate changes to the schedule and cost. The clients are people too. They know things happen sometimes but they deserve better than to be blindsided.

I'm probably not saying anything new here but I hope that I'm putting our process in a perspective that helps us to use it more effectively and keep from getting burned.

Channeling Emily Post: Meeting Etiquette II

A few weeks ago, I wrote about some tips on how to be courteous when scheduling a meeting or receiving an invitation to a meeting. Today I present the companion, being courteous during the meeting.

Meeting courtesy begins long before the meeting actually starts.

• Do your homework: If you've been asked review a document or perform some other preparation, do it at least a few hours in advance so that you can be thorough and have enough time to let it sink in.
• Prepare your handouts: If you're providing handouts, print them early because the printer will always jam and take longer than "normal".
• Use the restroom before the meeting.
• Arrive early enough that you can be ready immediately at the scheduled start time - no waiting to find a find a clean sheet of paper, pour your coffee, or boot your laptop.

During the meeting:

• Be sure to have brought a notepad, tablet, or laptop so you can take notes. Don't expect that you'll remember everything you need, a handout, or a post-meeting summary.
• Put your phone on silent and check your messages after the meeting. If your presence at the meeting isn't important enough that you think you can be checking your messages, then why are you at the meeting? If an emergency does come up then the meeting should be postponed so that everyone can participate.
• Be an active participant - ask questions and offer personal perspective when appropriate.
• Remain focused on the topic, don't start unrelated conversations with other people in the room.
• End the meeting on time.

After the meeting:

• If you uploaded files to the meeting room computer, remove them and turn off all  equipment.
• Clean up after yourself - if you have garbage (e.g. an empty coffee cup), throw it out; if you provided refreshments, don't leave the remnants in a mess
• If you've been assigned a post-meeting action item, complete it promptly.

The universal key to etiquette is to be considerate of other people. Treat other people, their time, and their property how you would like to be treated. Keeping this in mind should make meeting etiquette a breeze.

Channeling Emily Post: Meeting Etiquette

When your team grows beyond a handful and staff members have obligations to multiple projects, inevitably scheduling collaborative meeting time can be tricky. And then "tricky" turns into "frustrating" when common courtesy becomes extinct.

You can help save your coworkers some frustration by keeping in mind a few simple guidelines when it comes to scheduling meetings:

1. If you receive an appointment request, please respond promptly so that the requester can reschedule if necessary.
2. Please make sure all time unavailable is recorded on your calendar – out of office, personal appointments, vacation, etc. Even if you're working from home, it's nice for that to be indicated on your calendar because some meetings just can't happen by conference call.
3. For meetings outside of the office, please make sure the duration of the unavailability includes travel time.
4. If reserving a conference room, make sure it is included on the appointment, even if it's a spur-of-the-moment meeting.
5. If you have previously accepted a meeting request and can no longer attend, please decline promptly. Your presence at the meeting may be essential which could require the meeting to be rescheduled.
6. If you scheduled a meeting and can no longer attend, please cancel promptly so that attendees can remained focused at their current task.

Remember, meetings occupy the time of multiple people. Failing to apply a small amount of consideration can cause a huge waste of time. The wasted time isn't just when staff is sitting around waiting for someone to show up but also in the time that they require shift focus back to their other work. Courtesy also helps to keep meeting productivity maximized by preventing attendees from stewing over other attendees showing up late or not at all.

Update: Read the sequel about etiquette relating to the meeting itself.

Two Keys for Effective Defect Reports

When I was in high school, a class that I was in was given a writing assignment. This was a type of class that ordinarily wouldn't have writing assignments and so the students were a little unsure as to the requirements. One of my classmates asked, "How long should the paper be?" And the perverted old man replied, "The paper should be like a woman's skirt: long enough to cover the subject but short enough to still be interesting."

Today I want to expound upon effective defect reports. I am an absolute stickler for detailed defect reports. I have no problem sending issues back that don't have sufficient information. Defect reports are adult writing assignments and we need to make sure that we are including all of the necessary information. I could run down my list of criteria that I expect in every bug report, but you can find those types of lists lots of places. Besides, the list, like everything in testing, is context-oriented.

As inappropriate as my teacher was, he did imply an important point: it's not about a measurement, it's about accomplishing a purpose. Skirts, and clothing in general, maintain a certain level of modest, protect us from the elements, and evoke intrigue. Defect reports, must be able to fulfill two very important functions, otherwise they are a failure.

An effective defect report makes reproduction and troubleshooting as simple as possible.
More often than not, the person who discovers the defect is not the person who resolves the defect. This is a simple efficiency issue. If you have a PM or Scrum Master reviewing issues, they need to be able to assess the priority and assign the issue to the most appropriate developer. The developer should be able to understand what's going on without having to guess or ask additional questions so they can spend less time identifying the issue and more time fixing.

An effective defect report archives the defect.
The purpose of this is for testing. Often times, the person who discovers the defect is not the person who verifies that it has been fixed. The tester needs to be able to know exactly what was wrong so that when they test the resolution, they can determine beyond a doubt whether or not the defect is fixed. If the tester doesn't know precisely what was wrong, it's impossible to know if it's fixed.

If your bug reports fulfill those functions then you're well on your way to getting an A+ on your writing skills. Remember, context is everything - sometimes bug reproduction is elusive and sometimes a conversation can convey imporant information that is hard to express in text. If you keep mind of the purpose then the details will fall into place.

Squeeze or Slice?

When it comes to planning the scope for an iteration, I generally think of two different approaches: squeezing and slicing. So which one are you? Are you a squeezer or a slicer?

The Squeezer

• Tries to get as much out as possible in each squeeze
• Some squeezes go "Splllppppppt!" and hardly anything comes out
• More oozes out after you stop squeezing
• You don't know how much the bottle holds
• Even if you may know the bottle is 8oz, you never know for sure how much is left
• You have to pound the end and squeeze repetitively to get the last little bit out

The Slicer

• Each slice is more or less the same size
• You can see exactly how big the loaf is and how many slices are left
• Only the supernatural keeps the loaf from running out
• There are just a few crumbs to brush up after the last slice

As you may have guessed, I'm an advocate of the slicing system. The characteristics mentioned above are maybe a little bit euphemistic because in reality, software projects are not factory baked and sliced bread. They're homemade and each slice is cut individually. When you first pull the bread out of the oven, you might ideally want the bread to be sliced into 10 pieces. However, after the first slice or two, you might find that the bread is heavier or lighter than you thought prompting you to make thinner or thicker slices going forward. If you slice off more than you can chew, it's easy to cut that piece in half and save the rest for later. You don't always know how many loaves there will be before you're done baking and slicing but you always have an easily manageable unit.

I like slicing because planning is "baked in". Each iteration isn't like a spin of the roulette wheel. You can respond to experience and adjust accordingly. And you always have a clear vision of what the end is and when it will come.

Fast, Good, Cheap, and _______

The Triple Constraint or Project Management Triangle is a device that describes opposing variables in project management. The variation that I'm most familiar with has the three sides of the triangle representing: Fast, Good, and Cheap. The principle is that, when applied to a project, one variable must suffer at the expense of the other two, whichever one that is, or vice versa. For example, you can have a project run fast and deliver a good product but it won't be cheap.

Who says you have to sacrifice though? It's really not a "who" but a "what", which I recognize thanks to a recent post by Catherine Powell. (Our models differ but it's because of her that my brain got to thinking about this.) There's a fourth project component missing from the model and that's Scope. The fourth variable necessitates compromise but before talking about how Scope comes into play, let's review how the Project Management Triangle works. There is a variable for each side of the triangle A, B, and C and a fourth variable for the perimeter of the triangle D. The perimeter is fixed so that no matter what, A + B + C = D. If A increases, B and/or C must decrease. If A and B increase, C must decrease.

Why does the perimeter have to be fixed? Let's face it, most projects, if not all, have one thing that is 100% non-negotiable. In the Fast, Good, Cheap model, this is Scope. Without answering "what is this project about" you really don't have a project. Even if a project has more than one "non-negotiable," one will still trump the other.


As you may have recognized, the three sides of the triangle are not permanently designated Fast (Timeline), Good (Quality), and Cheap (Cost). Rather, the three sides are that which is not the paramount non-negotiable perimeter.

For Example
Timeline: The client needs a website to go live at the same time as a huge marketing campaign
Quality: The website must adhere to government regulations
Scope: The functionality of the website has to include everything specified
Cost: The expense of the project cannot go one penny over

Let's now apply these variables to the sides of the triangle. When a side of the triangle is benefited, it gets longer but it gets shorter when penalized.

Variable	Benefited	Penalized
Timeline	Decreases	Increases
Quality	Increases	Decreases
Scope	Increases	Decreases
Cost	Decreases	Increases

Using the Fast, Good, Cheap model for the three sides, let's say Scope is our fixed perimeter with a non-negotiable set of requirements. Let's say the company wants a bigger profit margin, which is in essence cutting the cost. If we want it to stay on time, the quality will suffer because of reduced testing. If we want it to maintain quality, the timeline will suffer because of less-skilled (i.e. cheaper) labor.

Under ideal circumstances, we'll have an equilateral triangle. This requires doing your homework up front. Figure out what your non-negotiable variable is and then set the remaining variables based on that. Doing this should minimize the need to make compromises enabling you to not have to change anything. If change is necessary and compromises are undesirable, the only way to change the perimeter is to change the contract either through a change order or a completely new contract.

Thoughts on Effective Project Management

Effective project management and execution has many components. To name a few that comes to mind:

• Planning
• Communication
• Cooperation

Projects don't always go smoothly though and so we compensate with:

• Process
• Documentation
• Incentives (or bribery)

Don't get me wrong, process, documentation, and incentives are not bad things but they're not guarantees for great projects. Just because you have process doesn't mean your project will be executed well. Just because you have documentation doesn't mean the project will be universally perfectly understood. Just because you have incentives does not mean your team will be motivated.

When the project struggles, don't panic and don't think that there's going to be a miracle cure. So what should you do? Breathe. Relax. Rather than jumping to a change in the model, figure out first if the model is being effectively executed. Sometimes all it takes is some individual coaching or team training.

Think for a second about treating a medical ailment:
Symptoms: Excruciating pain, being unable to walk or stand
Solution: Prescribe heavy medications, such as Oxycodone. If you can't feel the pain, then what does it matter right? But if you only treat the symptoms and don't fix the problem, the symptoms will reoccur as soon as the drugs wear off.

Problem: The leg is broken
Solution: Set the let and/or perform surgery to bolt the bone back together. YES! We are out of pain and we're mobile again. But if you only fix the problem and don't eliminate the cause, then someone is sure to come along and break their leg--OR WORSE!

Cause: The rug is bunched up
Solution: Smooth out the rug. If the rug is prone to bunching, tack it down or figure out what causes it to get bunched up. Perhaps it's to close to a door that opens frequently. If tacking is not an option or it can't be moved further from the door, replace the rug with one that has a non-slip back or that is shorter.

I contend that most issues in project management and execution are like this. Simple causes that, when ignored, cause expensive problems and exhibit symptoms disconnected with the cause itself. Fixing the rug is a simple fix. It's not a change to the model, it's just taking the existing model and working the kinks out.

[Not] Everything Is Urgent!

When projects get down to the wire, sometimes certain people (you know who they are) become prone to throwing out the rules for determining defect priority. As I previously wrote in Prioritizing Defect Reports, there are four factors that I consider when setting priority: Severity, Exposure, Business Need, and Timeframe. Unfortunately, Timeframe becomes a stumbling block when they fall prey to the terminal thought, "The deadline is right around the corner and all of these issues need to be done, therefore they are all Urgent!"

I call this a "terminal" thought because it leads to a disastrous method of project management: panic. Panic management occurs when organization goes out the window; and that's exactly what happens when all issues are prioritized the same. The priority indicator loses its value. Even when time is running short and all of the issues are crucial to launch, issues varying levels of priority and some need to be done before others. And what happens when nothing has any priority? Developers decided themselves which issues to do and when.

When we get to crunch time, I think it's appropriate to not only redefine the spans of time for the Timeframe factor but redefine the factor. Instead of thinking about a Timeframe, think about a Sequence:

• Urgent: Drop everything and work on this
• High: Complete before working on any lower priority issues
• Normal and Low: After confirming with the project manager that there is nothing more important that needs to be done, concentrate on the Normal priority issues first but may incorporate Low priority issues if there's an efficiency advantage. Low priority issues are completed last.

By maintaining your system of priorities, you'll help keep your team focused and everyone will have a clearer vision of the outstanding risk in meeting the deadline.