Worth the effort

In my previous post about control mechanisms I talked about how audit capabilities such as relationships from the original problem statement to source code help you prevent your project members from going too far astray from the work they should be doing. There are other methods of control that fit in with the same philosophy, which is:

• The controls must be a part of the work they are doing already
• They must feel natural, unforced, and good for everyone

One such method is authorization, in which permission is granted to the domain specialist to do the work that is required.  Authorization doesn’t seem very natural, of course. Isn’t it more natural to simply assign work to an analyst and the analyst goes off and does it? Yes, you can do that, and in many smaller organizations that may be a good approach. But even in an agile development team somebody must do some pre-analysis to get a sense for the scope of the task and the artifacts (code, test cases, documentation, etc) that are likely to be affected. Once you have a good sense for the kind of work that needs to be done, you may wish to restrict the developer’s scope of changes to just the pieces that you expect will need to change. Why? Because if the scope starts to extend beyond what you originally thought was necessary, even if you don’t stop it from happening, you still want to know that it’s happening. Or, you may set out an initial scope as guidance for the analyst, and let the analyst decide if he or she must extend beyond your initial recommendations. It’s intended to help, not hinder. It helps you stay on track.

The restriction can be as strict or as loose as you want. In the good old days of “source code control” – now called software configuration management – a configuration manager actually had to sign off on every file you checked out. Now that’s draconian! And it may still be in practice today, though I’ve never seen it anywhere I’ve worked. Here are the models I have seen:

• Wide open – You are granted permission to make any change you want within the scope of your project. Combined with audit measures such as I discussed last time, this method is popular and effective. But it is not for everyone.
• Monitored – You are granted permission to make any change you want within the scope of your project, but if certain artifacts are modified then a stakeholder is notified of the change. This allows more vigilant control over particularly sensitive artifacts such as complex source code files that are prone to error, non-functional requirements that are common to an entire product line, or features that certain people want to watch closely.
• Grouped Scope – You are granted permission to change only certain artifacts belonging to some sort of group, such as all the source files in a component, or all the requirements in a document, or all the test cases in a sub-section of a document. Sometimes this scope can be altered through the intervention of a manager or a change review board. Sometimes the scope can be changed only by creating a new work item.
• Expandable Scope – This is a variation of grouped scope – it allows the assignee to grant himself additional scope as needed, though ideally scope changes would be monitored by a manager.

Note that authorization is unrelated to locking. Artifacts are locked only after permission has been granted. Also note that these models apply to both source code and associated artifacts. There is no particular reason why an authorization model should not be available in any given domain of analysis.

OK, not quite true. There is one reason: In the past people didn’t ascribe the same sense of worth to non-code artifacts such as requirements or documentation. They didn’t feel that those other domains required the same level of rigor. But that’s changing. Many companies are finding that properly managing their non-code assets is truly worth the effort.