Well, Google found some traces of such a beast which is clearly describing a methodology-like thing:

This document aims at introducing briefly to the readers the Object Oriented Methodology (OOM). Information covered in the document includes a brief overview of the OOM, its benefits, the processes and some of the major techniques in OOM.

OOM is a new system development approach encouraging and facilitating re-use of software components. With this methodology, a computer system can be developed on a component basis which enables the effective re-use of existing components and facilitates the sharing of its components by other systems. Through the adoption of OOM, higher productivity, lower maintenance cost and better quality can be achieved.

This methodology employs international standard Unified Modeling Language (UML) from the Object Management Group (OMG). UML is a modeling standard for OO analysis and design which has been widely adopted in the IT industry.

The OOM life cycle consists of six stages. These stages are the business planning stage, the business architecture definition stage, the technical architecture definition stage, the incremental delivery planning stage, the incremental design and build stage, and the deployment stage.

But this thing didn t spread (likely) very far. Maybe you should ask your contact for some references.

Object Oriented programming is a programming technique used when writing code. This is something different from a methodology which is a way of planning, managing and implementing a software project.

see: http://en.wikipedia.org/wiki/Object-oriented_programming

Apples and oranges. OO is a way of designing code. Scrum/waterfall/spiral, etc... are about how you manage a project. They re independent of each other.

That said, you really should look into OO.

In the late 1980s and early 1990s, some authors published work (especially books) with titles and blurbs including the word "method" or "methodology" in them; these works focused on object-oriented modelling approaches, explaining in detail the modelling primitives (metamodel) that one should use to construct structural and dynamic models of systems. Their treatment of the process to follow, however, was minimal. Later, they were criticised by applying the term "methodology".

Nowadays, "methodology" is usually thought of including a process aspect, a modelling (or product) aspect, and a people aspect, at least. The modern methodologies that were built on the tradition of those 1980s-1990s works that I mentioned above are often called "object-oriented", because the modelling approaches that were used then were, in fact, object-oriented.

Actually, it is a debated topic in research circles whether the process aspect of a methodology is substantially different depending on the modelling aspect of said methodology. For example, is the process aspect of an object-oriented method very different from the process aspect of an agent-oriented one? If you think it isn t, then the term "object-oriented methodology" may make no sense to you.

Object-orientation is an entire iterative methodology, with each stage used to validate or expose holes in the previous. It covers everything from identifying ALL stakeholders, requirements elicitation from them all, documenting the requirements in Use Cases (not part of the original O-O methodology, but adopted when Jacobsen joined Booch & Rumbaugh at Rational & UML merged in his Objectory), Analysis of the requirements begins once they had been validated with text-based Use Case documents the stakeholders can understand. Analysis is still in the business problem space, not the software solution space. Architechure & System-level Design are the first steps in creating the solution space for the identified business needs. The tasks can then be broken up and Low-level Design and Programming, implementing the Design via the case hierarchy originally created during Analysis and refined in System Design in UML Case/Object diagrams is finally handed off to the coders. One hard-and-fast rule in OOADP is that the Analysis and Design artifacts are baselined BEFORE coding is allowed to begin. Any changes that the business or marketing departments want during coding MUST be submitted to a Change Control Committee, dominated by Development. They will prioritize requested changes, evaluate their effect on the canonical class hierarchy and distributed design, determine how much extra time, money, and resources each change will impose, and go back to the business & marketing people and say - "This is the cost in time, money, and resources. Are you willing to accept the cost?" If not, the change may be discarded or moved into the next release. When you design an enterprise-sized project, you only really get that one chance at creating its skeleton of the class hierarchies. The later you try to modify the systems and have to modify classes and dependencies, the more likely you are to incur extra expenses, time delays, requirement needs - and bugs. Often subtle bugs in areas you had formerly regression-tested to hell and gone.

Agile people used to refer contemptuously to the full OOADP methodology as "BDUF" (big design up front). Scrum is designed to be the antithesis of this, with 5 or 6 programmer teams working with only one Product owner who is responsible for business/customer needs, and knows only a keyhole view of all requirements, occasionally bringing in other SMEs as she identifies a need or gap. Tasks are written out as "stories" (that is a bit of a simplification - they can be any one of several forms of requirements or requirement changes) on 3x5 cards and are tackled a small group at a time, with the intention of finishing each group by the end of a 2 or 3 week "sprint." Undone tasks are put back in the backlog of stories, an analysis is done to determine the state of the piece of the project this team is responsible for, and some of the remaining stories are passed out for the next sprint. Business & marketing LOVE Agile as much as they HATED O-O because they can insert new or altered stories or Use Cases, or other forms of requirements almost to the end of the development stage. The final product keeps changing to meet what business & marketing see as quickly shifting needs and time windows (usually hysterically exaggerated). The various little stovepipes caused when you scale a project up to more than one Scrum Team are dealt with using periodic Scrums of Scrums, where the Scrum Masters of the teams get together and try to keep every team on the same tracks and determine if any teams have backlog items that block progress within another team. The bigger the project, the more bureaucracy is added to coordinating all these teams, each subtly changing their original mandate as stories are updated or new ones added.

I ve worked with O-O since the original CRC cards and Wirf-Brock refinements all the way through today s iteration of UML. I even spent several years as part of a four-man team from Bell Labs, teaching O-O and C++ to AT&T development teams. I ve also worked with Agile (mostly Scrum and ScrumBan, a merger of Scrum and Japanese Kanban). I have used Agile Scrum since 1998, before there was an official standard. Agile is only a partial methodology, so every project has to find other tools or methodologies to fill in the gaps. I ve seen thing get REALLY ugly if the teams were not made up of 1st-level ScrumMasters and all expert developers, cross-trained in each others skillsets. Corporations today have made rates so low, that most of the truly gifted programmers I worked with 15 or 20 years ago are doing something else for a living & getting their coding jollies working on mobile apps or open source projects. You rarely see a truly talented team. Companies hire people without the necessary 10x "rock star" skills for some of the roles, and Scrum teams can be erratically staffed. Also, the more you try to scale Scrum for larger projects, the more problematic the results and the more the department begins to shed canonical Scrum rules, looking for some hybrid that works better.

Agile is, as its early proponents first said, excellent for doing maintenance, enhancements, and smaller non-time-boxed projects and I ve seen it used very effectively. However, for a corporate enterprise project that is not driven by the fickle winds of marketers and business people s hysteria about slight changes in an external market s needs or time windows, I ll take O-O every time.

Whenever I m presented with a contract opportunity that has both Object Orientation and Agile in the same set of requirements, I run the other way.

Back in the day people believed that Object Oriented programming was going to solve world hunger. I suspect that now agile is going to do that, they ve lumped them together :-)

Seriously though, although some people took object oriented design to the status of a design methodology - identify actors & behaviours in a formal way to develop the design, it is really a set of principles about how to design software. It certainly isn t a methodology for managing the development of software projects like Scrum and agile might be.