Customer satisfaction by rapid, continuous delivery of useful software
Your customers and users will be satisfied because you are continually delivering value with usable software. This is a stark contrast with the traditional Waterfall product delivery process. If your customers are used to Waterfall, they may find it strange to have working software sooner. The big downside of Waterfall is that you deliver large pieces of functionality towards the end of the project life-cycle. This means that all throughout the development stages of Waterfall, your project is incurring cost with no return on investment. By delivering working pieces of functionality sooner and more regularly, you're giving your users an opportunity to get a return on their investment sooner. Sure, they may not have all the functionality they need upfront, but they can start to make use of the solution to make their lives easier and start realizing the benefits sooner. People and interactions are emphasized rather than process and tools.
Agile is focused very heavily around people and the interactions between people rather than the processes and tools
This is a core value of the Agile Manifesto. This is important because it is the input from your team and customers that will ultimately make your project a success, as opposed to what tools you use. Continual collaboration throughout the entire development cycle of your project enables everyone involved to build a good working relationship based on trust. This trust-based working relationship is crucial when building software incrementally.
Continuous attention to high quality code and design
When working with Agile, you're working short iterations and only build what is necessary to satisfy the requirements for that iteration, and nothing else. This forces you to keep your design simple, which helps you design testable and more reliable systems. Developers understand and choose many solutions to solving a businesses problems, and these are choices that reflect a craft that balances design, use, and support. Developers provide the technical support to the team that enables them to always move forward at rapid pace and keep code quality high. Developers like to use the latest techniques for keeping their implementations simple and clean without having to rework any of their solutions.
One of these techniques is refactoring. Refactoring is the process of improving the design of existing code without changing its behavior. In order to make changes to the structure of the code, refactoring uses a quick succession of small, well-defined steps that can be verified as safe or functionally equivalent. Refactoring is most often done in conjunction with test-driven development where unit tests and simple design make it easier to refactor safely.
Simple design
Keeping your design simple (and not repeating code) helps you keep your code maintainable. If you design your code to be modular and interface-driven, then you can reduce coupling between objects, which leads to a more robust system.
Test-driven development
Test-driven development (TDD) is a way of driving the design of code by writing a test, which expresses what you intend the code to do, making that test pass, and continually refactoring to keep the design as simple as possible. TDD can be applied at multiple levels, for example, unit tests and integration tests. Test-driven development follows a rigorous cycle. You start by writing a failing test, and then implement the simplest solution that will cause that test to pass. Next, you search for duplication in the code and remove it. This is often called Red-Green-Refactor, and has become almost a mantra for many test-driven design practitioners. Understanding and even internalizing this cycle is key to being able to use test-driven design to solve your problems.
Embracing changes in requirements
Your customer or business sponsor may change their mind about what is being built. This may be because you have given them new ideas from software you delivered in a previous iteration, or because the company's priorities have changed or new regulatory changes have come into force. The key thing here is that you should embrace it. Yes, some code may get thrown away and some time lost, but if you're working in short iterations, then this lost time is minimized. Change can be very scary at first for clients and partners alike, but when both sides are prepared to take the leap, it can be mutually rewarding. In some ways, Agile is a simple idea, but the reality is that it can mean different things to different people, depending on their role in the software development process. One of the key things, though, is to be open to change, not just in order to move in traditional ways of organizing projects, but to adapt your use of Agile itself.
Early return on investments
Another advantage to releasing higher-value features early is you start to get a return on your investment. Running a software delivery team is expensive. You have permanent developers and testers, as well as consultants with expensive day rates. There's also business analysts and project managers, as well as other hardware and software costs. These are all costs to the business. By releasing early and generating revenue from your product, you can start to offset some of the initial investments and development costs. On the flip side of that, if you have a more Waterfall-based approach where you end up with a "big bang" deployment after a year or so, you will have already spent large amounts of money to fund the development with nothing to show until the end.
Feedback from your customers
If you release early, you can start to solicit feedback from your customers a lot sooner. These customers could be public-facing customers or business sponsors. I've worked on many projects where the business customer specifies requirements, which you then build, only for the customer to want changes once they have something they can use. This always seems to happen—it’s very hard for someone to specify a system without having something to play with. You can use prototyping software to help, but there really is nothing like giving them actual functionality early on to start using. One of the principles of Agile is to embrace change in the requirements. This should be expected, so giving your customer something they can give feedback on earlier in the process will give them an opportunity to make changes sooner without causing much disruption.
Feedback from real customers
Once you start getting feedback from real customers, you can start incorporating changes and new ideas from the feedback into the product. It is much more cost effective to make changes early on in a product's development cycle than it is to wait until the end after a large release has been made. It's not just customer feedback that helps you build the right product—by testing your product early in the marketplace, you can gauge customer uptake and see how popular the product will be, and continually deliver better quality.
Everything we have discussed so far has business benefits or culminates in the fact that you should be delivering a better quality product with every release. By releasing earlier and soliciting feedback, you can learn from the product performance earlier, and use this information to create something better. Product and system development is all about continuous learning and improvement, which is much easier to do when you're delivering a project by being agile. It doesn't matter whether you're using Extreme Programming, Scrum, DSDM, Crystal, or any of the other project management frameworks. If you adhere to the core values in the Agile Manifesto and routinely deliver high-value functionality early to your customers, monitor their usage, and listen to their feedback, you can apply this learning to the ongoing development and increase quality as you go along.
Disadvantages of Agile
Now that we have examined some of the advantages of Agile development, let's take a look at some disadvantages.
Difficult to assess the effort required at the beginning of the software development life cycle
One complaint I have often heard from business leaders and project managers alike, is that compared to Waterfall, it’s hard to quantify the total effort and cost to deliver a project. On one hand, I can see why they would think this, especially when they come from a regimented Waterfall process world. Indeed, it is harder to fully quantify how long the total project will take, but the mitigation for this is that a product will be delivered incrementally by giving the users the most valuable requirements first, meaning you can plan for the coming sprint (and maybe a few sprints ahead) to deliver a specified amount of functionality.
It can be very demanding on a user’s time
Active user participation and collaboration with the users of your system are required throughout the development cycle with Agile. This can be very rewarding, and ensures you deliver the right product to your users. It's a key principle with Agile to ensure that a user’s expectations are well-managed, and the definition of failure is not meeting your user’s expectations. However, this level of participation can be very demanding on the user, and requires a big commitment for the duration of the project. I have been in this situation many times where the business users love the idea of what Agile can bring to them, but they don't like the extra amount of time they have to spend on the project in addition to their current workloads.
Costs can increase as testers are required throughout a project instead of at the end of a project
Testing is a key part of an Agile project during sprints or iterations. This helps to ensure quality throughout the project without the need for a lengthy and unpredictable test phase at the end. However, this does mean that testers are needed throughout the entire product development life cycle, and this can dramatically increases the cost. This extra upfront cost does save you money in the long run though, as you are continually having people test your code. Having a combination of manual testing and automation testing is the best way to drive up the quality of your product. The cost of a long and unpredictable test stage at the end of a Waterfall project can, in my experience, cause huge, unexpected costs when a project overruns—and they frequently do overrun.
Agile Vs Waterfall - Pros and Cons of Waterfall Model
Pros and Cons of Waterfall Model
In a minute, we'll take a look at a number of pros and cons of the Waterfall model. But before we do, I first want to cover some of the main high-level advantages and disadvantages to this development process.
The first advantage is that by splitting your project deliveries into different stages, it is easier to maintain control over the development process. This makes it much easier for schedules to be planned out in advance, making the project manager's life much easier. It’s for this reason I've found that experienced project managers tend to favor the Waterfall process. By splitting a project down into the various phases of the Waterfall process, you can easily departmentalize the delivery of your project, meaning that you can assign different roles to different departments and give them a clear list of deliverables and time scales. If any of these departments can't deliver on time for various reasons, it’s easier for a project manager to adjust the overall plan.
Unfortunately, in reality I've seen a plan adjusted where the implementation phase gets squeezed more and more, which means the development team has less time to deliver a working solution. Shortcuts tend to be taken, and the quality can suffer as a result. It's normally code-base unit integration testing that gets affected first. The testing teams in the test phase get a solution that contains more problems, which makes their lives very hard. So while departmentalization is seen as an advantage, it can easily become a disadvantage if another team is late delivering their part of the project.
Now, let's take a look at some of the high-level disadvantages. The Waterfall model doesn't allow any time for reflection or revision to a design. Once the requirements are signed off on, they're not supposed to change. This should mean that the development team has a fixed design that they're going to work towards. In reality, this does not happen, and changes in requirements can often result in chaos as the design documents need updating and re-signing off on by stakeholders.
By the time the development team starts its work, team members are pretty much expected to get it right the first time, and they're not allowed much time to pause for flaws and reflection on the code that they have implemented. By the time you get to the point where you think a change of technical direction is required, it’s normally too late to do anything about it unless you want to affect the delivery dates. This can be quite de-motivating for a development team, as they have to proceed with technical implementations that are full of compromises and technical debts. Once a product has entered the testing stage, change is virtually impossible—whether to the overall design or the actual implementation.
Now we've seen some of the high-level advantages and disadvantages. Let's take a deeper look at more of the benefits of the Waterfall model. Waterfall is a simple process to understand, and on paper it looks like a good idea for running a project. Waterfall is also easier to manage for a project manager, as everything is delivered in stages that can be scheduled and planned in advance. Phases are completed one at a time, where the output from one phase is fed into the input of the next phase. Waterfall generally works well for smaller projects where the risk of changing requirements and scope is lower. Each stage in Waterfall is very clearly defined. This makes it easier to assign clear roles to teams and departments who have to feed into the project. Because each stage is clearly defined, it makes a milestone set up by the project manager easier to understand. If you're working on a stage like Requirements Analysis, you should clearly understand what you need to deliver to the next phase, and by when.
Under Waterfall, the process and results of each stage are well documented. Each stage has clear deliverables that are documented and approved by key project stakeholders. And finally, tasks in a Waterfall project are easy to arrange and plan for a project manager. The Waterfall model fits very neatly into a Gantt chart, so a project manager is generally happiest when they can plan everything out and view a project timeline in an application like Microsoft Project.
The biggest disadvantage of the Waterfall model is you don't get any working software until late in the process. This means that your end users don't get to see their vision come to life until it’s too late to change anything. It can be very hard for non-technical people to be really clear about how they want an application to operate, and it isn't normally until they can visualize an application that they can really give good feedback. You can mitigate this a bit by doing some prototyping in the system design phase to help users visualize their system, but there is nothing like giving them actual working code to try out.
The Waterfall model can introduce a high level of risk and uncertainty for anything but a small project. Just because a set of requirements and a design has been approved does not mean that the requirements won't change. Waterfall is all about getting the requirements, design, and implementation right the first time. This is a grand idea, but in the real world it is very rarely the case, and this is a big risk to a project. We have talked about how Waterfall is better for small projects, but it is possible to have a small, but very complex project. The more complexity that is involved, the more likely it is that change will be needed further down the line. Complexity in the system is also very hard to implement and test, and can often cause delays in the later stages of the Waterfall software development life-cycle.
If you're working on a project where change is expected, then Waterfall is not the right model for you. I've worked on projects for a financial services company where changes in the law were causing compliance regulations to change. Unfortunately, these rules are very open to interpretation, which meant the legal team was involved at a very early stage. This meant that the interpretation changed a few times during the course of the project. If this had been a Waterfall project, we would have been in big trouble, as projects normally come with very hard and fixed set of deadlines.
This project was a perfect fit for an Agile project. If you are working on a large project and the scope changes, the impact can be so expensive and costly that the original business benefit for the project can evaporate, and then the project is cancelled. I've seen this happen a couple of times, and it's a real shame, as projects that show promise are stopped due to restrictions in the process.
Finally, the integration and delivery of a project is done as a "big bang" on a Waterfall project. This means you're introducing huge amounts of change all at once. This can very easily overwhelm testing teams and your operational teams.
In a minute, we'll take a look at a number of pros and cons of the Waterfall model. But before we do, I first want to cover some of the main high-level advantages and disadvantages to this development process.
The first advantage is that by splitting your project deliveries into different stages, it is easier to maintain control over the development process. This makes it much easier for schedules to be planned out in advance, making the project manager's life much easier. It’s for this reason I've found that experienced project managers tend to favor the Waterfall process. By splitting a project down into the various phases of the Waterfall process, you can easily departmentalize the delivery of your project, meaning that you can assign different roles to different departments and give them a clear list of deliverables and time scales. If any of these departments can't deliver on time for various reasons, it’s easier for a project manager to adjust the overall plan.
Unfortunately, in reality I've seen a plan adjusted where the implementation phase gets squeezed more and more, which means the development team has less time to deliver a working solution. Shortcuts tend to be taken, and the quality can suffer as a result. It's normally code-base unit integration testing that gets affected first. The testing teams in the test phase get a solution that contains more problems, which makes their lives very hard. So while departmentalization is seen as an advantage, it can easily become a disadvantage if another team is late delivering their part of the project.
Now, let's take a look at some of the high-level disadvantages. The Waterfall model doesn't allow any time for reflection or revision to a design. Once the requirements are signed off on, they're not supposed to change. This should mean that the development team has a fixed design that they're going to work towards. In reality, this does not happen, and changes in requirements can often result in chaos as the design documents need updating and re-signing off on by stakeholders.
By the time the development team starts its work, team members are pretty much expected to get it right the first time, and they're not allowed much time to pause for flaws and reflection on the code that they have implemented. By the time you get to the point where you think a change of technical direction is required, it’s normally too late to do anything about it unless you want to affect the delivery dates. This can be quite de-motivating for a development team, as they have to proceed with technical implementations that are full of compromises and technical debts. Once a product has entered the testing stage, change is virtually impossible—whether to the overall design or the actual implementation.
Now we've seen some of the high-level advantages and disadvantages. Let's take a deeper look at more of the benefits of the Waterfall model. Waterfall is a simple process to understand, and on paper it looks like a good idea for running a project. Waterfall is also easier to manage for a project manager, as everything is delivered in stages that can be scheduled and planned in advance. Phases are completed one at a time, where the output from one phase is fed into the input of the next phase. Waterfall generally works well for smaller projects where the risk of changing requirements and scope is lower. Each stage in Waterfall is very clearly defined. This makes it easier to assign clear roles to teams and departments who have to feed into the project. Because each stage is clearly defined, it makes a milestone set up by the project manager easier to understand. If you're working on a stage like Requirements Analysis, you should clearly understand what you need to deliver to the next phase, and by when.
Under Waterfall, the process and results of each stage are well documented. Each stage has clear deliverables that are documented and approved by key project stakeholders. And finally, tasks in a Waterfall project are easy to arrange and plan for a project manager. The Waterfall model fits very neatly into a Gantt chart, so a project manager is generally happiest when they can plan everything out and view a project timeline in an application like Microsoft Project.
The biggest disadvantage of the Waterfall model is you don't get any working software until late in the process. This means that your end users don't get to see their vision come to life until it’s too late to change anything. It can be very hard for non-technical people to be really clear about how they want an application to operate, and it isn't normally until they can visualize an application that they can really give good feedback. You can mitigate this a bit by doing some prototyping in the system design phase to help users visualize their system, but there is nothing like giving them actual working code to try out.
The Waterfall model can introduce a high level of risk and uncertainty for anything but a small project. Just because a set of requirements and a design has been approved does not mean that the requirements won't change. Waterfall is all about getting the requirements, design, and implementation right the first time. This is a grand idea, but in the real world it is very rarely the case, and this is a big risk to a project. We have talked about how Waterfall is better for small projects, but it is possible to have a small, but very complex project. The more complexity that is involved, the more likely it is that change will be needed further down the line. Complexity in the system is also very hard to implement and test, and can often cause delays in the later stages of the Waterfall software development life-cycle.
If you're working on a project where change is expected, then Waterfall is not the right model for you. I've worked on projects for a financial services company where changes in the law were causing compliance regulations to change. Unfortunately, these rules are very open to interpretation, which meant the legal team was involved at a very early stage. This meant that the interpretation changed a few times during the course of the project. If this had been a Waterfall project, we would have been in big trouble, as projects normally come with very hard and fixed set of deadlines.
This project was a perfect fit for an Agile project. If you are working on a large project and the scope changes, the impact can be so expensive and costly that the original business benefit for the project can evaporate, and then the project is cancelled. I've seen this happen a couple of times, and it's a real shame, as projects that show promise are stopped due to restrictions in the process.
Finally, the integration and delivery of a project is done as a "big bang" on a Waterfall project. This means you're introducing huge amounts of change all at once. This can very easily overwhelm testing teams and your operational teams.
Agile Vs Waterfall - When to use Agile and Waterfall?
When to use Waterfall Model?
Every software development project is different and requires a suitable software development life-cycle approach that is employed based on your team and organization's internal and external factors. There are some project situations where the Waterfall model is appropriate, but as we look at these, you may feel from experience that this doesn't always work out.
First, Waterfall is suitable if your requirements are well documented, clear, and fixed. How often is that the case though? From my own experience as a software developer, I can't remember any of the many projects I've delivered where the requirements have been clear from the start so that they can be captured in a document that doesn't change as the project rolls on.
Next, the product definition must be stable. Again, I can't think of a single project where this has been the case, as external factors like a change in the marketplace or a shift in business priorities mean that your product will change over time. I have worked on many projects where the final delivered product was quite different from what was initially specified. Under Waterfall this shouldn't happen, but in reality, what you are building can change.
There is nothing wrong with this, but it does fight against the software delivery process. Hold this thought in your mind, as this will form a big part of our core theme when we discuss Agile in detail later on.
Next, the technology should be well understood. This means that developers should understand the technologies that they're going to be using and how they work. Once you enter the implementation and construction phase of the project, developers normally have to work toward very rigid and set-time scales. In my experience, a lot of effort is expelled on the requirements and design phases, which normally eat into the time needed to actually develop the code.
Next, Waterfall works best on projects that are short, and by short I mean projects that take around two-to-four months in total. The longer a project runs, the more chance there is of the requirements and product definition becoming out-of-date.
Finally, Waterfall works best when all the members of your project team are available. It is quite normal for a development team to have a pool of resources that might be shared out between many different projects. If another project is overrun for any reason, you may not have all your people available at the time when they are required. This can greatly impact a project's time scale and put delivery dates at risk.
When to use Agile Model?
Agile Model limits the time needed to be spend in planning the project. It adopts the ever changing needs of end users through providing incremental releases and improve over the time. Whenever there is uncertainty in the requirement and need some degree of innovation to proceed agile model helps achieve success in any project.
Every software development project is different and requires a suitable software development life-cycle approach that is employed based on your team and organization's internal and external factors. There are some project situations where the Waterfall model is appropriate, but as we look at these, you may feel from experience that this doesn't always work out.
First, Waterfall is suitable if your requirements are well documented, clear, and fixed. How often is that the case though? From my own experience as a software developer, I can't remember any of the many projects I've delivered where the requirements have been clear from the start so that they can be captured in a document that doesn't change as the project rolls on.
Next, the product definition must be stable. Again, I can't think of a single project where this has been the case, as external factors like a change in the marketplace or a shift in business priorities mean that your product will change over time. I have worked on many projects where the final delivered product was quite different from what was initially specified. Under Waterfall this shouldn't happen, but in reality, what you are building can change.
There is nothing wrong with this, but it does fight against the software delivery process. Hold this thought in your mind, as this will form a big part of our core theme when we discuss Agile in detail later on.
Next, the technology should be well understood. This means that developers should understand the technologies that they're going to be using and how they work. Once you enter the implementation and construction phase of the project, developers normally have to work toward very rigid and set-time scales. In my experience, a lot of effort is expelled on the requirements and design phases, which normally eat into the time needed to actually develop the code.
Next, Waterfall works best on projects that are short, and by short I mean projects that take around two-to-four months in total. The longer a project runs, the more chance there is of the requirements and product definition becoming out-of-date.
Finally, Waterfall works best when all the members of your project team are available. It is quite normal for a development team to have a pool of resources that might be shared out between many different projects. If another project is overrun for any reason, you may not have all your people available at the time when they are required. This can greatly impact a project's time scale and put delivery dates at risk.
When to use Agile Model?
Agile Model limits the time needed to be spend in planning the project. It adopts the ever changing needs of end users through providing incremental releases and improve over the time. Whenever there is uncertainty in the requirement and need some degree of innovation to proceed agile model helps achieve success in any project.
Agile Vs Waterfall - What is Agile Methodology and Waterfall Methodology?
What is Agile Methodology?
Agile is a group of software development processes that promote evolutionary design with self-organizing teams. Agile development inspires adaptive planning, evolutionary development, and early delivery of value to your customers.
The word “agile” was first associated with software development back in 2001 when the Agile Manifesto was written by a group of visionary software developers and leaders. You choose to become a signatory on the Agile Manifesto website, which stamps your intention to follow the principles.
Unlike traditional development practices like Waterfall, Agile methodologies such as Scrum and Extreme Programming are focused around self-organizing, cross-discipline teams that practice continuous planning and implementation to deliver value to their customers.
The main goal of Agile development is to frequently deliver working software that gives value. Each of these methods emphasize ongoing alignment between technology and the business. Agile methodologies are considered lightweight in that they strive to impose a minimum process and overhead within the development lifecycle.
Agile methodologies are adaptive, which means they embrace and manage changes in requirements and business priorities throughout the entire development process. These changes in requirements are to be expected and welcomed. With any Agile development project, there is also a considerable emphasis on empowering teams with collaborative decision-making. In the previous chapter, I talked about how the Waterfall-based development process follows a set series of stages, which results in a "big bang" deployment of software at the end of the process.
One of the key ideas behind Agile is that instead of delivering a "big bang" at the end of the project, you deliver multiple releases of working code to your business stakeholders. This allows you to prioritize features that will deliver the most value to the business sooner, so that your organization can start to realize an early return on your investment. The number of deliveries depends on how long and complex a project is, but ideally you would deliver working software at the end of each sprint or iteration.
What is Waterfall Methodology?
The Waterfall process is split into separate stages, where the outcome of one stage is the input for the next stage. In the first stage, Requirements Specification, all possible requirements for the system to be developed are captured and documented in a requirement specification document. This document normally requires sign-off by key project and business stakeholders.
This part of the Waterfall model is typically organized by the business analysts, but depending on the size of your project, team, or organization, other members of your development team may be involved. This stage is about teasing out the requirements of the system from your stakeholders. This would include the required functionality, documentation of business rules and processes, and capturing any regulatory and compliance requirements that will affect the overall system.
The next stage is System Design. The requirement specifications from the first stage are inspected, and the system design is put together. This design helps in specifying the system design requirements, and also helps with designing the overall system’s architecture. It is this stage where architects, solution designers, and developers will work together to decide how the overall system will be constructed. This is from a code perspective, and also a technology choice and infrastructure perspective.
The next phase is Implementation. This is the phase where the developers take the design and start producing code to turn the design into a reality. The developers may also write automated unit and integration tests at this stage.
After the Implementation phase, we have the Integration and Testing phase. This is where all the deliverables from the implementation phase are brought together and tested as a whole. The testing team should be working to a defined test plan. Once the system has been tested and signed off by the test team, the next stage is deploying the solution to your end users. Your end users may be internal customers within your organization, or customers.
Once the solution has been deployed, it goes into the Maintenance phase, where any issues that are reported will need fixing and re-deploying. This would generally be in the form of release patch fixes to your system. You may also perform small enhancements to the system at this phase. If an enhancement is quite large in scope, then you might start the Waterfall process again and start capturing further requirements.
All of these phases are cascaded, where progress is seen as flowing steadily downwards like a waterfall. The next phase is started only after a pre-defined set of goals are achieved from the previous phase. In this model, the phases do not overlap.
Agile is a group of software development processes that promote evolutionary design with self-organizing teams. Agile development inspires adaptive planning, evolutionary development, and early delivery of value to your customers.
The word “agile” was first associated with software development back in 2001 when the Agile Manifesto was written by a group of visionary software developers and leaders. You choose to become a signatory on the Agile Manifesto website, which stamps your intention to follow the principles.
Unlike traditional development practices like Waterfall, Agile methodologies such as Scrum and Extreme Programming are focused around self-organizing, cross-discipline teams that practice continuous planning and implementation to deliver value to their customers.
The main goal of Agile development is to frequently deliver working software that gives value. Each of these methods emphasize ongoing alignment between technology and the business. Agile methodologies are considered lightweight in that they strive to impose a minimum process and overhead within the development lifecycle.
Agile methodologies are adaptive, which means they embrace and manage changes in requirements and business priorities throughout the entire development process. These changes in requirements are to be expected and welcomed. With any Agile development project, there is also a considerable emphasis on empowering teams with collaborative decision-making. In the previous chapter, I talked about how the Waterfall-based development process follows a set series of stages, which results in a "big bang" deployment of software at the end of the process.
One of the key ideas behind Agile is that instead of delivering a "big bang" at the end of the project, you deliver multiple releases of working code to your business stakeholders. This allows you to prioritize features that will deliver the most value to the business sooner, so that your organization can start to realize an early return on your investment. The number of deliveries depends on how long and complex a project is, but ideally you would deliver working software at the end of each sprint or iteration.
What is Waterfall Methodology?
The Waterfall process is split into separate stages, where the outcome of one stage is the input for the next stage. In the first stage, Requirements Specification, all possible requirements for the system to be developed are captured and documented in a requirement specification document. This document normally requires sign-off by key project and business stakeholders.
This part of the Waterfall model is typically organized by the business analysts, but depending on the size of your project, team, or organization, other members of your development team may be involved. This stage is about teasing out the requirements of the system from your stakeholders. This would include the required functionality, documentation of business rules and processes, and capturing any regulatory and compliance requirements that will affect the overall system.
The next stage is System Design. The requirement specifications from the first stage are inspected, and the system design is put together. This design helps in specifying the system design requirements, and also helps with designing the overall system’s architecture. It is this stage where architects, solution designers, and developers will work together to decide how the overall system will be constructed. This is from a code perspective, and also a technology choice and infrastructure perspective.
The next phase is Implementation. This is the phase where the developers take the design and start producing code to turn the design into a reality. The developers may also write automated unit and integration tests at this stage.
After the Implementation phase, we have the Integration and Testing phase. This is where all the deliverables from the implementation phase are brought together and tested as a whole. The testing team should be working to a defined test plan. Once the system has been tested and signed off by the test team, the next stage is deploying the solution to your end users. Your end users may be internal customers within your organization, or customers.
Once the solution has been deployed, it goes into the Maintenance phase, where any issues that are reported will need fixing and re-deploying. This would generally be in the form of release patch fixes to your system. You may also perform small enhancements to the system at this phase. If an enhancement is quite large in scope, then you might start the Waterfall process again and start capturing further requirements.
All of these phases are cascaded, where progress is seen as flowing steadily downwards like a waterfall. The next phase is started only after a pre-defined set of goals are achieved from the previous phase. In this model, the phases do not overlap.
Agile Vs Waterfall - History
Waterfall History
The Waterfall software development process was introduced computer scientist Winston Royce in 1970. Royce first wrote about Waterfall in an article called, Managing the Development of Large Software Systems. Although Royce didn't directly refer to his model as Waterfall, the article was actually about a process that was flawed for software development. Royce's model allowed for more repetition between stages of the model, which Waterfall doesn't allow you to do.
Royce's actual model was more iterative in how it worked and allowed more room to maneuver between stages. We will discuss a more iterative way of working when we discuss Agile later on in this book. Although Royce didn't refer to his model as the Waterfall model directly, he is credited with the first description of what we refer to as the Waterfall model.
Agile History
There have been many attempts to try and improve software development practices over the years, and many of these have looked at working in a more iterative way. These new practices didn't go far enough when trying to deal with changing requirements of customers.
In the 1990s, a group of industry software thought leaders met at a ski resort in Utah to try and define a better way of developing software. The term "Agile software development" emerged from this gathering. The term was first used in this manner and published in the now-famous Agile Manifesto. The Agile Manifesto was designed to promote the ideas of delivering regular business value to your customers through the work of a collaborative, cross-functional team.
The Waterfall software development process was introduced computer scientist Winston Royce in 1970. Royce first wrote about Waterfall in an article called, Managing the Development of Large Software Systems. Although Royce didn't directly refer to his model as Waterfall, the article was actually about a process that was flawed for software development. Royce's model allowed for more repetition between stages of the model, which Waterfall doesn't allow you to do.
Royce's actual model was more iterative in how it worked and allowed more room to maneuver between stages. We will discuss a more iterative way of working when we discuss Agile later on in this book. Although Royce didn't refer to his model as the Waterfall model directly, he is credited with the first description of what we refer to as the Waterfall model.
Agile History
There have been many attempts to try and improve software development practices over the years, and many of these have looked at working in a more iterative way. These new practices didn't go far enough when trying to deal with changing requirements of customers.
In the 1990s, a group of industry software thought leaders met at a ski resort in Utah to try and define a better way of developing software. The term "Agile software development" emerged from this gathering. The term was first used in this manner and published in the now-famous Agile Manifesto. The Agile Manifesto was designed to promote the ideas of delivering regular business value to your customers through the work of a collaborative, cross-functional team.
Subscribe to:
Posts (Atom)