Archive for the ‘Management’ Category

Rotation or Revolution

Thursday, May 6th, 2010 by The Director

This article on career rotation reminds me of a point.

In Big, the hit movie from the late 1980s, star Tom Hanks rises from a clerk in data processing—that’s what technology was called back then—to become vice president of product development for a toy company. That quantum leap in status and pay took him all of a week to pull off. Some would-be fast-trackers might call that the ideal job rotation.

Some companies have always encouraged ambitious employees to rotate out of their discipline—technology, finance, marketing, operations, etc.—and into a different department, often one in which they’d have to push themselves to succeed.

The rationale is simple: By seeing how other areas of the company operate—getting the proverbial big picture—an employee becomes more valuable, and the organization as a whole gains. Six to 18 months in a new assignment arms an employee with additional knowledge and layers of skills.

That career advice is more geared to people in big corporations who aren’t in tech jobs but managerial or other non-tech components (business analysts, project managers). Nobody is going to take a technical writer and try him out in QA, for example, or give him 18 months to taste development. However, rotation is important to keep your peeps, especially your QA bunnies, from burning out.

Let me explain. No, there is too much.

One of the shortest postings in my career came when I was put on a QA team on a long deathmarch of a multimillion (and I mean two) and multiyear (and I mean like four) project to develop a custom piece of software for a client. I joined the team some months in, when they had a mostly working Java desktop application (perish the thought! because the application surely perished). I started testing an area of it and tearing it up. The client didn’t like this, didn’t like that, wanted more of that, and altered the specs so that my employer had to change it. I spent nine months essentially testing the same features of the same application and often logging the same issues when I left.

Don’t do that to your testers. Let them see different things, different projects. If you swap them around, they get more experience with the gestalt of the application/business/et cetera as well as learn new techniques, technologies, and music fitting for QA when they work with different people.

Where Process-Improvement Projects Go Wrong Is Right

Monday, March 1st, 2010 by The Director

This article in the Wall Street Journal is spot on: Where Process-Improvement Projects Go Wrong:

What do weight-loss plans and process-improvement programs such as Six Sigma and “lean manufacturing” have in common?

They typically start off well, generating excitement and great progress, but all too often fail to have a lasting impact as participants gradually lose motivation and fall back into old habits.

I’ve sat through enough process meetings to know it’s true. We’d sit in a conference room, chart out a nice flowchart eventually of an ideal situation, and then when the meeting broke up and actual projects started, everyone would do what they always did in the first place. Which is ignore the process.

When you’re trying to improve the process in an organization, you have to take into account the specific organization and the major players within the organization. An outside consultant beaming down solutions from planet Six Sigma is not going to know enough about the industry and about the people within the company. They will offer procrustean solutions that the teams will easily ignore or forget.

The best process improvement can come from within if you have a long enough relationship with other people in the organization to know their strengths and their weaknesses. To improve the process, you need to account for the people who will try to make it work and to accommodate them. You’ll want to capture the best of the things they do and you’ll want to make sure the process handles all of their weaknesses and shortcuts, too, so when the fit hits the shan, the process handles that, too.

A process under glass, framed on the wall, isn’t the goal. Doing things the right way is.

Will That Put QA Management On The Hook?

Thursday, February 25th, 2010 by The Director

A proposal would hold vendors liable for bugs:

SANS’ newly released Top 25 list of common programming flaws came with a little legal muscle, too, with representatives from SANs, Mitre, the U.S. Department of Homeland Security, the National Security Agency, and other organizations pushing for custom software developers to be held liable for insecure code they write.

Experts from more than 30 U.S. and international organizations, including OWASP, Microsoft, Apple, EMC, Oracle, McAfee, and Symantec, contributed to the CWE/SANS Top 25 list. And procurement experts from some of the organizations are recommending standard contract language for procurements that would ensure buyers aren’t held liable for software that contains security flaws. “Wherever a commercial entity or government agency asks someone to write software for them, there is now a way they can begin to make the suppliers of that software accountable for [security] problems,” says Alan Paller, director of research for the SANS Institute.

Paller says the contract language would be based in part on a draft in the works by the State of New York (PDF) that refers to the SANS Top 25 and would make the state’s custom-software vendors contractually bound to provide apps that are free of those bugs. Paller says although there is “no formal agreement on the language” among the group at this point, it’s focused on the section of New York’s proposed contract language that reads: “the Vendor shall, at a minimum, conduct a threat assessment and analysis of vulnerability information, including the current list of SANS 25 Most Dangerous Programming Errors; provide the Purchaser with a written report as soon as possible after a vulnerability, threat, or risk has been identified.”

Well, within the context of the job, QA management is always on the hook. Any bugs that get through reflect poorly on QA (as they do on the whole organization, but I always internalize it because I’m that way).

