Put your Bugs where your Mouth is

Last month, Decade Software released EnvisionConnect 4.0—and what a proud day it was.

The new version is the previous version on steroids, and were constantly making strides to improve performance and make the product easier before version 4.1—always focusing on making the application faster for users to get in and out and still feel good about having got the job done.

My Development Team prides itself in maintaining a zero defect average. Every 30 days—during Sprint planning—we commit to closing every open defect in addition to delivering any new features we committed to providing.

Speaking to software shops across the nation, I have not found one who has been able to come anywhere near our zero defect average. (If you know of any, please let me know. I would love to glorify them in this blog!)

I recapped all of the above so that you understand my dismay at hearing someone say this week…

“One of our clients says he doesn’t like the Page Layout Editor”—Yes, we do allow users to redesign forms and pages—”because the user says the tool is buggy.”

Immediately, I searched the defect tracking system and consulted my Quality Assurance team. I wanted to find out how many bugs constituted “buggy” and why we had not eradicated those bugs.

I found no bugs related to the feature in question, aside from a couple we had fixed but not yet released.

Then I knew our problems lay somewhere else.

Is the problem related to the definition: What is a defect?

Not likely. At Decade Software, We have the most lax description in the industry: If the client is “bugged” by something, that’s logged as a defect. Ultimately, we may fix it as a defect in code, or by adding a new feature, or by changing a design, or by providing training for the user—but no defect is ever ignored with the words…

“…that’s just the way it is.”

So, if the code is not the problem, and the definition is not the problem, then there’s only one thing it can be. Someone found a defect and did not report it.

Even the best software teams cannot fix bugs no one has found. It is the responsibility of user—internally and externally—to report any problem found.

Software shops can’t make you happy, unless they know what is making you sad.

Did you miss me?

With all of this tweeting and twittering going on, you would think blogging would be losing popularity, but seldom does a week go by that someone doesn’t ask about my blog.

That said, I’m committing to blogging at least three days a week from now on.

…but I owe you an explanation, as to why I haven’t been doing so.

Because of the wild success of EnvisionConnect—due largely to the success of my own team—we’re really, really busy these days.

Presently, I am assisting with the launch of an all-new Decade Software user community, planning our 2009 training conference, and governing the launch of EnvisionConnect 4.0—our most anticipated release ever.

We’ll look at the details as the weeks progress, but in the meantime, I’m begging for your patience. I’m a really busy guy.

The customer is not always right

I’ve spoken much lately about the importance of working with the customer and creating a transparent environment, where everyone knows the best ways to do everything with our software, and I’ve spoken of the importance of getting customer input on priorities and direction.

I am one of our customers’ biggest advocates, and most of them will tell you so, but let me make this perfectly clear… The customer is not always right.

As I pointed out last Friday, often what one customer wants is detrimental to another. This is why it is so important that customers are allowed—no, encouraged—to share ideas, problems, and solutions with each other.

In other words, the customer as an individual is not always right, but the customers as a group nearly always are.

That said, check out this article from Alexander Kjerulf.

Customers get bug-free software

Yesterday, in my entry entitled Angry Customers Tell 3,000 Friends, I explained how I became involved in customer relations at Decade Software. Kevin and I had devised a plan to allow customers to more freely communicate with us and with each other through a new web site.

By increasing transparency, we would bolster a trusting environment where everyone freely helped everyone else become successful using our products.

Our past successes had told us that teamwork using cross-functional teams was the secret to meeting goals, so the first thing I did was form a new team. The Customer Communications Task Force was formed to get clients talking.

We scheduled meetings with customers and began demonstrating our ideas for the web site and our ideas for opening communication between customers—and they loved what we were doing!

The CCTF had picked up speed, and we were soaring to the finish line, and then we turned a corner—and we hit a brick wall.

We discovered quickly that launching a new web site is an action that steps on multiple toes, and in short order, I was accused of invading the territories of Marketing, Client Services, Graphic Design, and Administration.

They said, you're moving too fast. If you modernize our web tools, you'll have to change the look and feel of everything, and that will cost the company time and money—and that will cause customers to ask: why are you spending time and money on web sites, when you could be fixing the defect I reported?

