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.

Building a better Vulcan

Outside of the office, I love nostalgia, but inside, I am the first to promote change. Keep the things that work. Build on those things, and throw out the bad.

However, when Paramount Pictures took this approach with Star Trek, I was afraid of the change. I did not trust that JJ Abrams would be able to handle the job.

This was because I was not Paramount’s Product Owner, and their team did not ask me for buy-in, when they gathered requirements to fix something that I didn’t think was broken.

I was wrong. The movie was great, and I learned a lesson I have been preaching to others for years…

“The needs of the many outweigh the needs of the few.

–Mr. Spock, Wrath of Khan”

This became clear today, as I was reading new words of wisdom this week from Joel “on software” Spolsky…

Everyone is “Authoritative” on a self-managed team

One of my teammates said the other day…

“It is important that someone authoritative review all requirements documents.”

I gave him one of my you-killed-my-dog looks.

Considering this definition of authoritative…

“Having due authority; having the sanction or weight of authority: an authoritative opinion.”

…or this one…

“Having an air of authority; accustomed to exercising authority; positive; peremptory; dictatorial.”

…then everyone on a self-managed team is authoritative. This is because they are empowered to track down any answers they do not have.

However, there is another definition of authoritative that may be relevant…

“Substantiated or supported by documentary evidence and accepted by most authorities in a field.”

The most successful self-managed teams are those that are cross-functional, providing them with a balanced view of problems from all sides. If they do not have the variety of inputs they require to answer the questions at hand, they must seek out the advice of the experts—quite often “the experts” translates to “the customer”.

Does your team have have “forest goals” or “tree goals”?

This week, Jeff Sutherland revisits the roots of Scrum and expands on why trust is so important to teamwork.

He said…

“With trust based on real unity and cohesion, Boyd's Observe, Orient, Decide, Act feedback loop goes into an implicit state where there is Observe, Orient, and Decisions becomes implicit. The team goes into motion before the leader can give a command. Like in martial arts the Sensei is moving before he even sees the motion of the attacker using a sixth sense. This is the kind of trust a Dream Team has. You know it when you see it, but few software teams have that level of trust.”

I have seen my teams in this state, but they don’t always stay there.

Such a state is only driven by a “sense of urgency”—a sense is created only when…

1. Clear goals exist—not just “tree goals”, but “forest goals”. Your team must see how the little tasks they’ve committed to delivering add to the “big picture”.
2. The leaders are practicing what they are preaching. Truth, Trust, and Transparency have to be seen more-often than heard.

In that environment, the type of synergy Jeff describes is a no-brainer.

Incidentally, I have a meeting tomorrow to further to try and solidify my company’s “forest goals”. Wish me luck!

Another Team Parable: Quality and the Self-motivated team

Nearly a month ago, I called the team together to discuss defects. I wanted their feedback on an idea that I had.

I started the sentence with “What if…”

Someone said “uh-oh” and some eyes began to roll.

I said, “What if we stopped committing to and addressing all defects during a single 30-day sprint and instead committed to addressing them only in overtime. That way, we’d continue to maintain our zero defect count, but we’d be able to deliver more features, sooner.”

“What do you think?”

My team has always hated overtime with a passion.

As always, they thought I was crazy and told me so…

“This is not Agile,” they said. “This will not work. We’ll be coding into the late hours of night. We’ll be exhausted. Quality will decline.”

The sky is falling. That’s what they said.

I then said what I always say in times of change. “It’s your decision. You are a self-managed team, but I would appreciate it if you would at least give the idea a try. If it doesn’t work, say the word, and we can go back to the old way or try something new.”

And with that, my team elected to trust me enough to give the idea a try.

As I said, that was nearly a month ago.

Yesterday, the Scrum Master who most opposed the overtime idea was in my office for our monthly one-on-one.

He said…

“I’ve noticed something really odd lately. We seem to be creating very few defects lately. Now, even the guys who want to work overtime are having trouble finding something to fix.

“We’re coding the way we always have. We didn’t change our processes at all. We code as fast as we always have, and we test the same way we always have. I just don’t understand what changed.”

