Four Roadblocks To ‘Technical’ Challenges in Agile/DevOps

I do a lot of work in automation, and oftentimes we run into roadblocks to getting all of the tasks into an automation pipeline.  A lot of the time, when going over automation steps for a project, I’ll hear people say things like, “Well you can’t do that,” or, “That’s just not possible”, and unfortunately, a lot of people take those reactions as gospel and stop going down the path without asking the most important question: “Why?”

I could recount numerous stories where I ran into blockers that were absolutely able to be overcome, but because an organization has simply “always done it this way” they were not inclined to go any further down the road to make a change.  Usually, these blockers can be throw into one of four buckets – Technology, Process, Legal, or People.  Once you know what bucket it goes in, it becomes easier to decide what’s needed to approach the problem, make a recommendation, and get it resolved.

Technology

Technology problems are, in reality, oftentimes not the root problem.  When it is, it’s usually because the application doesn’t support the methods and goals that you’re trying to achieve.

Say for instance, you’re attempting to automate the process to create a virtual machine.  And the network team issues static IP addresses and logs what is being used in a spreadsheet.  Or, you’re attempting to automate the process for onboarding new employees, but the HR department is using an antiquated system for how they track new employees and who they work for and isn’t designed to be integrated with any other application.

These are technology problems which are relatively easy to fix.  You can use existing technologies like a database to track these things, or you can get dedicated modern applications that integrate with other platforms to be able to accomplish tasks.

Really, the biggest challenge to a technology problem is whether or not your organization is willing to make an investment towards the change.  This investment may be monetary, and if it is, that can be solved with buy-in from management and budgeting.  The other investment is putting in the effort to get the work done – in either case this stops becoming a technology problem and it becomes a people problem.  More on that later.

Process

Just about every company runs into this one.  I once worked with a company that had a 27 day SLA to deploy a single virtual machine.  27 days!  When my partner and I got a hold of the process flow, a lot of it was manual process and approvals of all of the different organizations involved.  When we laid out what could be automated, we were able to boil that process down with automated checks and balances that could get the same amount of work done within a few hours.

The problem, however, was that the documented processes and procedures that the company had been beholden to required that the manager of each organization manually sign off on the approval.  When those processes were challenged, none of the stakeholders were willing to champion an effort to drive the changes necessary.

Bart Schlatmann, former COO of ING Nederland I think put it best when he said, “Agility is about flexibility and the ability of an organization to rapidly adapt and steer itself in a new direction. It’s about minimizing handovers and bureaucracy, and empowering people.

You are as agile as your most rigid process.

Legal

Legal challenges don’t often come up, but when they do, they often can be solvable.  The most frequent I’ve seen is with open-source licensing.  Oftentimes, organizations will just issue a blanket “no” across the board for open-source software.  This is a mistake.

Yes.  Understand the licenses involved for using open-source.  Yes.  Ensure your company is reasonably covered when using it.  But if you are taking open-source entirely off the table for use, you’re hamstringing yourself and your initiatives.  No one moves to innovate and improve product faster than the open community.

For anything outside of that, the important thing to remember is to ask questions.  Understand the legal issues at hand.  Most importantly, understand what would be needed to stay within the legal lanes and still get the job done.

People

The most common, and the hardest to solve.  For the most part, people can be innovative, creative, and passionate about their work.  But they can also be territorial, stubborn, and unyielding to change.

Everyone should recognize this; not only of their peers, but of themselves as well.  Change is scary.  Habits are hard to break.  And when someone requests a change to something that you’ve worked so hard to build, it can be easy to say no.  Recognizing this in yourself is equally important as recognizing it in your peers.  Instead of a knee-jerk reaction, take a moment.  Think about the reasoning for the change and ask questions.  Understand the problem that the requester is trying to solve.

Perspective is valuable.  It’s based on our experiences, and thus everyone has a different take on things.  All perspectives are equally important.

People that are willing to embrace innovation and change are the ones who will enable an organization to move forward.  Those who fear change, and refuse to challenge their own ideals become anchors.  They will slow a company down, if not bring it to a grinding halt in terms of progress.

In this day and age of disruptors who surpass industry juggernauts in market share and value, it’s important to understand and evaluate the challenges you have to move your organization forward.  Keep your company flexible and adaptable to change.  Understand processes that are holding you back and adopt new ones to address the same risks but allow you to move forward.  Evaluate your people.  Coach them to ask questions of themselves as much as their peers, and reallocate those who are unwilling to adapt.

Finally, ask questions.  Don’t take ‘no’, or ‘we can’t do that’ as the final word.  Challenge the response with a question.  Understand the reasoning behind the response.  ‘No’ isn’t a solution.  It’s a roadblock.  Anything is solvable.  But you need to understand the why before you can get to how.