Make the Method Serve You
By Tom Spitz on May 12, 2011
This sort of feedback indicates that the individual may not yet have had the opportunity to fully explore OUM and to understand the philosophical basis upon which it has been developed. When you look more closely, you'll find a number of things that tell the real story:
- Views provide an initial pre-tailoring of the OUM materials (though still a superset).
- Supplemental Guides provide further tailoring recommendations along with product or discipline specific guidance to accelerate projects.
- The Implement Core Workflow view identifies core tasks at the heart of any project. It helps keep project teams focused on the essentials by providing a four-step process for building up a project plan.
- Guidance around iterative and incremental project planning and for managing an OUM project using Scrum illustrate our ongoing commitment to supporting agile project management.
Here is an excerpt:
Do not serve the method; make it serve you. The purpose of methods is to identify and manage risks, improve repeatability and quality, and encourage knowledge capture and reuse. If you’re not going to need it, don’t do it.
OUM should be scaled to fit your project. You should do no more than is necessary to satisfy the requirements of the project and appropriately address risks. Be sure to not only think about which tasks you will do, but also consider the depth to which your project team will execute specific tasks during specific iterations. Under the proper circumstances, spending the time to simply consider a task can constitute executing that task.
The output of a task (a work product) need not be a document. OUM provides templates for many of its tasks. Use of these templates is optional. They should be used only when appropriate to the context of the project. Work products can just as easily be a model in a repository, a prototype, a set of application code, or even the tacit knowledge contained in the brain of a developer. (Yes! This is an appropriate way to work, under the right circumstances.) Written documentation should be produced only when it is essential for the project’s success or the future operation and maintenance of the resulting software system and the business it supports.
A focus on understanding the most significant risks and requirements of the system is more important than producing elegant models or perfect documents. For example, not every model needs to be fully attributed to adequately manage design or implementation risks. On the other hand, skipping tasks simply to save effort may be a false economy, especially when implementing sensitive or mission critical systems. Do just enough.
OUM needs to support a broad range of projects; from those which must be very predictive to those which would benefit from being very adaptive. To be predictive, OUM needs to include materials that enable it to support a "heavy" level of ceremony. However, experienced practitioners will recognize the need to use careful forethought and judgment to employ "just enough ceremony" and produce "just enough documentation" to support the characteristics of a specific project.
Click to read the entire OUM 5.4.0 Read Me First.
Meanwhile are you going to Make the Method Serve You? What is your approach?