If there’s one thing that everyone should know about running agile projects, it’s this:
They’re all inherently (and wonderfully) different.
Lame, I know. But this is real life, and in real life, each and every project has wildly different challenges, successes, and people.
I wish there was a secret sauce. “The ONE thing you should know about Agile”. But to be truthful, the only thing you can be certain of is that you’ll never be 100% certain. It’s just always different.
Different isn’t bad, though. In the following paragraphs, I’ll show you why this isn’t necessarily a problem. Nor does it hurt our progress, products, or careers. In fact, I believe we can capitalize on the rich variety of personalities and challenges in your agile projects. You can jump on these opportunities to amplify team members’ strengths—and your ability to capitalize on these differences can be the single most determining factors of success.
You’ll build better products.
You’ll celebrate more successes.
You’ll forge stronger relationships.
So let’s get started!
A Quick Recap Of Agile
When we consider Agile as a whole, it’s important to think back to the Agile manifesto. It illustrates to us that “individuals and interactions over processes and tools” and “responding to change over following a plan” are core focuses. This sets Agile apart from other types of project management, because it creates a focus on improving and reducing risk while creating processes to build a better overall solution/product.
Agile centers in on assigning real-time value to the components that make people (and situations) different, and utilizes those differences to help mold and develop teams.
Anyone can take a class in Agile or Scrum to learn the procedure—and it’s not my intention to teach you any technical procedures in this article. It can be pretty straightforward to apply general Agile principles to a product process or roll out a new Agile PM software that provides a ready-made framework for your Agile team.
However, truly successful agile teams are the ones who amplify their individual abilities and strengths to the advancement of the whole team and product. It takes a sincere, ongoing effort to develop the soft skills that can make or break Agile projects. I want to provide you with inspiration and direction as you develop your soft skills and see new ways to apply them to your Agile projects.
What Everyone Should Know About Agile Projects
1. Setbacks are completely normal—and not entirely bad.
Each Agile project is different, which means you’ll face unfamiliar challenges in every single one.
You’ll always have setbacks, and this is completely normal, and not entirely bad. Understanding the nature of challenges, at their core, is incredibly important because—quite frankly—you’re going to come across a lot of them in Agile.
So, what is a challenge—and what is it not?
No single tool or development language is ever going to be an entirely perfect fit for what your specific circumstance calls for. Your team will have to problem-solve and find new ways to make things work. Sometimes it’s going to take a lot of planning, sometimes it’s going to take a lot of research. Sometimes, it’s just going to take a lot of trial and error.
These are the types of challenges you’ll likely find yourself in, and they’re going to be different every single day.
If I’ve learned anything in the world of digital project management, it has been to adjust my perspective of what a challenge is. Instead of dreading it, I learned how to use it to the advantage of the team; to view it as an opportunity for growth and learning.
Example: Project timelines
Project timelines are something that we all (at times, to our dismay) work alongside. Timelines help motivate team members and stakeholders to make tough decisions, even if they can’t reach a full agreement with everyone on the team.
Each project timeline acts as its own path—turning, bending and shifting. We lean into our timelines to help guide us, but the decisions we make in order to stick to timelines are always going to be carefully tailored to each circumstance we encounter. When you come up against too-tight deadlines, you’re actually forced to answer some pretty significant questions that reveal important information about priorities:
What feature is most important? Why? What can we downsize?
Where can we save time? What are we doing that’s really unnecessary?
How can we communicate better with clients to get faster approvals?
The challenge of hitting milestones—and the tradeoffs we make to ensure it happens—are ripe opportunities to mine for hidden assumptions, inefficiencies, weaknesses, and more. Once they’re out, only then you can tackle them and make your projects better.
There have been many times in my career where decisions made in order to meet timelines were the wrong decisions for the overall product. We lived, we learned, and we grew from it (and believe you me, we never made those decisions again).
How To Deal With Setbacks In Agile:
So, how do you do it? Not on your own, that’s for sure.
Lean into your team of experts.
- Developers are there to help problem solve with you.
- Designers are there to help create and map out solutions.
- Clients are there to give you the information the team needs to solve the problem.
Lean into your end-users.
- End-users use your tool, and they need it to work well to continue to do so. Use their experiences and opinions to guide the decisions you make.
2. You Need to Carefully Define (And Redefine) Success
Celebrating success is a large part of what makes building a product such an incredible experience. But make no mistake: creating a strategically focused, realistic, and useful definition of success is way harder than anyone ever thinks.
In the words of the beloved Marie Kondo, success is what ‘sparks joy’. To the Average Joe, it seems like a pretty easy thing to master: call out the good times and let them roll.
Right?
Not so fast. When building Agile projects, successes aren’t always that transparent.
It’s critical to be very intentional about success—what it looks like, what it is and isn’t, how it’s measured. Without this intentional approach, significant achievements can get overlooked and inappropriate standards of measurement can sneak into your projects, warping your notion of progress.
Example: Project Velocity
When an Agile team develops velocity, it’s used as a standard of measurement for that specific team. The arbitrary number helps the team understand what their general capacity is and provides a baseline number to make decisions from.
Too many points in the sprint?
– Take some stories out.
Going over your average velocity on a regular basis?
– Commit to a little more next time.
The team can find ways to celebrate success within their velocity (maybe it’s meeting it, maybe it’s surpassing it), but the bottom line is this:
Other teams cannot use that same velocity as a standard of measurement for their own success.
When we think about how velocity is treated sacred for individual teams, we should be applying that same mindset to how we treat other measures of success across teams and products. A single measure of success for product X doesn’t inherently mean the same success for product Y. Assumptions around what defines successes can be crippling for teams, and their perception of success.
Every project is different, and success should be sought out and defined differently as well.
How To Define Success In Agile Projects
- Consider your team members, and take notes about what drives them.
- Ask your team members how they perceive success.
- Use this information to set goals that resonate with your team’s ambitions.
- Set aside dedicated time to celebrate the small stuff. It’s so important for people to feel like every day matters, and by identifying unique ‘wins’ or small victories, you’ll be encouraging and supporting your team, and each of their unique successes along the way.
3. Agile Is Less About The Explicit Process—And More About The People
Ah, people and their differences! This concept is something that every project manager has found themselves navigating (and if you have yet to do so, prepare yourself as the day will most certainly come). As a PM, you meet and work with some of the most interesting and complex people. How you navigate these differences in personality and work style has a direct impact on how you implement Agile in your environment.
There are many different ways to build an understanding of someone’s unique character, and honestly, all of the ways take time. As a PM, you’re likely someone who can naturally empathize with many different types of people and that’s definitely something that you should lean into when building products with teams.
How To Better Understand The Different People On Your Agile Team:
Many times when I begin a new product (or join a new team) I dedicate a legitimate amount of time to understand my team members, and I’d recommend that you do the same.
Start conversations, observe people’s offhand comments, and take notes. Find the answers to these questions:
1. What makes them happy?
This seems simple enough, but you’ll want to gather clarity around this. It’s easy for us to assume what brings someone joy, but when we ask this question directly, we no longer rely on assumptions.
Get specific when you engage your team with this question. It’s important to legitimately understand where their joy stems from: “What about playing Xbox brings you joy? Is it winning a game? Is it collaborating with others? Is it learning about a new world?”
2. What makes them unhappy?
Every person you encounter has things that make them tick, and those things aren’t always obvious. We will meet people who will call out each and every granular aspect of the day that upsets them, and we’ll meet people who bottle things up inside, and only release in the form of a volcanic explosion. If you dive into the different ways that people can be made unhappy, you’ll arm yourself with appropriate tools (by either removing the problems completely, or understanding and working through those aspects as they happen).
Some people won’t be willing to give this information up easily. If you’re new to a team, don’t pressure people to open up to you too early. Build some trust over time and this conversation can become a natural stepping stone.
3. How do they think they work best?
This question is one of my favorites. It really provides people with the opportunity for introspection. Each person has a work style they like best—including how they like to give and receive feedback.
One of my favorite tools to use for this is the 16 Personalities test. It shouldn’t be used as an all-encompassing truth, but the results can help each member of the team better understand how and why each person is different. It brings empathy and understanding to the forefront, even for those who may not find it inherently easy.
Summary: Make Your Differences Work To Your Advantage
Any one person can understand how to implement the basics of the methodology, but it takes someone with courage to understand and use the differences innate to each project to their advantage.
In order to make Agile work, and work well, you have to be willing to face the ever-changing landscape containing new challenges, varied definitions of success, and a hodgepodge of different personalities. Welcome to the beautiful world of agile development!
In the end, the only “right way” to do Agile is the way that takes your unique circumstances into consideration. Honor your differences, and you’ll be in the right mindset to have an incredible agile team.
What Do You Think?
Do you feel like you know a bit more about what it takes to have a successful agile team? What questions do you have about agile, processes, or managing all of the differences you’ll face along the way?
Reach out in the comments below—I’d love to chat about any questions or feedback you have.