Webinar
The Agile methodology and principles are now applied in a wide variety of industries beyond software development. The simple reason is that its primary benefits are almost universally applicable.
So—what are the main benefits of adopting Agile project management? Read on to find out!
Agile is built on continuous valuable delivery. Agile teams can incorporate customer feedback in real-time and rapidly adapt to evolving needs and requirements. In 2022, there are two very real risks for traditionally-led projects:
The ability of Agile teams to react and pivot to continuous feedback (thanks to clear and collaborative relationships) is paramount in reducing risk.
ADDITIONAL LINKS
Once again, this benefit stems from the embedded collaborative nature of Agile. Your team continuously delivers valuable aspects of the project, which allows the customer to provide continuous feedback and commentary.
This feedback allows your team to adapt its user stories (or add new ones) to more effectively capture customer expectations. Over the course of a project, these little improvements accumulate until the final deliverable matches the customer’s expectations far more closely than would have been possible using traditional methods.
Remember the anecdote we shared in chapter one of this guide, about how Alistair Cockburn observed the engineers at IBM discussing their work and collaborating, and how this only happened in the unconventional but most performant teams?
That transparency remains at the core of all successful Agile projects to this day. This allows you to identify issues or bottlenecks in the team’s workflow…
Transparency can be heightened by using visual tools like Kanban boards, which is not possible using traditional project management.
The continuous delivery of value is integral to Agile. But on a psychological level, having a work environment where you are constantly succeeding in completing tasks is wonderful for morale—especially when this progress is reiterated through daily stand ups or visually on Kanban boards.
Over time, the need for continuous improvement becomes something of a collective mindset. This creates a positive feedback loop where employees feel empowered by their own success, but also driven by their collective ambition to improve.
Despite being one of the foremost benefits of the Agile system, the effect on customer relationships is rarely mentioned when discussing the methodology’s benefits. Agile teams work with their customers constantly—taking on feedback, discussing progress, exploring new options.
This solid relationship makes the entire project run more smoothly, especially when problems or roadblocks arise. The customer has established faith in the team (from seeing regular, valuable output) and it’s easier to speak candidly when you have a robust, mutually-respectful relationship.
Open communication, customer involvement, cross-functional collaboration—Agile teams are a melting pot of ideas and perspectives.
Rather than siloing issues, they can be aired before the entire team (or multiple teams) which allows you to generate more ideas and stimulate more creativity. This is true for both bigger picture ideas and user stories, as well as technical execution by your developers, engineers, or designers.
Other than the fact both methods exist, there are very few similarities between traditional and Agile project management. Let’s look at four key differences between the Agile and Waterfall methodologies in the context of project management.
Probably the most famous feature of the Agile methodology is its iterative nature. Every user story represents a complete piece of functionality; something the customer could actually use. Sequential changes (favored by traditional approaches) build on one another over time. There is no usable “product” until every stage of the project has been executed.
Traditional teams are far more linear, while Agile teams can work concurrently on any part of a project.
There is a fundamental psychological difference between Agile and traditional project management when it comes to what is being delivered. In both cases, a product is created. However, in traditional projects it’s about delivering exactly what was agreed with the client.
In Agile, it’s about delivering the most valuable product possible. That’s why there’s constant collaboration with the customer and why teams work in iterations—this gives them the best chance to affirm and reaffirm exactly what the customer wants, and to build exactly that.
Traditionally, customers are involved at both ends of a project. They’re present for defining the product requirements and expectations, and they review the finished result. While this is simpler for the customer, it increases the likelihood of receiving a product (or at least features or design elements) which are unsatisfactory.
Agile demands much more from the customer in the form of regular collaboration and feedback throughout the project. Customers need to be available and willing to participate, or one of the key strengths of Agile is wasted. However, the payoff for this commitment is a better-functioning product that meets their (potentially evolving) requirements as well as possible.
When discrete features are built during every Agile iteration, it’s straightforward for the client to see the product take shape and request changes to scope. What’s done is done, but the rest of the project is almost entirely flexible, as long as the team has the required expertise. Teams can quite simply adapt more quickly and effectively in Agile projects.
The traditional approach agrees to a full spec at the project outset and, more often than not, the customer doesn’t see any progress until the project is concluded.
One of the keys to Agile project management is constantly delivering value. In other words, keeping the team’s work aligned with the stakeholders’ expectations. A key document for maintaining this alignment is the project charter.
This is a simple outline of the project, its objectives and its constraints. It’s a useful reference point throughout the lifecycle of a project to ensure that all of the team’s work is well-directed.
What’s included in a project charter?
Product vision—The reasons the project exists.
Objectives—How the vision will be achieved.
Stakeholders—A list of the primary stakeholders in the project and their priorities.
Success criteria—How the success of the project will be judged.
Key deliverables—The primary outcomes desired by the customer/stakeholders.
Team members—The names, roles and responsibilities of all team members.
Timeline—Expected completion date for the project.
Assumptions and risks—Threats to project success and core assumptions which could affect the success of the project.
Budget—A general estimate of project costs.
Tips for creating a winning project charter
Here are 4 simple ways to create a project charter that’s both accurate and reliable.
Take input from team members
We already know that many aspects of the Agile methodology are collaborative in nature. Well it’s exactly the same when writing your project charter: input from your team members is vital! There are no medals for struggling through this document on your own.
Your team members will contribute a wide variety of ideas that, as an individual, you’re unlikely to discover on your own. Brainstorming sessions are an excellent way to unlock these perspectives. These will most likely relate to success criteria, deliverables, assumptions, risks or timeline.
Use a template
While the project charter is important, it shouldn’t require too much time and it’s absolutely not necessary to reinvent the wheel. There are a thousand templates out there and none of them are wrong. Adapt the template to suit your company or team, and then this “template 2.0” can be reused for any subsequent projects within the company.
A template also guarantees that you won’t omit any important information.
Don’t force optimism
The project charter is not meant to be boastful or impressive—it’s meant to be realistic. Adding probable risks and major assumptions is crucial to making your team as prepared as possible for delivering the project.
Be succinct
Make your project charter a waffle-free zone. It should contain all the core information and nothing more. The charter will be displayed prominently in the office (if your team still has one!) so it should be easy to consume in a short space of time.
Metrics can be a controversial topic. While almost everyone agrees that data can provide useful insights, it must be very carefully managed and assessed to ensure the team doesn’t race down rabbit holes in the wrong direction.
As you might expect, it’s not usually effective to take traditional project success metrics and sellotape them onto Agile projects. Just like the methodology itself has evolved, so have the most appropriate metrics for measuring results. And as with traditional metrics, there are many of them to choose from.
The following are our top picks for metrics which can be useful in the vast majority of Agile projects and which are fairly easy to track and analyze.
#1 Throughput
Throughput is basically the “Agile” word for productivity. It measures the average number of discreet work items (tasks) completed per unit of time—often each Agile iteration or sprint.
The value of throughput is that it gives the clearest possible indication how successful your team is at processing tasks. Of course, this presupposes that the work is completed to a sufficiently high standard.
#2 Lead and cycle time
These metrics essentially describe how long it takes for a requested item of work to be completed, from both the customer perspective (lead time) and team perspective (cycle time).
The time between you agreeing to a piece of work (e.g. a specific software feature or design element) and that work being delivered is the lead time. It’s an easy measure of how long the customer waits for delivery. Cycle time is always shorter, since it’s the time between the team beginning work on this task and its completion.
Cycle time and throughput are commonly combined to create a best estimate of “productivity” for the team or an individual.
#3 Work in Progress
This is a brilliantly simple solution for reducing cycle time and preventing multitasking. Agile teams keep careful track of the number of work items currently “in progress”—and in fact, they deliberately limit this number.
It is against the Agile philosophy for an individual to work on numerous conflicting tasks simultaneously. By limiting work in progress (WIP) team members will complete tasks rather than just improving on them, which is integral to delivering constant value.
#4 Aging work in progress
Also known as work item age, this is an important metric for unfinished tasks. This metric is most useful for identifying bottlenecks and comparing current and past performance. To fully appreciate work item age, work items can be plotted on an aging work in progress chart.
#5 Blocked time
Work items will hit roadblocks due to some crucial dependency: input needed from external workers, sign off from customers, etc. While these blockers are in place, the task cannot be advanced or completed.
In these cases, tasks should be marked “blocked”. Not only does this draw attention to the task (meaning others are more likely to pitch in and help, where possible) but repeated or accumulated blocks may indicate a flaw in the project process.
#6 Burndowns
For every Agile iteration (or Scrum sprint) there is a number of user stories the team is anticipating completing. The burndown chart describes how well your team manages to deliver those user stories. With the total amount of work on the y-axis and time on the x-axis, we would expect to see a steady, linear decline from 100% work remaining to 0% over the duration of the iteration.
Of course, this would be a perfect result and it’s rarely so clean. But it still works as a valuable indicator of how successfully your team manages its workload.
Other metrics
As with any type of project or methodology, there are many other metrics which can be applied to the Agile framework. These include velocity, control charts, cumulative flow diagrams, escaped defects, net promoter score and failed deployments.
Teams should feel free to use any metrics which they feel will help improve their performance. However, it’s important to remember that while avoiding metrics will leave you flying blind, too many will obscure your vision!
First and foremost, reporting in the Agile domain is about team performance. While there is always a place for individual performance review, the majority of analysis should be on how well the team has met the needs of the customer.
Each of the metrics we’ve suggested above can easily be visualized as charts. These will provide a wide view of the team’s success as well helping uncover potential bottlenecks, process improvements and even assessing how much value was generated for the customer.
We’d be happy to provide a bespoke 1:1 demo on how Cloud Coach can benefit for your business.
