Agile management adoption roadblocks & solutions04 May 2022

What is Agile management?

At the core of an Agile way to manage an organization is the ability to change goals, innovate and adopt new working strategies in a speedy yet lightweight manner, while maintaining respect for workers and sticking with the company's big picture goals. In other words, this means reducing the decision-making chain as much as possible to allow for quick changes in direction. We can see how this approach can automatically assign more respect - but also a responsibility - to team members.

The original Agile Manifesto, written for software development in 2001, has been adapted to all business processes, from operations and marketing through manufacturing to finance and defense projects. Below are the original principles of Agile management:

Screenshot of the Agile Manifesto principles:
https://agilemanifesto.org/principles.html

What are the typical adoption problems, and how to address them?

• Poor communication and unclear transformation goals

If you start the transformation with one team, it will be obvious to communicate the new strategy to all team members. And if you're the team leader, it will be down to you to make sure people align themselves with the fresh ideas and follow through with the program. But the same task becomes a lot more complex and out-of-hand when the subject of the transformation is an entire company. Who will apply, monitor and measure if the changes are taking place? What's the timeline? What happens if not all departments can/want to adapt? These matters become the more important and tricky to navigate the larger a company is.

Solution: Make sure all people know how they can voice their take on the Agile adoption process. It can be a designated chat channel, an Agile adoption Kanban board, or a spreadsheet gathering everyone's comments. We'd advise not to limit access to this channel to manager-level workers only but to listen to everyone's opinion.
Furthermore, create a list of goals for the adoption and give each element a due date. Whether you'll be planning a company-wide strategy change, or if you'll concentrate on specific teams' changes and later expand to the rest before you start to expect results - set up a list of measurable, explicit goals for the transformation.

• Lacking consequence and fear of failure

Let's imagine you're working towards a more Agile approach from your software development team: you want smaller tasks and more frequent releases, and more effective testing. But the team members say: yes, let's do this, but not right now - since the items we're currently working on are too important and urgent for the clients. While it's great to see the team caring so much about the client's satisfaction, it's easy to foresee that this pattern can keep repeating every week and month. It's up to the leader to decide when the change should take place, and the best way to go is to start right now. If the past two pandemic years have taught businesses anything, it is that we must be ready to change our ways at any moment, or we'll fail.
And, speaking of failure - let's assume you forced the abovementioned software development team to split their work into small tasks, introduce WIP limits and share the flow with the customer. And let's say the approach fails. Maybe the team is less efficient trying to focus on small chunks of work, the client isn't sure how to best contribute, and as a result, the jobs take longer to complete. That is also valuable information. With it, you'll know what the partakers are missing and how you need to educate them before the next iteration. Failure to meet one's goals should be a highly educative lesson, not a shameful ball drop.

Solution: Plan the Agile adoption process in rough stages with broad but measurable goals. The initial ones should get the teams familiar with Agile concepts and aims - and it's important not to skip them, as otherwise, you won't get the same understanding nor appreciation of the core principles later on. The first, most theoretical phase, is the one that helps to make the Agile management introduction a cultural change first, rather than just methodic. Then, work on adopting a few further changes, e.g., smaller task sizes and team's self-organization, self-planning with a weekly feedback meeting. After a few weeks of that, analyze what's happened and how productivity has changed. Are you completing more work, is its quality (measured, e.g., by the number of returns) better, worse, or the same? How does the team feel? If the results are satisfactory, introduce a few more changes. E.g., creating visual workflows, allowing for tasks monitoring in real-time - also by the client and other stakeholders. Let the team address user stories built by the clients. Introduce ways to measure progress in real-time, e.g., through story points or work time estimation, cumulative flow diagrams or lead time measurements, or bring in WIP limits to reduce waste and improve throughput.

• Not focusing on people

As obvious as it may seem, people make your company. It's not the process, not your efficiency scores, nor your bottom lines that decide how the company fares - but the individuals working in it. Agile views the human aspect as crucial, listing the requirement to enact workers' respect as one of its original principles.

Solution: The best way to get the workers interested and attentive to your Agile management introduction is by making them aware that Agile will works to their benefit. It will make them more empowered, freer to concentrate on one task at a time and better listened to - their feedback in conversation with the clients will matter. It is also more advisable to pick an Agile transformation leader for either the team or departmental level from within the existing workers, over introducing external consultants. Invest in the people you already have, promote from within, arrange training and retraining and offer competitive compensation. Loyal and caring employees are more open to changing and adapting for the company than any temporary, emotionally detached company employees.


• Fearing conflict

All forms of change can cause conflict, misunderstandings, waste, or even employees' quitting. That's just how it is. It should not, however, outweigh the benefits of making the change. When introduced correctly, methodically, and consequently, people will adapt. And the time and effort cost is unavoidable - it should not be your core focus.

Solution: Be prepared and be understanding. People will rebel, question, and avoid the changes you introduce, but you need to be decisive. Explain why you're making the change and expect compliance, but stay attentive to why someone may be reluctant. Make a list of typical questions and answers to cover all basics. Speak to the unconvinced team members, and if no amount of explanation does the trick to help them get on the same page as you, make it clear what you expect and that if they're not open to providing that, you will not be able to work together. Most conflicts over Agile adoption can be resolved for as long as both sides listen to each other carefully and work to weigh out the pros and cons as a team. But again, there will be people simply not happy to drop their past ways of working. For your Agile management adoption to be successful and permanent, they will need to adapt or leave.

Summing up, it's easy to appreciate that the scale of the fear of change can range from one team to another, and that it can have an impact on whether companies adopt any process alterations at all. Most people fear and dislike change. But they also must be aware that change is paradoxically the one constant element of successful work life.

The good news is that if you manage to adopt the flexible and lightweight Agile principles to one team's work, other departments are likely to notice the results themselves and be more interested in changing. And, best of all, after you've made the team's Agile, they'll be flexible enough to take on any other changes in the future. It's an investment worth making.