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.

It’s not really Friday, is it?

This has been a busy week, but its the start of one of our best sprints ever.

We are overhauling sections of our flagship software that will knock our users’ socks off, and my team is focused tighter than they have been in a long while.

In the meantime, teams from various departments are working more closely to increase transparency and provide customers with solutions faster.

—and we’re growing! We added two team members in the last 30 days, and we are still interviewing.

More and more potential customers are getting excited about EnvisionConnect, and our newly established Customer Communications Task Force is getting off to a great start.

Great week, but I’m exhausted from all of the excitement, and I’m still happy to see Friday.

[For you youngsters out there, the photo is Sergeant Joe Friday.]

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.

It's the customers, Stupid!

Firstly, I don't want to get into any political debates. To allow me to make my point, if you are a conservative, please suspend your disbelief in the legend I am about to recount.

Legend has it that Bill Clinton entered the White House inheriting a 300 billion dollar deficit. His predecessors had told him...

"You'll see how it is. You think you'll fix the economy, but something more important will always come up. You will get caught up in the crisis of the moment, and you will take your eye off the ball."

Like most of us, Bill was getting older and had to make notes to keep from forgetting. On his first day in the White House, he brought in a sign from his election campaign with writing on the backside in large print permanent marker.

The sign read:

"It's the economy, Stupid!"

He looked at the sign every time he entered the Oval Office—as did everyone who worked with him—and when Bill Clinton left office, the large deficit had morphed into a 200 billion dollar surplus.

[Again, I am just recounting the legend, and I have conducted no independent investigation. Please focus on the story or you will miss an important point.]

 Sometimes, Decade staff—the management team especially, with myself included—forget that the crisis of the day is only a small brush stroke in the big picture. If one customer calls with a problem, everyone's on it, until the customer is happy.

This is not entirely a bad thing, but sometimes we become so focused on a single client that we delay tasks that will benefit the entire customer base.

We forget that ancient Vulcan axiom...

"The needs of the many outweigh the needs of the few—or the one."

So—to help everyone focus—today, I will hang a sign on my office wall.

The sign will say...

All together now...

"It's the customers, Stupid!"

It is time to be transparent again

I’ve gotten several notes and phone calls. Readers want to know what happened to the avid blogger they had developed a love-hate relationship with.

Someone wrote…

“I know you were out awhile when your blog host had technical problems. Now that those are resolved, I’m guessing you’re just out of the habit. We miss the craziness. Please come back.”

Now, that was sweet……………but they got it all wrong.

For years, I’ve touted the virtues of transparency. I believe that trust is the key to growing a company, just as it is key to growing a successful team. Without transparency, there can be no trust.

The e-mail got me asking the tough question: Why have I not been blogging very much?

I tell myself that I’m too busy, but I’m at work at 6:30 or earlier every day, so I must be lying to myself.

The truth is: I felt I could no longer be transparent, and if I cannot be transparent, I would rather be silent.

Some folks were telling me…

“Stop bragging on your team’s accomplishments. It makes other teams look bad and feel jealous, and it makes what your saying difficult to believe. No team could be that successful. Talk about your future goals, and let your past achievements speak for themselves.”

While others said the opposite…

“Our company should never talk about what we are going to do. It makes us sound like our competition, full of empty promises. Don’t talk about any of our goals until after we have achieved them.”

That’s why I had a loss for words. I simply did not know what I could say.

Then, I remembered that honesty is still the best policy. When in doubt, just tell the truth.

So…………we're back!

Starting tomorrow, truth, trust, and transparency return.

2008 Decade Conference a Resounding Success

Tabulating the early results, it seems the 2008 Decade Software User Training Conference was a resounding success, and I especially want to thank Peter Lucas and Sandra Sanchez for making it that way.

Of the conference participants who turned-in their post-conference questionnaires, over 99% said that the classes they attended were structured well, included useful material, and were presented well.

In the written comments, many said that this was our best conference yet!

My favorite quote said...

“Class presenters were much more interesting and knowledgeable than in the past.”