I couldn't argue with that logic. Making customers happy is a goal we all share.

So, I gave up and turned my attention back to the Development Team and those defects everyone was so worried about.

To my knowledge, we were the first team of developers ever to adopt a no defect policy. Every 30 days, we plan the next 30 days of work, and we commit to closing every defect reported by our customers. We've been doing this for over a year.

Now, someone was challenging our logic, saying...

"You're fixing every defect reported, but how do you know if all existing defects have been found?"

Kevin responded by hiring three additional testers and an additional developer.

All along, Kevin and I had agreed that our new customer outreach could not succeed unless quality was top-notch, so I asked him to approve overtime to commit to defects as they are reported.

In other words, my team no longer commits to closing all defects every 30 days.

We now commit to closing all defects every day.

This is an accomplishment previously unheard of in the software industry, but my team makes it happen.

Last week, one of our support technicians reported...

"It is really nice when customers call with how-to questions. It has been a long time since someone called to report a defect, and even when they do, it's nice to say it will be fixed immediately."

This empowered the CCTF to return to our communications goals, and this time, with the full support of everyone in every department...

...that is, until I suggested changing the company logo.

Finally, something to rant about

I love blogging.

I love talking about my teams and their accomplishments. I love talking about the improvements this company has seen in these last few years. To me, that is what blogs do best—allow us to share successes and failures, so that we may learn from one another.

Unlike many in the blogosphere, I never use my blog for ranting.

Never—until now!

Our blog host (I almost said “of choice”) is Typepad. They were great until late October of last year, when they upgraded their product—and destroyed my way of life!

Their update broke my ability to post using Windows Live Writer, essentially forcing me to use their web interface to update my blog.

Despite my reputation, I do have more to do at the office than just blog. I seldom have time to toy with a kludge web application.

Sound petty? Of course, it does. Maybe I was really just standing on principal. Being a stubborn Southerner, I do that sometimes.

I started this post talking about how businesses can use blogging to learn from each other. I learned much from this experience.

Even the most minor of software changes can wreak havoc on your customers lives—and make them bitter towards you, your product, and your company.

The customer is still always right.

Sometimes we forget.

Do not command and control your clients

All of the go-to books on leadership tell you that command and control techniques do not work. Team-building—allowing people to balance their strengths and weaknesses to evolve into one cohesive, self-managing entity—is the fastest was to increase production, quality, and performance—simultaneously. My team has proven that in leaps and bounds.

...but did not know that this technique can apply to customers as well—particularly in the software industry.

I mentioned yesterday how our design team has worked with EnvisionConnect users to form a team that was able to work together and redesign our flagship product. After posting that, I was considering how and why that had worked so well.

We've all heard time and time again that,

"Design by committee doesn't work."

This reminded me of something someone told me long before I was a manager at Decade...

"Decade Software is a privately-owned company. It is not—nor will it ever be—a democracy, Mr. Mayor."

The person making the statement didn't understand the benefits of teamwork. He was stuck in the mind-set that command-and-control was the only way to manage.

In later years, my team and I proved that a democracy—a self-ruling people—provides any company—privately-owned or otherwise—the fastest route to success.

...and the same rule applies to customers as well.

Sure, you never please all of the people all of the time, but bringing a group together to understand each other's needs ensures that the final decisions are owned and accepted by the group as a whole.

It worked for development, and it worked for our design team. They did not give development a design based on their vision, telling the customers...

"That's the way it is."

That is another version of command-and-control.

Instead, our design team said...

"Let's get together and define a solution that works for everyone—or at least the majority."

The key to making such a strategy work is teamwork, and the key to establishing this kind of teamwork is honesty. Everyone must learn to say...

"Now, I see where you're coming from. I was wrong. Let's try it your way."

or...

"I see your point, but consider this, and maybe we can find a middle ground."

Is that possible? Can people truly change their perspectives completely? Sure, they can. Remember the guy who said to me all those years ago...

"Decade Software is a privately-owned company. It is not—nor will it ever be—a democracy, Mr. Mayor."

Today, that guy is the current leader of the design team. He is the one that directed them to invite EnvisionConnect customers to join our little democracy.

