By Jack Ganssle

Demotivated Teams

Published 2/04/2008

Longer title: Can ladling on process fix a demotivated team?

Recently a friend who works in a test group asked about realistic ways to slip better software processes into his team. But it turns out the group is completely dispirited, having for many years been victims of capricious schedules, vague and constantly shifting requirements, and a tolerance, nay, expectation of poor quality. As testers they are seen as an impediment to shipping. There's an expectation that these folks can make up for an already late schedule. Turnover is high.

I told him to forget process improvement. That's impossible when the engineers no longer care. Engineering isn't like an assembly line where workers emulate robots, and rules from high authority can be enforced. In engineering quality and efficiency comes from within ourselves, from caring deeply about doing the right things, and doing them well. Management's rules, well intentioned though they may be, will be quickly neglected by despairing engineers who don't care much anymore.

Process improvement requires a commitment from management to make meaningful change. It requires investing some amount of time and money whose benefits might not be immediately apparent. I get asked from time to time to give a seminar to an engineering group on a Saturday, as there isn't time during the week. I always refuse as that's a symptom that the suits aren't willing to incur the necessary costs of making change. It takes time to adopt anything new, whether it's a new compiler or a fresh process. Unwillingness to invest the required time renders any such adaptation futile.

When management guidance isn't much more than "ship it, damn it" the engineers will use shortcuts. And apathy will spread faster than the influenza. Process improvement is all about using smart ways to counter entropy. But apathy is the kindling of entropy.

Would adopting agile methods help? Nope. Yes, a lot of teams do get a fresh start when empowered by agile approaches. But these methods require buy-in from management. Agile can be particularly hard on the boss, as it requires an unusual level of honesty. Instead of everyone pretending that the schedule is meaningful until the inevitable disaster arrives, agile methods ask the boss to accept incremental development that may very well result in a slipped schedule or shipping without some functionality.

Management is the art of helping people be successful. Though often ridiculed in engineering circles, it is, in my opinion, much more difficult than most technical endeavors. It's so easy to get wrong, and so difficult to do well. Get it wrong and you may poison the environment so badly it's nearly impossible to recover.

Fixing anything, whether it's a software bug or a crippled team, requires, first, recognizing the root issues. A process band-aid just isn't enough to heal a sick team.

What do you think? Have you experienced such a caustic environment?