Methodology Design: The Way We Do Things Around Here
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
You might be coming back from the big meeting where the boss announced the methodology improvement program. Perhaps the subject showed up at your annual review as a "goal" for next year. Or maybe you’re the boss, and the subject keeps coming up in leadership meetings. It doesn’t really matter. The point is, you’ve got to improve your software development methodology.
Whatever that means.
Let’s face it—a software development methodology is just a fancy term for "the way we do things around here." Saying that you want to improve the methodology doesn’t really mean anything. There are piles and piles of factors in software development; simplicity, reliability, performance, fitness for use, response to change, accountability, speed, defect ratio, customer satisfaction, "making sure you pick the right projects," or "making sure you run the projects right"...the list seems endless. To reduce the "goodness" of your process to a simple one-dimensional statement is somewhere between immature and unethical.
At the same time, it is possible to improve a specific attribute of the way we develop software—for example, to make delivery dates more predictable, to make the state of the project more visible, to improve overall development speed, or to more easily respond to changing demands. Specific attributes of the methodology can be improved.
What the Textbooks Don’t Say
Tradeoffs are not just something you have to deal with now and then; methodology in design is all about tradeoffs. For example, if the organization wants accountability and predictability, it may require documented requirements with various levels of review and signoff, and create a change-control board with the power to line-item veto changes in requirements that may affect schedule.
Everything sounds good so far...until about six months later, when the VP of New Product Development can’t get the feature set changed in order to respond to a market demand. Some ninny down in software engineering is holding up the company’s ability to deliver products to customers, all in the name of "process improvement"!
Then again, perhaps you work in a stable field where the requirements don’t change much—such as defense contracting. In that case, locking down changes might be exactly what the organization needs.
My point is that improvement in software development must be subordinate to the needs of the business; the key is to trade away problems that bother the organization for problems that don’t. As SourceGear CEO Eric Sink puts it, "You can’t eliminate problems, but you can make trades to get problems that you prefer over the ones you have now."
Consciously or not, the trade is going to happen. If done unconsciously, the team could very well end up in worse shape than when it started. Then again, sometimes the organization wants everything: Predictability, accountability, visibility, and the ability to respond to change. In that case, either some genius is going to innovate something (more about that later) or else the system will find some tradeoff you haven’t thought of yet—probably something that’s hard to measure. In the case above, a constant pressure to meet mutually exclusive goals could lead the team to work on only those specific measures, ignoring the support they historically gave to the sales department. When the sales department has to cancel a series of web-based-meetings because they can’t figure out the system, costing the organization six months worth of sales leads, your raise, your bonus...it’s really hard to call that process improvement.
Since it’s better to make tradeoffs consciously, let’s talk about a few of the most common ones.