A Guide to the Agile Software

Development Life Cycle (SDLC)

Brocoders · Follow
Published in Brocoders Team · 12 min read · Nov 9, 2021

Learn about what happens at each stage of the software development

lifecycle, who is involved and what clients should expect from software
development team.
What Is an SDLC?
A software development life cycle (SDLC) is a methodology followed to
create high-quality software. By adhering to a standard set of tools,
processes, and duties, a software development team can build, design,
and develop products that meet or exceed their clients’ expectations.
The main SDLC models include:

Waterfall: Follows a sequential model of phases, each of which has

its own tasks and objectives

Cleanroom: A process model that removes defects before they

cause serious issues

Incremental: Requirements are divided into multiple standalone

modules

V-Model: Processes are executed sequentially in a V-shape (each

step comes with its own testing phase)

Prototyping: A working replication of the product is used to

evaluate developer proposals

Big Bang: Requires very little planning and has no formal

procedures; however, it’s a high-risk model
 Agile: Uses cyclical, iterative progression to produce working
software

The last one on the list, Agile, is what we’re focusing on today. You see, a
traditional SDLC (like Waterfall) front-loads the work — so if you require
a large product, it can take a long time before the team even builds a
working prototype. Most software development startups don’t have the
financial means to wait that long. Well-funded competitors could beat
them to the market; so, to make processes more rapid without
compromising on quality, many development companies are embracing
the Agile software development lifecycle.

The 12 Key Principles of Agile Methodology

The software development life cycle (Agile model) or Agile SDLC uses
incremental processes and iterations to rapidly deliver software products
and improve customer satisfaction. At its core, Agile is focused on
breaking a product down into smaller, incremental builds, as well as
placing priority on working software rather than on documentation and
planning. As outlined in the Agile Manifesto, there are several key
principles, including:

1. Satisfy the client via early, continuous delivery of valuable

software.

2. Adapt to changing requirements, even late in development.

3. Use a shorter timescale (between a couple of weeks to a couple of

months) for delivering working software.

4. Developers and business people should work together on a daily

basis.
 5. Motivate individuals by giving them an ideal environment,
support, and trust.

6. Convey information via face-to-face communication.

7. Use working software as the main measurement of progress.

8. Maintain a constant pace and promote sustainable development.

9. Pay continuous attention to good design and technical excellence.

10. Keep things as simple as possible.

11. Allow the teams to self-organize.

12. Regularly reflect on how your team can be more effective and
adjust accordingly.

Strengths and Weaknesses of Agile

The Agile methodology is well-suited for small and medium-sized
organizations — after all, the fewer people there are on the team, the
easier it is to collaborate and make decisions. When you hire a software
development company that follows Agile principles, you will benefit
from these strengths:

Faster deployment of software, so you get value sooner

Because your hired development team is working on up-to-date

tasks, they waste fewer resources

It’s easier for the team to adapt to your requested changes

Developers quickly detect and fix issues

Less time is spent on busywork and bureaucracy

However, Agile also has its downsides, namely:

Because you must constantly interact with the developers, it

demands more energy and time

The scope could creep up over time

When to Choose Agile

Agile and Waterfall are two of the most commonly used SDLC — but how
do you know which one is right for your project? Waterfall works best for
projects that have well-defined deliverables and concrete timelines. So, if
you can provide the software developers with clear requirements,
Waterfall is a good choice. On the other hand, if your project’s constraints
are unclear, Agile is the better SDLC, as it enables the developers to be
more flexible; they can evolve the project’s planning as the work
progresses.

Your software development team will likely follow Agile principles if:

You don’t have a concrete timeline or fixed budget

They don’t know all of the requirements

You don’t have a complex bureaucracy that would delay decision-

making

You need to capture the market quickly

 Agile and Waterfall

Agile Methodologies
Not every organization implements Agile SDLC in the same way; there
are several possible frameworks — Kanban, Scrum, Extreme
Programming, Feature-Driven Development, Crystal, Lean, and Dynamic
Systems Development Method. And, to make things more convoluted,
there can be hybrids. For instance, Scrum + Kanban = Scrumban.

