Agile Methodology
Agile is an approach to software development that seeks the continuous delivery of working software created in rapid iterations.
However, the phrase "agile methodology" is misleading because it implies that agile is a singular approach to software development. Agile is not a set of prescriptions for exactly which actions to take in software development. Instead, it is a way of thinking about collaboration and workflows and it is a set of values which guide our choices in regards to what we make and how we make it.
In practical terms, agile software development methodologies are all about delivering small pieces of working software quickly to improve customer satisfaction. These methodologies use adaptive approaches and teamwork to focus on continuous improvement. Usually, agile software development consists of small, self-organizing teams of software developers and business representatives regularly meeting in-person throughout the software development life cycle. Agile favors a lightweight approach to software documentation and embraces—rather than resists—changes at any stage of the life cycle.
Agile values
Agile as we know it today traces its history to 2001. Reacting to waterfall approaches to project management, which organizes a software project as a series of linear sequences, a group of software developers penned The Manifesto for Agile Software Development. In this document the programmers proposed a new approach to software development and described 4 key characteristics that they believed should be valued over other concerns. As they put it, agile software development teams should 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
Agile frameworks
Agile frameworks for software development—like Scrum, kanban, or extreme programming (XP)— form the basis for popular software development processes like DevOps and continuous integration/continuous deployment (CI/CD).
Scrum is perhaps the most popular agile framework in use today but not all agile is Scrum and, honestly, not all Scrum is agile. Scrum is a framework for managing work designed for small, cross-functional teams of 5 to 9 people who break their work into actions that can be completed within a consistent period of time called a sprint. Scrum teams consist of team members, a Scrum master, and a product owner. Typically, Scrum is implemented when a large project can be broken up into 2- to 4-week sprints. Scrum focuses on feedback loops through a ceremony called the "retrospective." The unofficial motto of Scrum could be "inspect and adapt."
Other agile frameworks, notably kanban, predate the agile manifesto. But these frameworks are considered to be agile because they promote the values outlined in the agile manifesto. There are too many agile frameworks and approaches to scaling agile to list all of them here.
Scrum and kanban
Once a product vision and team (or teams) adopt agile principles, starting with the ones identified in the agile manifesto, the organization must select a process methodology. Scrum and kanban are the primary agile processes.
Some organizations start with kanban because it’s relatively easy to explain and implement. Kanban works as a fan-in and fan-out process where the team pulls user stories from an intake board and funnels them through a workflow until they are marked done.
But many organizations implement scrum, which organizes the work in cadences called sprints, usually lasting one or two weeks. The product owner writes the requirements as user stories, then prioritizes them in a backlog based on their business value. The team reviews the backlog and commits to the top user stories they can complete during the sprint.
Scrum includes several standard meetings (sometimes called scrum ceremonies or scrum rituals) to help teams commit to sprint priorities, complete the work during the sprint, and end each sprint successfully. These meetings usually include a few common elements:
Sprint planning is where the product owner shares priorities, and the team decides how much work it can complete during the sprint.
Daily standup meetings help teams discuss the status of user stories; teammates share their daily goals, and anyone can escalate blocks that impede the team’s progress.
Sprint reviews are demo meetings at the end of the sprint, where the functionality is shown to the product owner to gain acceptance on completed work.
Retrospective meetings are where the team discusses what went well and what needs improvement in their agile and software development processes.
It should be noted that these practices are adaptable to agile hybrid work models.
Scrum improves a team’s performance by empowering the team to commit to an achievable amount of work rather than having a product, program, or project manager specify the expected timeline and scope. The user story forms a microcontract that separates business need, the acceptance criteria (or what agile teams sometimes call the definition of done), and then enables teams to self-organize on how to implement. Sprint reviews are one type of feedback loop, and product owners are encouraged to realign priorities and redefine requirements before each sprint. Sprint retrospectives help the team improve collaboration and initiate process improvements.