This was important to hear, as everyone on staff was committed to making that happen this year, and we are proud to have made strides in that direction.

Were there complaints? Of course, there were. You can never please all of the people all of the time. Two-thirds of our open forum panelists canceled at the last minute, and the Radisson Hotel had a problem controlling their flies, but by far, the complements exceeded the complaints, and everyone walked away smiling.

Next week, I'll be spotlighting some of the conference presentation teams and discussing the specifics of those presentations, but today I wanted to take a moment and thank the unsung heroes of our conference.

IT Wiz and Documentation Guru Peter Lucas and the company president's right arm, Sandra Sanchez are the glue that hold these events together. Too often, we forget to tell them...

"Thank you!"

And on that note, I want to thank all of those who attended and provided their feedback. We certainly couldn't improve without your input.

Thanks a million!

Preparing for the Decade User Training Conference

Everyone, I apologize for not writing much these last few weeks, but everyone here has been preparing for our annual user conference, next Monday and Tuesday.

I will tell you all about it next week, but in the meantime, I thought I'd show you a picture of some of the staff ready to go for the conference.

I think one or two of them might be a bit nervous. What do you think?

Pictured (from left to right) are Nicki Bradford, Jerad Little, me, Cynthia Hill, Art Amezcua, Mark Harmon, and Patrick Glaspey.

Grizzlies lost last night, but our team won!

Last night, Decade Software teams from all departments gathered their families and made another trek to Chukchansi Park for an all-you-can-eat BBQ outing.

The Fresno Grizzlies lost to the Portland Beavers, 4-2, but the July temperatures were lower than expected, allowing a good time to be had by all.

I wanted to thank Kevin for funding the event and to thank all who attended for coming out and supporting the DSC team.

Thanks! It was a blast.

Blues, Brews, and Barbeques this weekend

Some of my team will be joining me tomorrow at the Engelmann Cellars winery for Fresno's annual Blues, Brews, and BBQ festival.

They'll start serving at 11:AM, and the first band hits the stage around 1:30 in the afternoon.

If you haven't been to one of these before, you should check it out. It's a great time, and the weather this weekend is expected to be perfect.

Decade Software inspects restaurants in Canada

This morning, I am meeting with our sister company in Canada. The team there is taking first steps to migrate HES customers to EnvisionConnect.

As Developer Mike Vea and I prepared for the meeting, it considered that some of you may not yet heard of Decade Canada.

Here's the scoop as recounted on their web-site...

"In November 2003, Decade Software Company, LLC incorporated a Canadian subsidiary company called Decade Software Canada Ltd.

The Environmental Health software assets known as the Hedgehog Environmental Systems (HES) software were purchased from Procura along with the rights to the existing contracts.

The Hedgehog Environmental Systems software was originally developed in 1993 by Neil Grinwis of Hedgehog Systems. Neil was recruited to run the Canadian company and to continue servicing the Canadian Environmental Health customers."

Today, we are comparing business rules between the two products to ensure that HES customers have all they need before the move to EnvisionConnect.

Growth is always exciting for us. I'll keep posted on our progress.

Do Scrum Teams need their own Heisman Trophy?

Yesterday, I listed the problems Scrum can solve for you.

I talked about the requirements for structuring a solid team, including the establishment of clear, prioritized goals, but I stopped short of discussing rewards for achieving those goals.

All teams get rewards. The title of this blog represents one of the most famous of collegiate football rewards.

Full disclosure: Since I am not a big football enthusiast, I did not even know what the Heisman Trophy was, until the auctioned off OJ Simpson's.

In our early days in Scrum, we treated developers and wives to dinner when a Sprint was successful; we provided pizza at planning meetings; and after meeting our biggest goal of last year, we gave everyone on the team an extra week's vacation—one they all took at the same time!

Awhile back, I became concerned that team goals would not continue to mean as much if we did not continue to provide such rewards.

I was right and wrong at the same time.

Rewards still need to exist, but I was wrong in believing that they did not.

