A quality software development methodology lends consistent structure and strategy to your projects. By standardizing the steps required to bring a great idea to market, your team can edge ahead of the competition and inspire stakeholder confidence by working smarter instead of harder.
Table of Contents
6 Common Software Development Methodologies
Agile
The Agile methodology breaks projects down into smaller, shorter-term, more manageable, development cycles called iterations. Each iteration can include a variety of activities, including requirements gathering, analysis, planning, design, development, testing, or documenting.
Strengths
- Face-to-face communication is encouraged, allowing development teams to request clarification and minimize misunderstandings.
- Testing can be done during each iteration, resulting in a final product with very few bugs or design flaws.
- Team members are regarded as an asset.
- Multiple Agile frameworks are available:
- Scrum: The most used Agile framework with a focus on team motivation. Scrum is best known for starting each workday with a 15-minute meeting to review completed and outstanding tasks while identifying new and evolving priorities.
- Extreme Programming: Development activities using this Agile framework are driven by the need to be ‘good enough’. Driven by users and their requests, extreme programming is all about taking feedback and making it a reality—often with little regard to design or the possibility that a change may introduce instability or errors.
- Kanban: This Agile framework thrives on transparency, requiring constant communication regarding the current state of development activities.
Weaknesses
- Resource planning can be a challenge, because each iteration may require different expertise or skill sets.
- Documentation is encouraged, but often completed “just in time”, pertaining only to the current functionality added during an iteration and may not be relative to the project as a whole.
- Because development efforts can begin in parallel to requirements gathering for future iterations, it’s difficult to track progress or define and enforce a clear project endpoint.
When to Use
- When your development team communicates well and works closely together.
- Your project is easily broken down into smaller, logically chunked, modules.
- Your team includes members with strong project management skills, so development isn’t frequently sidetracked with requests for unexpected, additional, functionality or features.
- Your stakeholders see value and gain satisfaction from frequent updates with visible progress.
Spiral
For environments that need to prioritize mitigating risk, the Spiral methodology offers a conscientious approach that always begins with research and exploration.
Strengths
- Supports the development of large and complex projects using prototyping and analysis during every phase.
- Accommodates the constant refinement and revision of project requirements based on informed decision making and consent.
Weaknesses
- Overkill for low-risk projects.
- Requires the extensive use of prototypes, which adds complexity and expense.
When to Use
- Ideal when security is a significant concern.
- When your project could be affected by ancillary systems or regulatory requirements that are outside of your control.
DevOps
By unifying development teams with IT operations teams, the DevOps methodology values collaboration while delivering new and updated projects on a continual basis.
Strengths
- With continuous communication between teams, the DevOps methodology focuses on fast development, fast quality assurance, and fast deployment.
- Often takes advantage of automated testing.
- Changes to software are promoted out of a centralized code repository, making them easy to deploy or roll back.
Weaknesses
- Requires multiple teams work in parallel with empathy for each other’s challenges and objectives.
- Development activities are less structured and may not be requested with the support of detailed requirements or analysis.
When to Use
- DevOps is best suited for complex environments that require stability and consistent up-time.
- Ideal tool for ongoing maintenance tasks and delivering small, iterative, changes to existing software applications.
Lean
With the mandate to do the least you can, the fastest you can, Lean is a methodology that thrives in an environment looking for quick wins.
Strengths
- By eliminating features and functionality that aren’t considered absolutely necessary, projects developed using the Lean methodology are generally delivered quickly.
- With a focus on repeatable processes, code reuse is encouraged.
- Experts on your team are empowered and trusted to just get the work done.
Weaknesses
- Software built using this methodology generally lacks the scalability required to easily add on features and functionality in the future.
- Lean contains virtually no accommodation for coordinating the activities of multiple development teams, making it less suited for larger projects or those that require collaboration and communication with ancillary systems.
When to Use
- Lean is an ideal methodology for proof-of-concept projects, providing a bare-minimum product with only the most important functionality to users who can then offer feedback and drive later iterations and updates.
- Can be a lifesaving tool when dealing with stakeholders that cannot agree on project requirements—sometimes you just need to start somewhere.
Pair Programming
As the name implies, Pair Programming brings two developers together to work at a single workstation. Using this software development methodology, while one developer is at the keyboard, the other serves simultaneously as an observer, pointer, or navigator.
Strengths
- By applying a stream of consciousness approach to development, each developer can focus on a single aspect of a particular task: cutting code vs. adhering to project requirements.
- Can reduce testing time and expense by identifying possible issues as they are created.
Weaknesses
- Many developers find it intimidating or uncomfortable to be watched while they work.
- Requires both developers to be in the same physical location, ideally in an environment where frequent speaking aloud isn’t an issue.
- Works best when the pairing is expert-expert, so productivity and skillsets are evenly matched—though there are instances where pair programming can be seen as a valuable teaching and knowledge transfer experience.
When to Use
- This approach works best when development teams are small, and well-acquainted.
- Your project is structured such that ongoing brainstorming or strategizing is seen as beneficial.
Waterfall
Projects that are highly defined, with a series of sequential steps, thrive with the Waterfall methodology. Waterfall is a commonly employed software development methodology, operating on the principles of defining requirements and producing results.
Strengths
- Because project requirements are fully identified at the start of a project, phases can be planned with all activities defined (for design, development, implementation, verification, and maintenance).
- Upfront planning work can be completed by less technical team members.
- Deadlines are often fixed, and deliverables clearly identified.
Weaknesses
- Project phases do not overlap, and the only movement is forward, so changes to items completed in earlier phases is considered to be a new project.
- No working software is produced until the end of a life cycle.
- With the Waterfall methodology, the success of each project is determined by the quality of the requirements.
When to Use
- Your budget is defined and not easily adjusted.
- Your scope needs to be strictly controlled, due to stakeholder or regulatory requirements.
- You have strict control over your environment.
Choosing A Methodology
In large part, choosing a methodology is a mixture of education and instinct. Projects inspired by the best ideas in the world, brought to life by the most talented developers, are still vulnerable to risks like delayed delivery and dissatisfied customers.
Before choosing a software development methodology, consider the following criteria.
- Get to know your stakeholders: Don’t be afraid to ask questions before the start of a new software development project. Find out whether your stakeholders like to be more hands-on, reviewing progress at regular intervals, or if they prefer to employ a ‘wait and see how it all turns out’ approach. It can be helpful to learn whether your stakeholders also answer to other stakeholders of their own.
- Flexibility of project requirements: On one hand, when the requirements for a project are always changing, it can be difficult to deliver a product that meets expectations. That said, with some projects, we would never get started if 100% of the requirements needed to be determined ahead of time. In these instances, be sure you employ a methodology that offers checks and balances at regular intervals to be sure that changes to requirements are in the budget.
- Identify your end users: A project designed for large numbers of end users that are located across the globe has different considerations than one that will be deployed internally to a single team within your organization, located in the same physical location. Be sure you can answer questions about their demographics, education, expertise, and needs as they may pertain to your project.
- Understand the financials: It’s a harsh reality, but budget often drives the complexity and requirements for a development project. Be sure to choose a methodology that compliments the sophistication and complexity of what is being requested.
- Consider your timeline: If your project is longer-term, be sure to choose a methodology that accounts for the possibility of staff turnover or changes to infrastructure that may need to be accommodated. You also want to be careful that you don’t choose a methodology that is overkill for shorter-term projects.
- Know your development team: Look at your available resources and understand their abilities and capacity. Some teams employ methodologies that compensate for shortcomings, such as a lack of project management expertise or business analysts. Others look for methodologies that really isolate roles and let each team member perform singular tasks that compliment their expertise. Knowing where your team needs assistance and support will make it easier to choose the best methodology.
Consistency is Recommended
It may be tempting to choose a new methodology for each project your development team takes on, but this isn’t always sensible. Without consistency, your development team will fail to gain the efficiency and comfort derived from working with the same methodology over time.
Just as often, development teams boast using hybrid approaches, taking what they feel are the best characteristics from several methodologies and combining them into something customized and unique. Ultimately, this produces the same results as using no methodology at all—losing the consistency and structure of an established methodology, along with any community support.
Read next: Using Swim Lane Diagrams to Improve Software Development
