Waterfall

Methodology
WHAT IS WATERFALL?
Waterfall methodology follows a sequential, linear process and is the most popular
version of the systems development life cycle (SDLC) for software engineering
and IT projects. It is sometimes planned using a Gantt chart, a type of bar chart
that shows the start and end dates for each task. Once one of the eight stages are
complete, the development team moves onto the next step. The team can’t go
back to a previous stage without starting the whole process from the beginning.
And, before the team can move to the next stage, requirements may need to be
reviewed and approved by the customer.

The Waterfall model originated in the manufacturing and construction industries,

both highly structured environment where changes can be too expensive or
sometimes impossible. The first formal description of Waterfall is attributed to
Winston W. Royce in a 1970 article where he described a flawed software model. 

ADVANTAGES OF WATERFALL
Waterfall is best used for simple, unchanging projects. Its linear, rigid nature
makes it easy to use and allows for in-depth documentation. 

The advantages of Waterfall include:

 Easy to use and manage: Because the Waterfall model follows the same
sequential pattern for each project, it is easy to use and understand. The team doesn’t
need any prior knowledge or training before working on a Waterfall project. Waterfall
is also a rigid model; each phase has specific deliverables and review, so it’s easy to
manage and control.
 
  Discipline is enforced: Every phase in Waterfall has a start and end point, and
it’s easy to share progress with stakeholders and customers. By focusing on
requirements and design before writing code, the team can reduce the risk of a missed
deadline.
 
 Requires a well documented approach: Waterfall requires documentation
for every phase, resulting in better understanding of the logic behind the code and
tests. It also leaves a paper trail for any future projects or if stakeholders need to see
more detail about a certain phase. 
DISADVANTAGES OF WATERFALL
The biggest drawback of Waterfall is how it handles change. Because Waterfall is
a linear, sequential model, you can’t bounce between phases, even if unexpected
changes occur. Once you’re done with a phase, that’s it. 

Here’s more information on the disadvantages of Waterfall:

 Changes can’t be easily accommodated: Once the team completes a phase,

they can’t go back. If they reach the testing phase and realize that a feature was
missing from the requirements phase, it is very difficult and expensive to go back and
fix it. 
 
 Software isn’t delivered until late: The project has to complete two to four
phases before the coding actually begins. As a result, stakeholders won’t see working
software until late in the life cycle.
 
 Gathering accurate requirements can be challenging: One of the first
phases in a Waterfall project is to talk to customers and stakeholders and identify their
requirements. However, it can be difficult to pinpoint exactly what they want this
early in the project. Often times, customers don’t know what they want early on and
instead, learn and identify requirements as the project progresses.
STAGES OF WATERFALL

There are eight stages in Waterfall and they must all happen in sequential order.
For example, the development team can’t go back to the analysis phase if they
are in the testing phase.

1. Conception: This phase starts with an idea. The concept phase involves a rough
assessment of the project, why it’s beneficial, and looks at any initial cost estimates. 
2. Initiation: Once the idea is formed, you need to hire the project team, and define
objectives, scope, purpose, and deliverables.
3. Requirement Gathering and Analysis: Requirements are gathered and
analyzed to see if the project is actually feasible. All this information is documented in
a requirement specification document. 
4. Design: The design specifications created in this phase are used in the coding
phase to actually write the code. The requirements are studied and evaluated, and the
design of the system is prepared. The team’s goal is to understand what actions need
to be taken and what they should look like.
5. Implementation/Coding: The actual coding of the software begins. Any
flowcharts or algorithms created in the design phase are translated into a programming
language.
 6. Testing: Once the code is complete, the software needs to be tested for any errors.
When the testing is finished, the software is delivered to the customer. Some teams
may choose to include user acceptance testing (UAT), where users test the software
before it is deployed to the general public.
7. Maintenance: Once customers have been using the software in the real world,
they may find additional problems. The development team will need to resolve,
change, or modify the software to continue to be effective.
ITERATIVE WATERFALL DEVELOPMENT
In the traditional Waterfall model, the team goes through each phase for the entire
project. For example, they do the analysis for the entire project, then they do the
design for the entire project, etc. 

