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

[Cederic]

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

I don't expect my good software and hardware engineers to know how to solve all problems across all domains.

I do expect them to know that there will be a problem and articulate it sufficiently for a domain expert to provide a solution. I absolutely require them to be able to assess the viability and appropriateness of that solution.

This is why T shaped people are so valuable and never struggle for jobs. Be great at the thing you're great at but good enough to spot the bullshit everywhere else.

Re:No

[angel'o'sphere]

It may actually be shrinking, because the competent ones get lumped in with the vast incompetent masses and get treated as badly. Smart people will avoid IT just because of that.
Actually most of my friends in software development (I guess that is what you mean with IT, as we mean something different with IT) are early retiring from work. The main reason basically is: companies don't value the people doing development and system maintenance. With not value I exactly mean that: they value the cook in the kitchen, they value the nice looking secretary, they value the key account manager, they even value the security guard etc. but they don't value the developer or IT guy. However, 90% of the managers simply have not grasped yet: their company is an IT company. It does not matter what the company actually is doing, power generation, airline, railway, car manufacturing, selling books, crafting medical devices, etc. There is basically no company, not even a law firm, that is at its heart not an IT company. But: instead of realizing that their IT is the engine driving them forward, they consider it the "necessary evil" that only costs them.

Of course there are exceptions, like Zalando.

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 and No

[Jane Q. Public]

They really are all part of the same thing.

But this "splitting" it up into different fields is an attempt by some people to over-specialize.

Over-specialization, in turn, is an attempt to get paid more for doing less.

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?

Re:Yes and No

[mrvan]

Programming, motherfucker, do you speak it?

They claim to value: Responding to change

They really value: Instability and plausible deniability

We fucking do: Programming, motherfucker!

Re:Yes and No

[Idimmu Xul]

Interestingly, I see a bit more room for generalists in Agile and DevOps shops. Even if hiring practices still havenâ(TM)t caught up.

The 'devops' role is almost by definition a generalist. The best people that typically fill it are good enough to be developers in their own right, great enough to be systems administrators, good at QA, databases and a host of related disciplines. It's almost the inevitable by-product of experienced system administrators who know code and wrote code to get rid of repetitive tasks, at scale.

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]

The reality is that 'devops' has achieved critical mass as a buzzword, so any particular interpretation of what that means is both correct and incorrect in the current reality.

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

Yes and no

[Bud]

Lean IT is about delivering quickly and cheaply, Agile about delivering high value compared to the costs, devops about taking responsibility for your work. If you start with one of these methods and take it to its logical conclusions, you'll end up with something that isn't very far from the others.

The idea that you can start with a mishmash of all three is probably not productive - there's a kind of learning journey you have to go through - but I'm willing to change my mind if somebody delivers proof.

when you think about Agile, Lean IT and Agile..

[Idimmu Xul]

from tfa..

But when you think about Agile, Lean IT and Agile, aren't these all the same thing, essentially?

Well, two of them are ..

It's like a Venn diagram

[rgbe]

They are not all the same thing, but they have components which are similar, like overlapping circles in a Venn diagram. DevOps is the result of Lean IT. If you need to make things such as release cycles go faster, then you will end up with automation of manual and repetitive tasks, hence DevOps. Lean IT is largely about reducing waste. So if you reduce the size of the development cycle, you reduce the likelihood of a large amount waste occurring. From that comes Agile, small bite-size chucks of work. Although lean IT is not just about development.

I'd say no

[Idimmu Xul]

Agile is a project management paradigm.
Devops is a software *delivery* paradigm.
Lean IT is an accounting paradigm.

Agile is usually in contrast to a waterfall model. Agile has quick iterations where things can change whilst waterfall has one large iteration which hopefully ends with a delivered product.

Devops is the application of development tools to managing operations. This then paved the way for things like continuous integration, automated testing and deployments, cloud infrastructure, infrastructure as code, continuous delivery etc etc i.e. operations driven by code.

Lean IT is the is the elimination of waste.

You can implement devops practices with both Agile and waterfall. Devops doesn't rely on Agile's iterative premise of essentially not knowing what you're building until it's built. If you're doing waterfall and youve come up with all the requirements before hand, written Z notation or whatever to define behaviour, front loaded the work to complete all the test plans before the code is written, why not run CI to do automated testing and deployment as the code is written?

If Lean It is the elimination of waste, why does a devops environment have to be lean? Why can't I over provision cloud or physical infrastructure and just have it sit idly by doing nothing whilst running perfect, by the book, Agile project management and Devops takes place? What does the elimination of waste have to do with Agile or waterfall style project management? Neither Agile or Devops has the goal of eliminating waste, they have goals of delivering working code.

It could be said that Agile has a goal of not writing code that doesn't need to be written but the reality of that is when doing iterative sprints often because of the model, not knowing exactly what the customer wants for instance, you're going to end up rewriting code upon discovery that your assumptions were wrong. That's waste.

All three run together beautifully and there's plenty of cross over but to say they are the same or even have the same goals is naive.

Yes, of course

[93 Escort Wagon]

”Are DevOps, Agile, and Lean IT the Same Thing?”

Yes, they are all the same thing. They are buzzwords.

No. (explaination below)

[Qbertino]

"Agile" - Bullshit term (fake nown) stemming from the very real term "agile software development". The correct nown would be "agility" or "agility in software development" or "agile development". This is usually achieved by focusing on strict procedures and a clearly defined and limited set of tools and technologies in order to automate most tasks and be ready to quickly react to clients who don't know what they want to somehow know exactly what it may cost and when it needs to be finished. This is usually the case in the broader industry of web software development. This is why Scrum (offering those exact traits) is often used synonymous with "agility in software development" although it's just one method for agility. Albeit - done correctly - a very usefull and effective one.

