What is Agile Software Development?
Agile software development comprises various approaches to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change.
The term agile (sometimes written Agile) was popularized, in this context, by the Manifesto for Agile Software Development. The values and principles espoused in this manifesto were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban.
While there is much anecdotal evidence that adopting agile practices and values improves the agility of software professionals, teams and organizations, some empirical studies have disputed that evidence.
Agile Methodology: An Overview
The art of iterative and incremental software development. Those who work in the industry, or closely to it, are aware that the art of software development is special and a bit different to other kinds of engineering projects. It requires the care and attention of a team who are adaptable and flexible, and those who are willing to respond quickly to changes and who won’t bat so much as an eyelid to a client’s overnight demands. This is what Agile methodology is all about.
Agile methodology definition:
Agile methodology is a type of project management process, mainly used for software development, where demands and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customers.
Stemming from the values and principles of the Agile Manifesto, it was created as a response to the inadequacies of traditional development methods such as the Waterfall method. The software industry is a highly competitive market due to the fact that software is something that can be continuously upgraded. This means that developers need to constantly improve and innovate their products to keep on top of the game — and the linear, sequential approach of the Waterfall method just wasn’t cutting it.
A brief history of Agile software development
In the 1990s, software development faced a bit of a crisis. Referred to as ‘the application development crisis’ or ‘application delivery lag’, the industry realized that it couldn’t move fast enough to meet customer demands and requirements — the estimated time between a business need and actual application was about three years. See, traditional development models were based on a timeline approach, where development happened sequentially and the final product wasn’t revealed to customers until the very final step. This left little room for flexibility when it came to progress reviews and changes. So, by the time an actual application was finished, it was highly likely that requirements and systems of the project’s original objectives had changed.
With money and efforts wasted, and even some projects cancelled halfway through, professional leaders of the software community thought it was time for a new, refreshed approach. Then in 2001, in a snowy, ski lodge in Utah, gathered 17 individuals. Some of whom were already entertaining the idea of a new software development method. They all yearned to cement a process that legitimized what was being practiced, and so, came the creation of the Agile Manifesto.
What is the Agile Manifesto?
The Agile Manifesto is a declaration of the values and principles expressed in Agile methodology. Made up for four foundational values and 12 key principles, it aims to help uncover better ways of developing software by providing a clear and measurable structure that promotes iterative development, team collaboration, and change recognition.
The values and principles of the ‘Manifesto for Agile Software Development’ are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
- Customer satisfaction through early and continuous software delivery
- Accommodate changing requirements throughout the development process
- Frequent delivery of working software
- Collaboration between the business stakeholders and developers throughout the project
- Support, trust, and motivate the people involved
- Enable face-to-face interactions
- Working software is the primary measure of progress
- Agile processes to support a consistent development pace
- Attention to technical detail and design enhances agility
- Self-organizing teams encourage great architectures, requirements, and designs
- Regular reflections on how to become more effective
Those who apply any type of Agile methodology adhere to these values and principles. The manifesto offers a good overview of what is expected when it comes to the Agile development life cycle practices.
What is Agile project management?
Agile project management is a methodology that is commonly used to deliver complex projects due to its adaptiveness. It emphasizes collaboration, flexibility, continuous improvement, and high quality results. It aims to be clear and measurable by using six main “deliverables” to track progress and create the product.
- Product vision statement: A summary that articulates the goals for the product.
- Product roadmap: The high-level view of the requirements needed to achieve the product vision.
- Product backlog: Ordered by priority, this is the full list of what is needed to be done to complete your project.
- Release plan: A timetable for the release of a working product.
- Sprint backlog: The user stories (requirements), goals, and tasks linked to the current sprint.
- Increment: The working product functionality that is presented to the stakeholders at the end of the sprint, and could potentially be given to the customer.
There are various frameworks within Agile project management that can be used to develop and deliver a product or service. While they each have their own set of characteristics and terminology, they share common principles and practices.
Two of the most popular ones that support the Agile development life cycle are Scrum and Kanban.
Agile Scrum methodology
Scrum is an Agile framework that is used to implement the ideas behind Agile software development. Created by Jeff Sutherland and Ken Schwaber (who were also part of the 17 individuals who cemented the Agile Manifesto), it’s comprised of five values: commitment, courage, focus, openness, and respect. Its goal is to develop, deliver, and sustain complex products through collaboration, accountability, and iterative progress.
What distinguishes Scrum from other Agile methodologies are the roles, events, and artifacts that it is made up of, with which it uses to operate. Here’s what they are:
Scrum team roles
- Product owner: Product expert who represents the stakeholders, and is the voice of the customer.
- Development team: Group of professionals who deliver the product (developers, programmers, designers).
- Scrum master: Organized servant-leader who ensures the understanding and execution of Scrum is followed.
- Sprint: Iterative time boxes where a goal is accomplished. Time frame does not exceed one calendar month and are consistent throughout the development process.
- Sprint planning: Where the entire Scrum team get together — at the beginning of every Sprint — to plan the upcoming sprint.
- Daily Scrum: 15 minute time boxed meeting held at the same time, every day of the Sprint, where the previous day’s achievements are discussed, as well as the expectations for the following one.
- Sprint review: An informal meeting held at the end of every Sprint where the Scrum team present their Increment to the stakeholders, and discuss feedback.
- Sprint retrospective: A meeting where the Scrum team reflect on the proceedings of the previous Sprint and establish improvements for the next Sprint.
- Product backlog: Managed by the Product Owner, it’s where all the requirements needed for a viable product are listed in order of priority. Includes features, functions, requirements, enhancements, and fixes that authorize any changes to be made to the product in future releases.
- Sprint backlog: A list of the tasks and requirements that need to be accomplished during the next Sprint. Sometimes accompanied by a Scrum task board, which is used to visualize the progress of the tasks in the current Sprint, and any changes that are made in a ‘To Do, Doing, and Done’ format.
Kanban is a highly visual method popularly used within Agile project management. It paints a picture of the workflow process, with an aim to identify any bottlenecks early on in the process, so that a higher quality product or service is delivered.
Its six general practices are:
- Limiting work in progress
- Flow management
- Making policies explicit
- Using feedback loops
- Collaborative or experimental evolution
A concept that was developed in the production line of Toyota factories in the 1940s, Kanban achieves efficiency through visual cues to signal certain stages of the development process. The said cues are a Kanban board, Kanban cards, and sometimes even Kanban swimlanes.
- Kanban board: A visual management tool used to visualize the development process. It can be either physical (a whiteboard, sticky notes, and markers) or virtual (like Zenkit’s online project management tool), and can be used for personal productivity, as well as professional use.
- Kanban cards: Cards that depict a work item/task in the work process. Used to communicate progress with your team, it represents information such as status, cycle time, and impending deadlines.
- Kanban swimlanes: A visual element on the board that allows you to further distinguish tasks/items by categorizing them. Flowing horizontally, it offers distinction and provides a better overview of the workflow.
Other Agile development life cycle approaches
Extreme Programming (XP)
Based on the five values of communication, simplicity, feedback, courage, and respect, XP is a framework that aims to produce a higher quality of life for the development team, as well as a higher quality product, through a collection of engineering practices. These practices are:
- The Planning Game
- Small Releases
- Simple Design
- Pair Programming
- Collective Ownership
- Continuous Integration
- 40-hour week
- On-site Customer
- Coding Standard
Crystal is comprised of a family of Agile methodologies that include Crystal Clear, Crystal Yellow, and Crystal Orange. Their unique characteristics are guided by factors such as team size, system criticality, and project priorities. Key components include teamwork, communication and simplicity, as well as reflection to regularly adjust and improve the development process. This Agile framework points out how each project may require a tailored set of policies, practices, and processes to meet the project’s specific characteristics.
Dynamic Systems Development Method (DSDM)
DSDM is an Agile methodology that focuses on the full project lifecycle. It was created in 1994 after users of the Rapid Application Development (RAD) wanted more governance and discipline to this iterative way of working. Based on eight principles, its philosophy is ‘that any project must be aligned to clearly defined strategic goals and focus upon early delivery of real benefits to the business.’
It promotes the use of the following practices so that it can offer best practice guidance for on-time, in-budget delivery of projects:
- Facilitated Workshops
- Modelling and Iterative Development
- MoSCoW Prioritisation
- Time boxing
DSDM is designed to be independent of, and can be implemented in conjunction with, other iterative methodologies.
Feature-Driven Development (FDD)
FDD is a lightweight iterative and incremental software development process. With an objective to deliver tangible, working software in a timely manner, it is an Agile methodology that entails specific, very short phases of work, which are to be accomplished separately per feature.
Its development process is established on a set of best practices with a client-value aim. The eight best practices are:
- Domain Object Modeling
- Developing by Feature
- Component/Class Ownership
- Feature Teams
- Configuration Management
- Regular Builds
- Visibility of progress and results
Agile methodology best practices
It’s always handy to know how to do things best. Here are seven things you and your team should be doing when implementing any type of Agile methodology:
One of the core values stated in the Agile Manifesto, customer collaboration is a vital part of Agile methodology. Through consistent communication with the development team, the customer should always be aware of the progress, and the combined effort will result in a higher quality product.
A tool used to explain a software feature from an end-user perspective, the purpose of a User Story is to create a simplified description of a requirement. It helps to picture the type of user of the product, what they want, and the reason(s) for it. A common User Story format that is used is:
As a [role], I want [feature], because [reason].
Continuous Integration (CI) involves keeping the code up to date by producing a clean build of the system few times per day. With a rule stating that programmers never leave anything unintegrated at the end of the day, it enables the delivery of a product version suitable for release at any moment. What CI seeks to do is to minimize the time and effort required by each integration.
Performing automated tests keeps the team informed about which of the code changes are acceptable, and whether or not a functionality is working as planned. Regression tests are run automatically before work starts.
Programming in pairs aims to enhance better designs, less bugs, and a sharing of knowledge across the development team. One of the least-embraced Agile programmer practices, it involves one programmer ‘driving’ (operating the keyboard), while the other ‘navigates’ (watches, learns, provides feedback). The roles can be rotated.
Test-driven development (TDD)
TDD aims to foster simple designs and inspire confidence. Instead of a process where software is added that is not proven to meet requirements, it is a method based on the repetition of a very short development cycle where requirements are turned into test cases, and then the software is improved to pass the new tests.
A burndown chart is a graphical representation of the work that is left to do versus the time you have to do it. Using one as part of your Agile project management plan enables you to forecast when all the work will be completed. A detailed burndown chart will also include the amount of User Stories per unit of time.
Select the language of your preference