I said…

“That is bizarre. It’s almost as if the team found some reason to be more attentive to their work. Perhaps, it’s a testament to your leadership?”

He looked at me a moment and said only, “Isn’t it time for your next meeting?”

Meanwhile, in a country called Scrum...

In the country of Scrum, there is a backlog of bills to be addressed, and there is an impediment list of problems to be solved.

These lists are ordered by the Product Owner—and the Vice Product Owner if the Product Owner is assassinated.

The country of Scrum has two teams. Each team has a Scrum Master, who coordinates meetings to ensure that everyone does what is best for the team and the country.The Product Owner is available to answer any questions and provide any support the teams require.

The Product Owner(s) never interfere with the daily workings of the teams.

The goals of individual team members are rarely considered.

After both teams have delivered on their commitments, they come together, adapting and improving their processes, ultimately delivering a country that all stakeholders are proud of—and one that other country's envy.

I once lived in the country of Scrum, but during some quiet coo, I believe that my country was overthrown by the kingdom of Greed.

Axosoft OnTime adopts Scrum in a big way!

I have made much noise over the past year related to Axosoft OnTime's advertised support for Scrum and the product's shortcomings in this area. I have also explained how Decade Software has found ways to work around those shortcomings—but soon you will not have to.

Hamid Shojaee made this announcement today...

"OnTime is an extremely effective tool for managing Scrum projects, but I think we can do a far better job in future versions of OnTime. To make sure we fully embrace Scrum for future releases of OnTime, I had our entire team learn about Scrum. I also made sure we had multiple team members attend a two-day workshop with Ken Schwaber to become certified Scrum Masters.

Axosoft has embraced Scrum in a big way and we have made Scrum one of the main focuses of the next major release of OnTime. More generally, OnTime 2009’s focus will be on Project Visibility, which will help every single OnTime customer, not just those using Scrum. But for Scrum teams in particular, especially those hungry for some burn down charts and other visualization tools, you won’t be disappointed."

To be clear, I love OnTime. It has increased transparency throughout our company. My goal all along was merely to hold Axosoft accountable for their advertising promises and help them make OnTime even better.

It looks like that has happened.

Thank you, Axosoft. I am overjoyed at the news, and I am standing by to beta test if you need me.

3 Steps to Better Presentations

Tomorrow, I will be speaking to the Fresno County Office of Education on the subject of Scrum and Teamwork in general, reviewing the accomplishments Decade Software has made over the last few years.

This afternoon, I will be meeting with those who will present classes at the Decade Software User Training Conference next month.

...so I found Peter Stev's thoughts today quite timely.

"How will I know if the audience is getting what they need? Why didn’t I think of this sooner? The answer is simple: identify the users, figure out what they want to accomplish and why. Give the audience what they need to accomplish their most important goals. If you can identify and address their needs even before they are even aware of them, magic happens."

Check out his full post, and let me know what you think.

21 tips for delivering killer presentations

As you know, I worked in radio for 15 years, and I've been speaking publicly since Jimmy Carter was president.

In fact, this month I will be speaking to developers at the Fresno County Office of Education on Scrum.

At the office this week, everyone's getting excited about our user conference, and most are beginning to prepare their training sessions. To assist, I've put together my top 21 tips for public presentations.

1. Know your 15-word summary. Can you summarize your presentation in fifteen words? If not, rewrite it and try again. Speaking is an inefficient medium for communicating information, so know what the important fifteen words are and repeat them often.
2. Develop rapport with the audience. Presentations should be entertaining and informative. The audience expects some appeal to their emotions. Reciting dry facts without passion or humor bores your audience, as does repetitious or unnecessary words. Keep the audience engaged. Interesting talks fly by. Boring ones last forever.
3. Tell stories. If your presentation is lengthy, explain your points using short stories or anecdotes. Great speakers know how to paint mental pictures for the audience, creating emotional connections between ideas.
4. Tell the truth. If someone asks you a question and you do not know the answer, tell them so, but offer to help them find the answers after the presentation, and when you are wrong, say you are wrong.
5. Hold questions until the end. To keep the presentation moving, ask the audience to hold questions until the end. If they have questions not specific to the presentation, ask them to meet with you after the session.
6. Repeat questions. When accepting questions, have the person asking state their name and where they are from. Repeat these details and the question for your audience.
7. Prepare and adapt. Speak to your audience, listen to questions, respond to reactions—adjust and adapt. In case your material is not getting across, be prepared to change strategy. Know what you can (and cannot) omit, and brace yourself for the unexpected.
8. Distribute handouts. Ensure that the audience focuses on your presentation, instead of taking notes. Distribute most prior to the arrival of the audience, and hold additional handouts for late arrivals.
9. Make eye contact with everyone in the room. Sincere eye contact makes everyone in your audience feel involved. Exchange eye contact with many people in the audience for 3 seconds each, and routinely glance at the crowd while speaking.
10. Remember the slide rules. Show no more than 10 slides per 20 minutes with each slide containing no font smaller than 30-point. Using any audio or visual aids, “going large” avoids interruption by making everything easily understandable from the back of the room. Highlight main points within the first few slides, and throughout the presentation, use more words than those on the slides. Also, remember to number your slides (or script pages) in case you lose your place.
11. Never read slides or notes verbatim. Use words as reminders, and spend most of your time making eye contact. Knowing your material makes you more competent and confident—and assures your audience that you are an expert on your subject.
12. Speak with conviction and enthusiasm. With a little practice, you can inject your passion for a subject into your presentations, and enthusiasm is contagious. Structure presentations using logical progressions from introduction (Thesis statement) to body (strong supporting arguments, accurate and up-to-date information) to conclusion (re-state thesis, summary, and logical conclusion).
13. Breathe. Feeling the urge to use presentation killers like ‘um,’ ‘ah,’ or ‘you know’? Replace those with a pause, taking a short breath—in—not out. Allow everyone time to reflect and think. Racing through will leave everyone out of breath.
14. Slow down. Nervous speakers tend to talk fast. Consciously slow your speech down and add pauses for emphasis. Use statements like, “that’s a good question,” or “I’m glad you asked me that,” to buy time and organize responses. Astute guests will know, but it still smoother than “ums” and “ahs”.
15. Never plan gestures. Any gestures you use should be an extension of your message and the real emotions that message conveys. Planned gestures always look phony, because they do not match other involuntary body cues.
16. Arrive early. Never fumble with software or equipment while people are waiting. Scope the room early, run through your slide show, and identify any potential problems. Verify early that all electrical outlets and devices are functioning properly.
17. Practice your speaking skills. Practice instills competence and confidence. If possible, practice with the microphone. Some require that you speak from one angle. Other microphones absorb sound from different directions, but are prone to feedback.
18. Project your voice. Do not yell. Stand up straight and let your voice resonate on the air from your lungs rather than your throat, and you will produce a louder and clearer sound. Vary the tone of your voice and dramatize if necessary. If a microphone is available, adjust and adapt your voice accordingly.
19. Know when to apologize. Apologize only when you have done something wrong. Never apologize for nervousness or a lack of preparation time. Most audiences will not detect your anxiety, unless you draw attention to it. Apologize when you are late or shown to be incorrect. Confidence will promote audience trust, but arrogance will erode it.
20. Be the Audience. When preparing your presentation, think from the audience’s perspective. What might they not understand? What might seem boring? As an audience member, “What’s in it for me?”
21. Know when to stop talking. Conclude your presentation by summarizing your main points. Follow with an interesting remark or an appropriate punch line. Leave your audience with a positive impression and a sense of completion. Do not belabor your closing remarks. If there is time remaining, take questions, thank your audience and sit down.

Let me know if you have any to add!

Scrum goes Green

Dan Greening is doing an incredible job explaining Scrum in no nonsense terms.

Scrum is a software management technique with high transparency, adaptive control, reasonably accurate release forecasting, and high productivity. However, because Scrum exposes marketers and developers to greater visibility and accountability than traditional waterfall approaches, and because it requires different management structures, some organizations encounter resistance implementing it.

There is much, much more on his site.

Check it out.