As I said of some Scrum Masters yesterday, I did not really understand the problem that I was trying to solve.

In one of my monthly one-on-one's with staff, a trusted teammate—known as a tell-it-like-it-is guy, as opposed to a tell-it-like-you-wanna-hear-it guy.

He surprised me, explaining it this way...

"You've made this a great place to work, allowing us to solve the problems that have made our jobs painful for years. You are constantly looking out for us, motivating us to find ways to make our job easier and faster. Those are reasons enough."

He ended the explanation with the caveat...

"...but that doesn't mean we'll turn down steaks if you're buying!"

Intrapreneurs, Golden Children, Bobble-heads, and Ding Day

Someone recently said to me...

"HL, you'll never understand how stressful my job is. The boss treats you differently than he does me. You turned this company around. You are his Golden Child."

That last statement left me speechless—at least for a minute or two.

I never thought of myself as an Eddie Murphy type, but I have seen myself as sort of an intrapreneur. That is someone within an organization who behaves like an entrepreneur—someone who is always thinking beyond "that's the way we've always done it", pushing the envelope, trying and testing new processes until something is proven to work.

In a Scrum world, intrapreneurs are required, but in many offices, intrapreneurs are considered Satan's offspring and must be destroyed.

Said another way, some intrapreneurs are supported by management and some are not. It all depends on the culture within the organization.

This understanding and supportive culture was not always the dominant culture at Decade Software. There was a time when management was not trusted by the workers and vice-versa.

Most new ideas from employees were shot down before ever reaching the ears of upper management, and ideas from upper-management were seen as ridiculous, because employees were seldom told why something had to be a certain way.

In such an environment, employees had to leverage Kevin's open-door policy to discuss such ideas—and risk offending a more immediate manager or coworker—or the employee could be creative and send broadcast e-mails to all concerned.

That last option usually got you into trouble.

Your manager would label you a trouble-maker, and you would be called into Kevin's office for a discussion. Seemingly, to give you something to mope about over the weekend and make your family hate you, these discussions always happened on a Friday—a day once known throughout the office as "Ding Day".

Eventually, Ding Day events became so common-place that staff invented an award. They routinely presented a Jack-in-the-Box bobble-head to the person who received the most unusual "ding".

This award rotated from person to person and from department to department—until the day Kevin created a Microsoft Power Point presentation to demonstrate why I shouldn't "rally the troops" to encourage changes to company policy.

Ironically, Kevin didn't know then that the organizational hierarchy between he and I had clouded his view and that he and I were actually on the same page all along.

Kevin wrote the following over six years ago...

"Our business should be based on trust, respect, and proper ethical conduct. We believe that to become and remain successful, we must gain and maintain the trust and respect of our clients, our suppliers, and our fellow employees. To achieve these goals, we will create a self-aligning and self-sustaining culture by distributing leadership throughout the organization."

Eventually, our culture did change—just as Kevin's vision described—and the bobble-head was never awarded to anyone else in our organization.

Today, the trophy stands grinning in the office of that intranpeneurial spirit some call the Golden Child.

Real Development Teams don't cut corners

I am a firm believer in not discussing anything in an employee evaluation that hasn't been discussed earlier.

I have monthly one-on-ones with my team to ensure that this is the case. My goal is to always know the pulse of my team and to identify and correct problems before they have time to grow.

Yesterday, I was in such a meeting, and one of my team said...

"It was crunch-time. I had to finish, so corners had to be cut somewhere."

I wanted to say...

"Did you miss every meeting we've had for the last couple of years?"

Instead, I said...

"I'm sorry if I never communicated this to you, but we don't have to cut corners here."

My teammate seemed embarrassed and starting ticking off all he had accomplished last sprint.

I just looked with my most expressionless expression.

He continued...

"...I asked for help, but no one would help me."

I was stone-faced.

"Well, maybe I could have asked again....The team may not have realized how much I needed help....I guess I should have called my situation an impediment, and then maybe they would have knew it was important."

I smiled, and continued to listen.

