As said previously, Romulus methodology aims to provide an agile development method of building web applications by small/medium-sized teams through the use of Open Source Software tools and domain driven development.

Although methodologies are not tied to the usage of specific technologies, tools or languages, they need to be adapted to their target users and their background. OSS developers are a big target group. Often, OSS developers are reluctant to follow a methodology, so a bigger communication effort should be performed to reach this group of developers.

Romulus methodology is inspired in Extreme Programming, Pragmatic Programming and other agile methodologies, with the addition of a Domain Driven Development approach to software design. Its main principles are described next.

We (the team):
- Pair programming. Two people write the code at one computer. One focuses on detailed code, while the other one reviews the code and focuses on the big picture. This results in higher quality code and a more dynamic working environment. Pairs are changed and roles are traded frequently so that communication is empowered and everybody knows all parts of the system.
- Weekly iterative development. The system is developed with small increments to identify risks and problems. A new piece of code is integrated into the code-base as soon as it is ready. All changes during development are reversible. Thus, the system is integrated and built many times a day.
- Testing. Testing is integrated throughout the development lifecycle. Software quality is verified by testing during every iteration. All tests have to be passed for code changes to be accepted. Write unit test cases before implementing. Finally, write an automated test case for each bug you find.
- Software deliveries. Progress tracking is based on software releases and major decisions rather than written documents.

You (the team member):
- 40-hour week. A maximum of 40-hour working week. No two overtime weeks in a row are allowed. If this happens, it is treated as a problem to be solved.
- Take responsibility for what you do. Think solutions instead of excuses.
- Constantly broaden your knowledge. Testing is a learning mechanism, not a burden that slows down development.
- Improve your communication skills. Communicating your ideas to share different views is essential to reach good design.

It (the code):
- Simple design. Design the simplest solution that is implementable at the moment. Unnecessary complexity and extra code must be removed immediately. The system should be restructured when possible by removing duplication, improving communication, simplifying and adding flexibility.
- Good code. Focus on developing working software. Fix inconsistencies as you see them, or plan them to be fixed very soon.
- Collective ownership. Anyone can change any part of the code at any time.
- Control changes. The maturity of software can also be effectively measured by the frequency and types of the changes made.
- Coding standards. Coding rules exist and are followed by the programmers. Communication through the code should be emphasized to share coding rules.

They (the users):
- Active user involvement. The objective is that both developers and users end up sharing the same view of the software being built, so continuous user participation is crucial. Users should be available to answer any functionality question at any time.
- Accurate positive feedback. This is necessary in order to let erroneous decisions be corrected. The focus is on frequent delivery of products and all changes during development are reversible.
- Users define functional tests. Users are validators of the software product and therefore have to be responsible of specifying functional tests.
- Users decide scope and timing of releases. After programmers' effort estimation for each requirement, it is the user who decides what to do first.

Romulus methodology consists of three phases that are covered continuously to iteratively build a software product: