HL Arledge

Bush-bashing again this weekend

Trying to stay in shape as the years pass can be tough, but I've found a way to enjoy losing weight and staying fit. This year, I am spending more and more time hiking in Yosemite National Park.

Right now, I am preparing for my first overnight back-country hike is just a couple of weeks.

If you're looking for a good team-building exercise, you can't go wrong with hiking.

This summer, I hope to organize a group excursion with some of my fellow Decadians.

We often get involved in team river rafting, but I think this could be equally challenging and do more for bringing teams closer.

You're wondering about the title of this post right?

In Australia, hiking is called "bush-bashing".

So, here are a few bush-bashing tips for you...

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?

Requirements Problems? Nevermore, nevermore.

Tomorrow, I'm traveling to the Bay Area for a live demonstration of the RAVEN software everyone is raving about—bad pun intended.

Check out what they're saying...

"The award-winning RAVEN software enables business analysts to quickly build stakeholder consensus on requirements, reduces the time required for stakeholders to approve specifications, reduces developer rework due to requirements errors, and seamlessly links requirements and testing."

Too good to be true?

I'll let you know when I get back.

Remember...

The story of America's battle for freedom is inscribed in the tombstones of those who defended her.

Top 3 de-motivators used by poor leaders

There are those who think that the whole “manager versus leader” discussion is just current buzz-talk—some temporary fad with no meaning.

Those people are dead wrong!

There are many leaders who are not managers, and there are more managers who are not leaders.

True leaders use positives to show respect for the team, and they motivate the team as a byproduct.

Managers who are not leaders use negatives that bring down morale and consequently de-motivate the team.

The following three words are the de-motivators most commonly used by these managers: “Can’t”, “Only”, and “Easy”.

Leadership lessons from Indiana Jones

Who would have thought that a rogue with a lone wolf reputation, known mostly for  thinking outside of the box, could also be a good leader?

• Take a group of folks with mixed skills and form a team.
• Give them a common goal.
• Let them solve it any way they can using the skills that work best for them, both individually and as a team.
• Provide the team with a leader that primarily removes obstacles until the team directs him to take action somewhere else.

This sounds like a recipe for Scrum, but it is actually the plot of every Indiana Jones movie.

Again, I watched the first three this week.

Last night, I watched the Last Crusade, and tonight, I'm be at the theater watching Indiana Jones and the Crystal Skull.

My Fedora and whip are in the car.

New ideas in Environmental Health

As you know, Decade Software leads the industry in providing software for Environmental Health regulators.  As such, I like to keep readers abreast of new ideas in Environmental Health.

The folks at the Cowlitz County Environmental Health Department in Longview, Washington have started an interesting movement.

They are getting the community involved in identifying and correcting local Environmental Health concerns, using what they describe as a national protocol to work through the process.
The final of three public meetings will be held 7:30 to 9, Friday morning.

Get ready for Scrum TV

Mountain Goat reports that Scrum Guru Mike Cohn has been interviewed by Dave Prior of the PMI IT & Telecom Sig.

The exchange is available as a video podcast if you'd like to check it out.

To lead any team, you have to be willing to follow them

I've decided to publish some of my favorite quotes on Mondays.

No one has the energy to be original on Mondays.

This week's subject is one of my favorites—Leadership.

“No man will ever make a great leader who wants to do it all by himself or to get all the credit for doing it.”

— Andrew Carnegie

“You don’t have to hold a position in order to be a leader.”

— Anthony J D’Angelo

“I’ve got to follow them, I’m their leader.”

— Alexandre Ledru-Rollin

You’d think the attitude demonstrated in the last quote would be more common—considering it’s been around over four thousand years!

How do you please all software users all of the time?

Today, EnvisionConnect has no known defect for more than 30 business days.

This is a rule, and it supersedes all other rules.

Why?

Back when we had defects that lived beyond 30 business days, customers would beat us up over it. We'd address the most critical issues, but the rest would hang out in our tracking systems for years.

And we didn't know what to do about them.

Each customer had their own little pet bug that drove them crazy. This prompted them to drive the folks in support crazy. And that prompted the folks in support to drive Development crazy.

But there was little Development could do.

Since each individual customer had their own pet defect, there was no reasonable way to prioritize the list and make everyone happy.

This, however, was only the tip of the ice-berg.

Anytime we added new features or tried to modernize the look and feel of the application, customers would ask: Why is that more important than my pet defect?

Eventually, our very livelihood was effected by this.

We were afraid to modernize the look and feel of our application, because our customers would complain, but when competition came on the scene with spiffy, cutting-edge looking applications, our customers complained that our application wasn't as cute as the competition.

We were in a no win situation.

We had to revamp the way we do business. We had to find a means to deliver cutting-edge applications with a modern, spiffy look and feel—and still deliver a bug-free application.

It wasn't easy finding that happy medium, but we did it.

And now no one drives anyone crazy any longer.

Well, almost no one.