Today, though, we’re just going to look at Scrum and Kanban, which are
the most popular non-hybrid Agile methodologies.

Scrum vs. Kanban

Scrum divides a project into short iterations, usually between 1–4 weeks
in length. Each iteration is called a “sprint”. The Scrum Master leads the
team, and they work together to deliver an iteration at the end of each
Sprint. A Scrum team boosts collaboration and discusses progress during
daily standup meetings, and they use a Scrum Board to manage and
monitor their project.

Kanban focuses on visualizing work, limiting the amount of work in

progress, and maximizing flow. The team uses a Kanban board, which is
broken down into visual signals (sticky notes, tickets), workflow columns
(to-do, progress, complete), work-in-progress limits, a backlog section,
and a delivery point.

Scrum vs Kanban

Steps of a Scrum Workflow

 Scrum Workflow

There are 5 phases within Scrum: product backlog creation, sprint

planning, working on the Sprint, testing/demonstrating, and
retrospective. First, in product backlog creation, the Product Owner
works with the Scrum team to prioritize items based on:

Custom priority

Feedback urgency

Difficulty of implementation

Relationships between items

Various items are included in the backlog, like features, bugs and defects,
information attainment, and technical work. Large items are
transformed into “user stories” and “epics”.
Epics — Large chunks of work that can be divided into stories

User Stories — Short requirements written from an end user’s

perspective

Epics and user stories can both be put into the product backlog, but only
user stories are included in the sprint backlog.

Next comes sprint planning and creating the sprint backlog. The Scrum
team selects the most important user stories and breaks them up into
smaller tasks. User stories need to be made as small as possible, as the
average Sprint only lasts 2 weeks.

After the Sprint is planned, it’s time to get to work. Throughout the
Sprint, daily Scrum meetings are held. These last for about 15 minutes
and aim to gather the status of each team member.

Full life cycle testing is carried out, as each task is a working product.
After testing, each Sprint is demonstrated to the customer.

Retrospective is next, in which the team discusses what went well, what
can be improved, and the lessons learned during the Sprint. After that,
the next Sprint is planned, and the cycle begins again.

Phases of Agile SDLC: The Brocoders Approach

Discovery Phase

Description
Discovery is the first phase within service design and delivery. By
conducting user research, our team will understand what problems the
solution needs to solve for its users. By identifying users’ needs, wants,
and challenges, we’ll get insight into which problems need to be
prioritized. Discovery usually takes 4–8 weeks and is further divided into
2 stages: requirements elicitation and requirement specification.

Requirement elicitation: Researching and discovering the

requirements that customers, users, and other stakeholders have.

Requirement specification: Establishing an agreement between the

team and the customer on how the software should function.

Specification includes following techniques:

 Questionnaires

Interviews

Brainstorming

Change of perspective

Analogy technique

Document-centric techniques

Mind mapping

Workshops

User stories and use case modeling

Prototypes

The same roles are involved with requirement specifications. This SDLC
phase is the most important and obvious involvement for stakeholders, as
they have the most knowledge of the processes involved, and their input
is imperative to the project’s success. Using the requirements, the
stakeholders can stay involved during the rest of the project.

Techniques involved in requirements specification include:

Prototyping

Decomposing user stories into use cases and tasks

Participants

Stakeholders

Business Analysts
 Project Manager

Brocoder’s Discovery Responsibilities

During discovery, the team is responsible for:

Establishing success metrics

Developing user personas

Creating a prioritized list of user stories

Conducting market research and competitor analysis

Assembling a development team lineup

Specifying system requirements

As a result of the discovery phase, the client receives documents

containing:

Work Breakdown Structure

AUCTIONPROJECTSAMPLE

SELLERPROFILE AUCTION

Registration AuctionDraft Search

SignIn AuctionScheduled Search
Pacewordreset AuctionStart Search
Auctioncancel

GeneralProfilefields AuctionBiddingalgorythm Search

ProfilePictureUpload AuctionWinning Full
ProfilePictureCrop Search
Search

Feature decomposition
SellerDashboard Auctionbidding Auctions
SellerAuctionslist
 SellerAuctionslist Buynowfeature Auction
