How do companies like Microsoft and Google update every single one of the products in a week or two while other companies take years? The short answer is: Agile project management.
While teams following a “traditional” software development process like Waterfall will spend months or years building a product before showing users, Agile flips that process on its head.
Agile project management is a product philosophy that’s built on moving fast, releasing often, and learning from your actual users.
Research from the Project management institute found that Agile organizations are more likely to finish projects on time (65% vs. 40%) and hit all their goals (75% vs. 56%) when compared to non-Agile teams. Agile companies even grew their revenue 37% faster!
Agile project management started out in the software development arena and has flourished in that type of business environment. But, like lots of structured frameworks, it has quickly been adopted to other types of business sectors and has even been combined with Lean and Six Sigma philosophies to bring together a powerhouse change management framework that not only focuses on Waste removal and defect reduction but includes the Agile philosophies around speed.
Let’s repeat the key point one more time: Agile teams build products faster, hit their goals more often, and make more money. So why wouldn’t you want to bring Agile project management to your team?
This guide will help you through the core principles of Agile, helping you to evaluate if Agile Project Management is right for your team or organization. We will then review the 6 core components and the 7 sprint steps, and then we will guide you on how to get up and running with the 7-step Agile project management implementation plan, touch on the 9 Agile methodologies, the 13 best practices for any Agile team, and finally 8 reasons why Agile projects fail.
What is Agile?
Agile is a development process that takes an iterative approach to building products (particularly software). Teams use a number of Agile methodologies to plan releases and then work in time-blocked “sprints” to continuously push out new products and learn from customer feedback (both internal and external customers).
It’s this tight “feedback loop” between customers and the product developers that allows Agile teams to increase their development speed, collaborate better, and react quickly to customer needs and market changes.
While Agile has become the standard for almost every major software company from Apple to Facebook to Spotify, this wasn’t always the case.
Until the last few decades, most projects were run on what’s known as the Waterfall (or Traditional) method of development. In the Waterfall method, teams plan out the entire development process first and then work through it sequentially before releasing it to users.
This meant companies were investing a huge amount of time, resources, and money into something they didn’t even know would be successful.
By design, the waterfall method relies on predictability and sequence. But what most designers and developers started to crave was a more flexible project management method that included space for errors, setbacks, product changes, market changes, and feedback from real users.
The 4 Core Principles
At its core, Agile project management isn’t so much a methodology as a philosophy.
This means that while there are many different ways to implement Agile, they all share a few core beliefs that clearly differentiate them from all other Project Management methods. The following are the 4 core principles:
1. Individuals and interactions over processes and tools:
In Agile, the focus is on people. Effective communication, collaboration, and teamwork are prioritized over rigid processes or reliance solely on tools. By valuing individuals and their interactions, Agile teams can adapt and respond to changing requirements more effectively.
2. Working software over comprehensive documentation:
Agile emphasizes delivering working software early and frequently. While documentation is essential, it should not hinder progress. The goal is to create tangible value for users through functional software rather than extensive paperwork.
3. Customer collaboration over contract negotiation:
Agile encourages close collaboration with customers and stakeholders. Regular feedback and involvement ensure that the product aligns with user needs. Rather than relying solely on formal contracts, Agile teams engage in ongoing conversations to refine requirements and deliver value incrementally.
4. Responding to change over following a plan:
Agile acknowledges that change is inevitable. Instead of rigidly adhering to a fixed plan, Agile teams embrace flexibility. They adapt to new information, adjust priorities, and continuously improve based on feedback. The ability to respond to change quickly is a fundamental principle of Agile methodologies.
This doesn’t mean you should ignore the tools, documentation, and plans you’ve worked so hard to develop. But rather that the core focus of Agile project management should be on people, prototypes, collaboration, and iteration.
The 12 Guiding Principles
While the previous principles give you a good high-level view into the Agile mindset, they’re still a bit vague. That’s why the original Agile developers also released a list of 12 guiding principles for running an Agile project:
1. Satisfy the customer:
The highest priority is to satisfy the customer through early and continuous delivery.
2. Welcome change:
Welcome changing requirements, even late in development.
3. Deliver frequently:
Deliver working products frequently, from a couple of weeks to a couple of months.
4. Collaborate:
Stakeholders and developers must collaborate on a daily basis, working closely throughout the project.
5. Motivated individuals:
Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
6. Face-to-face conversations:
Face-to-face meetings are deemed the most efficient and effective format for project success.
7. Tangible outcomes:
A final working product is the ultimate measure of progress. Focus on tangible outcomes.
8. Healthy pace:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Technical excellence:
Continuous attention to technical excellence and good design enhances agility.
10. Simplicity:
Simplicity, maximizing the work not done, is an essential element.
11. Self-organizing teams:
The best architectures, requirements, and designs emerge from self-organizing teams.
12. Reflections:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
Users don’t care about documentation, they care about working products. They don’t care about your long-term plan, they want something now. If you’ve released a bad product, they expect it to be fixed now–not in a few months–or else they’ll find another option.
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 a new product.
The 6 Core Components of Agile
Agile as a concept isn’t that hard to grasp. But like any tool, framework, or method, Agile has its own quirks and nuances you need to understand if you’re truly going to master it.
Before we dive into the specifics of implementing Agile project management, let’s go over the core components.
1. User stories:
User stories are the backbone of planning out an Agile project. Simply put, a user story is a short, simple feature description told from the perspective of the user or customer.
In most cases, they take the form of:
“As a [type of user] I want [some particular feature] so that [some benefit] is received.”
This format helps you get specific about what needs to be built and why so you can more accurately estimate the time involved to actually make it!
2. Sprints:
Sprints are short cycles of development where you work towards a release. A typical sprint should take about 1–4 weeks and needs to finish with some usable piece of product being released.
The goal is to keep these sprints the same length throughout the project so it’s easier to plan future work, adjust your goals, and not get bogged down.
3. Meetings:
In Agile, teams self-organize and decide what should be included in sprints. This means that regular meetings are a huge component of keeping your team on track.
The core meetings you should think about are:
- Daily standups (or “scrums”): These are quick daily meetings where everyone talks through what they’re working on. It helps you stay informed and focused on hitting the sprint goals.
- Sprint planning: This is a longer meeting at the start of a sprint where the Agile team decides what work should be included.
- Sprint retrospective: At the end of a sprint, the team comes together to discuss what was completed, what worked, and how you can improve moving forward.
4. Agile board:
Agile projects move quickly and you need a tool to keep you organized.
An Agile board can be as low-tech as a whiteboard with sticky notes showing the current sprint’s user stories and progress. However, there are tons of amazing tools out there that can take your Agile team to the next level.
5. Product backlog:
As requests, user feedback, and new ideas come in, you’ll end up with a ton of potential features and projects to take on. These live in your product backlog until you’re ready to add them to a sprint.
The backlog can consist of features, fixes, non-functional requirements—pretty much anything that needs to be done in order to deliver a working product. However, the product backlog is more than just a storing facility. It’s an important piece of the Agile puzzle that needs to be regularly updated and “groomed.”
Taking care of the project backlog is a major part of the Agile project manager role.
6. Team Roles:
Finally, Agile project management brings in a couple of new team roles that you’re probably a bit unfamiliar with. While each Agile methodology treats team members a bit differently, the common roles you should know include:
- Scrum Master: The Scrum Master helps ensure that each sprint stays on track by monitoring progress, facilitating meetings, and helping remove roadblocks. They’re also the team’s advocate and help communicate with stakeholders.
- Project owner: The project owner helps define the goals of each sprint, manages the backlog, and represents the voice of the user to the team.
- Team members: The development team does the work decided on for each sprint. Agile teams are self-organizing, meaning they decide how best to accomplish their work rather than get directed by someone outside the team.
- Stakeholders: Every project has stakeholders–people who are impacted by the outcome of a project. In Agile, stakeholders are purely informational, as in they shouldn’t dictate how a project is run.
7 Agile Sprint Steps
Sprints are a key component to the Agile Project Management Framework. Sprints are short cycles of development where you work towards a release. A typical sprint should take about 1–4 weeks and needs to finish with some usable piece of product being released. The Sprints are multiple planned cycles that support the end goal while releasing usable products to the customer within each Sprint.
1. Plan:
The sprint begins with a sprint planning meeting, where team members come together to lay out components for the upcoming round of work. During this step, the team identifies the user stories or tasks to be completed in the sprint. They estimate the effort required for each task and prioritize them based on business value.
2. Design/Develop:
In this step, the team designs and develops the product or software in accordance with the approved guidelines. They collaborate closely, write code, create designs, and build features. The goal is to complete the planned work within the sprint duration.
3. Test/QA:
Quality assurance (QA) is crucial. The team performs thorough testing, including unit tests, integration tests, and user acceptance testing (UAT). They ensure that the product meets the specified requirements and functions correctly. Documentation of results is also essential during this phase.
4. Deploy:
Once the development and testing are complete, the team delivers the working product or software to stakeholders and customers. This could involve deploying the software to a staging environment or even releasing it to production.
5. Review:
After delivery, the team assesses the sprint’s outcome. They review what went well, identify any challenges or bottlenecks, and discuss lessons learned. This retrospective helps improve processes and ensures continuous learning and adaptation.
6. Reflect/Adapt:
Agile emphasizes continuous improvement. The team reflects on their performance, identifies areas for enhancement, and adapts their practices accordingly. This step ensures that the team becomes more efficient and effective over time.
7. Repeat:
Once a sprint is complete, the team starts the next one. Agile sprints are iterative. They repeat the entire process, incorporating feedback, adjusting priorities, and delivering incremental value to stakeholders.
7 Steps for Getting started with Agile Project Management
Now that you understand the philosophy and core elements of Agile project management, let’s dig into how to actually implement Agile on your team!
Switching to an Agile organization is a big move especially as a project manager, it can feel a bit daunting.
Agile promotes self-organizing teams, changing plans on the fly, and a ton of collaboration between the development team and stakeholders–all elements that make most project managers cringe.
But while Agile removes some of the structure you’re used to, it puts a different level of importance on project management.
Agile is all about rhythm. When you’ve got multiple, interdependent cycles of planning and delivery going on, your teams need to be in sync 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.
Here is 7-steps for implementing Agile project management:
Step 1: Set your project vision and scope with a planning meeting
At the beginning of a new Agile project, you need to define a clear business need that your project is addressing. In more simple terms: what is the end goal of this Agile project and how will you achieve it?
An Agile strategy meeting covers big picture ideas but it also needs to be realistic. You can start to think about the scope of work, but remember that Agile projects need to be flexible and adapt to feedback.
To keep your planning meeting focused, try using the Elevator Pitch method:
- 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)
The Agile planning meeting is where you get buy-in on your project. Try to include relevant stakeholders as well as the product owner and key members of the product team.
A planning meeting should happen before the project starts. Or, if you’re working on a project continuously, plan a major strategy meeting annually to ensure your mission is still valid.
The length of time an Agile planning meeting should take is totally subjective. However, depending on the complexity of the project, most can take anywhere from 4–16 hours (just not in a row!).
Step 2: Build out your product roadmap
With your strategy in place, it’s time for the product owner to translate that vision into a product roadmap. This is a high-level view of the requirements, updated user stories, and a loose timeframe of how it will all get completed.
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 time and 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.
The product roadmap is the responsibility of the product owner but should include input from any other stakeholders in the project—think marketing, sales, support, and development team reps.
The product 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.
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 (Minimum Viable Products) and should take as long as it does to feel confident that you’ve covered all the applicable goals.
Step 3: Create a release plan
Agile project management isn’t built around short-term sprints with the goal of regularly and consistently releasing usable products.
After you have a high-level roadmap in place, the product owner then creates a high-level timetable for each release.
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. A typical release includes 3–5 of these sprints.
A release plan is like rallying the troops. The product owner, project managers, Scrum Master, and all team members should be present.
At a minimum, your release plans should be created on the first day of any new release and reviewed at least every quarter.
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: Sprint planning
It’s time to move from the macro to the micro view. Together with the product owner, the development team plans “sprints”—short cycles of development in which specific tasks and goals will be carried out.
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.
Sprint planning in Agile is done by the product team but should include input and guidance from the product owner, project managers, and scrum master. However, ultimately it’s up to the team to decide what should (and can) get done in a sprint.
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).
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
Agile projects move quickly and so it’s necessary that you have regular moments to check in and make sure there aren’t roadblocks getting in the way. These are called “stand-ups” in Agile-speak.
A standup is a daily, 10–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 reviews
Each sprint cycle ends with a functioning piece of product getting shipped or reviewed by a customer. And while this is a huge milestone to celebrate, it’s also an opportunity 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.
Sprint reviews should cover the more practical aspects of the sprint. Check your initial plan and make sure all requirements were met according to your definition of done.
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.
The sprint review involves everyone who worked on and is impacted by the release. This means you should include your entire team as well as any key stakeholders.
The sprint review takes place at the end of each sprint.
Just say no to PowerPoints and feature dissertations. The sprint review should only take an hour or two max.
Step 7: Decide what to focus on next in your sprint retrospective
One of the core principles of Agile project management is that it’s sustainable. This means you should be ready to start on the next sprint as soon as the previous one ends.
To make sure you’re actually learning from each release (and not just moving forward blindly), you need to dig in with a sprint retrospective.
After you show off the release, a retrospective is a moment to think back on the process of the previous sprint.
Did everything go as planned? Was the workload manageable? Where could you improve your process or planning? 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.
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 give their insights.
It makes the most sense for your sprint retrospective to happen right after your sprint review.
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 after the sprint retrospective?
By the end of the sprint retrospective, your team should have a list of improvements and changes you can implement in your next sprint. And then the sprint process starts over!
Bring your learnings into the next sprint planning session and keep shipping functional products.
Top 9 Agile Methodologies
As we said earlier, Agile is more of a set of philosophies and principles rather than a prescriptive set of rules. As such, you can apply Agile principles in a number of different ways depending on how your team best works together.
These are called Agile methodologies. And while they’re pretty similar, they have their own unique practices, terminologies, and tactics.
1. Scrum:
Scrum is the most popular Agile framework, defined by the Scrum Guide in 2010. According to the 15th State of Agile report, 66% of respondents identified Scrum as one of the Agile frameworks they follow most closely.
What are the main characteristics of a Scrum team?
- Scrum teams work in short iterations called Sprints, with 2 weeks being the most popular choice. Each Sprint has its goal.
- Scrum clearly defines the team roles like Scrum Master, Product Owner, and Development Team.
- Scrum teams attend regular Agile events, like Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
Scrum works well in companies with frequent cross-team collaboration. It fits small teams, 3 to 9 people maximum. It’s a good choice for teams that work in short development cycles focused on timely releases.
The Scrum framework is also great for “newbies” in Agile because it provides clear guidelines. It’s one of the best-defined Agile frameworks: a good choice to start your Agile journey.
2. Kanban:
Kanban is roughly translated from Japanese and means “cards you can see”. In Kanban, the progress of the development process is visualized on a Kanban board.
What are the main characteristics of a Kanban team?
- Kanban teams work with a Kanban board. Typically, the Kanban board includes the “To Do,” “In Progress,” and “Done” columns. In software development, the Kanban board is usually extended to: “To Do,” “Dev,” “Test,” and “Done.”
- Kanban teams work with “Work in Progress” limits to prevent bottlenecks and achieve quicker release cycles.
- Kanban is a continuous workflow. Product improvements happen on an ongoing basis through continuous collaboration and ad-hoc team meetings.
Kanban is the way to go for teams that handle different-size tasks and need to juggle frequently changing product requirements. Kanban methodology is not as clearly defined as Scrum, so it wouldn’t be advised to inexperienced Agile teams.
The Kanban concept is usually recommended to smaller teams that work on repetitive tasks and are not heavily dependent on others. Kanban is a great choice if your team prioritizes the speed to market and is more advanced in Agile methods.
3. Scrumban:
Scrumban is a Scrum Kanban hybrid, taking some of the principles from Scrum and some of the principles from Kanban.
What are the main characteristics of the Scrumban team?
- Scrumban teams work on a time-based schedule. Instead of 2-week Sprints, they work with 3-month, 6-month, and 1-year buckets.
- Agile events are not a must in Scrumban. The team can choose to skip certain events, however, retro sessions and ad-hoc planning are definitely recommended.
- Scrumban teams visualize their tasks on a Scrumban board with applied ‘Work In Progress’ limits.
Scrumban is a great choice for either small or large teams that are experienced or just starting with Agile. It’s a good fit for those who find Scrum too rigid and think that Scrum rules are hindering the team’s productivity.
Scrumban works well with teams that are developing multiple products in fast-paced environments and have less strict estimation requirements from the senior management.
4. Extreme Programming (XP):
Extreme Programming (XP) focuses on producing higher quality software, sharing knowledge, and taking care of the software teams’ wellbeing.
What are the main characteristics of the Extreme Programming team?
- The team values simplicity, quick feedback, collaboration, and quality work.
- XP teams go through 5 development phases: planning, designing, coding, testing, and listening.
- The most important practices are test-driven development, pair programming, simple design, collective code ownership, plus a 40-hour week that prevents burnout.
XP is a good choice for mixed-skill level teams, especially ones where junior and senior programmers work together. It could also work well for teams with tight deadlines, smaller budgets, and frequently changing project requirements.
Extreme programming would not be recommended to remote teams, as it performs best when applied to small teams that work from the same location.
5. Lean Software Development:
Lean product development focuses on producing only what the product actually needs. It optimizes time and resources and reduces unnecessary activities.
What are the main characteristics of the Lean Software Development team?
- The team works with Minimum Viable Products (MVPs) that are released to the customers as early as possible. Customer feedback is then collected and included in future software iterations.
- The team eliminates redundant activities to save time (like reworking the code or using resources in an inefficient way), and team members are empowered to make their own decisions, which results in higher morale.
Teams that are responsible, experienced, and can be trusted to make important decisions on their own would benefit the most from the Lean methodology.
Lean methodology is not easily scalable as it’s more suited to smaller teams that are cohesive as well as teams that can embrace more detailed documentation.
6. Crystal:
Crystal methodology is made up of smaller Agile project management methodologies that were first introduced by Dr. Alistair Cockburn, co-author of the Agile Manifesto, and place the main focus on collaboration practices.
What are the main characteristics of the teams following the Crystal approach?
- Teams following the Crystal approach work with smaller Agile development methodologies like Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal Maroon, Crystal Diamond, and Crystal Sapphire.
- The Crystal approach is very flexible and adaptable, and it works well for different types of Agile teams.
- Crystal teams avoid unnecessary documentation and reporting and practice one of the lightweight Agile software development methodologies.
Different team sizes can benefit from the Crystal project management process. For example, Crystal Clear fits smaller teams and shorter projects (up to 6 developers), and Crystal Red works better with larger teams (up to 80 team members).
The Crystal approach is a good choice for teams that communicate frequently and cooperate without the day-to-day involvement from the higher management.
Crystal methodologies are not recommended to inexperienced Agile teams as the structure is not clearly defined, and there are some gray areas open to interpretations.
7. Dynamic Systems Development Method (DSDM):
Created in 1994, DSDM was meant to complement another Agile framework RAD (Rapid Application Development). DSDM’s main focus was to help with planning and creating more discipline in the team.
What are the main characteristics of the team following the Dynamic Systems Development Framework?
- Timely delivery, focus on business needs, and not compromising on code quality.
- DSDM teams work on a fixed cost, fixed time schedule, and negotiable features.
- Teams following the Dynamic systems development framework work mostly with the MoSCoW prioritization technique, facilitated workshops, and time-boxed iterative development.
DSDM Agile framework works well with small as well as larger, more complex projects. It would be a good fit for teams that can embrace ambiguity and frequently changing requirements.
DSDM works well in the corporate environment, where other Agile methodologies can be harder to implement.
8. Feature Driven Development (FDD):
Feature Driven Development originated from a long 15-month project, in a Singaporean bank, back in 1997. FDD blends different types of Agile methodologies and puts customer satisfaction at the center.
What are the main characteristics of the team following the Feature Driven Development method?
- Teams adopting Feature Driven Development focus mainly on making progress on features.
- FDD teams follow a 5-step development process flow: “develop an overall model,” “build a feature list,” “plan by feature,” “design by feature,” and “build by feature.”
- Features that the FDD teams build are similar to the user stories we know from Scrum.
The FDD Agile method is handy in large-scale software projects, especially in the finance and banking industry, where the main focus is on speeding up the release of features. It wouldn’t be recommended for smaller projects, though.
You might want to test it out if your project grows too complex for the regular Scrum team to handle, especially in organizations where only software development teams follow Agile methodologies.
9. Adaptive Software Development (ASD):
Adaptive Software Development has also originated from RAD. The main focus of ASD is to adapt rapidly to changing product requirements or sudden shifts in user behavior and market trends.
What are the main characteristics of the team following the ASD methodology?
- The team develops software according to three phases: speculate, collaborate, and learn.
- The ASD team focuses mainly on the end user and user feedback which can lead to more user-friendly products.
- Teams are required to deliver on time, embracing early delivery.
- Testing is introduced into every stage of the development process.
Agile Methodology Cheat Sheet
In addition, have a look at our selection of Agile templates – they can help you kick-start the Agile transformation in your organization!
| Agile Methodology | Suitable For | Known For |
|---|---|---|
| Scrum | Small teamsCross-teams collaboration | Scrum rolesSprintsAgile events |
| Kanban | Advanced Agile teamsFrequently changing product requirements | Kanban boardContinuous workflow |
| Scrumban | Fast-paced environmentDeveloping multiple products | Scrumban board3-month, 6-month, & 1-year buckets |
| Extreme Programming | Same locationMixed-skill level teamsSmaller budgets | Test-driven developmentPair programmingSimple designCollective code ownership |
| Lean | Small, empowered teams that make their own decisions | MVPEliminating redundant activities |
| Crystal | Different team sizesAdvanced teams in AgileLess involvement from the higher management | Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal Maroon, Crystal Diamond, and Crystal Sapphire |
| DSDM | Frequently changing requirementsCorporate environment | Fixed cost, fixed time schedule, negotiable featuresMoSCoW prioritization technique |
| FDD | Large-scale software projectsFinance and banking industry | Making progress on features5-step development process flow |
| ASD | Timely DeliveryContinuously updated offeringComplex software projects | Three phases: speculate, Collaborate, and learnEarly deliveryFrequent testing |
13 Best Practices for Agile Teams
Let’s review some of the best agile practices that, when implemented, will make sure that the company processes are optimized for best results.
1. Coherent Development and Testing teams:
In teams following Agile Scrum methodology, there should not be a demarcation line between DEV and QA teams. The developers, testers and the scrum master are supposed to be considered a part of one team performing their respective responsibilities to make the product a success.
Here, every sprint targets making a deliverable ready and the Development and QA work together to get it into a shape that can be reviewed by the customer while the scrum master makes sure that the team focuses on the most important tasks and gets them done on time.
2. Increased involvement of QA:
Since agile product development with scrum advocates working on the product in iterations in every cycle, testing also needs to be done in iterations. The target is to test the work done by developers in the same sprint. Thus, QA needs to be involved from the beginning of each sprint in all the user-stories understanding sessions and the sprint demos as well.
Making QA participate in the early stages ensures a reduced number of bugs in the later stages of development. Keeping QA involved since the start also means no big surprises for the end.
3. Highlighting risks & roadblocks:
Agile methodology encourages teams to account for any distractions that may come up during an iteration in advance. During Scrum, at times, the team may skip elucidating the risks and roadblocks while planning for the sprint and get overwhelmed with the sprint backlog, high priority bugs or some urgent customer enhancement requests during the sprint.
Thus, to avoid any end moment surprises, the delivery team should try to estimate the efforts that may go into dealing with the risks and roadblocks and prepare plans for end deliverables accordingly.
4. More frequent collaboration in the team:
Agile software development with scrum recommends short meetings daily between the teams. These meetings help in re-evaluating the team’s progress every single day and adjusting the sprint goal accordingly.
In Scrum, there are standup meetings daily. These meetings help in managing the focus of the delivery team as any blockers can be flagged and handled the same day they are encountered. The team members are also able to gather information about each other’s progress and are encouraged to share their inhibitions if any. Following Scrum Master best practices will help the team perform better.
5. Velocity Checks:
The concept of Agile helps in knowing the capacity of the team in being able to deliver the user stories. It’s often calculated by measuring the number of user stories that have been achieved by the team during the initial 3-4 iterations.
This helps the project team forecast the number of user stories that the team is capable of delivering and helps in preparing further sprint backlogs efficiently based on the capability measured by velocity metric earlier.
6. Limited or zero deviation in Sprint Backlog:
One of the agile best practices is that there should be zero or limited changes in the sprint backlog to keep the team focused and ensure timely delivery unless some very urgent bug or feature needs to be accommodated.
In Scrum Methodology, a substantial amount of effort is put on planning this during sprint planning meetings to ensure that only the agreed-upon user stories/tasks are being taken up during the iteration.
7. Keeping the product and sprint backlog separate:
The product backlog is the complete list of tasks that need to be done till the product is ready for final release while the sprint backlog is the set of tasks that will be taken up in a certain sprint.
A recommended best practice for Agile is to keep the product backlog and sprint backlog separate.
The idea is to separate the exhaustive list of product features and user stories from its subset that is to be implemented in any particular sprint. Doing this makes a clear demarcation between what the delivery team is expected to implement as a whole over multiple sprints and what the team is expected to deliver post a sprint.
8. User Story Prioritization & Timeboxing Tasks:
One of the Agile best practices that is always recommended is that the user stories and features should always be prioritized based on the business value being offered by them and the risks that are involved in implementing them. This approach enables the product owner and other stakeholders to estimate the financial value associated with each user story and the user story with the highest financial value can be realized earlier.
Timeboxing the tasks or the user stories helps in remaining aligned and accountable towards their completion which otherwise can run for an indefinite amount of time.
9. Customer Involvement after every sprint:
One of the main motives of practicing Agile is getting the product ready for the customer in iterations and getting feedback during all such iterations. Agile can only be successful when taking feedback from the client or the customer after every sprint is given the importance it deserves.
10. Automated Regression Test Suites:
Multiple iterations on the same product based on customer’s feedback results in multiple changes being incorporated and that also means a lot of time spent executing the same sanity and regression suites multiple times. Agile encourages having these sanity and regression suites automated. Having these tests automated significantly reduces the time and effort that goes in repetitive testing due to frequent code commits.
11. Estimate via Planning a Poker:
Estimates play an important part in making Agile methodology successful. In scrum methodology, there are dedicated sprint planning meetings at the start of every sprint to ensure that no overestimation or under-estimation of tasks happens and the team stays close to their goals throughout the sprint. Teams practicing agile do better estimates when the planning poker technique is used which also serves as a team-building activity.
During the planning and estimation meeting, corresponding to a task each estimator has to pull a card with numbers assigned like 0, 1, 3, 5, 8, 13, 20… representing the complexity of the task being discussed. The complexity of a task is directly proportional to the time that will be spent completing it.
All the cards are pulled simultaneously by all the team members. If the value that shows up on all the pulled cards is the same, it becomes an estimate. If not, the team members have a discussion wherein the highest and lowest number estimator has to give a reasoning for their selection. Again, there is another round of card selection, and this goes on till all the estimators agree on a particular estimate.
12. Using Burndown charts:
Agile utilizes the burndown charts in every sprint to assess the amount of work remaining at any particular time. It’s a graph with days on x-axis and work remaining on Y-axis and a slant line from top-left to bottom-right is an ideal graph as the work remaining keeps decreasing with the days in a sprint. Most of the scrum management tools provide such a chart for tracking.
13. Implementing Continuous Integration:
Agile Scrum methodology works well when there is continuous feedback for the development tasks. Continuous Integration is especially helpful in enabling continuous feedback. Not only building the software every time a commit is there, but continuous integration should also include testing the build every time such that any discrepancy or issue is caught at the earliest.
Thus, for an organization that opts to implement Agile Scrum methodology for their software development and wants to achieve quick and frequent releases to the market, the above best practices are followed.
8 Reasons Agile Projects Fail
1. Lack of Experience with Agile Methods:
According to the 9th annual State of Agile™ survey, 44% of the respondents to the survey said they blamed the failure of agile projects on a lack of experience with agile methods.
Indeed, agile is first about how you think, but it also impacts what you do and how you do it. Teams that are deficient in the ability to apply basic Agile practices tend to run into trouble. Investing in solid foundational training in Agile techniques, and competent coaching as to their proper application, is money well spent.
2. Company Philosophy or Culture at Odds with Core Agile Values:
A total of 42% of the respondents said company philosophy or culture at odds with core agile values was the leading cause of failed agile projects. In fact, it was interesting to note that two of the top five reasons that caused agile failures revolve around the organization’s culture – company philosophy or culture at odds with core values and a lack of support for cultural transition.
We know that Agile is first about “how you think,” and then about “what you do.” If your organization’s culture is either ignorant of or outright hostile to Agile principles and values, the prospect of success beyond isolated pockets of Agile teams is slim. Understanding that Agile impacts organizational values and facilitating that transformation is the first step to having a broader adoption of agile, and more success with agile as a means to successful delivery.
3. Lack of Management Support:
Some 38% of the respondents to the survey pointed to a lack of management support as the cause of failed agile projects.
This most typically pertains to “middle management”. In a poorly planned Agile transformation, it’s not unusual for there to be great enthusiasm for agile at the team level and general support of Agile at the executive level, leaving the project and program managers, functional “resource” managers, etc., in the middle of a messy “change sandwich”. Without strong executive guidance, this management layer can feel isolated and then simply dig in to survive. During an Agile transformation, executive leaders need to model the behavior they want their management team to display, live the values they want them to adopt, and help them understand how they fit into the changing organization.
4. External Pressure to Follow Traditional Waterfall Processes:
Another 37% of respondents answered that they found external pressure to follow traditional waterfall processes impeding their projects’ success.
This is especially common in large enterprises, where there are Agile teams and traditional waterfall teams working under the umbrella of the same portfolio. In such cases, the Agile endeavors are usually being grafted into the existing traditional portfolio and project management (PPM) methodology, as opposed to the PPM methodology transforming to an Agile approach. This doesn’t mean that Agile can’t succeed, but it does mean that Agile will need to coexist with (and to some extent, within) the traditional methodology. There are two ways to facilitate that coexistence are to involve people from outside of the agile part of the organization in your planning, reviews, and retrospectives, and also to agree on mutual organizational interfaces for the exchange of information.
5. Lack of Support for Cultural Transition:
The survey found that 36% of the respondents saw a lack of support for cultural transition as the reason agile projects fail.
This is closely related to #2 and #3 above, Organizational values and norms evolve over time, and as they become established, they stubbornly resist change. Senior leadership holds the most leverage in facilitating the transformation of an organization’s culture to one that embraces agile. Tangible, active involvement at the executive level is critical to cultural transformation.
6. A Broader Organizational or Communications Problem:
According to the 9th annual State of Agile survey, 33% of the respondents said they found a broader organizational or communications problem causing agile projects to fail.
To reiterate what we’ve looked at in several of the preceding points, Agile’s effectiveness beyond one-off teams here and there is dependent upon broader and deeper organizational buy-in to Agile values and principles.
7. Unwillingness of Team to Follow Agile:
Unwillingness of the team to follow agile was the cause of failure for 33% of the respondents to the survey.
This tends to happen when the members of a team continue to identify themselves by function (Dev, QA, etc.). Team-level resistance can also happen when there is a team member with a “strong personality” who insists on retaining his/her position at the top of the pecking order. In both cases, it comes down to a perceived loss of identity or control. Executive leadership’s effective influence on the culture and the management team, thorough training, and capable team-level coaching are necessary to overcome these impediments.
8. Insufficient training:
Some 30% of the respondents to the survey said they blamed insufficient training for failed Agile projects.
“Insufficient training” comes in three flavors:
- Nobody received training;
- Not everybody who needed training received it; or
- Some/all received training, but the training wasn’t very good.
Skimping on training isn’t a good idea, and never leads to a successful agile organization. Make sure that everyone involved in your agile efforts receives rock-solid training. Do it early. “Everyone,” by the way, includes your executive leadership.
If you’re struggling with any of these barriers to Agile success, this survey proves that you aren’t alone. The theme that underlies these impediments is that they can be traced back to cultural issues in the organization. In order to have significant and lasting agile success, there’s no getting around the need for strong executive leadership, solid training, and capable coaching.
In Summary
Agile methodology is an approach to project management that leans heavily on short time frames, adaptability, and iteration. It is based on the values and principles described in the Agile Manifesto for software development. Agile methodology involves defining the project scope and priorities, building the agile team, capturing customer feedback, testing and troubleshooting any issues, and delivering value frequently. Agile methodology also encourages breaking the silos of projects, building projects around motivated individuals, communicating face-to-face, and maintaining a sustainable working pace.
Even though the framework was developed for software development, there are principles, methods, and techniques within its framework that can support many other industries and businesses. Like any other framework, the Agile methodology is made up of tools in the toolbox. Simply apply the tools and methods as needed to support the end goal.
