What is the common stumbling block when adopting Agile methodologies?


What is the common stumbling block when adopting Agile… | Cervisys –

We often speak with IT decision makers who want advice on what tool to buy to make their shop more “DevOps.” My advice to them is not to buy anything.  

DevOps isn’t something you triumphantly stick a flag in or acquire through tooling purchase or corporate acquisition.

DevOps is the active intersection of frequent value delivery, frequent team communication, and frequent gap reduction between paying customers and the dev team.

Meaning, it’s a culture. Here’s a good analogy: Imagine you have a really long conveyor belt and your dev team is on the near side with your customers on the far side. Now imagine layers of different managers, executives, janitors, lawyers, and accountants all with “stop switches” for the conveyor belt for various inspections and approvals. 

Each individual understands their role, and they wholly believe they are the only ones with a stop switch but can’t figure out why the conveyor belt keeps jerking and lurching. 

They all band together and demand a new “Slack Docker” conveyor belt because everyone is badgering them to get value to their customers faster — it’s obviously the conveyor belt that needs upgrading. (sarcasm)

You can spend loads of money replacing every part of the entire conveyor belt and you will still not deliver value to your customers faster if you don’t address the culture of stopping workflow first. You cannot serve anything to your customers faster by merely adopting Puppet/Slack/Docker/Chef/Jira/Teams/etc., unless they are adopted to enhance your existing continuous delivery culture.

A DevOps shop breeds a culture that values continually shortening the time it takes to move defined increments of value, communicating and sharing workload, and taking feedback directly from the customer.

What do most companies stumble on when adopting an Agile methodology? It often means slowing down your current conveyor belt to half speed (or drastically reducing the size of the inspectable deliverables), while taking away everyone’s stop switch and replacing them with a single “stop switch” mounted high on the far wall figuratively speaking. 

It’s a very hard pill to swallow for those involved because they often gain much of their value from the fact that work needs to stop and be started by them. But even a slow conveyor belt that seldom stops will beat a fast conveyor belt that’s always waiting for approval to proceed. As the team gets comfortable with the new approach, you start increasing the speed of the conveyor belt, shortening the feedback paths, and then finally upgrading various tools.  

It will become very clear where you need to upgrade when your culture is driving necessity, and then we’d love to have that conversation with you.

Previous Post
End of Line for SQL Server 2008 R2 and Windows Server 2008 R2
Next Post
IT Service and Support: How do I know I’ll be a priority?

Related Posts

No results found.

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.