SellerPurchaseslist AlertsandNotifications Add
Cellernavments

AuctionChat
AuctionReview
AuctionFeedback

Feature Decomposition Example

Low fidelity prototype

Low fidelity prototype example

View Figma — BROtotype Web App UI Kit 1

View Figma — BROtotype Web App UI Kit 1

Project timeline

Project cost

Stakeholder’s Discovery Responsibilities

The stakeholder is responsible for:

Providing input and insight on requirements

Helping to determine priorities

Design
Description

During this stage, the designer, product manager, business analyst, and
stakeholders decide what the product will look like from both sides:
architecture and UX/UI. During design, the stakeholders need to be
involved in verifying that their requirements are correctly interpreted.
They often need to clarify requirements in both the design and
development activities. The stakeholders can use the requirements and
design documents to plan for necessary changes to the business
processes and business rules while the developers are working on the
program code.

Participants

Designer

Product Manager
 Business Analyst

Stakeholders

Brocoder’s Design Responsibilities

During design, the team is responsible for:

Architecture envisioning

Iteration modeling

Model storming

Preparing UX/UI screens

Update requirements

Stakeholder’s Design Responsibilities

The stakeholder is responsible for:

Attending weekly meetings with the designer

Providing feedback

Gathering feedback after user testing

Development and Coding
Description

At Brocoders, we follow the Agile principle, “Continuous Everything”. Via

continuous integration and delivery, we can shorten our release cycles
and average time to repair. It also ensures smooth integration of changes
to product code within the main repository. Our DevOps continuously
run automated tests in order to maintain strict control throughout the
SDLC.

The main stages of “Continuous Everything” include:

Continuous planning

Continuous development

Continuous integration
 Continuous testing

Continuous delivery

Continuous feedback

Participants

Project Manager

Product Owner

Development Team

Continuous Project Planning

Project planning is the key to successful product delivery within the

agreed timeline and budget. Because Brocoders uses proper project
planning, our team experiences better risk management, improved
motivation, and boosted coordination.

Jira setting up

The Project Manager “owns” project planning; they are responsible for
setting up and improving the development and delivery process, as well
as making sure the team is adhering to it.

Brocoder’s Continuous Project Planning Responsibilities

The project manager’s responsibilities include:

Creating a development communication plan and meeting notes

Introducing the team and leading project onboarding

Creating a RACI matrix for development team responsibilities

Setting up a task manager, such as the next-gen Atlassian Jira

Defining a project roadmap and milestones

Creating and prioritizing the backlog

Sprint planning: defining sprint goals and priorities, feature

requirements, issues breakdown, issues re-estimates, and risk
analysis

Sprint demos and collecting feedback

Providing team leadership and motivation: team standup

meetings, face-to-face meetings, team building activities,
problem-solving

Driving process improvements and introducing new, relevant tools

and approaches

Stakeholder’s Continuous Project Planning Responsibilities

The stakeholder is responsible for:

Meeting team members

 Participating in sprint planning meetings

Following project progress (we add them to our Jira board)

Reviewing the project roadmap and timeline

Continuous Coding & Development

Project development represents coding and task execution following
established best practices — in this case, using Agile. With Agile,
proactivity and communication are the keys to successful development.
At Brocoders, developers work within the same office space, so they can
quickly and effectively share ideas, problems, and solutions.

Brocoder’s Continuous Coding & Development Responsibilities

Our development team is responsible for:

Using modern web and mobile development frameworks: React.js,

React Native, Node.js

Front-end/back-end developers specialization: deep knowledge for

specific problems

Using open-source libraries (GNU GPL, MIT licensing)

Working with AWS infrastructure and Gitflow

Adhering to test-driven development principles

Reviewing each other’s code: the team lead reviews all code
pushed

Following security best practices, including token-based

authentication and user data encryption

Documenting development
Stakeholder’s Continuous Coding & Development Responsibilities
The stakeholder is responsible for:

Participating in weekly meetings and daily standups

Prioritizing tasks with the project manager and setting up sprint

goals

Participating in sprint demos/release demos

Providing the team with feedback and change requests

Reviewing reports

Testing
Description

The Project Manager and QA team work together to ensure bugless,

