September 15, 2021

A Guide to the Agile Software Development Life Cycle (SDLC)

Yulya Glamazdina

Yulya Glamazdina

Marketing Manager

9 minutes

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.

Frame 1206.png

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
AgileWaterfall
The plan evolves over timeThe plan is developed at the beginning
Iterative and incremental processesPhased and sequential processes
Produces working outcomes on a regular basisDelivers a final product at the end
Cross-Functional TeamsFunctional Teams

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 vs Kanban.png

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.

ScrumKanban
RolesRoles are must and include the Product Owner, Scrum Master, and Development Team.There are two optional roles: Service Delivery Manager and Service Request Manager.
PlanningAt the beginning of each Sprint, work is planned and divided into smaller "user stories".Rather than planning big batches of work, Kanban does "just-in-time" planning.
CommitmentCommitment is determined using sprint forecasting.Team members finish a task before picking a new one.
KPIsMetrics include Velocity and Projected Capacity, and they are measured on Burndown charts and Team Velocity charts.Metrics include Lead Time and Cycle Time, and they are monitored on Burndown charts and Velocity charts.

Steps of a Scrum Workflow

Frame 1215.png

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

6 phases of software development life cycle.png

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

WBS.png

  • Feature decomposition

Feature decomposition.png

  • Low fidelity prototype

Low fidelity prototype.JPG

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

KitKat.JPG

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.

Roadmap.png

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.

Testing.png

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 to modify
  • 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.

deployment phase.png

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.

Read more on our blog