In an iterative Waterfall model, there is still a lot of upfront planning required. Once
the plan is in place, the team follows the same pattern as traditional Waterfall but
does it for each story. They do the analysis for one story, then all the design for
one story, then all the coding and testing for one story. Then they repeat the
process for another story. The work is broken up into chunks that benefit the
development team. 

HOW WATERFALL DEALS WITH SOFTWARE REQUIREMENTS

Waterfall projects define all software requirements upfront. The project cannot
proceed unless these requirements have been identified and documented.

Some Waterfall projects may have a dedicated team to capture, collect, and
gather these requirements. They may use questionnaires, face-to-face or phone
interviews, white boards, and modeling tools to capture stakeholder and customer
requirements.

Once the initial requirements are defined, the team should produce a
requirements specification document (sometimes they may create more than
one). This document defines what needs to be delivered so everyone understands
the scope of the project. 
Agile
Methodology
WHAT IS AGILE?
Agile software development is based on an incremental, iterative approach.
Instead of in-depth planning at the beginning of the project, Agile methodologies
are open to changing requirements over time and encourages constant feedback
from the end users. Cross-functional teams work on iterations of a product over a
period of time, and this work is organized into a backlog that is prioritized based
on business or customer value. The goal of each iteration is to produce a working
product.

In Agile methodologies, leadership encourages teamwork, accountability, and

face-to-face communication. Business stakeholders and developers must work
together to align the product with customer needs and company goals. 

Agile refers to any process that aligns with the concepts of the Agile Manifesto. In
February 2001, 17 software developers met in Utah to discuss lightweight
development methods. They published the Manifesto for Agile Software
Development, which covered how they found “better ways of developing software
by doing it and helping others do it” and included four values and 12 principles.
The Agile Manifesto is a dramatic contrast to the traditional text A Guide to the
Project Management Body of Knowledge (PMBOK® Guide)and standards.
12 PRINCIPLES OF AGILE METHODOLOGY
The Agile Manifesto lists 12 principles to guide teams on how to execute with
agility. These are the principles:
1. Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
 2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months,

with preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and

users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity -- the art of maximizing the amount of work not done -- is essential.

11. The best architectures, requirements, and designs emerge from self-organizing
teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly. 

ADVANTAGES OF AGILE
Agile evolved from different lightweight software approaches in the 1990s and is a
response to some project managers’ dislike of the rigid, linear Waterfall
methodology. It focuses on flexibility, continuous improvement, and speed. 

Here are some of the top advantages of Agile:

 Change is embraced: With shorter planning cycles, it’s easy to accommodate

and accept changes at any time during the project. There is always an opportunity to
refine and reprioritize the backlog, letting teams introduce changes to the project in a
 matter of weeks.
 
 End-goal can be unknown: Agile is very beneficial for projects where the end-
goal is not clearly defined. As the project progresses, the goals will come to light and
development can easily adapt to these evolving requirements.
 
 Faster, high-quality delivery: Breaking down the project into iterations
(manageable units) allows the team to focus on high-quality development, testing, and
collaboration. Conducting testing during each iteration means that bugs get identified
and solved more quickly. And this high-quality software can be delivered faster with
consistent, successive iterations.
 
 Strong team interaction: Agile highlights the importance of frequent
communication and face-to-face interactions. Teams work together and people are
able to take responsibility and own parts of the projects.
 
 Customers are heard: Customers have many opportunities to see the work
being delivered, share their input, and have a real impact on the end product. They can
gain a sense of ownership by working so closely with the project team.
 
 Continuous improvement: Agile projects encourage feedback from users and
