Agile Software Development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In other words, Agile Software Development (ASD) is a methodology for the creative process that anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product. Agile software development focuses on keeping code simple, testing often, and delivering functional bits of the application as soon as they’re ready. The goal of ASD is to build upon small client-approved parts as the project progresses, as opposed to delivering one large application at the end of the project.
Agile methods grew out of the real-life project experiences of leading software professionals who had experienced the challenges and limitations of traditional waterfall development on project after project. The approach promoted by agile development is in direct response to the issue associated with traditional software development – both in terms of overall philosophy as well as specific processes.
Agile software development, in its simplest form, offers a lightweight framework for helping teams, given a constantly evolving functional and technical landscape, maintain a focus on the rapid delivery of business value (i.e., “bang for the buck”). As a result of this focus and its associated benefits, organizations are capable of significantly reducing the overall risk associated with software development.
In particular, agile software development accelerates the delivery of initial business value, and through a process of continuous planning and feedback, is able to ensure that value is continuing to be maximized throughout the development process. As a result of this iterative planning and feedback loop, teams are able to continuously align the delivered software with desired business needs, easily adapting to changing requirements throughout the process. By measuring and evaluating status based on the undeniable truth of working, testing software, much more accurate visibility into the actual progress of projects is available. Finally, as a result of following an agile process, at the conclusion of a project is a software system that much better addresses the business and customer needs.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Twelve Principles behind the Agile Manifesto
We follow these principles:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals.Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development.The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Agile Software Development Life Cycle
An agile software development life cycle is very different than traditional “Waterfall” Software Development Life Cycle (SDLC). Traditional software development projects follow what is commonly known as a waterfall approach, where each phase of the software development life cycle is completed in detail and in sequence, one stage at a time.
In the case of Agile Software Development Life Cycle, the initial planning and analysis is kept to a very high level, just enough to outline the scope of the development project. Then the team go through a series of iterations, analyzing, designing, developing and testing each feature in turn within the iterations.
For instance, it might look a bit more like this:
There aren’t really any distinct stages during the development. Instead, each feature is taken from start to finish within an iteration, with the software being released at the end of each iteration, or if appropriate even during an iteration.
An iteration is simply a fixed, short period of time that the team chooses to work within. Typically for agile teams, an iteration is between 1 week and 30 days. Strictly speaking, the Scrum agile development methodology advocates 30 days, but very few teams actually do this. 2 or 3 weeks seems to be more common. The Extreme Programming agile methodology advocates 1 week. This is very short and requires quite a lot of maturity in the team and its processes to achieve, because getting to a stable release every week can be difficult.
Either way, the principles are the same. The idea is to stick to short, fixed-length iterations and complete all stages of the development cycle for each feature in turn within an iteration.
The key difference this creates is visibility of complete working features much earlier in the project life cycle, allowing for a better gauge of progress and quality, and allowing for feedback and adaption along the way. The result is to see some results earlier, mitigate risk, and to allow flexibility to accommodate change.
One of the dangers of a waterfall approach is that by the time the detailed up-front planning, analysis and design are done, let alone by the time the solution is developed and tested, many requirements may have changed – especially these days when the pace of change is so incredibly fast. Agile Software Development methodology mitigates this risk too, helping to ensure that the right solution is delivered.
Agile Software Development With SCRUM
Scrum project management is a software agile development process. Scrum models allow projects to progress via a series of iterations called agile sprints. Each sprint is typically two to four weeks, and sprint planning in the agile methodology and Scrum process is essential. While the agile Scrum methodology can be used for managing any project, the Scrum agile process is ideally suited for projects with rapidly changing or highly emergent requirements like software.
SCRUM is an Agile Process for Software Development
Scrum is used in the agile process for software development. But rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the software development team. This is done because the team will know best how to solve the problem they are presented. This is why, for example, a sprint planning meeting is described in terms of the desired outcome (a commitment to a set of features to be developed in the next sprint) instead of a set of Entry criteria, Task definitions, Validation criteria, and Exit criteria (ETVX) as would be provided in most methodologies.
Scrum relies on a self-organizing, cross-functional team. The scrum team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole. The Scrum team is cross-functional; everyone is necessary to take a feature from idea to implementation.
These agile development teams are supported by two specific individuals: a ScrumMasterand a product owner. The ScrumMaster can be thought of as a coach for the team, helping team members use the Scrum framework to perform at their highest level. The product owner represents the business, customers or users, and guides the team toward building the right product.
Scrum projects make progress in a series of sprints, which are time-boxed iterations no more than a month long. At the start of a Scrum sprint, team members commit to delivering some number of features that were listed on the project’s scrum product backlog. At the end of the Scrum sprint, these features are done–they are coded, tested and integrated into the evolving product or system. At the end of the sprint, a sprint review is conducted during which the team demonstrates the new functionality to the product owner and other interested stakeholders who provide feedback that could influence the next sprint.
SCRUM Methodology and its Major Activities
The agile sprint itself is the main activity of Scrum project management. The agile methodology and Scrum process is iterative and incremental, so the project is split into a series of consecutive sprints. Each is timeboxed, usually to between one week and a calendar month. One survey found that the most common sprint length of a Scrum agile process is two weeks. During this time, the Scrum team does everything to take a small set of features from idea to coded and tested functionality.
In the Scrum model, the first activity of each sprint is a sprint planning meeting. During this meeting, the product owner and team talk about the highest priority items on the scrum product backlog. Team members figure out how many items they can commit to, and then create a sprint backlog, which is a list of the tasks to perform during the sprint.
This agile process methodology states that on each day of the Scrum sprint, a daily Scrummeeting is attended by all team members, including the ScrumMaster and the product owner. This meeting is timeboxed to no more than 15 minutes. During that time, team members share what they worked on the prior day, will work on today, and identify any impediments to progress. Daily scrums serve to synchronize the work of team members as they discuss the work of the sprint.
At the end of a Scrum sprint, the teams conducts a sprint review. During the sprint review, the team demonstrates the functionality added during the sprint. The goal of this meeting is to get feedback from the product owner or any users or other stakeholders who have been invited to the review. This feedback may result in changes to the freshly delivered functionality. But it may just as likely result in revising or adding items to the Scrum product backlog.
Another activity performed at the end of each sprint is the sprint retrospective. The whole team participates in this meeting, including the ScrumMaster and product owner. The meeting is an opportunity to reflect on the sprint that is ending and identify opportunities to improve in the new sprint.
Main Artifacts of a SCRUM Project
The primary artifact of a Scrum project is, of course, the product itself. The Scrum model expects the team to bring the product or system to a potentially shippable state at the end of each Scrum sprint.
The scrum product backlog is a complete list of the functionality that remains to be added to the product. The Scrum product backlog is prioritized by the product owner so that the Scrum team always works on the most valuable features first. The most popular and successful way to create a product backlog is to populate it with user stories, which are short descriptions of functionality described from the perspective of a user or customer.
In Scrum project management, on the first day of a sprint and during the agile sprint planning meeting, team members create the sprint backlog. The sprint backlog can be thought of as the team’s to-do list for the sprint. Whereas a product backlog is a list of features to be built (often written in the form of user stories), the sprint backlog is the list of tasks the team needs to perform in order to deliver the functionality they committed to deliver during the sprint.
Two other primary artifacts of the Scrum agile process are the sprint burndown chart and release burndown chart. Burndown charts show the amount of work remaining either in a Scrum sprint or a release. They are a very effective tool for determining at a glance whether a sprint or release is on schedule to have all planned work finished by the desired date.
In Agile Software Development Process, What are the Main Roles?
Even if you are new to Scrum, you may have heard of a role called ScrumMaster. The ScrumMaster is the team’s coach and helps scrum team members achieve their highest level of performance. A ScrumMaster differs from a traditional project manager in many key ways, including that the ScrumMaster does not provide day-to-day direction to the team and does not assign tasks to individuals. A good ScrumMaster shelters the team from outside distractions, allowing scrum team members to focus maniacally during the agile sprint on the goal they have selected.
While the ScrumMaster focuses on helping the team be the best that it can be, the product owner works to direct the team at the right goal. The product owner does this by creating a compelling vision of the product, and then conveying that vision to the team through the scrum product backlog.
The product owner is responsible for ensuring that the Scrum product backlog remains prioritized as more is learned about the system being built, its users, the team and so on.
The third and final role in Scrum project management is the scrum team itself. Although individuals on a Scrum team may come to that team with various job titles, while on the team those titles are insignificant. Each person contributes in whatever ways they best can to complete the work of each agile sprint. This does not mean that a tester will be expected to re-architect the system; individuals will spend most (and sometimes all) of their time working in whatever discipline they worked before adopting the Scrum model. But on a Scrum team, individuals are expected to work beyond their preferred disciplines whenever doing so would be for the good of the team.
One convenient way to think of the interlocking nature of these three roles is as a race car. The Scrum team is the car itself, ready to speed along in whatever direction it is pointed. The product owner is the driver, making sure that the car is always going in the right direction. And the ScrumMaster is the chief mechanic, keeping the car well-tuned and performing at its best.
Learn More About Agile Methodology and Scrum Process
For those looking to learn more about Scrum, the following is a list of pages on this site that will give you insight into the Scrum methodology. You can learn about the following topics:
- Daily Scrum
- Product Backlog
- Product Backlog Example
- Product Owner
- Release Burndown
- Scrum Master Requirements
- Scrum Team
- Sprint Backlog
- Sprint Planning Meeting
- Sprint Retrospective
- Sprint Review Meeting
- Task Boards
- Figures and Wallpapers
- Alternative Burndown Chart
- Scrum Presentation
Learn more about the following: