Software project management

Using Agile, scaling back helps software projects in recession

“You are about to embark on a dynamic quality endeavor. It is time to throttle down on your already oversized and over-budget test and development teams.” That was the opening salvo of Michael Mah’s (QSM Associates) SQE Agile Development Practices Conference session, Rightsizing your project in a down economy.

Project teams are just too large, Mah said. Sure, the poor economy has prompted downsizing in this industry; but that could be a blessing in disguise. After all, there have been many years of impractical spending, mismatched teams and dysfunctional workplace goals in software projects.

For too long, Mah said, executives and managers have emphasized speed over quality, judging success by whether teams turn out code lines on time, rather than on delivering in a reasonable time frame quality code that’s free of obvious functional flaws. He’s seen promotions being given to project leaders who met deadlines without ensuring quality. The results? We are paying the ultimate price in lost jobs and market share, he said.

“Now that I have pointed out where the trouble began, let me now explain where the trouble continues,” said Mah. Today, he sees many companies using the recession as an excuse for adopting seriously questionable practices, like trying to cut steps to recovery by cutting down on employees. In the short term, this does free up some cash; but once a company has rebounded or is recovering, new team members will have to be hired. Of course, it takes precious time and money to train new employees and pay for newbie mistakes.

On the other end of the spectrum, there are the overly-cocky executives who have spent more wisely over the years, they see this time where other companies are cutting back and pinching pennies as time to throw money and software at problems. This rarely works, and usually sends these companies into the downward spiral.

In a time of recession, throwing enormous manpower and software at problems will rarely resolve issues. It is more appropriate and intelligent to scale back, says Mah.

To scale back, project leaders should build strong relationships with a small core group of commited employees. Research your service and tool providers more thoroughly, gather references and check them.

“How many of you have some fear about loosing your job?” Mah asked the audience, and nearly all of them held up their hands. “And how does that make you feel? Bad, right?” Company and project leaders are responsible for alleviating fear, not creating it. Fearful teams don’t work productively. Often fear is responded upon with aggression.

The most effective way in managing concerned workers in a recession is by showing “concerned optimism,” Mah said. Explain the situation, but encourage the team. Leaders’ optimism and relationship helps team members feel confident in their abilities and have more belief that they are capable of working on innovative projects. A motivated and innovation-welcoming team is critical to success and growth. Optimism makes for more tolerable working environments and more creative problem solving.

“I remember a good many times I would work through 70+ overtime work weeks; partly because work needed to be done, but also because there was always a chance that the company president would see me there,” said Mah. “On the occasions when he did, he would always compliment me with a thumbs up and a ‘good job.’ That was all the praise I needed.”

More coverage from Agile Development Practices:
Early adopters, Agile philanthropy key points in ADP keynote

Agile philanthropy, one man’s ambition for a brighter future

Astronaut’s STPCon advice: Teamwork delivers “The Right Stuff”

I’m in Cambridge, Mass., for the the Software Test and Performance Conference this week.  After Wednesday’s performance test workshop, Thursday was the first regular conference day.

U.S. Air Force Colonel Mike Mullane — now retired after also serving as a space-shuttle astronaut — gave the opening keynote. Mike’s talk was on fundamentals of teamwork. He began by taking us through what happens on the day of a shuttle launch: Suiting up, strapping in, countdown and liftoff.

After explaining the tremendous pressure and risk of a shuttle mission, Mike asked us one question: If you were on a project like that, what kind of team do you want to be working with?

The best, right?

Mike talked about these three fundamentals of teamwork:

• Normalization of deviance;
• Responsibility; and
• Courageous self-leadership

I’ll tell you about one of them, “normalization of deviance.” Yes, Mike has a way with words.

To start with, Colonel Mullane reviewed the tragedy of the Challenger Accident, when O-ring failure causes the destruction of the shuttle. O-rings are basically rubber rings; they create a seal or barrier. You’ve probably seen them on your faucet. In the case of your faucet, they keep the water from leaking, but in the case of the Space Shuttle, they prevent the heat of the engines from leaking out from where the engines connect to the rest of the shuttle, instead forcing the heat down the hole in the bottom.

In the case of the Challenger accident, the o-ring failed, the heat leaked out, the section of the booster melted, this changed the pressure situation and the rockets, essentially, vaporized. This directly resulted in the death of the entire crew, including four astronauts Mullane had trained with directly.

How did this happen? Mullane used a fancy term: normalization of deviance. It basically means taking shortcuts, often under intense schedule or budget pressure. The first time you do this, you probably have no negative consequences. This leads to what Mike called “false feedback,” or that the absence of something bad happening means it was safe to do so.

Eventually the shortcut becomes the norm.

Now the original safeguard was put in place for some reason. Ignore it long enough, and eventually, you’ll have a “predictable surprise.” In almost all cases, the predictable surprise is not good for the team. Colonel Mullane refers to the Challenger accident not as an accident, but as a predictable surprise.

Then he pulls out documents. It turns out that in 14 of the 24 missions before Challenger, the contractor who recovered the solid fuel boosters from the water inspected the boosters and found critical or urgent problems in the o-rings. Colonel Mullane read multiple lettters from the contractor to NASA urging immediate action. One of those letters predicted the failure of the shuttle to the mission number.

The problem? Mission One was a success. So was Mission Two. For that matter, NASA had promised congress 26 missions a year, massively decreasing the cost per mission.

It’s really hard to ground a shuttle fleet when you promised the American people to put up a shuttle every two weeks.

Instead of grounding the fleet, NASA tested a damaged o-ring under pressure, and it worked, so NASA granted a waiver.

This subtle change meant that something intolerable had become expected. To avoid normalization of deviance, Mike recommended that we:

• Recognize we are vulnerable;
• Yes, plan the work and work the plan, but not blindly; and
• Maintain situational awareness.

By the time Mike finished, I found myself tearing up a little.  And the talk only got better.

We software testers may not be flying to the moon, but I submit there are still a few lessons we could stand to learn from the astronauts.