Can we talk?

One of the most important facets of just about any successful endeavor involving two or more people is the communication between the people. If the communication is good (honest and direct) it greases the wheels for all the other things involved with the project. If the communication is bad (withheld, indirect or otherwise lacking) it will eventually allow problems to grow and impede the project, if not derail the project directly.

I realize this is not a ground shaking realization, but when I look around I still find it surprising how many examples of poor communication exist. A personal example, I was recently involved in coordinating some volunteer work locally, and due to poor communication found that not only was there a lot of confusion, there was also a considerable amount of frustration. By addressing this, and formalizing the communication, the confusion and frustration went away. (We were done in by the weather, but that’s another blog entry) Another example that I recently read about was the a review of a project that was replacing Maine’s Medicaid processing system (read more at http://www.cio.com/archive/041506/maine.html). This project suffered from a number of problems, but one that stood out for me was that the people in charge of managing the project knew that early on that they needed more resources to meet the deadline, but felt they couldn’t ask a government organization for them. They knew the project was doomed, but continued marching forward! The problem wasn’t discussed when it might have been possible to address it.  Obviously there was more going on here than poor communication, but I’d bet that just about every problem was amplified by the lack of communication and the communication problem existed at all levels.

The thing that got me reflecting (and writing) about this was a conversation after a recent standing meeting on one of Visionpace’s .Net projects. During the conversation, I asked the team if we were doing all that we could with respect to one aspect of the project. (My belief is that we could do more. It’s not that there was a problem, but were we doing everything we could to maximize the value to our client?) I got some push back from the team and continued to pursue the topic. This led to an impassioned response by a couple of members on the team.

I’ve worked in environments in the past that viewed conflict as something that was not conducive to a good working environment. I think that conflict, the strong disagreement and back and forth that should accompany it, represents a level of honesty and integrity present in the communication between the participants. It’s a lot easier to avoid conflict in a lot of environments. This could actually be a disservice to the organization, especially if the person avoiding the conflict has some valid ideas and possibilities that aren’t brought out because of this avoidance. Note that conflict isn’t yelling back and forth or stomping off mad at another person. That’s called a tantrum and has no place in the workplace.

Anyway, here are some questions I consider when reviewing the state of communication in a project:

- Have I established a relationship of trust and integrity with all of the participants on the project? Have I worked to build and further that relationship? (If the answer is No, stop everything else and figure out why not.)

- Have I asked direct questions to the team and gotten direct answers?

- Have other people on the team asked direct questions and gotten direct answers?

- Has the team been reviewing, critiquing and otherwise discussing the project on a regular basis?

- Have difficult subjects been broached in conversation? (Even if they aren’t immediately resolved, have the hard questions been asked.)

- Is there anyone that is much quieter than the rest of the team? If so, have I asked them why? (In a private conversation?)

- Is there anyone that controls most of the conversations? If so, have I asked them why and asked them to tone it down for a while to see if others start talking more? (In a private conversation?)

- If an issue is found, or a risk identified, is it discussed openly with the team?

- Is the atmosphere one of mutual respect for the entire team?

- Has anyone disagreed strongly with an idea or direction on the project? How often. (Too often can be an issue with someone that is disgruntled. Not often enough could mean that the issues are being avoided.)

- Does the team ever have a chance to build a relationship outside of the project? (A lunch brought in and a conversation about anything other than the project can start this process.)

This is a partial list. The key is that good communication doesn’t just happen. It takes specific work and nurturing over a long period. Like trust, it’s something that can be lost very quickly and should never be taken for granted. If the communication isn’t present, the odds are against the project succeeding.

Beyond the standing meeting

I recently posted a blog with some thoughts about standing meetings so I thought I’d post some thoughts on another regular meeting we conduct at Visionpace. The goal of this meeting is twofold: to keep the company higher ups appraised of the status of  projects that we’re working on and allow us the ability to continuously ‘inspect and adapt’. I refer to this meeting as the PRM (Project Review Meeting, catchy huh?)

This meeting occurs weekly and includes Russ Swall (owner) and Doug Bliss (COO) and me. In the meeting we review all the projects that are in process or on the horizon. The amount of discussion about each project depends on aspects of the project (size, complexity, resources involved, customer requirements, etc.) We review the projects in alphabetical order of the last name of the developer involved with the project (seems to be as good as any other order) in order to make sure we cover all projects. Some of the information that we review include the projects’ velocity and burn down reports, any potential risks or issues that might need to be addressed in the project. If necessary, we’ll either determine a course of action or set a follow up date and time where we’ll continue the discussion.

The format for this meeting is fairly open. We don’t have minutes though each of us takes notes on items we need to do as a result of the meeting. We also don’t have a set time limit on the meetings. They usually run an hour or two. From a project management perspective, the real benefit of these meetings is that as I describe an issue or facet of a project, Doug and Russ can weigh in with a broader view of the subject, or identify a potential issue that the team might not be addressing. This provides a safety net of sorts, in that during the iterations we can focus on the work at hand by following our process, as well as keep an eye out for potential problems. We’re also able to separately step back from the projects and tweak the process.

The fundamental tone of the meeting is one of trust and respect, so I don’t feel pressured to try to defend my actions or protect my job. Rather I have the opportunity to openly and honestly discuss the projects, any thoughts or ideas that I have about the projects or the company in general, and any areas that I need help. Doug and Russ are also free to ask questions and make observations without concern that it might be misunderstood as a personal critique. This leads to two specific benefits for the company. First, the things that we are doing right can be leveraged even more because we discuss what, how and why as well as what’s next. Secondly, areas that need more focus are identified and the risks/issues are addressed fully and a plan to address the issues is determined.

Some of the key elements to the success of these meetings:

- Trust. All the participants understand that everyone’s motivation is to our customers, and in turn to Visionpace.  The conversations are never a personal attack. When Doug says something like, “Martin you need to focus on…” he’s not commenting on my abilities. Rather he’s identifying an aspect of my role and responsibilities that need attention.

- Focus. The meeting is to discuss ‘this piece of work, involving this group of people, in this environment, right now and right here.’

- Candor. Things that need to be said are said.

- Regularity. We have the meetings weekly allowing for a continual review and adaptation of our processes.

- Multiple perspectives. Both the long term strategy and short term actions can be discussed to make sure they are compatible.

- Shared commitment to our clients. I don’t have to be the one to come up with a solution or action to manage every facet of a project. I can rely on others in the company to help me, and help keep me growing.

Conducting a regularly scheduled, honest review meeting will not guarantee success for an organization in itself, but it goes a long way toward keeping the organization on the right track and continuously improving. If you’d like to learn more about this type of meeting and how to start doing this in your organization, please feel free to contact Visionpace.

Ask for a general question, get a general commitment.

I don’t know if this has ever happened to you, but when you are in the middle of a project (not even a business project, but say coordinating some volunteers for an event) and you ask around for help in general terms.  You know the conversation it sounds something like “Hey Jan. I’m heading up the refreshments for next weeks Scout meeting.  Would you like to help by bringing some cookies or maybe help setting up?”  Usually the people you talk to agree to these general commitments.  After two or three conversations like this you start feeling good about the project and have a sense that you’re going somewhere.  Then it hits you, all you’ve done at this point is ask two or three people if they are interested enough in what you are doing, to possibly take part in it.  At this rate, you could have ten people ready to help and waiting for further instructions in no time.

What really needs to happen is you have to have a plan, even a rough one, at the outset. With some sort of a plan, you can ask for a specific commitment like “Jan we need refreshments for next week’s Scout meeting. Would you be able to bring two dozen cookies on Tuesday night?”  After asking this, you wait for an answer (a specific commitment.) Then if you need to you can follow up with “Great! Thanks.  Also we will be setting up for the meeting at 6:45, can you be there to help?”  This benefits both you as the coordinator since you have a better idea of what to expect, and the person you are asking as they have a clear idea of what is expected from them.  It’s a simple concept that sometimes gets lost. The problem is that when it’s lost, you eventually have to go back and ask everyone that gave a general commitment for a specific commitment.  

I was reminded of this earlier this week when talking to one of Visionpace’s .Net development teams.  The conversation was concerning code coverage for our unit testing and my initial question to the team was “Are our coverage and testing scenarios sufficient for these user stories?”  Just as I asked the question, I realized it was too general.  Before I could rephrase the question, another teammate spoke up for me and said, “I think what Martin is asking is two questions. A) What is the percentage of coverage we have for the different modules on the project? B) Are we testing the ‘happy path’, boundary conditions and ‘unhappy paths’ for all unit tests?” He was right. His questions got to the specific meaning of what I wanted to know and he asked questions that the developers could give specific answers to.  Had the questions not be rephrased, I’m sure I would have gotten the equally general answer of ‘Sure’.  The answer is valid, but because of the question, I’d most likely have to ask the more specific questions later.  Instead we were able to talk about specific areas of the project that needed further testing for boundary conditions and testing the unhappy path.

