Published Articles

July 3, 2009

“This is now our number-one priority, and this issue is causing me some real pain. Can you expedite this?”

Does that question sound familiar? If you’ve worked in the software world even for a short period of time, you’ll be confronted with an appeal like this to resolve a defect, overcome a performance bottleneck, or enhance existing software in some way. And while my general rule is to keep people focused on agreed-upon priorities, there are still times when priorities need to be adjusted.

A development lead who worked for me was faced with the need for a customized report as part of an ongoing project with a customer. Of course, this was elevated to a critical status a few days before a schedule delivery to the customer, and that delivery did not include this report. In reality, this was not a new report. The customer was requesting that we change an existing report, modifying the output from a PDF format to an Excel spreadsheet.

Everyone in our organization empathized with the customer’s needs, since it helped them balance information between two disparate systems that was critical to the customer’s business. Of course, there were some in our own organization who felt it was necessary to “lobby” on behalf of the customer, and did so by talking directly to the lead developer on the project team.

As you might expect, the project team was doing all that they could to meet a delivery date that was only a few days out, and they did not have any time on their hands to add this request. This lead developer didn’t exactly have free time on his hands, either.

However, because the team was already stretched, the lead developer opted to take this task on himself. Developers are people who want to do a good job, and they want to be helpful. This particular individual happens to be a highly motivated person who didn’t want to let anyone down.

He quickly determined that the tool that we were using to generate our PDF reports had the capability of exporting data to Excel, with relatively minor changes required. He added this capability over the weekend so that other people in our organization – those closely tied to the customer – could look over the report, which was ready quite literally the day of delivery.

Needless to say, I started hearing about a major problem with this report as soon as others began looking at it. The concern was phrased along the lines of, “How could we possibly think that this was acceptable?” Naturally, all of this activity was under my radar until the crisis hit.

Since I had people in my office complaining about something that I previously knew nothing about, I promised to look into it right away. (Yes, people were satisfied that I was going to check into the problem, even if I wasn't immediately chiming in on the "How could we?" bandwagon.) I asked the lead developer about his take on the situation and to let me see some sample output so that I could understand the complaints.

When I looked at the Excel output, I noticed one thing immediately. The Excel output looked exactly like our PDF output, right down to the first page that printed off information such as the report title, criteria used to generate the report, and the report date. I also noticed that the actual report placed the data on the Excel spreadsheet like it would a PDF report, complete with all of the white space.

My initial reaction was, “If I requested Excel output, I would expect the data to be organized a little differently.” Not that what I was looking at seemed like a big deal.

The major complaints were as follows:

One of the columns wasn’t wide enough to see the data. You had to manually widen the column.

A heading was in one column, and the actual data was in a column right next to it, instead of directly underneath the heading. There was no heading where the data actually was found, it was just placed differently than it could have been.

Some data (like longer names) ended up in two rows instead of one.

Okay, the Excel spreadsheet met the literal request of the customer, but lacked polish. I get it. A short discussion with all involved determined that polish would be a good thing, and that since this report could easily be delivered at any time, we opted to proceed with our delivery and then send the polished report a few days later.

A short while after this transpired a couple of us were talking with the lead developer, and he felt a bit down. He had tried to keep the burden off of the team by taking on a task during his own time over a weekend, and basically got trashed for it. I supported him, but pointed out one thing that I’ve learned the hard way myself.

Expediting does not mean cutting corners. Work the process, but don’t circumvent the process – whatever that process happens to be. In our case, we knew enough to define what success looks like for a product feature, but we failed to do so in this case. We should have worked with others to be clear about how data in the spreadsheet was organized. It wouldn’t have taken much time.

A dialog about the situation would have revealed another important fact that became obvious after the lead developer spent a weekend on this. We could have (and most likely would have) determined up front that this particular piece of work didn’t have to be included with the scheduled delivery, especially since it was a late-breaking request.

Out of curiosity, I looked up some definitions of expedite:

Speed up the progress of; facilitate; "This should expedite the process." (Italics mine.)

3
comments

This shows a lack of experience on the part of the lead developer. I've learned the hard way to always refer change requests - however useful or informal - to management. People trying to do an end-run around the process and lobby developers for pet projects is a common problem, and is a major source of software instability, slipped schedules, and feature creep - not to mention bruised feelings.

I am solidly in favor of "skunk works" projects, like the developer's weekend hack. But you have to spin those things. Instead of presenting this as a completed feature, if he'd made sure to tell everybody, "This is a proof of concept and is probably buggy", people would have been happy and overlooked the flaws, and he would have gone from a zero to a hero.

In defense of the lead developer, he is experienced, but this was one of those "in the heat of the moment" issues with a lot of other activity already in play. He let his guard down once and tried to take the perceived fast path.

I too am in favor of "skunk works" projects. You're right, the right spin on this would have created a very different scenario!

Post a Comment

Welcome!

I'm currently an independent agile coach, residing in Portland, Maine. My work experience includes being a developer, a development manager, product manager/chief product owner, and agile coach. This blog is about channeling my passion for business, software development and writing – with an emphasis on agile leadership. The opinions expressed in this blog are my own and do not represent the views of my current or former employers.