Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

How to break bad news about shipping software

Matthew Heusser | Jan. 24, 2014
Imagine you're working on a major project such as Healthcare.gov. Suddenly, you realize there's no way the software will be done on time -- or even work. What do you do? Hear how veteran testers, project managers and developers tactfully handle such situations.

Fraser's examples are factual. She left it up to the product owner to decide if the product would ship. Her job was to inform the owner of the consequences.

Compare these comments:

  • "The software will cause the application to crash, on average, every 20 moves, or 40 minutes of game play. And we'll have 12 levels of content, not the planned 20."
  • "There are too many bugs. We can't go."

The first statement is factual. Who can argue with it? If senior management wants to ship, then, when the house is burning down because of software crashes, the problem becomes fixing, not blaming. That changes the role of test and QA from "find bugs and protect the user" to "provide information to decision makers."

That's great if you're a tester. What if your role is line management?

The Management Perspective: Reframe Progress as Problems to Be Solved
Johanna Rothman - author of Behind Closed Doors: Secrets of Great Management and Manage Your Project Portfolio, has been managing and consulting on software projects since the 1980s. She, too, once found herself in a hole. The first thing she did? Stop to figure out what was next, Rothman says, because she didn't want to stay in that place.

Rothman was directing a team of 80, bringing in dinner for everyone five nights a week. It was obvious that the team would miss deadlines, but in the 80s, it had no tools to know just how bad things were.

"We didn't know about velocity charts then. We didn't have user stories," Rothman says. "Even today, some people don't have requirements in the form of user stories. What they can ask is, 'How can we show progress?'

Take the requirements you have, in whatever form you have them, Rothman says, and make them features, in some sense of the word. "Customers, after all, buy features. Turn what you're doing into a feature. Then, show progress by feature." This will require working across teams, - but that's a good thing, she says: "Showing progress, and working through features, will start getting you places."

Once there was a way to measure, Rothman asked for release criteria. What really block the project from release? It might be a date. Healthcare.gov, for example, was going to ship Oct. 1, 2013, no matter what. The blocking issues might be core features, or a handful of things instrumental to the user experience. If you know the "have to's," she says, you can cut the "want tos" and refocus the team. That can change a lot about a project.

Tricia Broderick - the director of software development at Techsmith as the company planned its internal developer conference and now a coaching trainer at Santeon Group and chair of the coaching/mentoring track at target="_blank">Agile 2014 - also empathizes with those breaking bad news on software projects.

 

Previous Page  1  2  3  4  Next Page 

Sign up for CIO Asia eNewsletters.