Why so much ado about San Bernardino County?

By now, you've heard that San Bernardino County has migrated from Envision to EnvisionConnect. You've likely heard that they have completed billing and have over 40 inspectors in the field carrying Toughbooks running EnvisionConnect Remote, but maybe now you're asking yourself:

• Hasn't Nevada County used EnvisionConnect for nearly a year?
• Haven't many other Environmental Health regulators across the country adopted EnvisionConnect since then?
• Hasn't Anchorage, Alaska successfully migrated from Envision to EnvisionConnect?
• Hasn't Sacramento and Orange County been beta testers for a couple of years now?

Of course, the answer to those questions is a resounding "yes".

That brings us to your next question: What's so special about San Bernardino County?

Encyclopedia's describe San Bernardino this way:

"San Bernardino County is the largest county in the contiguous United States by area, containing more land than each of nine states. The county is larger in area than the states of Massachusetts, Connecticut, Rhode Island, and Delaware combined. Any of those states could be replaced in the list by New Jersey, Vermont, or New Hampshire."

San Bernardino County

That makes the county sound pretty important, but that's not exactly why it's so important to us. We are very close to our long-time customers, most of which still use Envision—and many have done so since the original DOS version. Some of the staff at these agencies are like family—or at least like co-workers. We have known them a very long time, and it is important to our staff that we keep them happy.

EnvisionConnect was actually designed by the Envision user community, and no matter how many new customers climb aboard, it is the final approval of our long-time customers that keep us on the edge of our seats. We've tried hard to cook what they ordered, and we're awaiting the moment they taste it and tell us whether we got it right.

That's where San Bernardino comes in.

Envision is a complicated application. It provides the tools to manage a vast number of programs regulated by the environmental health industry. Some Envision agencies regulate more programs than others. San Bernardino County is an agency that uses most of the programs regulated by Envision.

We knew that if San Bernardino's migration proved successful, everyone else's would as well. Today, Dan Avera and his team are smiling, but our smiles are bigger.

San Bernardino is LIVE with EnvisionConnect!

Recently, I stated that San Bernardino County (here in California) was slated to go-live with EnvisionConnect today—making them the first Envision customer to fully migrate from Envision to EnvisionConnect.

This morning I received the following memo from John Jensen, our Client Services Manager:

 

From: John Jensen
Sent: Monday, July 02, 2007
To: Decade Software Company
Subject: San Bernardino Environmental Health went LIVE TODAY WITH ENVISIONCONNECT!!!

San Bernardino is live on EnvisionConnect today!!!

It was a long weekend for San Bernardino and Decade staff. We still have some issues to resolve, but for the most part they are using EnvisionConnect...

...I want to thank the Developers that worked with Client Services this weekend to help us meet this goal. I really appreciate everyone's commitment to meeting San Bernardino’s goal of being live on EC Monday, July 2, 2007. You showed team work and commitment to the Decade teams. I am proud of our teams.

Great job!!!

Migration Response Team prepared for any emergency

Scrum dictates that nothing shall impede the project goals. The job of the Scrum Master is to insure that such impediments do not interfere with promised deliveries. Between now and July 31st, the Development Team's Job One is making sure that 90% of our customer base has the base functionality required to migrate from Decade Envision to Decade EnvisionConnect.

San Bernardino County is the largest county in the contiguous United States by area. Like most environmental health agencies in large counties, San Bernardino County Environmental Health Services uses Envision to manage everything. San Bernardino County has their own goals. They wish to be be the first Envision customer to use EnvisionConnect to conduct CalCode inspections in the field—and they can't wait until July 31st.

Luckily for us, Scrum is a process designed to expect and react to change.

Today, professionals from all Decade Software departments meet to form a splinter group—a San Bernardino Migration Emergency Response Team—that will be ready for action when SBCDEH completes their migration on July 2nd. Until someone shoots that guy Murphy and repeals his law, we know something will go wrong. Our goal is to be ready to react and rectify the problem immediately with minimal impact to the customer.

Watch this weblog to see what happens. I have said before that this is a very exciting time to be at this company. It becomes moreso everyday.