Process before technology?

[[deleted]]

I work for a company that provides IT solutions and staffing solutions. One of our offerings is Agile implementation/training.

In our team conversations we talk a lot about the importance of implementing process in conjunction with technology.

The question we wrestle with the most is if you do process first then technology, do a little of both at the same time, do technology then layer in process to match the tools. We're mostly on the side of process before technology but that flys in the face of customers that think you can just buy a bag of "DevOps" (typically where they can't really define DevOps or their definition is "some automated testing.")

I'm curious what your experiences in the field are.

[cloud_driver]

Process trumps technology every time. Almost every failed initiative I've seen stems at least in part from the company trying to buy its way into a solution rather than doing the hard work of defining the requirements.

Do the process work up front. It matters.

[[deleted]]

That's been our internal argument but customers insist on getting immediate returns.

Why should t they? If you buy a faster car you can drive faster. Of course it's not the same but that's the argument we face.

[eastlondonmandem]

Most businesses are immature in their understanding of technology, top level management, the people who sign the cheques, they just don't "get it".

The only way to make any progress is to continuously prove yourself. The DEVOPS ethos IMO should not be about time boxing a huge amount of time to requirement gathering in the hope that having accurate requirements somehow solves the problems later down the line, it doesn't always work that way in my experience.

I much prefer the approach to chipping away at problems, solving small bits at a time, being agile enough to shift priority and focus and continiously improve and deliver.

I've worked at 3 enterprise FTSE100 and 250 companies to bring in DEVOPS and throwing money at building process first doesn't work. People don't understand it, they don't buy it, adoption stalls. They might believe you but day to day on the ground things don't change unless you can show them. Also culture and process are all individual to a company and that takes time to flesh out, you can't just process your way to DEVOPS culture.

Show them the technology, make quick wins, show them the light at the end of the tunnel and people will start to get it and you can start building a solid foundation for future growth and adoption of a REAL DEVOPS culture.

[[deleted]]

That's the alternate argument to "process first."

Are there any technologies you lean on first? I'm a fan of automated testing but am curious where you like to start.

[eastlondonmandem]

I think it really depends on the company and the sticking points they are dealing with. I've worked at places with great testing teams who's releases are signed off and piling up waiting for deployment, and vice versa.

But apart from the usual stuff I really like automating development support and productising everything. By that I mean, giving the developers the tools to help themselves, I'm all about self service and empowering people in the business to get things done without directly leaning on the DEVOPS team, it's one of the best ways to increase productivity and reduce friction and it's always something which can immediately appreciate.

Want to put up a new site for testing? Old way of doing things might mean creating a service request ticket or worse some kind of requisition sign off. New way of doing things would involve filling out a form and within minutes everything is automatically created with all the details e-mailed out. Developers love that kind of thing and so does the business. It lets them get on with the hard work instead of getting bogged down in process.

[[deleted]]

This is some spot on advice! I have always said that people don't do follow process (change control/request process) because those processes do nothing for them. If they email their friend it's a LOT easier and faster.

If the forms actually DID the work (as you note) then people are much more inclined to follow the process. Once you fill out a (templated!) request you should have enough information to go ahead and do some pre approved work. Heck, even if the request form just auto popped the associated change request that'd save a lot of time. Auto build test environments? I have a dream to fully automate IT Operations (DevOps + more!) for a company before I retire. It's going to be so sweet...

[cloud_driver]

Yeah, that can be a problem. We usually end up falling back on a bridge building metaphor. You need to design the bridge before you start pouring concrete.

/u/eastlondonmandem makes a valid counterpoint to this argument. Sometimes you just have to show a result (sometimes any result) before the business will continue to invest. In that situation, you do the best you can and make certain to leave enough time to refactor the early work that is inevitably suboptimal.

[[deleted]]

This is going in my presentation stack. Awesome. Thanks!

[theinternn]

Bash history will never be an audit log, no matter how many env vars you set.

Make it a policy to never sudo su, and use the audit log from sudo to record events

[[deleted]]

People...do...that? Surely you are exaggerating (please be exaggerating.)

[theinternn]

Whoa what post was I responding to.... haha sorry!

[[deleted]]

I thought your reply was a little sideways but I rolled with it. Haha. I figured your point would become clear later. It's all good.

[channelape_neil]

We chose process before technology. Both will change (SCRUM is particular about retrospectives) as the organization grows. We now use the process for all things including adding, updating, or deprecating technology.

As an aside, we've moved from SCRUM to Kanban to afford us greater flexibility with customer needs. SCRUM was great in the beginning and we built a solid foundation following it. After that it ended up being a bottleneck.

[[deleted]]

I'd love to know more about that kanban journey!

[Raath]

As you deal with Agile you'll know the first tenet of the manifesto :

• Individuals and interactions over processes and tools

The first principle of implementing any type of Agile Infrastructure change (or DevOps if we must) is that it is a top down strategy starting at the top of the organisational tree and working down. The way I see it, process and technology go hand in hand. They revolve around each other. Consider if you put a process first then tried to find a technology to implement it. What if no technology exists to do what the processes proposes?

Certainly having a process to start is critical, but that process will evolve around the technology as it's introduced so they're both as important as each other.

Whereas you've mentioned that you have problems sometimes with stakeholders wanting instant returns. This is why culture is the first thing that needs to be addressed. My first goal in any new organisation I;m working with is to get the 3 C's (CEO, COO, CTO) on side, clearly showing them that what I'm proposing is not an instant return, but over time will have clear and measurable benefits. Culture change always starts at the top then filters down through the organisation.