According to the2020 State of Agile Report, 95% of organizations say they’ve adopted Agile development methodologies within their team. It’s one of the most widely used and trusted frameworks for the modern technology company. So why do 84% of those respondents feel like they’re not doing Agile the right way?
The answer is simple—there’s no right way to do Agile.
Debuted in the2001 Agile Manifesto, the Agile method was created in response to outmoded software practices that didn’t scale with changing technology. At that time, computing speeds were increasing exponentially, cloud services were beginning to take form, and the coding languages people used to build new software were becoming more adaptive. Product and development teams needed a way to keep up.
The Agile product management methodology helped teams respond and react to change faster and more efficiently. With a focus on small, empowered teams and collaborative workflows, the Agile method’s core tenet is adaptability.
That adaptability is key for product teams today. Although many organizations may feel that they do Agile incorrectly, the reality is that you don’t need to follow Agile 100% for the methodology to work for your team.
No product organization is the same, and depending on your existing workflows, the scope of your projects, the size of your team and many more variables, you’re likely to find that some components of Agile work well with your team’s processes, and others aren’t a perfect fit.
That’s why instead of sticking to the traditional Agile Framework, you should leverage the principles that work best for your team and adapt the rest to suit your team’s unique needs, goals, and workflows.
Of course, getting to the point where you know which Agile principles work and don’t work for your team requires a bit of experimentation. So as you consider which parts of Agile you want to follow—and which ones you want to change for your team—consider the ideas below as a starting point.
Tips for Adapting the Agile Framework:
- Encourage Experimentation
No processes are sacred, and everything is subject to change as long as the change adds value. If your team has a new leader or is starting a new project, this is a great time to revisit existing workflows and propose changes. A retro meeting is another great place to talk through processes and propose new ideas, based on what worked or did not work in the past. On our team, we do both sprint retros and monthly team retros, so we can discuss ways to improve at both a micro and a macro level. - Customize Sprints
There’s no law that says your team has to work in two-week sprints. Based on the size of your team or scope of your mission, one- or four- or six-week sprints may actually be a better fit. Figure out which timeline works best for your team and your project, and try out a different sprint length if you think it would help. We originally worked in two-week sprints, but we found that one-week sprints made it easier to account for incoming bugs and to break up tasks into smaller chunks, so we made the change. We regularly revisit this choice and plan to switch back if it stops working. - Trust Your Team
This one goes to the leadership roles. Team leaders have high-priority tasks to focus on already, so micromanagement shouldn’t be one of them. Trust each team to build their own processes and find the practices that help them get their work done effectively and efficiently, without worrying about whether it follows “true” Agile methodologies. At Amplitude, we all use JIRA and have a few standardized practices to make it easier to collaborate across teams, but we don’t dictate how teams should manage their backlogs, how they plan or estimate work, etc. In practice, this means that different product teams may even have different sprint lengths. - Consider the Customer
Ultimately, any product team is attuned to the needs and behaviors of their customers. Product managers are well-versed in product analytics, intimately familiar with the customer journey, and often listening to and advocating for these users. So as you adapt Agile to suit your team, consider how customer feedback—not only the information you receive, but how you procure it—impacts the speed and frequency of your iteration loops. For example, on our team, we are talking to customers, tracking changes in behavior, and making significant updates to the product on a weekly and often even daily basis, so shorter sprints make sense with our cycle.
Make Agile Work for Your Team
Product management is an art, not a science. New ideas come forward—some are in vogue one year, and tossed out the next—and some ideas retain their impact, with modifications over time. Just as you experiment to build and hone the best features for your product, so should you experiment with the ways you go about that work. The best way to do Agile is the way that works best for you.
Interested in learning more about product management and team processes? Check out Amplitude’s North Star Playbook to jump-start your learning.
