Author
A methodology is a specific approach and order of doing things to reach a particular goal. Software development methodologies are no different and any new software product passes through the same 6 broad stages of a development life cycle:
- Planning
- Design
- Development
- Testing
- Deployment
- Maintenance
But as the somewhat brutal saying goes “there’s more than one way to skin a cat”. The scope and detail of what happens in each of these broad life cycle stages is not always the same.
Sometimes a software development team is given the responsibility to make its own project management decisions within a looser framework. On other occasions, they are bound to a relatively strict framework of processes and rules. Sometimes the finest details of how a finished software product will look and function to achieve its intended utility are decided from the start and executed to plan. Other times many of the details will be decided upon along the way to the software product accomplishing a broad goal set for its utility. Validated experiments and user feedback will inform the finer details.
In a well-managed software development project, these variations within and between the broad phases of the software development life cycle are not a coincidence. They are by the design of the software development methodology it has been decided the project will follow.
Software development methodologies also often involve a principle, core belief or culture. For example, the four values of the Agile methodology are:
- individuals and interactions over processes and tools;
- working software over comprehensive documentation;
- customer collaboration over contract negotiation; and
- responding to change over following a plan.
The methodology also adheres to 12 principles.
Different methodologies also sometimes further break down or rename the traditional broad stages of the software development life cycle.
There can also be variations to exactly what and in what order software development teams do things even if following the same methodology. That could be because the methodology intentionally leaves space for flexibility or because different methodology frameworks are being followed.
A software development framework is a layer of detail below the umbrella of broader development methodologies like Agile and gives more precise details on how and when components of the development process should be executed.
Now that we’ve covered the theory, let’s take a look at some of the most historically and currently significant software development methodologies and frameworks used. You can almost guarantee at least one software product you know and have hopefully loved using was developed using each of these methodologies or frameworks.
Can We Help You With Your Next Software Development Project?
Flexible models to fit your needs!
Waterfall
The waterfall methodology to software development is a plan-driven, sequential approach. The final software product is planned in its entirety with functionalities and other requirements defined from the start. Can be compared to building a house to detailed architectural plans.
While often considered an ‘old school’ approach, a waterfall model to software development can still make sense for some projects. That usually means when all requirements are 100% clear from the beginning like when migrating a legacy app to a new tech stack or for a simple software product.
Agile
Agile software development is an iterative approach where requirements and solutions evolve as the project progresses. Agile development is broken down into smaller chunks called sprints. Requirements and solutions are usually reevaluated after each sprint.
While the waterfall methodology is used to build a fully complete software product from beginning to end and then releasing it, the agile methodology means releasing the minimum viable product to provide users with added value. The MVP is then adapted and added to iteratively, informed by user behaviour and feedback.
As software products grown in scope and complexity Agile has become the dominant software methodology. Its advocates argue an agile approach leads to the development of software users want or need rather than the software someone has presumed (often wrongly) they want and need.
Lean
The Lean approach to software development was actually first developed for manufacturing processes and defined in the Toyota Production System before being repurposed as a software development methodology. Toyota describes the production system that represents the Lean model as:
“A production system based on the philosophy of achieving the complete elimination of all waste in pursuit of the most efficient methods.”
Lean falls under the umbrella of the Agile methodology as a subset of practices.
Scrum
Scrum is the most commonly used approach Agile development framework and is a lightweight process framework for agile. A key difference to other Agile processes are concepts and practises divided into the 3 categories:
- Roles
- Artefacts
- Time Boxes
Kanban
Kanban is an alternative strategy to Scrum to implement an Agile software development model. While Scrum is based on short, sharp, structured sprints, Kanban is a more continuous and fluid strategy.
It is based on visualising workflows, optimising efficiency and limiting work in progress at any one time.
Scrum vs. Kanban
Scrum is sometimes defined as a specific implementation of Agile with Kanban a specific implementation of Lean.
Feature-driven development, Extreme Programming (XP) and test-driven development are further variations that fall under the Agile umbrella.
DevOps
DevOps, a methodology, organisational culture and set of tools and practices, has become increasingly popular in recent years. That been aided by the fact DevOps is compatible with Agile аnd different aspects of DevOps are even taken from Agile.
Where they differ is that Agile is a general methodology for product development while DevOps specifically focuses on merging software development, QA and IT operations teams into one unit enabling continuous integration and continuous delivery of new iterations.
DevOps means engineers work across the whole software development lifecycle from development to testing and deployment. Pre-DevOps the software development team would simply hand the software build in a staging or test environment over to operations whose job was then to deploy it.
DevSecOps is an extension of DevOps in which everyone working on a software development project is responsible for security.
GitOps
GitOps, specific to cloud native software development, is another model or set of practices that brings development and operations tasks and responsibilities closer together within a Continuous Deployment pipeline.
Summed up in a single sentence:
“GitOps is versioned CI/CD on top of declarative infrastructure.”
The paradigm, anchored to the principle of the Git repository always holding declarative descriptions of the infrastructure currently desired in the production environment which represent the ‘single source of truth’.
The live environment must always be an exact copy of the Git declaration because that means software should run in exactly the same way in both. Which in turn means any new code added to the Git and already tested in that environment can safely be automatically pulled into the live environment. Traditionally, the operations team manually pushes approved iterations into the live environment once testing is complete.
Choosing a project-appropriate methodology or framework is important but executing it well more important
The most appropriate software development methodology for a given project will depend upon a combination of the nature of the project and the experience and preferences of the management and team working on it. A complex, large scale project is a very different beast to a small simple one and different approaches may be appropriate. How experienced the team is can be another important factor.
But, ultimately, a methodology or framework is a productivity and organisational tool. And a tool’s effectiveness is determined not only by it being applied under appropriate circumstances but how it is used. A good tool used well provides efficiencies and better outcomes. But even the best tool used badly won’t result in a positive outcome.
Working to an appropriate software development methodology or framework will lead to the best possible outcome when there is also strong leadership and buy-in from the development team.
When does IT Outsourcing work?
(And when doesn’t it?)
