Agile and Scrum have almost become synonymous. Have you wondered what's the difference? Scrum is just one way to be Agile. It is the most popular which leads to the common confusion. Agile actually refers to a philosophy shared by group of development methods, each offering a unique approach.
Agility is a concept. It's important to think of as something you are (or try to be!) not as something you merely do. All Agile development methods have a shared philosophy and core set of principles
. "The Manifesto for Agile Software Development" was published in 2001 and promotes four key values: individuals and interactions, working software, customer collaboration, and responding to change. Essentially Agile is not concerned with executing a planned project in a sequential order.
The Agile umbrella has many offerings depending on your needs. Below are some of the most notable ways to be Agile along with their strengths.
Scrum, for collaboration and focus
Scrum is iterative, incremental and relies heavily on frequent team communication and customer interactions. A flexible environment for development is offered in 1-4 week timeboxed iterations called sprints. These short cycles allow for teams to develop a cadence, typically measured with "story points" via velocity, and a short feedback loop. Frequent evaluation with stakeholders and customers ensures an essential feature isn't overlooked and that nothing is overdeveloped, or gold plated. Sometimes Scrum is criticized as inefficient due to the ceremonies requiring team attendance, like retrospectives, demos, sprint planning and backlog grooming. There is validity to the critique; Scrum is not the most efficient method but it is very effective.
Kanban, for efficiency
This method is not time bound and focuses on flow. Work is kept in a prioritized backlog and moved through columns with WIP (work in progress) limits, generally labeled with states like Ready to Start, In Progress, and Done. The backlog’s priority order can change fluidly; developers will pick up the top work item when they are able to start something new. Bottlenecks are revealed dynamically when column constraints are hit. Work items are pulled from the backlog and put into production when column constraints allow supports a just-in-time delivery made popular by Toyota's production system.
XP (Extreme Programming), for development practices
Features are broken into granular tasks for very short iterations, typically one to two weeks. As long as the team hasn't started working on a task during the iteration it can be changed out for another task of an equivalent size. Work is sequenced in a strict priority order and code is released quickly through mandated engineering practices including test-driven development, pair programming, and refactoring. Acceptance tests take the place of requirements and specs.
Lean, for eliminating waste
Everything from unnecessary documentation to slow communication is regarded as waste and targeted for elimination to produce a better product. If at any time quality is not met team members are empowered to stop the process. They can also insist any issue or defect is resolved before the process moves forward. However there is no specific Lean development method, unlike others listed here. Technically any process can be considered "lean" if it aligns with the following values: Eliminate waste, Build quality in, accelerate learning, Defer commitment, Deliver fast, Respect and empower People, Optimize the whole
Feature-driven Development (FDD), for organization and reporting
Projects start with something similar to a "Sprint 0" often employed by Agile teams that serves as a short period to setup the work that will occur in subsequent iterations. In FDD the initial activities are developing an overall model, building the feature list and creating a development plan with ownership assigned by feature. Then the design and build cycle begins, each iteration lasting anywhere from a few days up to two weeks, with small groups of features. Sufficient time is spent on documentation and end-users participate through reports. FDD is not well suited for small projects due to the level of complexity and possibility for multi-tasking.
Dynamic Systems Development Method (DSDM), for meeting deadlines and budgets
Focused on projects with tight schedules and budgets by incremental prototyping. Functionality and requirements are the variables rather than time or resources. Features identified as the most important are delivered first using MoSCoW prioritization
. DSDM strives to deliver 80% in the first of the scope in 20% of the time by iterating in intervals, typically 2-6 weeks in length.
7. Crystal Methods, for a customizable process framework
Developed to address the variability of characteristics like project and team size, Crystal believes there is no singular process that is right for all teams, and therefore offers a family of methods. This also allows for the process to evolve with the project and people over time. The different methods are named by colors in ascending opacity. Crystal Clear is considered the most agile version increasing next to Crystal Yellow, Crystal Orange, and finally Crystal Red. Each has a different set of recommended practices, core roles, and techniques. However all methods emphasize the importance of people in software development; process is considered important but secondary.
With so much variety under the Agile umbrella you may feel overwhelmed decided which is right for your team. Be pragmatic in your decision making and do not worry about adapting one pure method. Feel free to cherry-pick elements from each instead of fixating on one, just remember to be agile! Inspect and adapt as you iterate because the needs of your group will evolve.