"DevOps" - DevOps is the merging of administration and development through automation, standardization and ever increasing performance of computers and networks. Administrative tasks and development tasks move closer together, as both take less work and offer more enablement for IT workers. The line between development, administration and maintenance blurs, hence the portmanteau term "DevOps" - as in "development and operations". These tasks are also moved together because in the SaaS world product lifecycles are increasing shorter or in some cases perpetually changing, requireing IT experts to switch between development, maintenance and administrative tasks on a hourly basis.

"Lean IT" is a broader term describing the trimming down of IT in companies and ventures due to the ever increasing power and versatility of hard- and software. Tasks usually left to special computers and software are now increasingly being handled by off-the-shelf hardware, such as headless desktop computers serving as utility servers, upper-range consumer-grade NAS devices as essential fileservers or cheap generic web-based groupware for mission-critical document management. Stuff like this can nowadays also often be easily moved on to SaaS (aka "Cloud") offerings and back again with enough reliability and fault-tolerance that the risk associated with such an infrastructure shift is justifiable. IT gets leaner and cheaper, with less requirement for highly trained staff. A good example these days is the demise of the on-premise self-hosted MS Exchange groupware/mailserver that is replaced by web-based solutions or subscriptions purchased directly from MS and putting many high-earning MS Exchange experts out of jobs.

One could argue that all three concepts exist only because of ever increasing efficiency in digital technology, but the terms itself do describe different things.

My 2 eurocents.

They are not the same at all

[cjonslashdot]

They are different schools of thought, with different origins, and different communities. That said, there is overlap, and today many "Agile coaches" are intimately familiar with all three schools of thought, although the reality is that most Agile coaches know very little about DevOps.

In fact, DevOps arose partly out of the failure of the Agile community to address the things that DevOps addresses. The Agile community is largely controlled by the Scrum community, which is highly dysfunctional, because it is driven by a set of thought leaders who have turned it into a certification mill. It is their moneymaker, and they have proven to be rigid in their thinking (not very Agile!) and treat Scrum like an ideology. The Scrum community has done enormous harm to the Agile movement, which was founded on very strong principles (the Agile Manifesto), but which ran aground in the mid-2000s because of its inflexibility and dogmatic extremism. The ideas are not the problem - the "thought leaders" were the problem.

DevOps arose out of a need by big companies to deliver Internet scale things fast, while managing their risk. This later came to be known as DevOps. They did it by looking at the whole delivery process, end-to-end, and by creating enough automation and tests so that if something passed all the tests, it was good enough to release. Automation of deployment was an essential part of that, because end-to-end test require continuous delivery - you must deploy to a test env to run such tests. If you want to run those tests continually, you must deploy continually to the test env - hence the need for automated deployment. And of course A/B, canary and scaling deployments are a natural evolution of that. All this happened inside the Googles, Facebooks, Netflixes, and Amazons, and later came to be called "DevOps".

The Agile community was caught with its pants down, because it should have been talking about these things, but wasn't - it was stuck in the same old conversations over and over again - about how to have a good retrospective, how to engage the product owner, and so on - and completely ignored the technical side of things. This was regrettable because some of the early advocate thought leaders, such as Kent Beck and Ron Jeffries, were ardent advocates of automation and technical practices, but the Scrum community co-opted the whole thing and drove it into a ditch. Eventually, the Scrum community realized they were being overshadowed by DevOps, and they started to try to get back in the game by saying that one should use "Scrum plus extreme programming's technical practices". That's kind of weird because extreme programming also has ceremonies very much like Scrum, so if one uses XP, one doesn't need Scrum at all.

Now today the Agile community is trying to take itself back from Scrum, and get on board with DevOps.

Lean IT is another similar story. It because clear that the Agile community was not addressing how to "scale" Agile. The Agile community was saying useless things like "don't do Agile, be Agile" - yet offered no insights as to how to take action on that. So people looked to "Lean" and found some answers there.

And then there are things like Less and SAFe, which were attempts by some individuals to answer the question of how to scale Agile. The Scrum community was immensely derisive of SAFe - an indication of how insular and dogmatic it is, because they felt threatened by it - and indeed today SAFe is immensely useful in organizations that build big things - large programs needs actionable models for how to apply agile ideas at scale. Yet SAFe had its own gaps, namely it said little about the technical practices, but unlike the Scrum community, the thought leaders of SAFe embrace other ideas and have added DevOps to their mix of recommended things to consider. SAFe is not a methodology by the way - it is just a model for how to think about scaling issues.

So to bring all this "under one umbrella", one must consider that for those who know these schools of thought, they

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

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

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.

Re:Yes

[erp_consultant]

From my experience (over 20 years) it seems to me that management is more concerned with shipping something than shipping something good. It is mostly about delivering projects "on time". Quality issues? That's Support's problem.

For management people the next rung on the ladder is only attainable when you have shown that you can deliver projects on time and on budget. Quality is almost never part of that equation, unless the project goes horrifically bad. Even then they can usually lay the blame on contractors, or the offshore monkeys, or anything else that comes to mind.

This is one of the reasons, in my view, that we have so many poor managers. We have lots of people that have learned how to game the system but relatively few that actually know how to manage people and tasks effectively. Over the years I have had some great managers and they really stand out because they are so much better than the norm.