One exercise that I do occasionally is to go 24 hours and consciously make sure I don’t ask any general questions.   After I do this, I find that I continue to ask more specific questions without thinking about it.  Of course this leads to other issues when it comes to my kids. Rather than ask “Have you done all of your chores?” I’ll ask “Has the laundry been put away? Have the dishes been put away and the dishwasher loaded? Have you cleaned your room?”  One of my kids might answer yes to all the questions and bound off to their room.  When I follow up with “Why is the living room dirty?” the answer is usually “You didn’t ask me if the living room was clean…..”  Se la vie.

A few thoughts on standing meetings

On the surface, the standing meeting appears to be one of the most basic and straightforward components of an agile process. At a specified time, and on a regular (daily) interval, the team gathers and each person states what they did since the last standing meeting, what they will do by the next standing meeting, and identifies anything that stands in their way.  The meeting itself is designed to take 5 minutes or so.  However just about anyone that has worked in the software industry for more than two weeks will tell you, things are seldom as they seem on the surface.

Among other things, an effective standing meeting will:

-         allow all team members review what the remaining tasks are for the current iteration on a regular basis throughout the iteration, and track the progress regularly

-         identify potential problems (sooner rather than later) and prevent thrashing

-         constantly reminds the team as to what the customer deemed were the most important stories to work on for the iteration

