NASCAR and Formula One teams have the same goal: get a car around a racetrack as quickly and safely as possible. But they take different approaches–NASCAR uses stock cars, and Formula One uses open-wheel cars.
Agile methodologies are a bit like these racing teams, as they each offer software development teams different ways to quickly get products and features to customers. The best part, you don’t need to pick just one. Software development teams can use a mix of Agile processes based on their budgets, customers, market conditions, and other factors important to them.
Not sure where to start in adopting these methodologies? Keep reading to learn about the benefits of Agile and how some of the most popular methodologies work, so you can choose the best one(s) for your software development team.
What is Agile?
Agile methodologies are sets of practices that help software development teams deliver value to customers through iteration.
The goal is to make continuous, fast, incremental improvements as a development team based on feedback from end users.
Projects are broken up into shorter phases for teams to cycle through: first planning, then executing, and finally evaluating the impact of their work.
The official history of Agile starts with the Agile Manifesto–a document that was created in early 2001 by a group of software development professionals that called themselves the “Agile Alliance.” The document highlights the values and principles that have become pillars of the agile development model.
But why’d they create it? Developers were looking for a more modern approach to software development, something to replace the “Waterfall” methodology popularized in the 1970s.
“Waterfall” is a linear sequential model, which is a very academic way of saying that your team doesn’t move on to the next phase of your project until the prior step is fully developed, tested, and ready to go. Agile doesn’t have this rigidity: development and testing happen simultaneously, creating a continuous feedback loop for all stakeholders (like developers, product managers, designers, QA, and customers).
What are the main benefits of Agile?
Customer needs and expectations can change during the development lifecycle. Unlike the “Waterfall” model, agile development makes it easy to adapt to these shifts by changing previous phases or even pivoting to an entirely new initiative when necessary.
With this flexibility and adaptability come many advantages of Agile.
Frequent delivery
Agile principles emphasize working iteratively and quickly, but this doesn’t mean rushing processes for the sake of speed. It means empowering teams to deliver smaller changes on a more regular basis.
Projects are broken down into smaller, repeatable tasks with frequent deliveries. In linear development methods, the customer doesn’t see what the product is going to look like until it’s finalized. Agile brings customers into the development process, gathering and incorporating their feedback throughout.
Imagine you’re building a travel booking website. The website should allow people to find and book flights, train rides, car rentals, hotels, and more.
Instead of waiting for the entire website to be completed before making it public, an agile development approach could focus on delivering “flights” first.
Releasing new features incrementally allows customers to interact with them. Customers can then immediately evaluate and provide feedback on a feature. The insights garnered from user behavior and feedback can then be used to improve your development process for upcoming features.
Tighter collaboration and communication
Agile’s fast-moving initiatives and frequent deadlines make close collaboration and teamwork a priority. Fast, incremental delivery requires all stakeholders to be equally invested in the process in order to achieve their goals.
Agile teams have the visibility they need to plan ahead and prioritize tasks. Better communication also decreases the chances of team members not having anything to work on or having too much on their plates at once. In Agile, transparency and a willingness to share ideas openly are crucial, making collaboration and open communication key.
Continuous improvement
With linear development methodologies, teams only review processes once projects are complete. Agile project management gives teams more room to experiment with processes, see what works and what doesn’t, and make necessary changes immediately instead of waiting for the project to finish.
Through constant evaluations, your team will get better at estimating the time it takes to complete tasks. You’ll also be able to understand your customers better through continuous communication and tailor your processes over time to match their preferences as well.
For example, you might notice after each new release that your customer’s reactions or comments are becoming increasingly sparse. This might be a sign that your communication style is too technical, and they don’t really understand what’s been delivered.
Agile work can catch an issue like this early to constantly improve every aspect of your work, customer communication included.
4 popular agile project methodologies
At their cores, all agile frameworks share the same principles: iteration, collaboration, learning, and delivering value to the end user.
Since all agile methodologies preach the same principles, it’s not unusual for teams to use a couple of different methodologies at once. For example, the two most popular frameworks, Scrum and Kanban, are often combined to create a hybrid system called “Scrumban.”
Let’s take a look at some of the most popular agile approaches to get a better understanding of what agile software development looks like in action.
1. Scrum
The term “Scrum” originates from the sport of rugby. In rugby, a scrum is when the team huddles together to move the ball forward in unison. In software development, it signifies your team coming together to move the product forward.
All work in the Scrum methodology revolves around the “Sprint.” A Sprint is a fixed time period of work: the iteration period. It could be a week, a month, or any other period of time, depending on the project and what it calls for.
Generally, the shorter the Sprint, the more frequently teams receive feedback.
Scrum roles
Scrum teams have three main roles: the Scrum Master, the Product Owner, and the Developers.
The Scrum Master leads the team. Their responsibility is to keep communication and collaboration between all stakeholders running smoothly
The Product Owner is in charge of managing the product backlog. The Scrum Master lets the Product Owner know the goals and scope of the initiative, so the Product Manager can focus on prioritizing the features that deliver value as quickly as possible
The Developers are building the code, so they can give the most realistic time estimates for each iteration. They will work with the Product Owner to decide what features will be built during each Sprint
Scrum processes
There are four main processes that are included in each Sprint:
Sprint planning defines the goals for each Sprint. During planning, they’ll pick features from the backlog to work on and define how long the Sprint will last.
Daily standups are 15-minute daily meetings to discuss progress and call out any potential roadblocks that could compromise the Sprint’s success
Sprint reviews occur at the end of each Sprint. The team discusses what they achieved and how much progress they’ve made
Sprint retrospectives are more detailed reviews where the team discusses what worked well and what problems need to be addressed to make the next Sprint more successful than the last
Is scrum right for your team?
Scrum is the most popular agile methodology because it can be used by just about any type of team. It’s one of the best methods for teams new to Agile because the roles and processes are logical, simple, and easy to follow.
While the most basic version of Scrum is designed to work best with small teams, there are offshoot methodologies for larger Scrum teams, like Scrum of Scrums (SoS), Large-Scale Scrum (LeSS), and Scaled Agile Framework (SAFe).
2. Kanban
Scrum and Kanban are very similar concepts that both focus on incremental, continuous improvement.
The biggest difference is that Kanban is a much more loose and less structured methodology. Kanban is a continuous planning process. There is no formal commitment to complete something in a set duration of time, like in a Sprint.
Kanban roles
While there are no official roles in Kanban, teams sometimes give certain members unofficial roles: most commonly, the Service Request Manager (SRM) and Service Delivery Manager (SDM):
The SRM is similar to the Scrum Master. It’s one person on the team who is designated to liaise with customers and other stakeholders (like upper management) to understand their needs and expectations better and relay that knowledge to the team
The SDM is like the Product Owner. They are tasked with identifying and helping to remove blockers to make sure that the team is able to work on their tasks without interruptions and unwanted delays
Kanban processes
Kanban uses a “continuous workflow” structure without defined increments like Sprints. However, teams do create stages for their continuous workflow. Every team defines these stages as they please, but most commonly it’s “To Do, In Progress, In Review, Blocked, Done.”
The centerpiece of the process is the Kanban Board, which helps the team visualize work that passes through each stage. The Kanban Board has several core elements:
Workflow stages (To Do, In Progress, In Review, Blocked, and Done) are visually present as columns or pipelines
Task cards represent each task that needs to be completed. They are moved through the pipeline and taken off the board when they are considered done
Work-in-progress limits designate the maximum number of tasks your team should have in each column at any given time. These limits provide a framework to gauge capacity, optimize the workflow, and minimize burnout.
Is Kanban right for your team?
If you appreciate the values and principles of Scrum but find it a bit too time-bound, Kanban’s style of continual workflow with no fixed iterations might be perfect for you. The biggest difference between the two is the Sprint.
With Kanban, you don’t have to wait until a Sprint is over to deliver a feature or reflect on the work you’ve done. The development process is continuous and doesn’t have any strict deadlines or timeframes to follow.
Kanban Boards are also great for teams that respond better to visual frameworks and want an easy and clear way to follow their progress.
3. Extreme programming (XP)
Extreme Programming (XP) is an agile methodology that prioritizes speed without sacrificing code quality. Developers are expected to push themselves to the limits of their abilities, hence the “extreme” epithet.
But how do you work quickly without sacrificing quality? In XP, you write the tests before you write the code, and every line of written code must pass testing before it’s released. In this test-driven development, short cycles and immediate feedback result in more reliable code that works the way it’s supposed to on the first try.
XP roles
There are three main roles in an agile XP team:
Coaches are typically external consultants who have experience working with XP teams but aren’t directly involved with the development processes. They can help teams that are new to XP avoid common mistakes
Trackers are the link between the developers and customers: the people who organize meetings and keep track of progress. You can assign one of your developers to be the tracker, as it doesn’t have to be a position of its own in XP
The Developers are the people who build the product and are responsible for writing and testing code
XP processes
The five main phases of XP that are iterated continuously are:
Planning: Define requirements in the form of user stories. These stories describe the desired results of each feature or product. Once user stories are created, the team gives estimates on how long each story will take to complete
Coding: The actual coding performed by developers. There are three main coding standards in XP:
Pair programming means two programmers working together on the same code. Usually, one will focus on writing while the other focuses on reviewing the code to fix mistakes and recommend improvements
Continuous integration means that XP teams commit code multiple times a day, a process known as continuous delivery
Collective code ownership means that the entire team takes responsibility for the code, and everyone is allowed to review and update all code. This helps avoid code duplication and encourages frequent communication
Testing: The core XP process that involves both regular automated testing and acceptance tests in which the customer verifies whether the feature or product is working according to the agreed requirements
Listening: Constant communication and feedback among developers, project managers, and customers to make sure that value is being delivered as planned
Is extreme programming right for your team?
Extreme Programming is primarily only used among highly experienced development teams as it's more about the process of planning what to code, coding, and reviewing the code. And since it calls for developers to write their own tests and collaborate on code all across the project, it works best for highly experienced and skilled development teams with a flat hierarchy.
In XP, group dynamics are prioritized over role distinctions and tenure. It shouldn’t be important who on the team is a senior, medior, or junior developer.
4. Crystal
Crystal is one of the more unorthodox agile methodologies. Instead of prioritizing processes and tools, the focus is placed on the team members and their skills, personalities, and interactions.
In Crystal, every project is considered unique. It’s up to the team members to decide how to optimize their workflow by picking the tools and processes that work best for a given project.
There is no one true Crystal method, rather it evolves to fit project characteristics like:
Team size
Criticality
Project priority
Crystal methodologies are represented by different colors on a spectrum, for example:
Crystal clear: Teams of six or fewer
Crystal yellow: Between 7-20 team members
Crystal orange: Between 21-40 team members
Crystal red: Between 41-80 team members
Crystal maroon: Between 81-200 team members
To gain a more detailed understanding of the spectrum, take a look at Alistair Cockburn’s (the “father” of Crystal) article, “Crystal clear a human-powered methodology for small teams.”
Crystal roles
Roles in the Crystal methodology are very flexible and are assigned by the team based on the needs of each project. These are the most typical roles you’ll see in the Crystal methodology:
The Executive Sponsor: The person paying for the project (often the customer)
The Ambassador User: Someone who has been involved in the project since day one and is familiar with the entire system and what needs to be delivered. They are the ones who test the final product
The Lead Designer: Like a Product Owner, the Lead Designer is familiar with software development and evaluates the project’s progress
The Programmer: The person (or people) who are coding the project
Crystal processes
As mentioned, there is no formal structure to the Crystal methodology. However, the work being performed is based on six key principles:
Frequent delivery: Release and test new projects as soon as possible
Reflective improvement: After each delivery, reflect with your team on what can be improved in terms of tools and processes
Consistent communication: Make sure that your team is constantly communicating about everything related to the project: blockers, best practices, what’s working, and what isn’t. Cockburn preaches the importance of “osmotic communication”: having teams in the same physical space when possible to allow information to flow between members at all times
Personal safety: It’s important to make sure that all team members feel free to express opinions and give suggestions. Crystal prioritizes safe communication where no one is afraid to comment on the project in whatever way they feel necessary.
Easy access to experts: The team should always have access to people who have expertise in whatever is being worked on and can provide guidance whenever necessary. Experts can be internal or external
Technical tooling: Crystal encourages development teams to have open conversations about the tools being used and whether they can be upgraded or altered to improve processes. Cockburn recommends continuous deployment and automated testing tools to quickly catch and fix errors
Is Crystal right for your team?
Crystal works best for teams that work on a wide variety of products and need complete flexibility to adapt to each new endeavor as needed.
In Crystal, interpersonal relationships and promoting open communication are prioritized. Cockburn also believes that Crystal works best when teams are small and work together in a single location, where they can interact in person every day.
Figure out which agile methodologies work best for your team with ClickUp
Choosing the right agile methodology for your team or project is far from an exact science. Just like any other process change, agile methods should be tested to see which ones work best for your team and provide the greatest value.