Implementing Agile Project Management Framework (and Scrum)
How is Microsoft able to release brand new versions of every single one of their projects every three weeks? Or why can Google update their desktop and mobile applications every week or two while other companies take years?
Stories like these are why the cult of Agile project management has so many devout followers.
Rather than traditional software development like the Waterfall method, where you might spend several months or years on a project without showing it to the user, Agile is all about moving fast, releasing often, and reacting to the real needs of your users.
Agile development takes the emphasis off you and puts it on your customers. It’s a small change, but one that can have huge results.
According to research from the Project Management Institute, agile organisations finished projects on time 65% of the time, versus 40% for non-agile companies. They also completed 75% of their goals, versus 56% for non-agile and even grew their revenue 37% faster!
Faster development. More releases. More revenue. Why wouldn’t you want to bring Agile project management into your own team? Well, like any tool or method, Agile has its own quirks. And while it’s used by everyone from Google to Microsoft to Spotify, Apple, and Facebook, you need to know what’s beneath the surface before diving in headfirst.
This guide will take you from the origins of Agile, right through to its core values and principles, how to know if Agile is right for your organization, and then give you a 7-step plan for implementing Agile project management into your own team.
Let’s get into it:
What exactly is Agile?
At its core, Agile isn’t so much a methodology as a philosophy. It’s a blanket term for an approach to project management that prioritizes incremental, feedback-driven changes into software development. (We’ll get into the methodologies and how to actually use Agile later on).
To understand why Agile works so well, we need to do a bit of a history lesson. Until the last few decades, the Waterfall method was the prevailing way software (and most products) were developed. This meant spending a huge amount of time and effort upfront gathering resources and planning with a lot of key decisions based purely on assumption.
But by the 70s, it was clear this method wasn’t working. For ‘modern’ developers, the Waterfall method felt constricting, regulated, and too slow moving. And when the hacker generation made its way into the workforce in the late 90s, this feeling was only amplified. The waterfall method relies on predictability and sequence, but what these software developers needed was a more flexible project management method that made room for errors, bugs, setbacks, and feedback from real users.
So, in 2001, a group of 17 individuals came together to create an “alternative to documentation driven, heavyweight software development processes.” After a few days, they emerged with a document outlining their beliefs on how software projects should be run. They called it the Agile Manifesto.
As part of their Manifesto, the creators of Agile defined 4 key values that all Agile projects should adhere to:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Now, they didn’t mean you should throw out your time-honed tools, documentation, and plans. But rather that while those things are valuable to any development effort, the items on the left should be your core focus: people, prototypes, collaboration, and iteration. To present their beliefs in a more actionable form, they also released a list of 12 guiding principles for anyone running an Agile project:
- The highest priority is to satisfy the customer through early and continuous delivery
- Welcome changing requirements, even late in development
- Deliver working software frequently, from a couple of weeks to a couple of months
- Stakeholders and developers must collaborate on a daily basis
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- Face-to-face meetings are deemed the most efficient and effective format for project success
- A final working product is the ultimate 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—maximizing the work not done—is an essential element
- 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
If you think of software development today, these principles, and Agile in general, can be seen as a response to sky-high user expectations.
Users don’t care about documentation, they care about working software. They don’t care about your long-term plan, they want what they want now. They want a bug fixed yesterday, not in a week or with the next release (whenever that is).
We’ve all become very needy consumers, and Agile is a fantastic way to make sure the user’s needs are put front and center whenever you’re developing new software.
How to know if agile is right for your team (and why it might not be)
This all sounds great on the surface, but not every project benefits from Agile project management. So, before we get into the specifics of working with Agile, let’s take a bit of a deeper dive.
Agile might be a big departure from how your company or your teammates are used to working. It means moving quickly, which means not everything will be spelled out or planned beforehand. Therefore, you need to know whether or not your environment can handle this kind of change.
To do that, there are 5 questions you need to honestly answer:
1. Are you willing to start a project without knowing where you’ll end up?
You know that saying ‘fail fast?’ It refers to Agile project management. With Agile, you’re moving quickly and continually testing with real users. Which can be super stressful if you’re a control freak.
Before you adopt Agile, ask yourself how comfortable you are with putting out a less-than-finished version of your product for users to test? Do you feel good about launching an MVP (Minimum Viable Product) or do you think your project needs to be fully baked before it can see the light of day?
2. How risk-averse are you?
Like we said before, Agile is all about continuously deploying and learning from your mistakes. Which means you’re potentially taking on a higher level of risk than you would if you went with a more traditional project management style.
Is your culture a fly-by-the-seat-of-your-pants startup where risk is your middle name? Or are you standing on the precipice of failure and need to make sure everything goes perfect right away (which, if we’re being honest, never happens)? If you’re going the Agile route, you’d better be prepared to take on any unknown issues that come up along the way.
3. How flexible is your team?
In Agile, you work with your customers to make the product better. But this doesn’t always fly with designers, developers, and makers of all kinds with an ego (i.e. all of us). Ask yourself if your key players can put their ego aside and adjust their efforts and ideas based on customer needs.
4. How strict is your company hierarchy?
One of the key principles of Agile is not only to work with your users, but that developers will have access to key stakeholders on a daily basis. For some companies, this is a stretch. What is your culture like? Is there a hard set hierarchy in place or will those at the time gladly be a part of the development process?
5. How do you measure progress? And success?
Shiny new object syndrome and Agile don’t mix. Agile project management is all about working to continuously refine your processes and better your product. So, if you’re more likely to just run off after the next exciting idea and leave the last one to flounder, you’re not going to get the best results that Agile has to offer. Take a minute to look at how you and your culture define progress and success. Can you see that small, steady steps get you closer to your end goal?
How to implement Agile Project Management into your technical team
You’re ready and willing to change the way your team approaches project management and start building products the Agile way.
Agile is all about rhythm. When you’ve got multiple, interdependent cycles of planning and delivery going on, your teams need to be in check more than anything else. As a project manager or team leader it’s your job to have that view from 30,000 feet up to make sure everyone is working together smoothly.
Agile is a mix of constant planning, execution, learning, and iteration, but a basic Agile project can be broken down into these 7 steps:
Step 1: Set your vision with a strategy meeting
What is it?
At the beginning of a new Agile project, you need to define a clear business need or vision that your project is addressing. In essence, you need to answer why you’re doing what you’re setting out to do? It’s big picture stuff, but this is the core belief that you’ll refer back to as you build.
For product companies, one of the best ways to define your vision is to use what’s called the Elevator Pitch:
- For: (Our Target Customer)
- Who: (Statement of the Need)
- The: (Product Name) is a (Product Category)
- That: (Key Product Benefit, Compelling Reason to Buy and/or Use)
- Unlike: (Primary Competitive Alternative)
- Our Product: (Final Statement of Primary Differentiation)
If you’re not building a product, you can still probably see how you could quickly adjust this pitch to match your project’s goals.
Who should be there?
This is where you get buy-in on your project, so as many key stakeholders should be present, including relevant executives, managers, and directors, as well as all product owners.
When does it happen?
Your strategy meeting should happen before any project starts or at least annually to make sure your mission still is valid, with periodic meetings for updates.
How long should it take?
This is totally subjective, but a proper strategy meeting can take anywhere from 4–16 hours (just not in a row!)
Step 2: Build out your product roadmap
What is it?
Once your strategy has been validated it’s time for the product owner to translate that vision into a product roadmap. This is a high-level view of the requirements for your project with a loose timeframe for when you will develop each of them.
The ‘loose’ part here is important. You’re not spending days or weeks planning out every step, but simply identifying, prioritizing, and roughly estimating the effort each piece of your product will take on the way to making a usable product.
So, what does this look like for an Agile project? Product Management expert Roman Pichler, suggests working with a goal-oriented product roadmap, which is sometimes also referred to as theme-based:
“Goal-oriented roadmaps focus on goals, objectives, and outcomes like acquiring customers, increasing engagement, and removing technical debt. Features still exist, but they are derived from the goals and should be used sparingly. Use no more than three to five features per goal, as a rule of thumb.”
For each of these goals, you want to include 5 key pieces of information: Date, Name, Goal, Features, and Metrics
This gives you a clear idea of what needs to be done, when, and how you’ll measure success.
Who should be there?
The product roadmap is done by the Product Owner, but should also include buy-in and input from any other stakeholders in the project—think marketing, sales, support, and development team reps.
When does it happen?
The roadmap needs to be in place before you start planning out sprints, so it’s best to move into creating it directly after your strategy meeting.
How long should it take?
Like all things in Agile project management, you want to move quickly rather than dwell on early stage planning. However, your roadmap is a literal map from your mission to your MVP and should take as long as it does to feel confident that you’ve covered all the applicable goals.
Step 3: Get Ramped up with a release plan
What is it?
Now that we’ve got a strategy and a plan it’s time to set some tentative timelines.
At this stage, the product owner creates a high-level timetable for the release of working software. Because Agile projects will have multiple releases, you’ll want to prioritize the features needed to get you to launch first.
For example, if your project kicked off in November, you might set your MVP launch for early February, with a high-priority feature release the following May. This all depends on the complexity of your project and the lengths of your “sprints”—the periods of work dedicated to each goal (which we’ll get into next!). A typical release includes 3–5 of these sprints.
Who should be there?
A release plan is like rallying the troops. The product owner, project managers, and all team members should be there. You can also bring in a few key stakeholders to add some additional oomph and get the team fired up.
When does it happen?
At a minimum, your release plans should be created on the first day of any new release and reviewed at least every quarter.
How long should it take?
Be realistic about how long a release will take, but don’t let that slow you down. A typical release planning session should take around 4–8 hours.
Step 4: It’s time to plan out your sprints
What is it?
It’s time to move from the macro to the micro view as the product owner and development team plan “sprints”—short cycles of development in which specific tasks and goals will be carried out. A typical sprint lasts between 1–4 weeks and should remain the same length throughout the entire project as this enables teams to plan future work more accurately based on their past performance.
At the beginning of a sprint cycle, you and your team will create a list of backlog items you think you can complete in that timeframe that will allow you to create functional software. Then, it’s as simple as using one of the Agile methodologies to work through them (which we’ll cover more in-depth below).
Who should be there?
Sprint planning is a team effort, and therefore the product owner, project managers, and all team members should be present to voice their thoughts and concerns.
When does it happen?
Sprint planning takes place at the start of each sprint cycle. For example, if you’re doing weekly sprints, you’ll do a planning session every Monday (or whatever day of the week you choose to start on).
However, there is one last piece of the puzzle. With all of this information, organization, and prioritization happening, you need a proper project management tool to keep your Agile project on course. The best software addresses 3 pain points common to the Agile project management process:
- Reporting and metrics: Things like time tracking and projection, easy-to-understand progress reports for stakeholders, quality assurance, and a big picture look at progress
- Communication: The ability to keep everyone on track with updates to local and distributed teams, shared task lists, feedback, and assignments
Project assessment: Functionality around identifying and remedying obstacles or bottlenecks, evaluating performance, and making sure financials are under control
Sprint planning sets the tone for the cycle. So while you don’t want to spend too much time at this stage, it could realistically take you 2–4 hours. But once you’ve planned your sprint you’re quite literally off to the races.
Step 5: Keep your team on track with daily standups
Throughout every sprint you need opportunities to make sure no roadblocks are creeping up and getting in the way of completing your goals on time. That’s where the daily meeting, or “Standup” in Agile-speak, comes in.
A standup is a daily, 15-minute meeting where your team comes together to discuss three things:
- What did you complete yesterday?
- What are you working on today?
- Are there any roadblocks getting in the way?
While this might seem like an annoyance to some of your team, these meetings are essential for fostering the kind of communication that drives Agile project management. Agile depends on reacting quickly to issues and voicing them in a public space is a powerful way to foster cross-team collaboration.
Step 6: Sprint’s done? It’s time for a review
What is it?
If everything has gone as planned, by the end of your sprint cycle you should have a functioning piece of software. At this point, it’s time to review what was done and show this off to people on your team and any key stakeholders. Think of it as Agile show-and-tell.
The key here is to check your initial plan to make sure that all requirements were met. As the product owner, it’s your choice to accept or refuse certain functionalities. If something went wrong, ask why? How can you adjust the next sprint so your team can hit their targets? Agile is all about continuous learning and iterations, and this means on your processes as well as your product.
Who should be there?
Your entire team as well as any key stakeholders should be at your sprint review to check in on progress and voice their support.
When does it happen?
The sprint review takes place at the end of each sprint.
How long should it take?
Just say no to powerpoints and feature dissertations. The sprint review should only take an hour or two max.
Step 7: What’s next? Decide what to focus on in your sprint retrospective
What is it?
For Agile project management to work, you need to have a clear next step after each step. This is determined during your sprint retrospective. Once a sprint has been completed and features have been shown off, it’s time to decide what work gets done next. Did you learn something during the sprint that changes your initial timeline or vision for the project?
Don’t simply plan, but also take this time to discuss how the previous sprint went and how you could improve in your next one.
Who should be there?
The retrospective is a natural extension of the review, and so while your stakeholders can leave, the rest of the team should be involved and giving their insights.
When does it happen?
It makes the most sense for your sprint retrospective to happen right after your sprint review.
How long should it take?
Again, keep it short and sweet. An hour or two max is probably all you’ll need to debrief and plan for the next brief.
What happens now?
At this point, you should have a functional piece of software you can ship, get feedback on, and plan new features or fixes for. This continuous shipping, learning, and building is what makes Agile so powerful. Rather than simply working through your backlog, you’re releasing products and seeing how people interact with them. This means rather than work on a product for a year only to release it and find out some core functionality is missing, you could potentially figure that out after a sprint and adjust accordingly.
How to implement Agile: The top 3 Agile methodologies explained
At this point, you might feel ready to dive into Agile and bring it to your team. However, there’s one more step we need to go through. As we said earlier, Agile is more of a blanket term for a philosophy of project management and development. To use these ideas to their fullest, some very smart people have developed Agile methodologies you can follow.
These methodologies are all quite similar, but from an implementation standpoint, each has its own mix of practices, terminology, and tactics.
Let’s take a look at the top 3 and break down how they’re different:
Scrum
Scrum is probably the most well-known Agile methodology and often the two go hand-in-hand. It’s especially popular in the software development world thanks to its simplicity, proven productivity, and ability to act as a catch-all framework for the various practices promoted by other Agile methodologies.
Here’s how it works:
With Scrum, the “Product Owner” works closely with their team to identify and prioritize their goals or features and add these to what’s called a “Product Backlog”. The backlog can consist of features, bug fixes, non-functional requirements—pretty much anything that needs to be done in order to deliver working software.
With this backlog in place, the Product Owner decides priorities and teams sign up to deliver “potentially shippable increments” of software during their Sprints, which typically last 30 days. Once the team has committed to that Sprint’s backlog, nothing else can be added to it except by the team. At the end of that 30-day Sprint, the backlog is analyzed and reprioritized (if necessary) and the whole thing starts over.
Kanban
Like Scrum, Kanban is an Agile methodology built around continual delivery, while keeping things simple and not overburdening the development team. Kanban is based around 3 basic principles:
Visualise your workflow on a ‘board’: Being able to see all the items you’re working on in context of each other can be incredibly informative and help keep things clear and simple when projects get complex. Kanban tools (like Planio!) use a ‘board’ style to see all your items and where they fit in the flow from to-do to doing to done.
Keep your work-in-progress (WIP) limited: Like in Scrum where the backlog is defined before your sprint and nothing can be added (except by the team), Kanban relies on teams knowing how much they can actually do in each sprint.
Have clear next steps: To keep the flow of Kanban moving, you should always know what happens next after an item is finished. This means keeping your backlog prioritized and updated.
Extreme Programming (XP)
Extreme Programming (XP) isn’t extreme in the Mountain Dew sense, but it is a bit of a departure from the other methodologies we’ve discussed.
XP is a more disciplined approach to Agile project management that involves high customer involvement, rapid feedback loops, continuous testing and planning, and close teamwork to deliver working software quickly. To give you an idea, a typical XP Sprint lasts only 1–3 weeks.
The original XP ‘recipe’ described by software engineer Kent Beck, was based around 4 values—simplicity, communication, feedback, and courage—with 12 supporting practices. It’s definitely more complex than other methodologies and looks something like this in practice:
In XP, there are tight feedback loops where the “customer” works closely with the team to define and prioritize granular goals called “User Stories”. The team then estimates, prioritizes, and plans the delivery of these stories, getting more feedback from the customer until it’s ready for release.
Final thoughts on implementing Agile project management
Congratulations! You now should have a clear understanding of what Agile project management looks like and a few of the powerful ways you can use it on your own teams.
However, there is one last piece of the puzzle. With all of this information, organisation, and prioritization happening, you need a proper project management tool to keep your Agile project on course.
The best frameworks addresses 3 pain points common to the Agile project management process:
- Reporting and metrics: Things like time tracking and projection, easy-to-understand progress reports for stakeholders, quality assurance, and a big picture look at progress
- Communication: The ability to keep everyone on track with updates to local and distributed teams, shared task lists, feedback, and assignments
- Project assessment: Functionality around identifying and remedying obstacles or bottlenecks, evaluating performance, and making sure financials are under control