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.
Anita Wotiz
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)
Thanks for such a wonderfully tips which we all should follow in our daily routine work. All Points are useful and practical. This is also very useful but very rarely used by people.
Great point on listening towards the end, I think that is key no matter how big the team is. What about small teams (2-3 members) though when it comes to the 5 practices you mention above? Any tips or experience?
I think you can tailor each of these practices to work for small teams. The titles make them sound heavy, but they really don’t need to be. I’m going to write more on each of these the rest of the week, but in general, I truly believe that you can take the essence of each and make them work for even tiny teams. The small team just means that communication is easier, that requirements reviews and change reviews go more quickly. But getting the requirements down in writing, keeping up a current requirements baseline, putting every change through a process, testing every requirement (and checkmarking that it’s been tested), keeping track of necessary tasks, it’s all possible to do with 3 people.
And, I’ll suggest that you do these things from the beginning (even with a tiny team), rather than add in the practices later. It’s easier as well as more comfortable.
See if the rest of my posts this week help, and let me know if I can expand more on your question.