smooth, and seamless market releases. With Agile, testing begins at the
start of each project, even prior to development. It’s a continuous
process, thus delivering an ongoing feedback loop. Bug tracking services
and heath-check services: sentry.io, NewRelic, logz.io allow us to catch
the bugs before they are reported by users.
Let’s take a closer look at continuous testing.

Participants

Project Manager

QA Team

Brocoder’s Testing Responsibilities

This can vary between teams, but at Brocoders, we follow best QA

practices:

Conducting a product analysis and forming a test plan

Conducting unit tests, ensuring each software component is safe

Search Medium
to modify Write

Performing end-to-end automated tests, thus protecting releases

from possible regressions

Functional testing

Getting early feedback via user approval testing

Using regression testing cycles — each new release needs to be

better than the last one

Using a test management system (at Brocoders, we use Jira for test
cases, test planning, and tracking test cycle executions)

Tracking bugs

Stakeholder’s Testing Responsibilities

The stakeholder is responsible for:

Expressing expectations for test results

Validating test environment changes from the POV of an end-user

Making user group aware of process modifications resulting from

software improvements

Deployment
Description

The deployment phase is a milestone within the DevOps pipeline; it’s

when we determine that the build is ready to be deployed into the
production environment. At this point, each change in code has gone
through a series of manual and automated tests — therefore, the
operations team is confident that breaking issues and regressions are
unlikely.

Once a project is finished, it needs to be transferred to the production

environment, and all production servers need to be hosted on the client’s
accounts. We work with the 3 most popular cloud service platforms: AWS,
Digital Ocean, and Azure. The platform you choose depends on your
client’s requirements — but AWS is a common choice as most companies
have more experience working with it.
Participants

Project Manager

Development Team

Brocoder’s Deployment Responsibilities

Team members are responsible for:

Running through the pre-launch checklist to make sure the

product is fully functional

Creating a rollback strategy in case something goes wrong

Doing launch testing, including full feature scope tests, A/B tests,
and User Acceptance Tests

Stakeholder’s Deployment Responsibilities

Stakeholders are responsible for:

Setting up an account on AWS, Digital Ocean, or Azure

 Buying a domain (preferably from AWS or one that can be
transferred to AWS)

Providing information about the SSL certificate they would like to

buy

Providing production repositories

Feedback and Review

Description

The product owner and the development team prepare for Agile sprint
review meetings. The product owner needs to know the user stories that
were completed during the Sprint, while the development team should
prepare to demonstrate full, releasable functionality.

In order for a product to be considered demonstrable, it must be

developed, tested, integrated, and documented.

After the product demonstration, feedback is acquired — which the

Project Manager can use to better tailor the backlog. The PM, team, and
stakeholders collaborate to finalize the next steps.

Participants

Project Manager

Development Team

Product Owner

Brocoder’s Feedback and Review Responsibilities

The PM is responsible for:

Reviewing the Sprint’s results and explaining if any items for the
backlog were not completed

Updating the backlog and restating the project scope going

forward

Collaborating on the next steps

The team is responsible for:

Discussing the successes they faced during the Sprint

Identifying the challenges they experienced

Holding a live demo of the product

Answering any questions about the increment

Collaborating on the next steps

Stakeholders Feedback and Review Responsibilities

The stakeholder is responsible for:

Asking questions about the backlog and the product

demonstration

Collaborating on the next steps

Final Thoughts on the Agile Lifecycle

At Brocoders, we love all things Agile. It’s the perfect development
process for reducing time-to-market, enhancing flexibility, and
improving client satisfaction. Agile gives us the ability to prioritize work
and features, letting us give our clients working products as quickly as
possible. If you’re interested in focusing on individuals instead of tools,
getting a working product instead of large documentation, and adapting
to change rather than following a plan, then perhaps our Agile approach
is right for you, too.

Sdlc Sdlc Methodologies Agile Development Sdlc Phases

Software Development

Written by Brocoders Follow

192 Followers · Editor for Brocoders Team

Technical partner for well-funded startups and small-medium businesses. Our full-
cycle development team bring product from MVP to a successful product stage

More from Brocoders and Brocoders Team