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

[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

[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.

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.