team members throughout the whole project, so lessons learned are used to improve
future iterations.
DISADVANTAGES OF AGILE
While the level of flexibility in Agile is usually a positive, it also comes with some
trade-offs. It can be hard to establish a solid delivery date, documentation can be
neglected, or the final product can be very different than originally intended. 

Here are some of the disadvantages of Agile:

 Planning can be less concrete: It can sometimes be hard to pin down a solid
delivery date. Because Agile is based on time-boxed delivery and project managers
are often reprioritizing tasks, it’s possible that some items originally scheduled for
delivery may not be complete in time. And, additional sprints may be added at any
 time in the project, adding to the overall timeline.
 
 Team must be knowledgeable: Agile teams are usually small, so team
members must be highly skilled in a variety of areas. They also must understand and
feel comfortable with the chosen Agile methodology. 
 
 Time commitment from developers: Agile is most successful when the
development team is completely dedicated to the project. Active involvement and
collaboration is required throughout the Agile process, which is more time consuming
than a traditional approach. It also means that the developers need to commit to the
entire duration of the project.
 
 Documentation can be neglected: The Agile Manifesto prefers working
software over comprehensive documentation, so some team members may feel like
it’s less important to focus on documentation. While comprehensive documentation
on its own does not lead to project success, Agile teams should find the right balance
between documentation and discussion.
 
 Final product can be very different: The initial Agile project might not have a
definitive plan, so the final product can look much different than what was initially
intended. Because Agile is so flexible, new iterations may be added based on evolving
customer feedback, which can lead to a very different final deliverable. 
THE AGILE DEVELOPMENT CYCLE
Here are the phases in the Agile development cycle. It’s important to note that
these phases shouldn’t happen in succession; they are flexible and always
evolving. Many of these phases happen in parallel.  

 Planning: Once an idea is deemed viable and feasible, the project team comes
together and works to identify features. The goal of this phase is to break down the
idea into smaller pieces of work (the features) then to prioritize each feature and
assign it to an iteration. 
 
 Requirements analysis: This phase involves many meetings with managers,
stakeholders, and users to identify business requirements. The team needs to gather
information like who will use the product and how they will use it. These
requirements must be quantifiable, relevant, and detailed.
 
 Design: The system and software design is prepared from the requirements
identified in the previous phase. The team needs to think about what the product or
 solution will look like. The test team also comes up with a test strategy or plan to
proceed.
 
 Implementation, coding or development: This phase is all about creating
and testing features, and scheduling iterations for deployment (following the iterative
and incremental development approach [IID]). The development phase starts with
iteration 0, because there are no features being delivered. This iteration lays down the
foundation for development, with tasks like finalizing contracts, preparing the
environments, and funding.
 
 Testing: Once the code has been developed, it is tested against the requirements to
make sure the product is actually solving customer needs and matching user stories.
During this phase, unit testing, integration testing, system testing, and acceptance
testing are done.
 
 Deployment: After testing, the product is delivered to customers for them to use.
However, deployment isn’t the end of the project. Once customers start using the
product, they may run into new problems that the project team will need to address.
METHODOLOGIES THAT ARE USED TO IMPLEMENT AGILE
Agile is a framework and there are a number of specific methods within the Agile
movement. You can think of these as different flavors of Agile: 

 Extreme Programming (XP): Also known as XP, Extreme Programming is a

type of software development intended to improve quality and responsiveness to
evolving customer requirements. The principles of XP include feedback, assuming
simplicity, and embracing change.
 
 Feature-driven development (FDD): This iterative and incremental software
development process blends industry best practices into one approach. There are five
basic activities in FDD: develop overall model, build feature list, plan by feature,
design by feature, and build by feature.
 
 Adaptive system development (ASD): Adaptive system development
represents the idea that projects should always be in a state of continuous adaptation.
 ASD has a cycle of three repeating series: speculate, collaborate, and learn.
 
 Dynamic Systems Development Method (DSDM): This Agile project