-         prevents gold plating or working on non-priority user stories by constantly updating the team about your progress.

The standing meeting will not:

-         magically ensure that iterations goals will be met on simply because we’re meeting daily

-         replace the design/inspections/review discussions that need to take place

-         increase the overhead on a project (if they are executed appropriately).

In order for standing meetings to be effective, a lot of other things have to be in place. Things like user stories that can be broken into tasks for planning the development and then tracking the iteration. Testing (both unit and acceptance) to ensure that when a developer feels they have implemented a task, the code can be tested to ensure that it is in fact working and didn’t cause any unanticipated problems. The team has to be trusted enough to be able to have open and candid conversations about the project. The meeting has to be consistently scheduled so everyone knows when and where it is and so they can accommodate it (attendance is critical). The meeting has to follow a consistent format, so the necessary information is delivered in the shortest time possible. If issues or problems are identified during the standing meeting, they should be addressed in a separate conversation with the appropriate parties. (The entire team may not be involved).

During the iteration review, the effectiveness of the standing meeting should be discussed by team to see if there are any changes that need to be made.  During the iteration planning, the tasks should be broken down in such a way that they’ll lend themselves to supporting the standing meeting. (Having five fifteen hour tasks does not lend itself to iteration tracking as 14 four hour tasks). 

As stated a lot needs to be in place in order to be effective, but in order for a project to be optimally successful, having regularly scheduled and formatted standing meetings is crucial.

Cellular Routers and the Last Mile

