Slashdot Asks: Are DevOps, Agile, and Lean IT the Same Thing? (zdnet.com)

ZDNet writes: There have been three great movements shaping the information technology landscape. There is Agile, which emphasizes collaboration in software development; Lean IT, which promotes delivering software faster, better and cheaper; and DevOps, which seeks to align software development with continuous delivery...

These three movements have their own advocates, methodologies and terminology. But when you think about Agile, Lean IT and Agile, aren't these all the same thing, essentially? They all have the same goals, which is to deliver high-quality software on a continuous basis, collaboratively. Is it time to chuck the terminology and semantics and bring these three activities under the same roof?
Their article cites "advocates" -- two authors who have both written books about Lean It -- who are pushing for the concepts to all be brought together into a single mold. But it'd be interesting to get some opinions and real-world anecdotes from Slashdot's readers. So leave your own thoughts in the comments.

Are DevOps, Agile, and Lean IT the same thing?

Comments

No

[gweihir]

But they all stem (in part) from the same root-cause: A slow realization that IT personnel is routinely not very good and that you would need far less IT people if the were really good. Of course, the usual implementation does it completely wrong by paying peanuts and then being surprised when they get monkeys.

Re:No

[gweihir]

Actually, if you have somebody really good, then they can handle all of that in one person, no gateway, no additional layers. But you can expect them to not work for the laughable money developers get paid these days. If you look at proper established engineering fields and then compare with IT, you find the difference pretty extreme. Incompetence and very, very narrow competence seems to be the norm in IT, not the exception as in proper engineering. IT has to overcome that, but it will also mean no more cheap coders (that end up costing a lot more) and somehow the about as incompetent IT management cannot handle that.

Re:No

[Kjella]

But they all stem (in part) from the same root-cause: A slow realization that IT personnel is routinely not very good and that you would need far less IT people if the were really good. Of course, the usual implementation does it completely wrong by paying peanuts and then being surprised when they get monkeys.

Meh, sometimes you pay very expensive consultants and you still get shit. In my opinion there's way too much focus on the process and far too little focus on the actual output. And by output I don't mean the finished result, but from each step in the requirements -> solutions -> systems -> functions -> code chain. It doesn't matter that much if you're trying to cook and eat the elephant in one piece (waterfall), chunks (iterative waterfall), timeboxes (agile) or nibbles (continuous delivery) if it's still raw or spoiled.

I know everything is much easier in hindsight but every time we fail we should backtrack and see where we actually failed. Like, is this a code error, a low level design issue like a missing function, a high level design issue like the overall data flow is wrong, is it a requirement that was implied but not properly expressed? And then go back and see when we did this, why didn't we see it? Yes, some issues and needs you only learn about by actually running into the problem but a lot of other things are simply "we didn't think this through" and maybe we should.

Re:No

[N1AK]

Very narrow competence is extremely common in engineering even where there is strict regulation of the term. I've known engineers who focus on specific technical fields and engineers who are generalists. In both cases they would be very poor at doing the other job, at least without considerable training and experience.

You're also dismissing the complexity and variety within IT by claiming someone really good can do everything really well. Even if they have the base skills to be able to be able to do anything really well they won't have the exposure and experience in all areas. Service desk roles are often seen as 'entry level' or not requiring proper IT skills, however my experience of the best service desk staff is that they share attributes with many other high performers in IT, the ability to effectively define and work through problems for example, but also extensive experience and understanding of user facing systems, user behaviour, endpoint hardware, business requirements etc.

With that said I'll be the first person to agree with the argument that performance can vary considerably between individuals, and that companies often shoot themselves in the foot by restricting wages meaning they end up doing with 8 people what could be done better and cheaper by 5 higher performers.

Re:No

[Bert64]

In the past 30 years, IT has gone from a niche field for a handful of geeks and very large businesses, to common and ubiquitous. However, the pool of available competent people did not increase so fast and thus you have cheaper incompetent people filling the gaps.

To make matters worse, a lot of vendors (especially microsoft) have been marketing their software as easy to use and not requiring an expensive competent sysadmin to manage, but the reality is that while someone with low skills can get a system limping along it will perform poorly, as well as being unreliable and insecure.

Re:No

[gweihir]

It is more like 1 high performer instead of 30 low performers from my observations. And the problem with IT folks usually is that they are not _engineers_. They lack the mind-set. A proper engineer that has specialized in a narrow field can still learn another field or go broader, because they have a solid engineering foundation. Sure, takes some time, but most IT folks are true 1-trick ponies and no good engineer is ever that restricted.

Re:No

[postbigbang]

And you touch on the root problem with this entire question.

The question was conjured by a writer at ZDNET so that the question could be answered in a compare/contrast article that made the author money.

The blazing, glowing, throbbing problem with the title is that it's a question and when a question is posed as an article headline, the answer is almost always NO, leading to lots of considered, even heated replies as to defend the answer.

The tl;dr is it's designed to sucker you into a conversation. My actual sentiment is to say: no. None of these are the same thing, except they're all coding. Three incongruent avenues to coding.

Re:No

[ilguido]

In my opinion there's way too much focus on the process and far too little focus on the actual output.

