Have you ever wondered how some companies can release apps or new features on a continuous basis? For many, the answer is agile project management.
Keeping an efficient rate of deployment isn’t magic (most of the time). First, it definitely depends on the quality of the team. But even more so on the quality of the methodology used. And when it comes to software development, most would agree that agile is the way to go. For many, it’s the obvious choice for maximum efficiency and customer-satisfaction.
Agile is a project management methodology. It’s characterized by dividing tasks into short intervals of work, and maintaining high flexibility. That means the frequent reassessment and adaptation of plans.
In this guide, we’ll go through the basics of agile project management. This is by no means a definitive guide. But it should help you get a foundational understanding of the concepts. And if you want to move on from there, we’ll include some resources that can help you advance further.
If you want to jump ahead, start here:
What is agile?
As a methodology, Agile goes back several decades. But fundamentally, the modern origins of agile started in 2001. It came with the publication of the Agile Manifesto.
The manifesto, published by 17 software developers, outlines lightweight development methods. It contains 4 key values and 12 principles. These guide an iterative and people-centric approach to software development.
The 4 key values 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
Furthermore, the 12 key principles are:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity — the art of maximizing the amount of work not done — is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Why use agile project management?
Agile can be a very efficient way of increasing your organization’s productivity. On top of that, agile project management is highly flexible. It allows for the opportunity to further tailor your process and product to the customer. Additionally, it helps limit the impact of negative decisions.
If you’re constantly iterating, the mistakes are often small and the cost is thus contained. Let’s take traditional waterfall methodology as a contrasting example. You work months on a project to finally release it to the public. Instead of a roar: dead-silence. Instead of iterating and testing your prototype with your target audience, you’ve now spent months of work on something that clearly doesn’t excite your users.
That’s of course a bigger blow to your organization, as opposed to releasing a functional minimum viable product. That way you gradually iterate until you have something that makes the end-users go “wow!”.
If you’re looking for more hard facts around the efficiency of agile, let’s look to Dr. David F Rico. In 2009, he compared agile with traditional methods of project management. Rico analyzed 23 agile processes and compared them to 7,500 traditional projects.
His found that agile project management was:
- 41% better in terms of overall business value
- 83% faster time-to-market speeds
- 50% had higher quality
- 50% were less costly
- 83% were more productive
Popular ways of using agile
While agile is a set of values and principles, these can be applied in several different ways. Two of the most common ways of adopting agile are Scrum and Kanban.
Key agile skills
As an agile project manager, there are a few skills you should possess. In general, you should:
- Avoid micromanaging people: Agile welcomes self-organizing teams. That means trusting the expertise of your team-members and allowing them to do their best work in a way that suits them.
- Be decisive: Prioritization is a key feature of agile. When managing agile projects, you should be prepared to make quick decisions on product matters. Stalling prevents the process moving forward.
- Be able to focus: In line with the above, you need to be able to focus on what’s important. Agile avoids unnecessary work, and consequently you need to keep your eyes on the ball and not get lost in inessential details.
- Have strong coaching skills: You have to support your team. Both in terms of actually following the process, but also coaching them through issues if needed.
- Be flexible: Agile isn’t waterfall. If new data comes up that that suggests you should change, you must be willing to change. And that might mean setting your ego aside, if the data contradicts your intuition.
Industries using agile
Agile was designed for the software industry and it’s highly applicable there. However, it’s a methodology that is very versatile. Being a strongly collaborative methodology, it lends itself to several different industries. Have a look at the data below from CIO:
Pros and cons
Stronger stakeholder engagement: Agile involves several stakeholders in the process via the Product Owner. That means everyone who should have a say gets their say. This can be internal, as well as external, stakeholders — which ideally leads to a better product.
Improved transparency: With a clear scope of work, everyone should feel up-to-date on what is going to be released and when. Transparency is key as organizations grow, and agile can be a good way to improve that.
Increased predictability: At the end of each sprint or each cycle, there should be a release. This makes agile somewhat predictable, both in terms of delivery and in terms of cost. But this isn’t always the case, as we will discuss below.
Increased flexibility: The ability to adapt to change can definitely improve end-results. An iterative approach where you take in new data on a regular basis reduces the risk costly mistakes and increases the chances of releasing a desired product.
Stronger user and business focus: Agile focuses strongly on the value added to the business as well as the user. Sometimes, this might get lost in the process, but agile brings it back into focus.
Potentially lower predictability: “Wait, didn’t you just say that agile increases predictability?” Well, yes. But sometimes, especially in the beginning of a development life cycle, it can be very difficult for the developers to estimate the time it takes to release a product. These unknowns can cause frustration and lead to poor decisions.
Potential to lose focus: Agile is easy to get started. Since it can start off with fairly little data, it assumes that more will be accrued in the process. As such, if any stakeholder communication isn’t clear, a developer might misunderstand the focus or unintentionally lead the project astray. Furthermore, the scope can gradually increase until the workload become unrealistic and deadlines are no longer met.
Needs buy-in from stakeholders: You can’t do agile alone. You need the buy-in from all stakeholders in the process in order to make agile fully work. If the team isn’t comfortable with the project management methodology, you can count on bottlenecks.
Communication-intensive: Face-to-face communication is preferred for agile. And since the process is prone to change, this means communication must happen regularly. For some teams, having such a communication-intensive method can be hampering.
Lack of documentation: Documentation can be hassle. But it can also be a huge help. Especially when it comes to onboarding new members or sorting out issues. With limited documentation, there’s a potential for issues.
Is agile right for your organization?
You need to determine a few things before you determine if agile is right for your organization. Below are a few basic aspects you should consider.
Does your company culture support agile?
First, try to gauge whether your company culture would support agile project management. Is your team flexible? Can you live with uncertainty? Can you cope with communication-intensive methodologies? If so, ensure all stakeholders are onboard. This is the first main step.
Does agile apply to your project(s) and industry?
Agile works best when a concrete product is being produced. You need something measurable and concrete. This is why agile lends itself well to software development.
However, it can also work for such departments like marketing, where you can produce collateral or measure the impact of certain campaigns. Determine whether you’re creating a concrete product and whether it’s measurable. If it’s more abstract, agile might not be the best way to go.
Can you start a project and not know where it will end up?
Agile can be both predictable and unpredictable, as discussed above. But two of the key principles of agile project management are flexibility and customer focus. That means that the product may change along the course of the project. Are you comfortable starting out with the idea of an apple and ending up with an orange?
How risk-averse are you?
Agile works to minimize risk. However, due to its flexibility, the risks come in different shapes. Continuously deploying means learning from your mistakes. You might take on more, but smaller, risks, than if you approached a project from a traditional method.
If you’re a startup that needs to move fast and is comfortable with breaking things, no problem. But if you have a structure that frowns on failure, you might want to opt for the more traditional route.
Is your team flexible enough?
Maybe you are comfortable with making decisions on the fly, but is your team? Are people willing to set aside their own preconceived notions if new data appears that changes the direction? Agile is customer-centric, and that means that the customer is king. All stakeholders should be onboard with this. That includes a willingness to change accordingly if the situation demands it.
Roles in agile project management
Agile has different roles depending on the framework. But below are 3 general roles that can be used to assemble most agile teams.
The Product Owner is the visionary and captain of the agile team. The PO steers the course for the product and has final word on features and changes. He or she also defines work to be done, and sets the objectives as well as expectations. In summary, the Product Owner is responsible for maximizing the value of the product. This also includes creating the backlog and reviewing the deliverables.
The Team Lead is responsible for the welfare of the team. The Team Lead ensures that the processes are followed and deadlines respected. Furthermore, the Team Lead offers support and guidance offered if needed.
He or she should be comfortable with measuring quantitative and qualitative results, as well as maintaining daily tasks, reducing friction, and calling meetings. Additionally, the TL holds the Product Owner and Team Members accountable.
The team member focuses on the product. The team members make up the majority of the team. As such, each team member brings their unique skill based on the team’s needs. As agile encourages autonomy, it calls for proactive team members.
Team members take on assignments and consult the Team Lead when necessary. Team members also support each other, ultimately forming a cohesive group.
There are many methodologies for applying agile project management. With that said, as with roles, there are a few general aspects worth keeping in mind.
The first concept you should be familiar with is the daily standup. As the name suggests, it’s a daily meeting where you explain what was done yesterday, what’s to be done today, and voice any challenges. These meetings are typically done standing up to not take up too much time. Generally, these meetings are time-boxed to 15 minutes.
A sprint is a work-cycle of tasks, and this is one of the key elements of agile. Work is divided into segments, and a sprint is a time-box where products are planned, developed, reviewed, and released. They usually involve small parts of bigger projects that are divided into parts and features to be be released.
Agile requires quality control. This means both quality control of the product and quality assurance of the process. Both have to be conducted to ensure that the work is being delivered at a consistent quality. Reviews also have to happen before tasks are marked as complete, as well as after the sprint.
Hurdles to adoption
The company culture can be the single biggest hurdle to adopting agile. You need buy-in from multiple departments, and they all need to be willing to work together. Again, flexibility here is key. If you have a rigid company culture, it’s a sure-fire way to put sticks in the wheels of the process.
Not great organizational fit
Why is your organization adopting agile? To reap the benefits of agile project management, you have to ensure that the methodology is actually applicable. Maybe agile would hamper more than help. If you don’t have concrete products, agile can become too abstract to adopt.
Consequently, it can make the entire organization slow down instead of speed up. Agile is adaptable, but discuss with your stakeholders before you move forward. And speaking of which…
Perhaps your company culture and organization are a good fit for agile. But then there are individual stakeholders that are less flexible. Again, having all stakeholders onboard is crucial. Some might be less flexible, but as long as they buy in to the general premise, it might still work.
Adopting agile via Scrum
Scrum is a framework for adopting agile methodology. It’s one of the most popular agile methods — especially in software development. This is because Scrum is simple, yet productive. The framework was created by Ken Schwaber and Jeff Sutherland, and is is outlined in the Scrum Guide — a concise document of 19 pages.
Scrum focuses on complex problems, and as such it encourages flexibility in the framework. That way, the right process to emerge for the right problem.
Basics of Scrum
The Scrum team consists of 3 roles, as common to agile project management:
The Scrum Master: The Scrum Master is responsible for supporting the the framework. (S)he assists the the team and helps them understand the theory and process of Scrum. Furthermore, the Scrum Master helps manage interactions with outside stakeholders, and aims to maximize their value.
The Product Owner: The Product Owner’s job is to maximize the value of the final product. What this looks like might vary greatly among Scrum teams. One thing that remains, however, is that the Product Owner is solely responsible for managing the product backlog. This includes expressing requirements, ordering tasks, and ensuring clear specifications.
The Development Team: The Development Team consists of those that do the work. Ideally, the Development Team delivers a feature at the end of each Sprint. Development Teams are self-organizing, which means that not even the Scrum Master tells the team how to tackle the product backlog. They are also cross-functional and without titles.
As with agile project management in general, Scrum operates via Sprints. The Sprint is a time-box of one month or less. During this time, tasks are managed and a potentially releaseable product or feature is created.The scope of the sprint may be re-negotiated between the Product Owner and Development team. But no changes can be made that would endanger the Sprint Goal.
Sprints consist of 6 aspects:
- Sprint Planning
- Daily Scrums
- Development work
- Sprint Review
- Sprint Retrospective
Planning a sprint is a collaborative effort that involves the entire Scrum Team. The Sprint Planning is time-boxed to a maximum of eight hours. The Scrum Master is responsible for the event taking place.
Daily Scrum is a daily standup-meeting that is time-boxed for 15 minutes. Here the Development Team plans the coming 24 hours. The structure of the meeting is flexible and set by the team. You can use the similar structure as above, such as:
- What did I do yesterday?
- What can I do today to help the Sprint Goal?
- Are there any obstacles?
The Sprint Review happens at the end of the Sprint. The purpose of the Sprint Review is to inspect the Sprint and adapt the Product Backlog. The Sprint Review is informal, and a time for feedback. The end result is a revised Product Backlog with items ready for the next sprint.
The final event is the Sprint Retrospective. It is an opportunity for the Scrum Team to to plan improvements for the coming sprint. Here the last Sprint is reviewed. That includes:
- What major items went well
- What potential improvements there are
- A plan for the improvements on the Scrum Team’s work in general.
The Product Backlog is list of everything known to be needed in the actual product. This list is the source of all requirements for the product, and the Product Owner is responsible for maintaining it. This list is an evolving document, and it changes as the product and environment changes. As such, it’s an ongoing process between the Product Owner and the Development Team.
The Sprint Backlog contains items from the Product Backlog selected for the Sprint. It is a plan that emerges during the Sprint, and will thus be modified during it. This means that estimated work remaining is updated, and changes can only be made by the Development Team during the Sprint.
The Increment is the sum of all the items from the Product Backlog that are completed during the Sprint.
Scrum is a fairly well defined framework. The above is simply a condensed version of what Scrum is, and if you’re interested — check out the Scrum Guide. As with other agile methods, Scrum is adaptable, even though it has a defined outline. Consequently, you can likely adapt it to your organization’s needs to increase the productivity of your team.
Adopting agile via Kanban
Kanban is another popular agile tool used by teams all over the world. Kanban boards use cards and columns to manage the work. It’s a very simple process that lacks the comprehensiveness of Scrum. However, this doesn’t have to be a bad thing. Kanban can be quite efficient.
A major difference from Scrum, is that Kanban does not impose organizational changes. Instead, you have to organize this yourself as you see fit, making Kanban a far more flexible system. But it can also be a system that requires more of its users.
These are the basics of Kanban:
- Kanban board: This is the board that encapsulates the entire workspace.
- Kanban list: This list contains a set of cards, for example tasks in a to-do-list.
- Kanban card: These cards make up individual items related to the board. For example individual tasks.
And typically, the Kanban-board consists of 3 lists:
- To-do: Tasks to be done.
- Doing: Work in progress.
- Done: Completed tasks.
Finally, Kanban centers around 3 basic principles:
1. Visualize your work: By placing the tasks on a board, you can easily get an overview of the entire project.
2. Limit the work-in-progress: Kanban doesn’t lend itself as easily to sprints but rather works in a continuous flow. Don’t overload your “Doing”-column. Keep it trimmed and realistic, to keep solid track of what you need to accomplish.This means that you might want to decide how many cards can be at the WIP-column at one time, which helps you set the limits for the entire workflow.
Starting out, you might want to have the WIP-column contain 1–1.5× the number of people working in that stage. A key aspect is to eliminate bottlenecks and look at the wait-stages.
The goal is to see how long tasks remain in these handover-phases. Reducing the time spent here will also greatly help reduce the overall time of each cycle. For Kanban, the cycle time is a crucial metric. While Scrum limits the amount of time allowed for a particular amount of work via Sprints, Kanban limits the amount of work that is allowed in the to-do-list.
3. Monitor the flow: Ensure the board is in constant motion. Prioritize and organize the backlog and move tasks over accordingly.
Scrum vs. Kanban
Which is right for your organization? In a sense, it can be like comparing apples to oranges. But here’s a basic breakdown that can help you decide which — if any — makes sense for you.
If you require a more structured approach, Scrum is the way to go. While still adaptably, it has a more rigid approach than Kanban. But if you prefer to organize your work more freely, Kanban could be the best choice for you.
The JIRA Agile tool is specifically designed for agile project management. It interacts well with the other tools from Atlassian. As such, it’s a suitable choice for those who are already invested in the ecosystem. These include Stash or Bitbucket — Atlassian’s Git-hosting tools, as well as Bamboo for continuous integration.
In JIRA, you can create a list of tasks with a tool called Confluence. Here you can also maintain a backlog and efficiently plan sprints. If you prefer to work using Kanban, that availability exists too. The Kanban board is interactive and easy to update as the work progresses. As for communication, it happens via HipChat. It connects discussions to the tasks themselves, making it easy to keep track.
With its clear format and easy-to-manage features, Trello is a great candidate for your agile project management tool. This tool works like the traditional whiteboard, where Product Owners can create lists in accordance with the agile workflow. Apart from that, Trello enables users to share access and input details on each task in the form of comments, checklists, due dates and attachments.
Active Collab has proven to be a shining star in project management through its time tracking and billing features. The system is able to calculate the time you spend working using a timer app, then generate a time tracking report for your project. Similar to other tools, users of Active Collab can create their tasks and monitor them from conception to completion via comments, checklists, timelines, and more.
An all-in-one calendar helps the team to stay focus on their roles and deadlines. Another useful feature of Active Collab is its collaborative writing tool. Team members can work together to create documentations for the project, which is important for more agile collaboration. Implementing Active Collab is also simple: You can either host it locally or use through a cloud service.
Pivotal Tracker is a project of Pivotal Labs. It’s optimized for agile development. Similar to Trello, the project page is consist of lists of tasks, often expressed as stories that users can interact with. Team members can prioritize tasks that are important and track down the number of tasks have been finished during the day.
The tool includes a whiteboard, where team members can have discussions; project monitor, to show the status of your work; and Sprout, a configuration tool.
If you’re looking to dig deeper into agile methodologies, a certification might be what you’re after.
As stated in the beginning, this is by no means a definitive guide for agile project management. However, it is something that should help you get started. And since agile project management is a flexible methodology, the goals is not to impose strict guidelines.
Agile project management is first and foremost based on the original values and principles. From those, you can derive a method that works for you and your organization.
And that is in a sense why agile project management has become so popular. Not only is it a very efficient method for delivering products that end-users like. It’s also incredibly adaptable. As such, it’s a versatile method for a wide variety of organizations and industries.
If you want to learn more, dig into the Scrum Guide and immerse yourself in the process. Should you then be even more thirsty for knowledge, the best way might be to get yourself an official certification from one of the accrediting bodies above.