If you work in the software development sphere, you’ve almost certainly heard the term “agile” thrown around your office. Agile has been the go-to methodology for software development and innovation since the early 2000s, and there are plenty of stories to prove that it works. Agile is spreading beyond the tech world and becoming standard practice across several industries.
But what is Agile methodology, and how can it help you with collaborative project management?
What is agile project management?
Agile methodology is an iterative process that gives teams the power to deliver high value to their customers without the cumbersome elements of a full-blown launch. Rather than waiting months or years to deliver a full suite of software products, for example, an agile team delivers work in smaller chunks. This enables teams to collaborate closely with their customers to evaluate a product plan and strategy in real time making adjustments as needs shift.
The simplest definition of Agile is: “a project management approach that enables software developers (and other professionals) to respond to customer feedback and release new iterations more quickly.” The Agile process breaks down a project into small, manageable increments led by a collaborative and self-organizing team.
The Agile concept originated from “The Agile Manifesto,” a 68-word credo created by 17 software engineers (called the “Snowbird 17”) in 2001. The authors behind the manifesto were frustrated by the software development industry, particularly its long lead times between releases, excessive documentation, and failure to consider the customer’s needs. Their publication made shockwaves through the industry, resulting in many developers abandoning the old development practices (known as “Waterfall”) and adopting this new system.
The best way to understand Agile is to look at the values and principles outlined by those original developers.
Why use agile? A look at the agile values
The best way to understand Agile is to look at the values and principles outlined by those original developers.
People over processes and tools
When the Snowbird 17 were developing Agile, the software development industry was hyper-focused on processes. The belief seemed that the right tools and techniques would lead to successful software, no matter who was doing the work. The Snowbird 17 rejected this concept, suggesting that the right team was essential for success.
Project managers can implement this value into their work by considering their team before starting a new project. The right combination of personalities, talents, and experience can significantly impact your success.
Working prototypes over excessive documentation
We can all agree that documentation is essential. Every project needs clear documentation to keep track of changes, manage timelines and workflows, and everything else that goes into successful deliverables. However, working in Agile means making the deliverables the top priority.
This methodology prioritizes promptly providing the customer with finished software (or other projects) and documenting the project development to suit those timelines. Streamlining documentation is crucial and gives team members only the information they need to complete their project phase.
Customer collaboration over contract negotiation
This value speaks to the adaptive nature of Agile. Agile project managers nurture a feedback loop between the development team and the customer. This customer collaboration enables the team to adjust their project plan throughout the development process and improves their chances of achieving customer satisfaction.
Responding to change by following a plan
In the early 2000s, updating software was considered an excess expense. Therefore, development teams had to create detailed plans before writing a single line of code — and they were expected to stick to the plan.
Of course, anyone who works in project management knows that isn’t always possible. Projects run into backlogs, bottlenecks, and countless other issues that can veer the team off the original roadmap.
Agile practices encourage teams to embrace the uncertainty of project development by assessing the project after each phase and adjusting priorities as necessary. This adaptive process ensures that the development team always addresses customer needs first and foremost.
The 12 principles of agile
In addition to the Agile values we discussed, the Snowbird 17 also developed 12 Agile principles. These principles help guide Agile teams as they move through each development cycle in their project.
The Agile principles are as follows:
1. Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.
Agile project managers know that a happy customer receives regular deliverables rather than making clients wait extended periods between software releases, project updates, or other deliverables.
2. Welcome changing requirements, even late in development.
Agile processes harness change for the customer’s competitive advantage. There is time for feedback and changes baked into the Agile framework, so development teams can more easily accommodate changing priorities and meet their client’s business needs.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for a shorter timescale.
“Working software” is the top priority in Agile software development. Agile developers work in iterations rather than creating a one-time finished product. Creating a product (or meeting project goals) satisfies the customer, and the Agile approach still allows for changes down the road.
4. Business people and developers must work together daily throughout the project.
It is essential that project managers, teams, and clients align their goals and priorities. Therefore, the feedback look (Agile value 3) is crucial during development.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to do the job.
Agile value 1 emphasizes the need for talented team members. This principle pushes this notion further, asserting that the right team will accomplish its goals without micromanagement. Project managers must give their teams the support they need to engage with their work.
6. A face-to-face conversation is the most efficient and effective method of conveying information to and within a development team.
We’ll admit this principle is a product of its time. The early 2000s were not equipped for remote work the way we are today, and now it’s much easier to practice Agile with a hybrid or remote team. However, this principle highlights the need for regular team communication, and we fully agree.
7. Working software is the primary measure of progress.
In many cases, your client doesn’t care about your team’s metrics or goals—they just want the product in their hands. The Agile approach keeps this in mind and prioritizes deliverables, which help satisfy your clients.
8. Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Meeting regular delivery goals requires consistency. This is why Agile asks teams to set an achievable, repeatable timeline for their work.
9. Continuous attention to technical excellence and good design enhances agility.
While much of Agile for business focuses on project development and management, it is also important to remember that the work should exhibit excellence, whether you’re designing software or doing any other project.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
Agile’s iterative approach allows developers to focus on meeting their primary goals and delivering the work on time. Small changes or updates can always be a part of the next iteration.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
Similar to principle 5, this principle asserts that teams are most effective when they take ownership of a project. Allowing teams to self-organize gives them power over the project, leading to more diligent work.
12. The team regularly reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This final principle reflects how vital continuous improvement is in Agile. Not only are Agile teams constantly improving their deliverables with each iteration, but they’re constantly learning how to improve themselves.
Traditional project management vs. agile project management
There are many positive aspects of Agile project management. The focus on customer satisfaction, communication, and regular improvement makes Agile very attractive to project managers — but how does it compare to the old Waterfall method? Let’s compare:
- Start with a specific target
- Rigid planning process
- One development cycle
- Test once development is complete
- Minimal client involvement
- Start with an overall vision
- Adaptable planning and evolution
- Multiple development cycles
- Test throughout the process
- Consistent client involvement
There are some cases in which Waterfall is the ideal project management approach. Small, simple projects are better suited to Waterfall, as well as projects from clients who don’t want to offer feedback. But if your project is more extensive, complex, and has changing priorities throughout development, Agile is the best way to manage things.
Benefits of agile project management
Agile management yields several benefits, which is why it’s become so popular in the IT industry and beyond. The top benefits of agile project management include more adaptability, greater customer satisfaction, and more efficient teams.
When you have the freedom to adapt your project as you go, you can more closely align with your customer’s priorities and deliver products that meet their needs.
Greater customer satisfaction
Agile not only helps you align with your client’s needs, but it streamlines the time between planning and delivery. This makes your client much happier and improves your business’s reputation.
More efficient teams
Agile’s focus on people over processes and continuous improvement makes team development a priority. This method helps your team become stronger and more efficient with every deliverable.
The six phases of agile project management
Like most project management methods, Agile starts with planning. However, this phase doesn’t require an overly-detailed roadmap through the project. It only needs three things:
- A project vision statement that outlines the scope, milestones, and deliverables.
- A rough timeline for each deliverable.
- A backlog of items you want to change in later iterations.
The initial design phase in software development is when developers create a user interface and build the software’s architecture. For other projects, this is the period in which project managers build their teams, let them organize, and begin delegating tasks.
This is the meat of Agile project management: the period of development and adaptation. During this time, managers should communicate regularly with the client and adjust priorities or change the roadmap and timelines as necessary.
The testing phase is when the client gets their first deliverables. This is a time to ensure that the team is on the right track and meeting the customer’s needs. If they are, they can move on to the following deliverables. If not, it’s time to adapt and redo steps three and four.
To your customer, this is the final step of your project development. Your team should have met all their requirements and submitted their deliverables, leaving your client happy with the outcome.
As we discussed in Agile principle 12, there is always room to review and improve. Therefore, the final step for an agile team is to debrief after completing a project and find ways to become more efficient or successful with the next job.
Types of agile methodologies
Agile is an umbrella term for several more specific management approaches. Each has its benefits and drawbacks, but Scrum, Kanban, and Lean are the most popular.
Scrum is a framework designed specifically for keeping complex product development and project management on track. Primarily used for agile software development, but applicable to any activity requiring teamwork, the scrum framework guides cross-functional teams to communicate, hold each other accountable, and iterate to deliver results.
Like a Rugby team (where scrum gets its name) trying to take possession of the ball, scrum encourages teams to work together and learn from their experiences to improve. Essentially, it is a set of tools, resources, and well-defined roles that help teams manage their work.
The Agile scrum framework is structured around roles, events, and artifacts.
- Product owner
- Scrum master
- Scrum development team members
- Product backlog
- Sprint backlog
As you can see, the Agile scrum process is very simple. You can think of the Scrum Master as the glue that holds the team together. A Scrum Master’s main job is to nurture an environment where teams can develop micro-alignment within Agile.
The Product Owner looks over the Product backlog and orders the work to be done. The Scrum Development Team then turns part of that work into an Increment of value (or goal) during a Sprint planning session (e.g., in two weeks, we will complete the build out of the onboarding application).
The scrum team and its stakeholders then analyze the results and make any adjustments for the next Sprint. And they iterate the process until the project is complete.
Another popular Agile framework is Kanban. Similar to Scrum, Kanban is a model designed to help teams work more effectively together. Whereas short, structured work timeframes (i.e., Sprints) and well-defined roles are the heart and soul of Scrum, Kanban offers a more fluid and continuous workflow.
Kanban is all about helping teams visualize their work and maximizing efficiency. Kanban teams aim to reduce the time it takes to complete a project and they do this by constantly considering how to improve their flow of work. Using Kanban boards, teams create their own columns to organize how projects flow through the necessary stages.
A marketing team might, for example, take a blog article from Backlog, to Prioritized, to Outlines Ready, to Drafting, to Editing, to Designing, to Published. Looking at their Kanban board, the team can then determine that it takes one week to create a piece of content and determine where they can eliminate bottlenecks to become more efficient.
Related: Scrum vs Kanban Board: Which to use?
As the name suggests, Lean development aims to be as lean as possible throughout the project. They eliminate all non-essential activities, shorten the development life cycle, and focus on big-picture changes rather than the details.
Types of ceremonies and meetings in agile
Meetings or “Ceremonies” are the key to making your Agile machine run smoothly. While we discuss many of the Agile ceremonies below in the context of Scrum, they can be applied to other forms of Agile such as Kanban or Lean.
Let’s take a look at some of the most crucial Agile ceremonies and how they empower teams to innovate with Agile principles.
Sprint planning happens at the beginning of each Sprint. The purpose is to set up the team for success. Before the meeting, the Product Owner will look at the Product backlog and come up with a list of priorities to bring to the development team. The team discusses each item together and collectively determines how much effort is involved in each one. From here, the team creates a forecast outlining what work they expect to complete during the Sprint. This outline becomes the Sprint backlog.
Daily scrum (aka daily standup)
These short meetings (no more than 15 minutes) are designed to quickly brief everyone on the team’s progress.
This high-level meeting should be informative, but without pulling everyone into the weeds. Typically, each team member answers three questions:
- What did I complete yesterday?
- What will I work on today?
- Am I feeling stuck on anything?
A simple, straightforward agenda, along with the built-in accountability, ensures success for daily stand-ups.
Learn more: Expert tips to make daily stand-ups more effective
Sprint Reviews happen at the end of a Sprint or when a team hits an important milestone. These Agile ceremonies are a time for teams to showcase their work, celebrate wins, and get feedback from stakeholders. It can help to have some simple guidelines for work to be ready to be shared during Sprint Review. To share your work, it must be complete and up to quality standards, for instance.
Because Agile is all about getting rapid feedback and using that feedback to make the product or development process better, retrospectives are another significant element. Sprint Retrospectives help teams understand what went well and what could be improved.
However, Product Owners should emphasize that these Agile ceremonies are not simply a time to complain or air grievances. Teams need retrospectives to figure out how to build on what’s working and find creative solutions for what’s not working. Remember, continuous improvement drives development within agile teams. The most successful teams take their retrospectives seriously.
Scaling agile: A look at the Scaled Agile Framework (SAFe)
Now, you may be thinking all of this sounds great for small teams. When you consider implementing Agile principles involving only a product owner, a Scrum leader and a small development team, you can see how a tight-knit team like this could move quickly, make adjustments, and course correct. But you might be wondering how it would work with multiple teams across a large organization.
No doubt, real challenges arise with scaled Agile. The good news is that there’s a framework for this too. The scaled Agile framework (aka SAFe® Agile) is a set of guidelines and workflow patterns for implementing Agile at scale.
SAFe® encourages leaders to focus on a set of five core values and how best to promote these values across the organization:
- Built-in quality
- Program execution
The principles within the SAFe framework will improve the organization as a whole by replacing traditional “waterfall” thinking with design thinking. Cooperation across functional and organizational boundaries will improve as well as efficiency and productivity.
Now if the idea of bringing together multiple agile teams is intimidating, PI Planning is here to help. PI Planning stands for Program Increment Planning. These sessions are events scheduled at regular intervals throughout the year where cross-functional groups of 50-125 people, called an Agile Release Train (ART) working on the same project meet to talk about the bigger picture.
Here is a brief description of what these sessions look like:
- Teams meet face-to-face for two full days every 8–12 weeks.
- Teams plan and define the work that needs to be done.
- Teams review backlogs, discuss what features will add value, and update the product roadmap.
- Teams identify risks and dependencies.
Learn more: The complete PI planning guide for hybrid and remote teams
Unlock the power of agile with your teams
Whichever agile approach you use, remember that the goal is the same: to provide the maximum value to your customers. The best thing about agile is that it’s flexible enough to implement in any team environment. If you aren’t yet using agile to unite your cross-functional teams, get started and witness the transformation.
Mural makes it possible for enterprises to implement and scale agile methodologies in a visual, collaborative way. Sign up for Mural today, free forever.
Looking for a framework to start with common agile ceremonies? Mural's Agile templates help you easily run retrospectives, sprint reviews, and more!