What Everyone Should Know About Agile Projects [#Agile #AgileProjects]
1. Setbacks are completely normal—and not entirely bad
2. You need to carefully define (and redefine) success
3. Agile is less about the explicit process—and more about the people
1. Setbacks are completely normal—and not entirely bad
Each Agile project is different, which means you will face unfamiliar challenges in every single project. Understanding the nature of challenges, at their core, is incredibly important because you are going to come across a lot of them in Agile.
No single tool or development language is ever going to be an entirely perfect fit for your specific circumstance or situation. Your team will have to problem-solve and find new ways to make things work. Sometimes it is going to take a lot of planning. Sometimes it is going to take a lot of research. Sometimes, it is just going to take a lot of trial and error.
These are the types of challenges you will likely find yourself in, and they are going to be different every single day.
Example: Project timelines
Project timelines are something that we all work alongside. Timelines help motivate team members and stakeholders to make tough decisions, even if they cannot reach a full agreement with everyone in the team.
When you come up against too tight deadlines, you are 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 is really unnecessary?
• How can we communicate better with customers 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, and weaknesses. Once they are out, only then you can tackle them and make your projects better.
How to deal with setbacks in Agile:
• 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.
• • Customers 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 creating a strategically focused, realistic, and useful definition of success is way harder than anyone ever thinks.
Example: Project Velocity
When an Agile team develops velocity, it is 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.
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 is meeting it, maybe it is 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 does not 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 ambitions of your team
• Set aside dedicated time to celebrate the small stuff.
It is so important for people to feel like every day matters, and by identifying unique ‘wins’ or small victories, you will 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
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 the unique character of someone and all of them take time. You are likely someone who can naturally empathize with many different types of people and that is definitely something that you should lean into when building products with teams.
How to better understand the different people on your Agile team:
Start conversations, observe offhand comments of people, and take notes.
Find the answers to these questions:
- What makes them happy?
Get specific when you engage your team with this question. It is 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? What makes them unhappy?
Every person you encounter has things that make them tick, and those things are not always obvious. We will meet people who will call out each and every granular aspect of the day that upsets them, and we will 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 will arm yourself with appropriate tools by either removing the problems completely, or understanding and working through those aspects as they happen.
Some people will not be willing to give this information up easily. If you are new to a team, do not pressure people to open up to you too early. Build some trust over time and this conversation can become a natural stepping stone.
- How do they think they work best?
This question 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.
Make your differences work to your advantage
Any person can understand how to implement the basics of an Agile based 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.
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 will be in the right mindset to have an incredible Agile team.
ADAPTED FROM
What Everyone Should Know About Running Agile Projects:
The Digital Project Manager
Like this? Leave your thoughts below...