HL Arledge

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.

Decade Software's best-kept is still a secret

[You may recall the blog post below. It is from last year at this time. Tomorrow, I will try again to get Decade Software's best kept secret. Wish me luck!—and in the meantime, refresh your memory of how this went down last year.]

Every year, Kevin Delaney begins— weeks in advance—planning his Presidential Address for the opening of our annual EnvisionConnect Users Training and Conference—and every year, I drop by with some hint of something I think he should discuss, and every year—he hates my idea.

This year, I thought using the phone would be less intrusive, maybe catch him off guard, and he would be more receptive to my suggestion...

"Hi, Kevin. It's me, HL."

"No."

"You've haven't heard why I'm calling."

"No."

Requirements, I pondered, weak and weary...

I went. I saw. I learned. I am here to recount my experience.

Firstly, if you follow use case best practices, then you are way ahead of the game in understanding how RAVEN works. We do so at Decade Software, but instructor Steve Yeo told us that this rare among the software shops he visits.

The user-interface is modeled after Microsoft Outlook, so there was only a small learning curve. We covered the basics of the application in under two hours.

The other six were discussing those best practices.

The rules for writing Use Cases are simple:

• Write concisely—no extraneous words.
• Write in Active Voice—not passive voice.
• No assumptions—assume your reader knows nothing that you are explaining.
• Be consistent—if the system shows once, it shouldn't display later.
• Flows describe Functional Requirements Only—Preconditions, Post-conditions, and Business Rules are documented outside of the flows.
• Document all alternate flows—If this then that, otherwise that.
• Use Requirements English—Actor Function Object Target ("User enters Login Credentials in the Password Dialog.")

RavenFlow's sales folk get a little cryptic discussing pricing structure, but once you cut through that—and verify that you can live with the best practices defined above—I assure you that RAVEN can help your organization deliver requirements faster with little rework and greatly improve transparency.

But...

As Steve said...

"We can only give you the tools to get the job done. Solid processes start at the top and only work with complete buy-in from the team."

Now, where have I heard that before?

Do you need to hire a consultant to fix your team?

In business—and in life—you get back what you put into it, but do you really need to hire expensive consultants—or pay for re-certifications—if you don't need them?

Most everything that works is documented in a book somewhere—or it can be learned from experience. Even things that are better learned in a classroom setting will not require refresher courses unless (1) processes and strategies improve, or (2) you don't practice what you've been taught.

This all crossed my mind when I was prompted by the Scrum Alliance to re-certify—just pay them another hundred bucks per certification—as a Scrum Master and as a Scrum Practitioner. The re-certification provides no new training as Scrum processes and strategies have not changed—although Ken's new book did enhance existing processes with some trial by fire examples.

I live Scrum everyday, so I have more Scrum experience than most Scrum trainers, so tell me again why I should send more money to the Scrum Alliance?

Consultants are the same. If you listen to them long enough, you'll break things and believe the consultant predicted the break—the same day you paid him to tell you how to repair it.

Consulting would not be easy for me

Seeing my new blog and podcast, three different people this week have asked me if I was considering doing some consulting on the side.

I'd love to—but there are two major obstacles to the idea: (1) I'm too busy at Decade, and (2) the consulting industry would absolutely hate me.

• I'm too busy.

My team has worked hard to get where we are, and I have no intention of abandoning them now, and—in addition to acting as coach and confidant to my two teams—I am an active member of the management team and an in-house Scrum consultant to at least two other Decade teams.

Oh, and I still code from time to time.

• Besides that, the consulting industry would hate me.

Most process-improvement-type consultants charge by the hour. From the perspective of truth, trust, and transparency that is a ridiculous idea.

In Scrum-talk, your pigs and chickens would be guarded by a wolf!

Transparency is the most important factor to earning trust. If someone has agreed to do X (some goal based on expected business value) to assist you with team-building, then they must charge X. Otherwise, the wolf has no incentive to solve the problem in a timely fashion. The wolf will not commit—take ownership of the problem.

In fact, if the wolf is being paid by the hour, solving your problem would put him out of work. Not only does the consultant not have an incentive to commit, he or she actually has an incentive not to commit.

So, you see, even if I had time to help another company, the consulting industry would have nothing to do with me.

E-mailer's thoughts regarding building trust with an audience

Gustavo Cavalcanti was kind enough to forward some early feedback from Wednesday's presentation at Fresno State...

 

HL,

I was really blown away by your presentation. I was being sincere when I said it was the best presentation given to our group, in my opinion. And apparently I am not alone - please read below an email I received just a few minutes ago from one of the attendees.
Thank you very much!

- Gustavo

"RE: HL’s Perfect and Mythical Presentation

Gustavo - 

It's too bad that last night's presentation by HL was not taped. 

Tips to calm nerves before a presentation

In this morning's EnvisionConnect Open House, both of my Scrum teams will be presenting the product to Marketing and Client Services. This presentation is much larger that the routine Sprint Review Meetings. Many more spectators are invited.

This seemed like a perfect time to discuss tackling nerves before a presentation. Being thoroughly prepared is the best way to combat nerves.

Here are some quick tips to better prepare and boost self-confidence early...

• Verifying that all your props and audio-visual aids are setup at the location early boosts confidence and enables you to concentrate on preparing yourself.
• Number the pages of your script or slides in case you get side-tracked.
• Verify early that all electrical outlets and devices are functioning properly.
• When creating your Audio-Visual aids, go large! To avoid interruption, everything should be easily understandable from the back of the room.
• Thorough preparation for your presentation gives you the confidence that everything will go right.
• And last but not least... Practice makes perfect!

Chickens coming home to roost at EnvisionConnect Open House

At Decade—long before the adoption of Scrum—every product release coincided with what we called a Release Hand-off Meeting. In this session, we would demonstrate everything new in the latest upgrade. The Development Team always went into the meetings happy and proud—and we always came out completely frustrated, because the audience—Marketing and Client Services personnel—would often get into huge debates on how we could have done a better job.

In Scrum, we have our Sprint Review Meetings. Chickens are invited, but they cannot speak. I always thought that was a rather rigid rule until today—when I read Chris Spagnuolo's attempt at a Sprint Review Meeting, where chickens were allowed to speak...

Another year, another certification, another hundred bucks

It is official. I have been awarded as a "Certified ScrumMaster Practitioner" by the Scrum Alliance.

This honor is bestowed upon anyone who has actively and successfully served as a "Certified ScrumMaster" for one year.

I had to fill out a lengthy form a few weeks back, describing my team's history and day-to-day activities.  A committee then evaluated my standing and approved certification yesterday.

Now, all I have to do is send them a hundred dollars.

Scrum news from the Mountain Goat

Our Scrum friends at Mountain Goat Software have updated their popular—and redistributable—Introduction to Scrum presentation. The new version features all new graphics and the content has been greatly improved since the original was released in 2002.

The presentation is available in Power Point and Keynote formats and is available in various languages. I highly recommend it as a starting point when introducing Scrum to others.