At my last company we took pride in the amount of work we were able to accomplish with a very small team – software of high quality and releases on tight schedules. The high quality and the responsiveness to customers’ demand for new features kept our customer support expenses low and gave us good customer references.
We were fortunate to have, as our senior technical staff, individuals who had been exposed to both the heaviest of software processes (in the Aerospace industry) as well as the chaos that can accompany a lack of any software process at all. So we worked well together, putting in place those practices that made sense, modifying those that were needed but too heavy, and eliminating those that had a low cost/benefit ratio.
Our stable of mandatory practices included:
1. Written, reviewed, approved requirements
2. A requirements baseline, implemented with a requirements management (RM) tool
3. Strict change management (using a feature-rich tool)
4. Testing of every requirement (using the RM tool to track progress)
5. Every task needed for a release is recorded and assigned an owner (whether a coding task, testing task, or other) and every task tracked to completion
I tell my students that a practice will not work unless every software engineer buys into it. If one engineer allows a Sales person to whisper a good idea into his/her ear and agrees to sneak it into the next release, then the whole process will be subverted. Every practice must be selected for its benefit, must be structured to be easy to follow, and engineers must see the benefit to themselves. If practices are perceived to be a pain in the neck and of little ultimate benefit, they will be abandoned. You will see a quiet mutiny, little acts of forgetfulness and uncooperative behavior, excuses related to deadlines, until you finally abandon your plan and chaos reigns.
Getting engineers to buy into selected practices usually involves some sort of training, but it also often involves learning a lesson. An undocumented requirement requested by marketing, making a change without going through the process, an untested requirement getting into a release – sometimes it takes a lapse, a bad outcome, followed by a “what have we learned from this” for the engineer to appreciate the benefit to themselves.
Management, too, must respect every rule put in place to implement the practices, and upper management must not just respect the rules but enforce them, and never allow them to be circumvented, by anyone. Even by themselves. Without this management commitment, engineer buy-in is impossible.
It’s a constant cycle of benefit analysis, buy-in, adoption, listening. What’s “listening” got to do with it? You have to be willing to discard or modify what doesn’t work or what wastes time. So you must listen to the complaints and suggestions and understand what isn’t working. And then adapt. Analyze, adopt, adapt. That’s how you get to Practical.
www.duckpondsoftware.com (see the Consulting tab)
Instructor, UCSC Extension in Silicon Valley
Software Requirements Engineering and Management (next class Aug 2009)
Software Project Planning, Monitoring, and Management (next class Oct/Nov 2009)