"I know that we don't cut corners. We commit to only the work we can accomplish, and if we fall behind, we get help....There were some who finished early and took on more tasks. I should have went to the Scrum Master with my impediment."

"Instead of coming in your office with a list of reasons why or why not, I should have just said, 'I screwed-up, and this is what I'll do to prevent it from happening again.'—huh?"

As this teammate left the office, I was grinning.

I guess he really did attend a meeting or two.

Serenity Clock and the Lost Defects of Doom

Our Quality Assurance Engineers have been integrated into our Scrum teams now for over a year.

For the most part, this integration has improved quality by leaps and bounds, but like others learning the ways of Scrum, our QA Team admitted just this week to still harboring a few die-hard habits and fears.

In a Scrum world, a meeting of retrospective follows the end of every sprint, and in that meeting, all problems and mistakes are identified and potential avenues for improvement are explored.

Eventually, through this incremental process improvement cycle, both process and product become more refined.

The one thing you don't do is to try and solve problems before they are proven to exist. Unfortunately, this way of thinking is completely counter to the historic QA mindset.

That traditional mindset reminds me of Indiana Jones.

Indy tackles a problem head-on, expecting the worse, and improvising as he is attacked. When sent into a cave to retrieve some artifact, he knows he must explore every tunnel, even if he knows exactly which cavern holds the item. If he doesn't do this, some giant boulder or tribe of cannibals may come out of that tunnel and the movie will end early.

Our QA team—Dave Blanton and Serenity Clock—dream of similar adventures.

When they are sent into the dark and frightening realm of defect verification, Dave and Serenity feel they cannot simply verify the defect and get out. If they don't explore each and every corridor, some incompetent developer will kill one defect and give birth to three. Those new defects will then scurry and hide in the bowels of our C# code, only to appear later and make QA personnel look like brainless monkeys.

Exploratory Testing is  a staple of testing new code, and it has a home in the Regression Test arena, but it has no place in the Defect Verification process.

"I take pride in our product," argues Serenity Clock. "I must explore any chance I get."

"If we don't," adds Dave Blanton, "We will be embarrassed and ridiculed for not doing our jobs."

Maybe this happens in some other world, but not in the universe of Scrum.

Mistakes happen. Identify them. Fix them. Put measures in place to prevent reoccurrence.

Then, move on.

Blame no one—otherwise everyone will be afraid to admit mistakes and all problems will take longer to solve.

Command, control, and punish are yesterday's mistakes. Trust and transparency are the secrets of today's management successes.

Remember when Indy was up against that master swordsman. In the days of Errol Flynn or James Bond, he would have picked up a sword and matched the duelist blow by blow, until the evil doer was defeated.

Indy pulled out his pistol and shot the guy!

The old ways are dead. Embrace the new if you want to experience success.

Decade Software is a living, breathing entity

I don't usually regurgitate post verbatim, but these thoughts from Anna Farmery are well worth repeating...

"Business exists because of humans—because humans establish them, because humans run them, because humans buy from them.

I think if we change our mindset from a business as an entity to business being human it can have great benefits

1. Care about it's health by checking on its heart and soul is fit and well - engagement surveys, sessions with people, feedback
2. Care about its vision by constantly ensuring that it's vision is clear.
3. Care about its "blood pressure" by listening and searching for pressure points that need to be released.
4. Care about its "teeth" by ensuring that the targets are stretching, that they are motivating people to push on...
5. Care about its hearing by ensuring that the lines of communication are working well.
6. Care about its mind by ensuring that information is being shared, that people are encourage to develop their thinking...
7. Care about its beliefs and values to ensure they are being respected.
8. Care about its mobility - can it act quickly?

A business is so much more than a corporate entity - it is a group of people who want to achieve their dream, it touches peoples lives in the community, in the world."

Do Product Owners evolve and adapt like fire ants?

Mike Cohn posted something I found interesting this week...

"...product owners evolve in adaptation to their environment, just as the fire ants had evolved in adaptation to theirs. His unfortunate situation won’t change until some other environmental factor comes along that changes the motivation and incentives of the product owners."