However, when I read something like this, I get a little skittish and recollect sitting in a sexual harassment seminar given to all department heads and learning that I, personally, was on the hook as a potential plaintiff if one of my minions made a hostile-in-the-sexual-way environment (hostile-in-the-QA-way environments are standard). I am sure I paled a bit learning someone could get my house. I mean, I had a Canadian on staff, and you know what that means (the man was born in Canada).

I’m probably a little worried for something that probably won’t come to pass. A little liability and being required to fix problems is good. That fear can help make some better software. How the torts shake out, though, that remains to be seen.

Meetings, Managers vs. Productive Employees

Monday, August 3rd, 2009 by The Director

A thoughtful rant about how meetings affect managers differently than programmers, et al.:

 There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

When you use time that way, it’s merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you’re done.

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

That can hold true for QA, too.

Worse, that block of time might have looked good when the meeting was scheduled, but slipping development timelines now impose that meeting in the four hour block on a Thursday afternoon between being ready for test and the time the client expects to review the Web site in a test environment.  We’re not talking beta, here, bubs, they expect it to be feature complete and ready.  Instead, I’m supposed to sit in a four hour seminar on succession planning?  How about I talk about secession planning, wherein we in QA form our own nation-state, huh?  And we’re marching on the kitchen at 19:00.

Sorry, got off topic there.  But as a hands-on manager, I’ve struggled myself with meetings and the trappings of executivedom.  Hey, let’s have a meeting here and a meeting there; meanwhile, the actual production of the things we’re paid for go off the rails because all the decisionmakers are in the fishbowl conference room, not deciding and not contributing.

Sorry, got off topic again.  You know what else can blow something up?  Because we in QA don’t have the creative genius aura that allows us to metaphorically close our doors and get deep into work.  People are always popping by with questions or comments or whatnot.  Project managers want updates on things you haven’t gotten yet.  Designers have questions about how to spell the client’s product name.  And so on.  Meanwhile, you’re trying very careful to remain focused on a methodical assault on a Web site or application, and every time you’re called to avert your eyes from the screen, you need a couple of seconds to step out of the testing mode and into “social” interaction and then a couple seconds back to where you were and what you were doing.

I do my best testing alone, in a darkened room, with limited interruption.  That way, I can give the site or application my undivided attention and can see the small things that are wrong.  I hate being called out of that for meetings, communication, or other less productive activities when I’m under deadline.

Ah, this rambled.  Perhaps I’d better mount another assault on the coffeepot.

(Link seen on Outside the Beltway.)

Casey Stengel on Successful Quality Assurance Management

Thursday, July 16th, 2009 by The Director

Sorry to go back to this well twice in one day, but:

 The secret of managing is to keep the guys who hate you away from the guys who are undecided.

Cooking Your Own Dog Food

Wednesday, December 3rd, 2008 by The Director

An old expression in IT goes something along the lines of eating your own dog food, which means you use the very software you write every day.  Also, it goes to show that people who use that expression tend to think of their own work as grinding horsemeat and mixing in the right amount of ash to meet the minimum standards.  However, Joel Spolsky explains in his Inc. column for December that, as a manager, you need to be able to do more than report cost/benefit analyses and calculate ROI in 3000 words or more:

Anyway, on my first day of work for the sergeant major, I didn’t know what to expect. I was sure it was going to be horrible, a suspicion that seemed to be confirmed when he took me to the officers’ bathroom and told me I would be responsible for keeping it clean. And then he said something I didn’t anticipate.

“Here’s how you clean a toilet,” he said.

And he got down on his knees in front of the porcelain bowl — in his pressed-starched-spotless dress uniform — and scrubbed it with his bare hands until it shined.

To a 19-year-old assigned to clean toilets, which is almost by definition the worst possible job in the world, the sight of this high-ranking, 38-year-old, manicured, pampered disciplinary officer cleaning a toilet was a shock. And it completely reset my attitude. If he can clean a toilet, I can clean a toilet, I thought. There’s nothing wrong with cleaning toilets. My loyalty and inspiration from that moment on were unflagging. Now that’s leadership.

To be a good QA manager, you need to be able to actually perform software quality assurance tasks as well as or better than your underlings.  You should probably be one of the team’s star players, able to teach and inspire and lead by example.

A lot of QA management without this capability is right now sucking wind through puckered lips, but it’s true.  Come crunch time, you have to be able to get in there and contribute to what your team is doing with a late deliverable and a looming deadline.  Walking around with a checklist on a clipboard and you’re only making things worse.

Although you could walk around, like Spolsky, with a power tool.  That sort of energizes/terrifies people.

Bonus defect!  The automatic pager on Inc.com content management system fails.  Go to page two of the article and click either prev or 1 links to go back to the first page, get a free 404 error.


wordpress visitors