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

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 Agile Manifesto is the approach to software project management that helps companies to be more flexible, responsive, and ready to face new challenges. This Manifesto was the answer to the problems that occurred in the software industry in the 1990s. There was an enormous time lag between the corporate software requirement specifications (SRS) and the software development for the needs of those requirements. Many customer requests changed during this lag, which led to the cancellation of a great number of projects. As a result, in 2001, a group of 17 leaders met and signed the Agile Manifesto in order to change the situation for the better. The Manifesto consists of four basic values and twelve principles that define the process of software development. Each team applies them in different ways, but all of them are an essential part of the delivery of high-quality software to businesses. The four values of the Agile Manifesto include:

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

These values are designed to make a software development process focused on quality and oriented to meeting customers’ needs.

The Twelve Agile Manifesto Principles

The 12 Agile principles support the core values by promoting a work environment that puts the customer first, gives structure to business goals, and responds quickly to changes in market forces and user needs. They also give developer teams an opportunity to modify each stage of the development process and make the environment comfortable for the team instead of needing to focus on the surrounding circumstances. The twelve principles of Agile development are presented below.

1. Customer satisfaction through early and continuous software delivery

As we can see, the satisfied customer is the top priority of all the 12 principles. Early and continuous delivery helps meet customers’ needs and increases the return of investment (ROI). Regularly receiving working software also makes customers much happier, as they are usually not huge fans of waiting for updates. By applying this principle, the software developers will be able to respond to challenges much faster.

2. Accommodate changing requirements throughout the development process

It’s essential to meet the deadlines and avoid delays when a new requirement appears or a new feature needs to be introduced. Requests to change something should not cause fear, even if they occur at the final stage of the project execution. Such customer demands should be met eagerly, as they are usually the most valuable ones.

3. Frequent delivery of working software

Regular delivery of debugged software becomes possible when the whole development process is divided into smaller stages. In addition, this principle facilitates better validation of implemented ideas and approaches.

4. Collaboration between the business stakeholders and developers throughout the project

Regular collaboration between the business and the developer team significantly improves the quality of the decisions taken and makes the communication process between the stakeholders much easier. The main goal of this principle is to achieve the synergistic effect between the people who make software and those who use it for their own purposes.

5. Support, trust and motivate people involved

Developers who don’t think about basic needs and have a comfortable working environment are much more likely to operate better and achieve higher results. When motivated individuals get all the trust and support they need, the job is usually done well and in time.

6. Enable face-to-face interactions

Having the opportunity to discuss different aspects of the development process in person makes communication between members of the team much more effective. Unfortunately, the COVID-19 pandemic put some restrictions on personal collaboration, and many software developers moved to an entirely online environment. This led to slowing down and postponing many projects.

7. Working software is the primary measure of progress

Delivery of high-performing software to the customer is the main KPI for the team's performance assessment. It doesn’t matter how many sleepless nights were invested in the project, how many lines of code were written, or how many bugs were fixed. If the software doesn’t operate in the way it was initially expected, the work can’t be considered finished.

8. Agile processes support a consistent development pace

Team members need to discuss and establish a maintainable pace at which they can comfortably operate and deliver working software on a regular basis. When this principle is applied in practice, its main goal is to avoid professional burnout and the necessity of heroic deeds. Optimization of basic processes is the solution.

9. Attention to technical detail and design enhances agility

A well-chosen set of skills and design solutions gives the developer team an opportunity to maintain the speed of the project, constantly improve the code, face the challenges, and respond to them effectively. All these aspects of the development process make it much more agile. Operational excellence makes the difference between a true professional and an ordinary team member.

10. Simplicity

Complex decisions can slow down the whole software development process. The amount of effort must be just enough to do the task at that time. If something can be done in a simple way with a medium amount of effort without loss of quality, it should definitely be done this way. One important thing to remember is that the customers are paying for the result, not for hard work.

11. Self-organizing teams encourage great architectures, requirements, and designs

Experienced and motivated teams who make decisions, take responsibility, regularly communicate, and share ideas with each other are able to deliver high-quality solutions through a sustainable development process. The team that has to be pushed by its leader on a regular basis should revise its whole approach.

12. Regular reflections on how to become more effective

Last but not least, the twelfth principle states that constant personal growth, skill and process improvement, and self-organization are the key factors for efficient work and final success. Continuous improvement can be achieved through repeating the four basic steps: plan – do – check – act. If something goes wrong, the team can always discuss it and move on.

Final Thoughts

The ultimate goal of Agile is to unite the software development process with business needs. A lot of web development companies follow Agile in building products. Projects built on the basis of the Agile values and principles focus on the customers and encourage their direct involvement and participation in the process. The implementation of the Agile Manifesto all over the software industry proved its effectiveness and positive impact on many processes.

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 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.

Steps of a 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

• Feature decomposition

• Low fidelity prototype

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.

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.

Contact us to know more about our expertise and work process

Contact us

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 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.

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.