Common barriers to agile adoption
A lot of organizations are trying to “go Agile”. That sounds great, but they often fail. Sometimes they get part of the way there, sometimes they got most of the way and achieve some benefits, but then struggle. Sometimes they fall in a heap and don’t get anywhere. Often they just end up doing “cargo cult” agile. That is, they just adopt some of the rituals and trappings, but don’t understand the principles. They are just going through the motions. Many organizations try hard but hit barriers that stop them from becoming agile. This article will describe the common barriers to agile adoption. And provide some advice on how to overcome them.
What are the common barriers to agile adoption?
This article isn’t a witch hunt and I’m not out to name and blame. I’m just trying to point out where agile transformations often struggle. And what the common barriers to agile adoption are. So you can take this into account and prepare for these hurdles.
Risk and security
These folks have a tough job. They have to make sure the business, its customers, its staff and assets are safe. That’s not easy, considering the number of threats out there. Internal and external.
These people are used to long lead times so they can do analysis and make risk / threat ratings and recommendations. They will generally want extensive plans and documentation a long time in advance. That is so they can take their time to understand all the risks and report their findings.
This doesn’t sound very agile. If you are doing agile, you will probably plan as you go and not write huge volumes of documentation. And the documents you write will probably be just in time, rather than well in advance.
My advice is to bring these people on board as much as you can. Instead of having one big dedicated risk and security team, who sit in their own world operating according to their own ways, try moving them to your area, much closer to your team. You might want to have someone actually in your scrum team, if that works and doesn’t make the team too big or slow. Otherwise, make sure they are co-located close by. And make sure you have very short feedback and communication loops with them. Inviting them to a sprint review every now and then probably isn’t going to cut it.
Make sure to have frank discussion with them about your team’s Definition of Done. This is a crucial artifact (ok, technically it is a “commitment” for an artifact) that helps everyone understand and agree on quality and risk management around the product. If risk or security reviews are part of your team’s Definition of Done, then you will definitely need to have these people in your team.
Otherwise, your team isn’t able (on their own) to create a Done Increment. Which means they are not a Scrum team.
Project funding
Project funding can be a huge barrier to an organization moving to agile. Traditional funding for work is done on long project budget cycles. Someone puts together a business case for a big project, with defined features and benefits. The work, scope, value and risk are all baked into the business case. The stakeholders give out the money on the basis of that business case. And the people who agreed to give out the money are expecting all those things.
This means that many agile teams are actually constrained by the business case. They don’t have a lot of room to inspect and adapt. If your funding says you have to build widgets X and Y, then you’re supposed to. Even if it turns out not to be a good idea.
This is a big problem and one of the reasons we need to move from projects to products. And from project funding to product funding. Otherwise, teams are not really able to inspect and adapt.
Operations
Operations teams are often in a tough place. They’re under pressure to do more with less. To keep systems running while putting through piles of changes. To be “flexible” and “lean” while keeping everything tight, secure and stable. They often end up in conflict with development. The stereotype is the hotshot cowboy developer, trying to push through risky code changes, and the stressed out operations engineer, trying to keep everything from falling over. And the stereotype is often true.
If Operations (the people, systems and processes) dictate you can only release anything once every six months, that’s a barrier to agile. If they say you can’t do a change without filling out a hundred forms with a hundred approvals, that’s a barrier to agile. Or if they make you write a hundred page Word document to describe a simple REST API, that’s a barrier to Agile. I’m not saying they’re bad people. I’m saying this system sucks, for everybody. Development AND operations. That’s why DevOps was born.
DevOps to the rescue?
DevOps aims to bring development an operations together
DevOps tries to fix this, by saying:
- get development and operations to work together. No more “throwing code over the wall”
- build better processes, automated as much as possible, that reduce risk and improve cycle time
- extend your pipelines to staging if not production, by extensive test automation and configuration management.
DevOps is a big change and a huge journey. And a lot of people are still figuring out how to do it right. But as I’ve argued before, DevOps complements Agile very well. And if you get it right, it will turn Operations from a barrier into a huge advantage.
Human Resources
HR is an important function and they often get a bad rap. A lot of people don’t understand what they do. Some people see them as a barrier: “I can’t hire / fire / promote this person, because HR says so”. Unfortunately, a lot of HR departments are bound by traditional bureaucratic forms and strict rules and procedures. A lot of organizations are very risk-averse, and wrap processes around decisions like these to make sure they aren’t taken hastily and cause problems.
I don’t have an easy answer to this. Partly it will require a culture shift. HR departments need to move from being a restricting force to an enabling force. It’s possible that a lot of the HR functions should be more fairly spread around the organization. For example, it makes more sense for Guild / Chapter Leads to do the recruiting, interviewing and hiring, since they know what sort of people they are looking for.
Management
A lot of the “management” functions start to move, change or go away as an organization becomes agile. And that’s ok. But people will be freaked out by these changes and may resist them. Management can be one of the common barriers to agile adoption.
The changes are:
- line management becomes less important and “hands-on” as people and teams become empowered
- technical managers become less important as teams become more self-directed and define their own technology spaces
- service managers become less involved as people move from silo IT to DevOps
- project managers become less powerful as the firm moves from a project to a product mindset.
That’s not to say those people won’t have jobs or won’t have anything to do. They may just have less “management” responsibilities and more “work” responsibilities. Which is probably a good thing for a lot of people. But expect resistance from some, especially those who have been in management roles for a long time.
Conclusion
So what do you think? What have you found to be the most common barriers to agile adoption at your workplace? Let me know in the comments.
