Adopting an Agile mindset and way of working poses many challenges, as it’s more than just a framework or a set of practices. This is quite a journey from changing people’s mindset and aligning the entire organization to managing expectations and team motivation levels.
So what are the most challenging aspects when transitioning to Agile principles?
This article is part of a more comprehensive guide: Demystifying Agile in Software Development. Make sure you get yours! |
We interviewed nine Agile experts and practitioners to get their insights on what are the most common challenges with adopting Agile and how to best overcome them.
By far, the most crucial challenge has to do with changing an entire organization’s mindset. Where most companies have difficulties is unrealistic expectations, thinking that just making the decision to be Agile and investing in training is enough. In reality, that change will take months if not years, especially if the rest of the organization (senior management, sales, marketing etc.) doesn’t follow suit.
The change in mindset has to happen on various levels. For one, it’s about moving from a task and process-driven organization to a value creation one, where people are given the tools to decide what they think it’s best.
“Agile is a combination of structure, processes, methodology, but, especially mindset, organizational culture and value systems. I see a lot of failed implementations caused by the wrong mindset. It’s not enough to invest in education about Agile. Companies need to create the right context so that people can take ownership. Agile is not a destination, it’s work-in-progress.” Agile Consultant, Rolf Consulting
Transitioning to a mindset of creating value and making decisions involves risk, so companies need to consider how they will handle it and encourage people to take ownership.
“I see resistance to Agile because people still feel more comfortable in the old way of working. In Agile, they need to make decisions on their own, and sometimes these decisions will be bad ones, so they now need to adjust fast. Companies should pay attention to how they manage this risk.” Agile Consultant, Rolf Consulting
When adopting Agile, it’s essential to lead by example and not expect that the Agile mindset is for your development or IT department alone.
|
“If the CEO decides to adopt Agile and expects people to change, but she continues to work the same way she always has, people are going to notice and will question why they need to change.” Ralph van Roosmalen, Agile Consultant, Agile Strides |
Having patience in the process is also a decisive factor and poses problems.
|
|
“When companies don’t have patience, they won’t focus on the long term because they expect results in a few months. If you hire an Agile coach, start doing Scrum and expect to be Agile in six months, you are wrong - you just planted a seed if you are lucky.” Ralph van Roosmalen, Agile Consultant, Agile Strides |
Agile is not just about flexibility, it’s a mix of flexibility and structure, and the lack of the latter leads to chaos. That is why you need to have periods of uninterrupted work such as sprints. So it matters to find your company’s balance between how much adaptability and predictability you need.
“Adaptability and predictability are the new terms we talk about, not Agile of Waterfall.” Agile Consultant, Rolf Consulting
And since we are always talking about flexibility, many times that gets translated into change requests. A big challenge arises when change requests are based on opinions rather than facts.
| “In cases like this, it's very hard to say ‘no’, especially if it's coming from a leader in the company with a lot of ‘political’ influence. So you are going to be thankful for feedback, explain that it does not work and why, but you still get the same input. What then? In cases like this, what could work is creating a customer focus group to help steer the direction of the product, driven by real-life needs and challenges.” Mircea Alexandru, Software Development Manager, Mark Information |
Agile is about embracing change, but too much change can tire and demotivate people, so it’s essential to take it step-by-step, introduce small changes, and communicate with your team openly.
|
“Be careful with changing too much at the same time - give people time to adjust. And keep in contact with them, care about people, listen to their complaints, worries, and ideas.” Ralph van Roosmalen, Agile Consultant, Agile Strides |
Keeping close communication with the business owners, the product owner, and the development team makes the difference in delivering the right features or working in the wrong direction.
| “Engagement with the stakeholders, the Product Owner, in particular, helps a lot. I’ve seen cases in which the Product Owner doesn’t have the time, enough knowledge, or simply wasn’t available to answer questions from the team in due time. And it created tensions and confusion.” Vasi Axinte, Senior Software Developer, Wirtek |
| “One of the challenges we saw was the lack of communication between the decision-makers and the rest of the team involved, which can lead in treating inefficiently the impediments that may occur during the processes involved.” Raluca Meyer, Founder &CEO, Viralink |
One of the easiest traps to fall into is maintaining a large backlog, which works against agility.
| “It’s complicated to prioritize a backlog with 40-50 user stories. So it’s best to keep a minimal backlog with what the team aims to deliver over the next 2-3 sprints. If you put an item in the backlog to develop in the next six months, maybe it’s not that important.” Mircea Alexandru, Software Development Manager, Mark Information |
Product Owner engagement is also critical, as well as the Product Owner communication with the team.
| “Sometimes the team has a different priority than the Product Owner, and it’s important that they talk openly about them and the risks and wins involved. The Product Owner makes the final call, but the team’s role is to communicate openly what the risk is.” Flaviu Zapca, Co-founder, CoreBuild |
| “Our backlog has improved since having our Product Owner 100% focused on managing the backlog.” Alexandra Filip, Scrum Master, Wirtek |
If you are to deliver the right product, it all starts with slicing your product into pieces. This approach allows your customers to react, especially when long-term features are foggy - there's a saying, "I'll know it when I see it".
The second thing is to identify how you want to use your backlog - tasks or stories?
There's a reason why it's called a story, it really needs to shortly tell the story behind the feature request.
Implementing a user story with success starts with defining it with enough details so that the development team can find the best technical solution.
This process usually gets complimented with a backlog strategy called story mapping. The final purpose is to create a user-centered product by visualizing the goals and steps needed for the feature to come to life.
| “When you define a user story from the user’s perspective, using the formula “as a user I want to”...”so that”. you are putting in just enough information so that the developers know exactly what they need to build. I’ve seen cases in which the “so that” was not defined at all, because they didn’t understand the value of it.” Adina Balea, Director of Software Engineering Services, Wirtek |
Teams need to decide for themselves what they need to make sure they understand what they should deliver.
| “In our team, we use a few guidelines we need to check for each user story: the user story should be clear enough, and it has to have acceptance criteria, only then do we move to estimations.” Vasi Axinte, Senior Software Developer, Wirtek |
| “For more complex user stories, my team prefers to do a kick-off meeting with everyone involved, architects, developers, QA. This way, we can all discuss, and everyone understands what the story is about, without needing to document too much or create detailed mockups.” Mircea Alexandru, Software Development Manager, Mark Information |
Planning becomes a challenge as stakeholders sometimes tend to change the sprint’s scope right in the middle of it. Keeping defined periods of time for development helps in this sense.
| “Once you establish the scope of the sprint, you don’t change it. You need to have time for uninterrupted work.” Flaviu Zapca, Co-founder, CoreBuild |
| “It’s appealing to make a change request during the sprint, but we learned not to affect the sprint scope, except for "A errors" as we call them, critical issues we cannot postpone.” Mircea Alexandru, Software Development Manager, Mark Information |
Estimations can also be challenging when team members come up with very different time estimates.
| “One challenge I’ve seen with estimations is that people will estimate differently based on seniority level or just how they understand a story. When we see significant differences in estimations, it’s a sign we might need additional clarifications.” Vasi Axinte, Senior Software Developer, Wirtek |
| “I’ve seen is that people in the team, especially senior ones, will estimate a story as if they developed it, and then at planning, that story is allocated to another team member. In this case, we encourage everyone to speak out, ask for more time, and re-estimate if they need to.” Mircea Alexandru, Software Development Manager, Mark Information |
But perhaps a more subtle challenge is moving from estimating work to estimating deliverables.
“This is a difficult transition to make: from planning and estimating work to estimating deliverables.” Agile Consultant, Rolf Consulting
Special thanks to our contributors for sharing their insights and ideas with us:
Ralph van Roosmalen, Founder & Agile Consultant, Agile Strides
Raluca Meyer, Founder &CEO, Viralink
Flaviu Zapca, Co-founder, CoreBuild
Alexandra Filip, Scrum Master, Wirtek
Adina Balea, Director of Software Engineering Services, Wirtek
Ionuț Pop, Scrum Master, Wirtek
Mircea Alexandru, Software Development Manager, Mark Information
Vasi Axinte, Senior Software Developer, Wirtek