delivery framework is used for developing software and non-IT solutions. It addresses
the common failures of IT projects, like going over budget, missing deadlines, and
lack of user involvement. The eight principles of DSDM are: focus on the business
need, deliver on time, collaborate, never compromise quality, build incrementally
from firm foundations, develop iteratively, communicate continuously and clearly,
and demonstrate control. 
 
 Lean Software Development (LSD): Lean Software Development takes Lean
manufacturing and Lean IT principles and applies them to software development. It
can be characterized by seven principles: eliminate waste, amplify learning, decide as
late as possible, deliver as fast as possible, empower the team, build integrity in, and
see the whole.
 
 Kanban: Kanban, meaning “visual sign” or “card” in Japanese, is a visual
framework to implement Agile. It promotes small, continuous changes to your current
system. Its principles include: visualize the workflow, limit work in progress, manage
and enhance the flow, make policies explicit, and continuously improve.
 
 Crystal Clear: Crystal Clear is part of the Crystal family of methodologies. It can
be used with teams of six to eight developers and it focuses on the people, not
processes or artifacts. Crystal Clear requires the following: frequent delivery of usable
code to users, reflective improvement, and osmotic communication preferably by
being co-located.
 
 Scrum: Scrum is one of the most popular ways to implement Agile. It is an
iterative software model that follows a set of roles, responsibilities, and meetings that
never change. Sprints, usually lasting one to two weeks, allow the team to deliver
software on a regular basis.
OTHER PRACTICES IN AGILE
There are many other practices and frameworks that are related to Agile. They
include:
 Agile Modeling (AM): Agile modeling is used to model and document software
systems and is a supplement to other Agile methodologies like Scrum, Extreme
Programming (XP), and Rational Unified Process (RUP). AM is not a complete
software process on its own. It can help improve models with code, but it doesn’t
include programming activities. 
 
 Rational Unified Process (RUP): Created by the Rational Software
Corporation, a division of IBM, RUP is an iterative, adaptive framework for software
development. According to Rational, RUP is like an online mentor that provides
guidelines, templates, and examples for program development. The key aspects of
RUP include a risk-driven process, use case focused development, and architecture-
centric design.
 
 Lean vs Agile: Lean development focuses on eliminating and reducing waste
(activities that don’t add any value). Lean development takes the principles from Lean
manufacturing and applies them to software development. These principles are very
similar to Agile, however Lean takes it one step further. In the development phase,
you select, plan, develop, test, and deploy only one feature before you repeat the
process for the next feature.
 
 Test-Driven Development (TDD): Test-driven development relies on repetitive,
short development cycles. First, a developer writes an (initially failing) automated test
case for a new feature and quickly adds a test with the minimum amount of code to
pass that test. Then, he refactors the new code to acceptable standards. 
 
 Scaled Agile Framework (SAFe trademark logo): The Scaled Agile
Framework is a very structured method to help large businesses get started with
adopting Agile. SAFe is based on Lean and Agile principles and tackles tough issues
in big organizations, like architecture, integration, funding, and roles at scale. SAFe
has three levels: team, program, and portfolio. 
 
 Rapid Application Development (RAD): RAD’s approach to software
development puts more emphasis on development than planning tasks. It follows an
incremental model, where each component is developed in parallel. The phases in
RAD are: business modeling, data modeling, process modeling, application
 generation, and testing and turnover.
 
 Empirical Control Method: With Agile software development, you can use an
Empirical Control Method, which means that you make decisions based on the
realities you observe in the actual project. The empirical model of process control has
three parts: visibility, inspection, and adaption. 
HOW TO ESTIMATE BUDGETS IN AGILE
Without in-depth, upfront planning, many project managers are unsure of how to
calculate the cost and budget of an Agile project. 

Estimating the cost before the project even starts can always be challenging,
regardless of which project methodology you use. However, in an Agile project,
you can tie the amount of time the project will take with its total cost. 