Over the last ten years a lot has been written about bridging the gap for the last mile (http://en.wikipedia.org/wiki/Last_mile) and given that I live pretty close to the end of the mile, I’ve been interested in the different technologies as they developed.  Since the phone and cable companies aren’t interested in running high speed service to my place (too few houses to make it profitable) and I wasn’t too keen on the prices for satellite based broad band hardware, I’ve been watching the cellular telephone industry as they have been releasing new technologies. 

Finally I have found a solution that I felt met my needs. I recently purchased and EVDO PCMCIA card (think cell phone on a network card) and a cellular router from Kyocera. (I went through the site http://www.evdoinfo.com. No affiliation, but they have a lot of good information and made for an easy online purchase.)  I was able to activate the card and configure the router in less than 30 minutes, following the instructions included with both.  Once configured and running, I had a WEP encrypted WiFi hot spot throughout the house. I haven’t used my PocketPC to see how far away from the router I can get a signal, but the signal is strong throughout the house.  The other benefit of this setup, is that when I travel I can take the card (and router if I want) with me and have high speed internet anywhere Verizon has the service available. Right now this is around most metropolitan areas, but is expanding. If the EVDO service isn’t available, the connection defaults to standard dial up.  The router also came with a 12v power cord so you can create a WiFi hot spot from your car.  Lots of potential. In fact one guy in

New York

is using this in a way that will almost surely end up as part of the basic gear used by police and fire personnel, and possibly even the military.  (See more at http://www.evdoinfo.com/The_News/Latest_News/ShakinDave_-_Portable_EVDO_WebCam_in_Eye_Glasses_20060327703/)

I’ll leave it to those who predict technologies on a regular basis to project when this kind of cellular data transmission becomes ubiquitous, but my prediction is that this market will continue to grow for a couple of reasons:

-         the basic infrastructure (towers, repeaters, etc.) is in place

-         it doesn’t require launching and maintaining geosynchronous satellites

-         you don’t have to drop cable to keep the service (no right of way, no maintenance, no back hoe’s)

-         as the technology advances and demand increases, the infrastructure for that area can be advanced as needed maximizing ROI

The end result, I think, is that in the not too distant future we’ll see companies like Verizon and Sprint offering video and television, much like Vonage offers telephone service over traditional data lines. It’s a brave new world and I like it!

In support of Big Visible Charts

If you’re not familiar with the concept of displaying critical project information in a very direct and low tech way, I recommend you do some reading on big visible charts. Ron Jefferies has an excellent write up on this at http://www.xprogramming.com/xpmag/BigVisibleCharts.htm.  I bring this up because we recently had a reaffirmation the benefit of big visible charts during an iteration review meeting for one of our .Net projects. During the iterations for this project we are tracking the iteration burn down in hours on a large sheet of paper posted in the war room. In this instance, a situation occurred that required us to task out user stories twice during the two week iteration. (We tasked out a week’s worth of stories at the beginning and the middle of the iteration.) As part of the daily stand up meeting, we update the iteration burn down with the hours remaining for all the tasks. This reflects tasks in the back log and tasks in process. It would go up and down as we reassessed the work remaining on tasks in process and, new tasks missed during the task break down, tasks implemented, etc.

The benefit of having this chart was that during the iteration review, when we discussed velocity and ways to increase the velocity, the developers got up and walked over to the burn down and began to discuss the changing slopes; when it dropped the steepest, when we tasked out new stories mid-iteration, when it wasn’t as steep a drop, etc. This conversation lead to two distinct behaviors that we’ll adapt on future iterations, to help maximize the iteration burn down and thus overall velocity. We might have determined to adapt these behaviors without the presence of the iteration burn down, but the amount of effort to create and update the chart is negligible and it provides a direct sight to what’s important to any project, progress. The best thing about it was that the developers had the discussion without any direction from management and determined the behaviors to adapt. This means that the behaviors are easier to implement and follow.

If you're interested in the behaviors we're adapting, email me at: molson@visionpace.com