This. Exactly this. There are so many things wrong with how these things are actually implemented in the real world! The bosses who are sold on these ideas do not understand that a good process does not substitute competent people, that is you need competent people in order to have a functional process and not the other way around. Moreover there is not one process to rule them all, different tasks, different projects may need different processes.

Yes

[Anonymous Coward]

They are all bullshit ideas from management that do not work in reality

Re:Yes

[LostMyAccount]

Management has a vested interest in systems which allow a small number of people to control a large number of people. It enables the people at the top of the organization to claim to be in control and extract large compensation amounts for the benefits of their control. Switching to another system usually involves a compelling purpose for switching from the existing system and almost always it's the promise of reduced costs. So most modern systems of management really are focused on control and cost reduction. It's no surprise that when you focus on control and cost reduction as your primary goals that the ability of these products to achieve goals like "quality outputs" are seriously in question and often a failure from the perspectives of those subject to these systems.

Re:Yes and No

[Idimmu Xul]

Yes and no.

Specialising is often necessary due to hiring and experience constraints.

You can't be immediately good at everything but the project needs code, databases, networking and infrastructure.

Sure you can get code off the ground by a beginner who's taken a Udemy course and managed to get something up and working on Heroku and Mongo cloud, but what do you do when the platform grows, you need to move to AWS or/then physical infrastructure to reduce costs and scale.

You want the same guy to learn AWS security policies or hire in for it?

AWS costs have spiralled. You've now moved to the datacenter, you've got some dedicated infrastructure provided to you in a VLAN via a switch the datacenter manages. You expect the same developer to know the ins and outs of the operating system, kernel tuning, scaling the service horizontally and the database too?

Now you've leveled up. You own racks, you're running redundant BGP services for peering, you're managing your own switches with their own VLANs, you've got keepalived rewriting MAC addresses to reroute packets between machines.

Same guy for complete company life cycle? Or can we hire specialists?

Empty buzz words..

[Junta]

They all have the same goals, which is to deliver high-quality software on a continuous basis, collaboratively.

This is obviously what everyone wants and some people think waving some philosophy or methodology wand can magically make this happen. The people who kick off these pseudo-religions by reflecting upon the moments they experienced a good team making a good product, and thinking "boy if everyone pretended they were like this good team, everything would work out, here's some ways to pretend..."

If they do a good enough job naming and headlining their methodology, marketing type folks jump on board, get it out in the media, get certification mills running, advertising efforts start to coalesce around this next silver bullet that will make your terribly dysfunctional team of bottom of the barrel employees perform like the best. Key leaders get seduced by the profit potential and likely don't even realize their original vision isn't panning out.

Then when a critical mass of people observe that terrible teams are still terrible teams despite ostensibly adopting 'habits of effective people' someone inevitably proclaims a *new* methodology (which generally is the same as the old methodology) to start the cycle all over.

The reality no one wants to acknowledge is that success requires a *small* team of *really good* folks at the core. At *best* that would mean a company actually has to spend money and that is not the answer they want. At *worst* it means that the talent they need is simply unavailable at any price, or that if it is, they wouldn't have a clue how to recognize and distinguish such talent from crap.

Re:Yes and No

[Junta]

Though it is a parody of project management methodology, it is a good way to illustrate how a vague 'methodology' can be twisted into whatever you want it to be.

You assumed that they are advocating for sequestering themselves off somewhere and doing what they want and the users having to live with it.

I on the other hand would fixate on "We are tired of being told we're socialy[sic] awkward idiots who need to be manipulated", as a way of saying programmers can work more directly with their user base without management having to micromanage that interaction. My perception stems from the reality that a group I collaborate frequently with that declares 'Agile' somehow has developers that have never had a single conversation with a user of their software, and somehow the team justifies this through application of Agile-compliant buzzwords to describe their dysfunction.

Re:Yes and No

[Junta]

After observing teams ranging from a handful of servers up to thousands of servers, one huge mistake I see oft repeated is a company getting all tangled up in trying to use complex advanced function they do not need, introducing fragility and hard to debug behaviors that no one quite understands.

Yes, various advanced functions have their uses, but there is a high probability that if you are trying to integrate a high number of them, you are *probably* making things needlessly difficult. Even if it could provide value, that has to be balanced against your own limits and perhaps it's better to forgo that value for the sake of staying in reach of your competency (by all means learn things and grow competency, but don't overextend yourself).

Agile is NOT supposed to increase quality

[raymorris]

The summary has it wrong.
According to Scrum.org, Agile is *not* supposed to improve quality, that's not one of its goals, and indeed it deliberately chooses to sacrifice quality in order to achieve it's goals.

Agile has two main goals it can achieve:
1. Working around the fact that most programmer were never taught how to properly determine requirements.

2. Getting partial implementations out the door faster, so the organization can get part of the benefit before the system is finished.

By giving up on teaching how to determine and document requirements, quality is reduced.

By purposely pushing out code before it's done, as soon as it might be somewhat useful, quality is reduced.

That's not to say Agile is bad. Getting half-finished software TODAY instead of completely finished software three months from now may be very valuable in many cases. It just doesn't improve quality.