First, create a burndown chart and use the burndown rate to estimate how many
sprints will be in your project and when the project will end. Then, calculate how
much the team will cost based on their hourly rates. Multiply each person’s rate by
the number of working hours per week, then multiply that by the number of weeks
in a sprint. Once you estimate the initial budget for your team, you can add any
other costs, like technology, travel, or equipment. 

You could also break down each user story into tasks. Once you have an idea of
how many hours it will take to complete each task, you can estimate the project
budget. 

And lastly, you could use planning poker to estimate the effort required for
development goals. Planning poker is a consensus-based, gamified technique for
estimating the effort of development goals. Each team member makes estimates
by playing numbered cards face-down on the table, instead of saying it out loud.
The cards are then revealed and the estimates discussed with the whole team.

AGILE AND PAIR PROGRAMMING

Pair programming (also known as “pairing”) is part of the Extreme Programming
(XP) practices. It is when two programmers share a single workstation, which
includes sharing one screen, keyboard, and mouse. The purpose of this technique
is to encourage better communication, clarification of the problem, and
understanding of the solution. Pairing is often used in Agile projects to quickly
deliver high-quality products, but is it always required? 

The answer depends on your programmers, company, and goals. For some
projects and programmers, pairing might improve productivity. However, it may
not always be appropriate for every project. The best thing to do is experiment and
see if it works for you.

HOW AGILE ADDRESSES SOFTWARE REQUIREMENTS

Agile helps development teams focus on customers’ most important requirements
as quickly as possible. With continuous feedback and frequent face-to-face
interactions, the project team and stakeholders understand and prioritize the right
requirements.

Agile teams use backlogs with user stories to manage requirements. Before an
iteration begins, the team agrees on which requirements they should meet with
the next delivery. This collaborative approach ensures that the most important
features get prioritized. And, requirements are continuously updated throughout
the project as new information is surfaced.

CAN YOU USE AGILE FOR PROJECTS OUTSIDE OF SOFTWARE?

While Agile was traditionally created for software development, it can also be used
in many other projects and industries. 

It’s important to remember that Agile software development was born from the
principles of Lean manufacturing and organizational learning. These ideas weren’t
based on software to begin with. And, many practices in Agile, like stand-up
meetings and visual management, are so common and can apply to any industry. 

There are not many case studies of teams using Agile for things outside of
software, but there are a couple. For example, Kate Sullivan, a corporate lawyer
on The Lonely Planet legal team, has transformed the legal affairs service delivery
with Agile. The team uses whiteboards and cards, morning stand-up meetings,
prioritization, weekly iterations, and regular retrospectives. 

Agile can definitely be applied to projects outside of software development, you

just have to find the right method and approach for your needs. You can start with
boards and cards, a work backlog, stand-up meetings, or iterations (weekly
planning meetings) to see how your team responds. 

HOW TO GET STARTED WITH AGILE

A simple way to get started with Agile is to incorporate daily stand-up meetings
into your project. Daily stand-up meetings are easy to incorporate into any other
project methodology you may already be using (even Waterfall) and don’t require
any training or knowledge transfer. Meet at the same spot every day for about ten
minutes and have everyone talk about what they worked on the day before, what
they’ll work on today, and any roadblocks.

If you want to make the complete switch to Agile all at once, you may want to start
with understanding why the team and organization want to make this change.
What is and isn’t working? What are they looking to improve? Then, you could
conduct an Agile assessment, getting a complete view of the people, skills, and
technologies used. 

Whichever route you choose, remember that Agile is flexible in its very nature.
There is no wrong or right way to get started with Agile. Do what works for you
and your team.

Smartsheet's newest view, Card View, gives Agile teams a more highly-visual way
to work, communicate, and collaborate in Smartsheet. Card View enables you to
focus attention with rich cards, give perspective with flexible views, and prioritize
and adjust work more visually. Display information on cards including custom
fields, images, and color coding to better focus your team’s attention. Categorize
cards into lanes to organize your work more visually.