When I look at the Product Owner for the EnvisionConnect project, Darryl Booth, I think I see where Mike is coming from. Darryl's focus has changed quite a bit in the year or so that he has been in the role, but until reading Mike's thoughts I hadn't attempted to determine just how much.

I think I'll make that one of my next projects and let you know what I find.

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.

Three EnvisionConnect secrets revealed

A colleague e-mailed regarding the post, What is a Smart Client anyway?.

She asked...

"In this article, you insinuate that the technology is the reason for EnvisionConnect's resounding success, and too many times to mention, you have attributed the product's success to Scrum and the hard work and commitments of you team. Are there any other factors to the product's success."

Well, what can I say? I am shocked.

If I have led readers of this blog that these are the only two factors in making EnvisionConnect the success it is today, then I owe both our design team and our customers a very BIG apology.

Here are some secrets to our success, but don't tell our competition—if we have any.

• Envision became EnvisionConnect to draw attention to the fact that the new interface was designed from the ground up by our customers.
• Our design team works side-by-side with customers, creating and evaluating prototype interfaces to ensure that the designs delivered to development are the most intuitive work environment possible.
• Both our design and development teams work iteratively—think “evolution”—continuously improving and enhancing EnvisionConnect based on the latest user feedback.

So if I have slighted our customers or designers in any way, I am sorry. The development team could not have done it without you.

Give the 3 gifts of Trust in 2008

I have blogged incessantly this year regarding the successes my team has had. I have not omitted the failures, but I was extremely lucky in 2007. The failures were overshadowed by our successes—and I expect 2008 to be more of the same.

Much of this success can be attributed to Decade's commitment to Scrum and the concepts of Perpetual Teams™ , but our successes can be equally attributed to a hard-working team committed to achieving their goals.

After recently reading Patrick Lencioni's holiday retrospective on the best gift you can give employees, I realized that part of the reason my teams were committed as they were, was likely due to the gifts I gave them since I have been in this position.

Lencioni sums up those "gifts" in this way...

• First, get to know your people better than you know them today. Take an interest in what is going on in their lives and find out what their dreams and passions are, both professionally and personally. The only caveat is that you have to be genuinely interested. If you haven’t done this much before and you’re afraid that it will feel weird to start now, do it anyway. Your employees want it, need it and will thank you for it.
• Second, talk to them about how their job impacts the lives of others—customers, vendors, colleagues, even you!—in some way, large or small. Help them understand that their work matters, to someone, and that without them, others would suffer.
• Third, help them figure out how to best measure and gauge how effectively they are doing their jobs, especially in terms of the impact they have on others. Give them the ability to determine for themselves whether they are succeeding or not, and free them from depending on your subjective opinion for a sense of accomplishment or esteem.

These gifts cost little, but given sincerely, they are worth a fortune. If you are looking for team success in the coming year, I recommend that you start handing out these gifts right away.

We weren't always delivering products with zero defects

I promised earlier this week to provide the statistics I reviewed in my last public presentation. I will begin to keep that promise today. However, since you do not have the benefit of hearing the full presentation, you will not benefit from the full story of the many process improvements Decade Software has made.

Along the way, we have incrementally improved our processes, learning from the Rational Unified Process, Six Sigma, and others. Additionally, Kevin has invested more resources in the last year than any year prior.

I wanted to mention these little caveats to make it clear that I do not attribute our successes solely to Scrum or current leadership alone.

And with those disclaimers aside, let's look at the numbers...

During the life of Envision for Windows and it's related products, there were 8,596 defects reported, but—in spite of our best efforts—we were only able to close 2,221. Concerned with the defect count—and the fact that the 21st century web and smart-client technologies were improving usability standards worldwide—we scrapped Envision's user interface and began anew.

Two years later, EnvisionConnect had improved usability, but we seemed to be continuing our defect trend. A total of 472 defects had been opened, but only 190 had been closed.

We had to take measures more drastic.

That was about the time Kevin asked me to become a manager.

More tomorrow...