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

[Anonymous Coward]

The problem is, there is IT as in -- a person working at a hotel that handles "making shit work" with no coding or internal dev involved.

And then there is IT, in a firm which does development work... along with pushing that work to clients/for themselves/to live.

The second IT example? Needs to be a coder, or at least very much understand the technical issues coders will have. The first doesn't even need to be all that comprehensively trained.

I've worked in IT for decades, but as someone that *enables* coders to get their job done. I've also acted as the gateway for coders, ensuring that idiocy doesn't cause explosions.

Note that this is the same issue in reverse, but more common -- developers that have NO idea about how hardware works, about load issues with hardware, about security, the list goes on.

Whatever the case, you need a gateway person. That doesn't mean devs can't push to live, it just means that someone must set some level of method to push to live, without security issues, and with that gateway person monitoring things like load, etc.

My biggest gripe with devs, are the ones that love to push large patches on Friday at 3:40pm. Then go home for the weekend, while I get paged at 2am on Saturday due to load issues with that same new patch.

Incompetence exists in all fields.

Re:No

[Anonymous Coward]

Simple rule: You can't push to live on a Friday unless YOU are the one on call during the weekend.

Re:No

[Anonymous Coward]

but sales needs it for the weekend conference, so it's going live or heads will roll

Re:No

[jrumney]

Alternatively: they all come from the same root cause: the lucrative industry around selling training in the latest IT buzzword of the day to companies that are perpetually struggling to deliver quality software with their workforce of low paid coding school graduates.

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

[Anonymous Coward]

As I said, it just means that the one who pushes it live will be the one is who on call for the weekend.

That gives him the motivation to get it done right.

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

[gtall]

Just to amplify a bit, IT and programming do not occur in isolation. Each job has a context and the context is frequently complicated. So MS and others can produce a tool that promises to make a particular job easy, but those tools will not be able to bring the context into the user's mind. That's where it gets hard because many people do not have what it takes to learn context. So they can bang around on a keyboard, but they won't be designing a control system given the latest panoply of tools for the job. Rather they will cobble together some brief example code, some stuff they googled for, and incorporate a few suggestions from coworkers they could be arsed to ask.

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

[gweihir]

Indeed. I would go so far to say that the pool of available competent people has not really expanded at all. 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. And while I have managed to avoid this, I have to say that I got lucky in addition to being competent. If, for example, you bury people in bureaucracy, competent people will just go under even faster than the incompetent ones. Hence I cannot really recommend going into the IT field.

Re:No

[gweihir]

The implication is the other way round (why do people even here do not get how that works?): You pay peanuts, you get monkeys. If you get monkeys, you may or may not have paid peanuts, that is not specified by the implication. There is a lot of high-priced consulting out there that delivers really bad results. But the ones that deliver really good results are also asking high rates, although typically not as high.

Re:No

[Anonymous Coward]

This takes issue with research finding teams that tend to do consistently well, tend to be diverse and candid teams. In such teams, people do whatever they excel at, take time to teach/learn from one another, are outspoken and quickly resolve issues and are not harassed by management to fill 100% of their capacity, thus have capacity left to deal with other/new shit.

Management tend to enforce exact opposite, and also tend to cater to the one rock star, instead of making sure the team progresses and improves. This maximizes bus factor, lowers salary costs and tend to work OK as long as the people put up with it. When such rock stars leave, and such a star could even be the CEO, everything tend to crumble. The book "From Good to Great" is basic research on this.

Having rock stars are a symptom the organization doesn't work very well (bad flow), that management is incompetent (doesn't know what needs to be done next) and that the organization as a whole is oblivious to all the gaps this creates over time.

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]

the lucrative industry around selling training in the latest IT buzzword
That "industry" does not exist anymore since minimum 15 years, probably longer.

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

[Anonymous Coward]

If a company is lucky enough to have a rockstar, then it has one. And they won't stay in a bad company
But sure, many companies can't separate between a rockstar and their own asshole... ðY£

Re: No

[Anonymous Coward]

I think the problem is this....
You provide a hardware services to enable the devs.

The issue is that over time the devs then get pampered and have no knowledge of hardware and in the long run start to write code with no understanding on the realities of hardware.

That's where people start to realise that having devs actually know hardware and support as well actually make sense and can get a better result.

And for a time they do because they are a few smart people who are successful and grew bigger and simply cannot find enough smart people and they couldn't scale fast enough and smart people always demand more money so it became expensive as well. Then they again start to specialise.

I think it's a balance and you need to give people exposure, but you need specialised people to maintain depth of expertise.

There should be a balance of full stack people and specialised people in a large sizable team.

Re: No

[Anonymous Coward]

"Their company is and I.T. Company"

This is DevOps.

Re:No

[Anonymous Coward]

only allow new non-emergency deployments to occur on Tuesdays

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

[Anonymous Coward]

I disagree. They are all the same thing. Mindless bullshit pushed by overpaid consultants who sell management on the notion of getting something for nothing.

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

[ulski]

Yes. It is buzzwords on buzzwords.

Re:No

[Anonymous Coward]

An extension to this is focus on management. Development doesn't give good enough results, there are structural problems, the right people are not talking with each other. So management things shuffling around who reports to whom.
Why would that help? Teams that don't get along won't suddenly be best buddies because they now have the same manager 2 levels above. In almost any bigger company, communication is simply horribly managed. Sure, there's now stuff like "Slack" and "yammer" etc., but none of them seem to really do a GOOD job to help with large-scale, cross-team, yet interactive communication.
In politics the importance of embassies has been know since ages. Yet I am not aware of any company doing anything remotely like it. The closest you might get to is cross-team job rotations.

Re:No

[avandesande]

It's always the requirements. If you write sufficient requirements they would be transferable into machine code and what is the point of that.

Re:No

[Anonymous Coward]

Exactly this, we have about 100 pages on our process, but it's just a "yes-list" kind of procedure. Nobody gives a beep about the actual output in each step of the process.

Vague nearly useless requirements - check
Solution/design that is one sentence for each "module" - check
unit tests - oh yes, we will write those and then right after the code is finished "fix" them to make sure they pass whatever the code outputs -- check
functions - oh, yes... we wrote those... check

Re:No

[raftpeople]

Completely agree. While process can be valuable, the most important ingredient is having good people (smart+experienced) that regularly collaborate to review+adjust to keep the project on track.

Articles like the one in the summary are written as if these methods are new but they're not new. In my experience with enterprise projects (35 years), smart people naturally identify good approaches to problems. There is a continuum of approaches and smart people align specific aspects of projects with the methodology that makes sense, frequently combining them on the same project.

For example, I'm at the tail end of a complex multi-year project involving a facility with multiple vendors systems connected together and interfacing with material handling equipment and various types of user devices (voice control, rf, pc, etc.).

There are aspects of this project where it was most cost effective and efficient to be waterfall, the solution was known in advance and the cost of iterating through changes with multiple vendors systems software and hardware was much higher than up front design.

Other aspects of the project were more localized, but again the solution was known in advance so iterating through many areas with design then build was the right choice.

There were also some areas where the solution was not known in advance. These areas took a more agile approach of smaller design+build, test the theory with users and equipment and continue iterating. These areas remain open and in process because we understand the limits of our knowledge, we know we will adjust these areas within the first few days of go live and probably for the 12 months after.

Re:No

[DNS-and-BIND]

Yeah, but if you get the right process, you don't need competent people. You can just hire H1Bs off the boat and as long as they follow the process, they produce the same results as the expensive workers. Why spend more?

Re:No

[ShanghaiBill]

I worked in IT 30 years ago, and there were plenty of incompetent people back then as well.

I am skeptical that the proportion of incompetents has actually gotten worse.

This appears to be a case of Golden Age Syndrome.

Re:No

[Bert64]

Yes, perhaps more than 30 years ago but depending on the field...

When i worked for a small ISP years ago all of the technical staff were geeks who were keenly interested in technology both professionally and as a hobby. They would learn new technologies on their own and introduce them into the workplace, they would come up with creative ways to solve problems and look for (or create) the best tool for the job.

These days, there are a lot of people for whom technology is simply a job, once they finish work for the day they have zero interest in technology. They do not seek out new technologies, and don't want to learn them unless forced to do so. They won't come up with their own creative solutions, but would rather just buy products and pass off responsibility to someone else.

Re: No

[Anonymous Coward]

This sounds like the guys I work with / work for. Our technology decisions are shit but that's all they've ever known and they don't care to get with the times. They just hope we get acquired soon so it becomes someone else's problem.

Re:No

[Anonymous Coward]

Agile and lean are management strategies, and devops is a strategy for deploying software. None of them is actually coding.

Re:No

[postbigbang]

The output of all three is (hopefully) working code. My description is of the output. I don't talk about gas, diesel, and hybrids, as fuel consumption methods, rather, all three are auto/truck transportation motive design methods. You quibble too easily, AC.

Re:No

[mirthful1]

Be interesting to do a startup of these types of early retirees you mention -- folks that still might just want to get back into the saddle for 'one last great project'. They're not in it for the money and more the craft. Also, they're probably more aware of their 'faults' and able to moderate those better with age/wisdom. Now, approach a VC with NO idea but that staffing plan, lol. They often have ideas but no team. Curious if anyone would bite :)

Re:No

[Etcetera]

The problem is, there is IT as in -- a person working at a hotel that handles "making shit work" with no coding or internal dev involved.

And then there is IT, in a firm which does development work... along with pushing that work to clients/for themselves/to live.

The second IT example? Needs to be a coder, or at least very much understand the technical issues coders will have. The first doesn't even need to be all that comprehensively trained.

I've worked in IT for decades, but as someone that *enables* coders to get their job done. I've also acted as the gateway for coders, ensuring that idiocy doesn't cause explosions.

I think this really hits the nail on the head... But it also highlights an important part: IT is not your product, and once IT is going beyond "allow the devs to get laptops working and their local apps to function", you're really in a separate area. At a previous location I worked at, there was a giant line between Corporate IT and, what we called for lack of a better term, Cloud Infrastructure (even though it wasn't a cloud, it was just our server farm).

If you're administering a server that sends data out to customers, you're not IMHO doing "IT" any more.

Re:No

[tommeke100]

I agree and would like to add that even during _real_ Engineering Studies, your specialization (for example parallel processing) is really only a couple of courses, projects and maybe your thesis. Same is true with for example Machine Learning. As an Engineer you should be able to step over to a related field and get that amount of theoretical and practical knowledge (I'm not talking experience) in a couple of months to a year.

Re:No

[Anonymous Coward]

In IT, there is no such thing as being great at one thing. It's a strange profession where being great at one thing typically means you're great at most things. It's actually an interesting area of intelligence research because mastery is paradoxically inversely related to experience. It's seems to be because anyone who spends enough time on one thing to become experienced, will not have enough deep understanding to master the area. In this case, deep understanding comes from understanding how the area interacts with other areas, which requires understanding those other areas.

I guess you could describe it as most professions can have mastery in an area without similar understanding on other areas. In IT, in order to have deep understanding in one area, you need similar understanding in all areas. But this is not as difficult as it seems. Most of the issues are intuitive to those with strong abstract reasoning. Abstract reasoning is also a skill that allows one to horizontally transfer understanding from one area to another.

Re:No

[gweihir]

Indeed. Somehow the most critical people are treated as the most expendable ones. It boggles the mind.

Re:No

[gweihir]

That magic process does not exist. You always need competent people to get good results. And you always need to be able to trust the people that work for you.

Re: No

[Anonymous Coward]

Even with full-stack developers, you will get shit code. Most dev environments I have been in valued making deliverables set by marketing, and likely already sold to customers, so the goal is to get the code in. Nothing else matters, be it focusing on resources, security, robust coding, or anything else. Then, once that deliverable is done and the dev team actually has made what marketing sold... marketing goes and sells another fantasy feature again, and the mad scramble with a permanent sprint begins again.

The problem is that the customer expectation for code has been lowered. What what once alpha quality stuff is now what hits production. The "it builds, ship it" joke is now our reality. Because this is what customers buy, companies will happily sell junk ridden with security holes, where the only real working mechanism is the telemetry and analytic grabbing.

Until the VPs and C-levels actually see stuff happen that affects their world, it doesn't matter if you have a full stack developer who knows CPU ISAs all the way to the web language... you will still get the same garbage code as you would if you just offshored everything, just because there is no interest and no room for developers to focus on anything other than getting that latest bell and whistle checked in and into production.

Re:No

[Anonymous Coward]

Also ideally you want at least 2 of those people that can back each other up. People do like to take vacations and do change jobs and do get sick....

Re:No

[Pseudonym]

Yeah, they are all very different certifications which require distinct expensive training courses. Now hand over several thousand or else.

Re:No

[Anonymous Coward]

Wow. This is so so so true. Most of IT sucks and they suck even more by going to conferences where they come back with some big yappy mouths and learn some cool talking points to show off. I am stunningly surprised sometime how bad all the outsourcers are and especially surprised how most of the IT guys are ok to not learn to be good at their own trade.

So.. NO.. None of these words are same thing but in a IT context, YES. They are all same sh*t that doesn't do sh*t.

Re:No

[Ensign Nemo]

I thought the whole point of devops was "Developers and Operations" working together? I see very little of that.

I see way more "DevOps engineers" who act like they are most important part of the entire company. I've been in meetings with IT/DevOps directors and this attitude of "we should be in charge of everything and we know best" is pervasive even though it is abundantly clear they have never done development or anything outside of IT. I am not exaggerating either. I think I understand why there is so much disdain for IT.

Devops has become IT with new shiny tools and massive chips on their shoulders. IT used to be "data janitors", which I also didn't like, to "engine driving things forward", which is just as stupid. ...

"But: instead of realizing that their IT is the engine driving them forward,"

This attitude has warped and become "We're the most important group of the company."

IT is a piece of the puzzle. It's a piece that is an important as all the others and should have the same respect, but get over yourselves, you are not the engine driving things forward. You're a gear in the transmission; one of many.

Re:No

[gweihir]

Indeed. And for sure there are IT/CS/Coding people that can do that. They are just very rare.

Re: No

[Anonymous Coward]

The problem.is they want to pay each of those two half as much. Then wonder why they need two in the first place since everything is working and there is no down time...

And then the remaining one leaves when he gets tired of half pay. On the plus side I made $200k in the last year and doing some (generally) fun renovation work and that is taxed at cap gains rates.

Re: No

[Anonymous Coward]

You seem to think your company is terrible at making boats, when in fact they are a very successful bicycle company.

Re:No

[Anonymous Coward]

This is what bean counters don't understand.

The advantage a company has over the competition is never the machinery or the process.
If those mattered then banks would be willing to give a loan to any nitwit willing to buy those and fund that company until they have ran you out of business and can jack up the prices.

The thing that makes one company better than the others are the knowledge of the workers.
A competitor can try to get them, but they can't offer them the same salary, workers need to get a better offer to be willing to move.

If you can reorganize a company so that the workforce is replaceable then anyone can hire an equivalent workforce and do the same thing you do.
If you then try to make any profit at all that means the competition can do it cheaper.

Re:No

[Anonymous Coward]

Of course, the usual implementation does it completely wrong by paying peanuts and then being surprised when they get monkeys.

Yes, because if you want elephants, you should be paying bananas!

Re:No

[Anonymous Coward]

To management, having two employees is like having two cars. One car is "good enough", and two cars costs too much. It is expected for the sole admin not to be sick or go on vacation, as management can show how they are maximizing human resources. When in reality, that admin likely will ditch sooner or later.

Re:No

[Cederic]

It's a strange profession where being great at one thing typically means you're great at most things.

Hmm, no. You can be great at software engineering but that's a massive field in its own right. There are four people on the planet that are great at algorithm design, software engineering, network topologies, storage configuration, database administration, project management, testing, service acceptance, hardware design, disaster recovery planning, data centre wiring and data science, all at the same time. Well, four people with a margin for error of 4 or so.

Most of the issues are intuitive to those with strong abstract reasoning.

20 years experience means you don't need to reason, you know the answer already. Hands-on implementation experience means you avoid the mistakes that intuition can't escape.

Abstract reasoning is also a skill that allows one to horizontally transfer understanding from one area to another.

This is why you can develop that broad base of understanding. But don't pretend you're great at everything.

All of the things I listed above I can do. I can do them well enough to bullshit people working in those domains. I can them well enough to keep their customers happy.

I also know I'm far from great at most of them. I just happen to know enough to spot the difference, and to spot when the domain experts aren't doing their job well enough. I understand enough of the language, approaches and techniques to help them deliver what I need. I know I could do their job, I just can't be arsed spending five years getting to the level of knowledge and experience that I expect them to add today.

A man's got to know his limitations.
-- Harry Callahan

Re:No

[DNS-and-BIND]

That just means the process has not been adequately broken down into discrete tasks. If this happens you need more consultants to train your people better. Or they're untrainable and they need to be fired and replaced with cheaper and more pliable immigrants.

Re:No

[angel'o'sphere]

but get over yourselves, you are not the engine driving things forward. You're a gear in the transmission; one of many.
Nitpicking very much?

So what is the engine?

A company is like a ship. It is is the engine, the gears (if it has some), the transmission and the security and communication systems if you don't grasp that, you should not run a company.

Re:No

[mapkinase]

You described the world of which I have managed never be a part since I submitted my first program on cards to the punchcard girls. I do believe your horror story, though.

Thank you God for sparing me.

Re:No

[Anonymous Coward]

The bosses who are sold on these ideas do not understand that a good process does not substitute competent people,

Exactly. People are not interchangeable, especially not the good ones.

So to have success with sw, you have to be able to indentify the good ones, and you have to do whatever it takes to attract & keep them.

But this is not what bosses want. They want interchangeable people, because that makes management so much easier. (Failing to see that if people were indeed fully interchangeable, most bosses would be redundant!) So bosses fall for every marketing scam, every management theory that have "interchangeable workers" in them. Because that is the one thing they must get working. So far it hasn't worked, and they cannot see that it never will. For it'd be so profitable, if interchangeable people came true! So they are desperately seeking, as if in a goldrush or looking for money trees or fountains of youth.

Re: No

[illiac_1962]

Let me rephrase that. All of those buzzwords are about delivering extremely poor solutions FASTER! Makes me think of all the dirty code snaking it's way to production...FASTER!

Re: No

[pak9rabid]

jump.net?

Re:No

[gweihir]

No, it does not mean that. Seriously. Maybe when everything in IT is standardized (in 100 years or so), such a process can be created, but not before.

Re:No

[gweihir]

Well, "A" players hire "A" players, but "B" players hire "C" players. Seems to me the bosses are mostly "B" players (or worse) ...

Also "never promote people that deserves it, because they will not be grateful" (Machiavelli, I think).

Re: No

[gweihir]

LOL! Excellent! That is sooooo true.

Re:No

[Anonymous Coward]

Sturgeon's Law applies here, as everwhere. Trouble is today, the big internet companies soak up so many of the good developers, that the remaining available pool for the other jobs is skewed even further towards crap - rather than the 10% who are not crap, you only have 5%.

And then you factor in (I've been in IT for 35 years) that back then people went into IT because they liked it, not because the dot com boom and 'The Big Bang Theory" made being geeky cool, and I doubt that the ratio these days is anywhere near as good as it was then.

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

[JaredOfEuropa]

Specialising is often necessary due to hiring and experience constraints

In a way. I’ve often said something similar, except that I called (over-)specialisation and the increasing compartmentalisation of work the result of lazy HR practises. Once you are almost solely relying on well defined specialist “resources”, you’ll find that specialists are a lot easier to manage (and replace!) than generalists. That’s the difference between managing resources and managing people. And while your output will not be as good with specialists, it will be more consistent; what someone called “predictable mediocrity”.

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

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

[bmimatt]

This.

They do work well together. But only when implemented correctly across the org.
Most of the time it's just blind leading the blind down another dark corridor, while singing the songs of Agile, DevOps, shared responsibility while forcing shit culture on everyone under a new label.

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

[Anonymous Coward]

I can do all those things and a hell of a lot more.

Re:Yes and No

[Anonymous Coward]

Without speaking to end user, you're developing shit.
Without testing, you cannot and should never, refactor.
Continuous Delivery can take some getting used to, but cuts down the feedback loop in the extreme.
But if one is a programmer, one is ofc oblivious to these higher concepts and just do what they're told.
Being a developer might sometimes mean talking to upper management, or even be a CEO.

Re:Yes and no

[angel'o'sphere]

DevOps is not a method. It is a job description.

No idea why americans don't get that.

Re: Yes and No

[Anonymous Coward]

I disagree. Agile and Devops are not the same. I don't know what Lean I.T. is so I won't write about it. A team does Agile, whereas a company does devops. Agile can have a team in which there are no members who actually put the code on a machine. In Devops, these guys are integrated into the process.

Agile is how a team manages their work. Use scrums, kanban boards, and have meetings about work. The focus seemed to be to improve a developer's life so he doesn't need to work late.

Devops is how a company manages its work. A company is no different from a car factory. Work must be visible so that we can identify bottlenecks. There must be feedback at each step. There is a recognition that software developers must include and think about the I.T. side. If you forget about the I.T. side, then your company will fail.

(The way software is written affects how it is deployed, and if software isn't written properly, it can be extremely difficult to deploy, and extremely costly to run)

Both focus on continuous improvement.

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

Re: Yes and No

[Anonymous Coward]

...Until you realise your the Brent in the organization, and your entire work queue is filled because you haven't distributed your knowledge to other programmers, and the project will never get done on time.

Re:Yes and no

[Anonymous Coward]

The methods used are part of DevOps, but that's not the whole story.
Primarily, as I understand, it solves people and culture problems (throw it over the wall, blame the other team, handover delays, etc.). It borrows from Agile and Lean but is not the same.

Re:Yes and No

[Anonymous Coward]

Same guy.

Consider, what you just wrote.

You clearly, have some breadth.

Re:Yes and No

[Idimmu Xul]

I have a hard enough time finding developers that catch and log exceptions, let understand anything outside of their IDE

Re:Yes and no

[Darinbob]

Agile is not just for IT, or even primarily for IT, it's just a product development style. DevOps is mostly an IT thing, it only makes sense in the context of having customer facing servers; so you make operations and development the same group, despite no commonality in skill sets, so that you don't have to hire as many people. Lean IT I dunno, I haven't done IT since the 80s, but it was always lean and underfunded back then. But they're most certainly NOT the same thing.

Re:Yes and No

[Anonymous Coward]

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

Whilst I agree you can't be immediately good at everything, I firmly believe (through experience) that if you hire sufficiently talented people that they can pick up and resolve issues in tangential areas quicker than specialists in those areas often can. I've certainly seen enough devs solve IT problems faster than IT only folks, for the simple fact the devs understood what was going on under the hood; problem with an OS? It's the job of IT folk to sort it, but a dev will understand the technical details of the error and the solution better than IT folk will.

And the same applies to the role of devs too; a strong architect who comes from a development background will solve development problems quicker and more gracefully than most developers can and so on; this is often why you pay these people more, not simply because they're just "better" specialists, but because they can specialise in more things too.

But for me, and this is where I agree with you, it's not practical to hire "just" these people simply because they're a) expensive, and b) there aren't remotely enough of them on the planet to go around. Even if you could afford to outbid the competition to pay them their worth, you'd probably struggle to make your money back, and you'd never find enough of them regardless.

As such, when you do get this type of person, the constraint isn't that they can't do these things well, it's simply that they don't have enough time to do everything, and as such the best way to utilise them is to give them sufficient freedom to orchestrate things as they see fit - if they tell you their time and contribution is best spent on problem B, whilst some other people struggle on with problem A, then don't overrule them and stick them on problem A, trust them that the most likely way that A and B will get done is if they dedicate themselves to problem B because they've deemed it the problem most needing of their attention, whilst problem A may well be solveable by general staff, albeit in a longer time frame.

Re:Yes and No

[JDShewey]

DevOps is not a role and if you are hiring "DevOps Engineers" you are doing it wrong. You don't hire "Agile Developers" - agile is a method that developers use. The same goes for DevOps. It is a way of running a team. That team should be made up of generalists and specialists as is appropriate to the size and business needs of the organization.

Re:Yes and No

[Anonymous Coward]

The 'devops' role is less a generalist and more a multi-role specialist.

A generalist would be okay at a number of things but they don't want that. What they want out of a devops person is to have one person who can do everything, probably to the level that a specialist in each area would do. DevOps is a buzzword that means "you will be doing everything from design through to user support and training". It is a word that, to me, means "we want 6 people for the price of one".

Your own description is at least 4 separate jobs, each prefaced by 'good at' or 'great at'.

Re: Yes and No

[Anonymous Coward]

Strange how people who complain about not being able to hire "good" people always seems to fail to mention the three things that might attract good talent:
Location
Pay
Working conditions

A great offer in Bumfukistan is not attractive in a major American city.

A hundred k for a talented devop, or whatever, is not so good when it is for endless eighty hour weeks and 24/7 on call, especially when the CapEx budget is enough to buy laptops or replace the aging UPSs and power supplies, but not both.

Re: Yes and No

[Idimmu Xul]

$100kpa (USD), Node/React developer, fully Remote, standard 40 hour week, flexible with working hours as long as there's some cross over with JST 9-5.

The problem is probably more down to the fact javascript developer arent real developers as the loation, pay and working conditions seem reasonable to me? ðY

Re:Yes and No

[Anonymous Coward]

DevOps only works hand in hand with self-provisioning environments, the most extreme versions of these are the cloud providers.

Developers who know how to code, might know how to tune a webserver, but don't need to bother with the underlying OS, networking, etc...
If you can get a good platform (AWS, Azure, Google) where you don't need to worry about setting up your network and configuring interconnectivity and don't need to know more about load balancers than which strategy you would like for your webapplication, then you're on track for DevOps.

If you want to run everything in house, and one team should do everything, prepare to hire network engineers, sys admins, capable electricians, dba's and developers. That is not DevOps.

Yes.

[Anonymous Coward]

Now iterate.

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.

Yes

[Anonymous Coward]

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

Re:Yes

[garethjrowlands]

Care to share your experiences of them? I sense anger in you but there is hope.

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

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

Re: Yes

[Anonymous Coward]

I agree about managers, projects and quality. But are you claiming that these things are to do with lean, devops and agile? All three try to avoid projects and try to concentrate on product instead. All three require and measure important aspects of quality. For, example devops and agile both mandate automated tests and a 'green build'. Lean and devops talk of left-to-right 'flow', which does not work if there is poor quality. And they optimise for right-to-left feedback mechanisms so any downstream problems are found quickly.

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

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

[Anonymous Coward]

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

Agile's pronouns are they/them.

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

[Anonymous Coward]

Two out of three ain't bad

Agile is like active methodology in teaching

[Rosco P. Coltrane]

it works only if the practicioners (teachers or coders) are phenomenally good. That is to say, in the real world where most teachers or coders are average, most of the times it doesn't. That's why there are so many failed Agile projects out there, for the odd one that functions well.

I thought the development world had realized that by now: are we still under the spell of this fad?? Jeez... Some things just refuse to die.

Re:Agile is like active methodology in teaching

[Anonymous Coward]

> it works only if the practicioners (teachers or coders) are phenomenally good

When talking about Agile, people usually mean Scrum, so I will focus on that. Scrum usually contains daily scrum meetings. Daily scrum is where I spot those who are not good. If the person keeps on doing a task that would normally take one day at most, I know that he is either lazy or having serious problems. Obviously if you have nothing but bad apples in your project, there is nothing that will save you. But daily scrum is really good way to spot those who can't do their job.

Re:Agile is like active methodology in teaching

[Anonymous Coward]

A good manager can figure out who isn't getting work done in a timely fashion without dragging everyone into daily meetings that they'll all hate.

Re: Agile is like active methodology in teaching

[reanjr]

Sometimes you plan to work on one thing, then get derailed. Just because someone brings up the same task during standup every day doesn't mean they're not getting shit done.

Re:Agile is like active methodology in teaching

[HornWumpus]

An unproductive programmer can turn the 'daily standup' into a routine, long, waste of time (e.g. Vi vs Emacs, tabs vs spaces, normalization, comment style etc etc).

Thus lowering everybodies productivity to his level for 3 or 4 hours/day.

The fact is that 'daily standup' is just a 'meeting' type manager misapplying his favorite mode of communication.

Re:Agile is like active methodology in teaching

[Anonymous Coward]

Any team lead who lets a junior programmer get in the way that much, is a bad team lead. Juniors are going to Junior, it's up to the system around them to make sure they're presented work in a achievable enough set of very specific instructions so that they don't get too blocked. If your Junior dev keeps derailing the senior devs on the team, yea, the junior is doing, something wrong, but you're doing something waaay more wrong.

A daily standup is a fast way to share current priorities among a team and allow for collaboration without getting bogged down in details, anyone who just turns it into another pointless meeting is probably missing the point in agile like 40 other different ways and the team has more issues than just "long standups".

Re:Agile is like active methodology in teaching

[HornWumpus]

Anybody who needs a meeting for daily status updates isn't doing his/her job. A daily standup is _not_ fast compared to each coder firing off an end of day progress update, then glancing at the project plan/issue DB at the next start of day.

That's what email, project, issue tracking and source control is for (depending on what phase of development you're on).

Who says it's a JR programmer wasting everyone's time? _Most_ teams are pretty damn dysfunctional and don't know how to promote.

What % of your dailys require doing anything to the project plan? 1-2%? Those are the days a competent tech lead calls a meeting. Other days, you just update the tasks to reflect ongoing work.

Slashdot editing?

[Anonymous Coward]

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

Didn't take much thought to identify that two of those are pretty much identical, not sure about the 2nd Agile though.

Only a Millennial would ask such a silly question.

[HotNeedleOfInquiry]

Only a Millennial would ask such a silly question.

Only one Methodology Counts

[Anonymous Coward]

"Destroy && Deploy"

Re:Only one Methodology Counts

[Anonymous Coward]

I believe you past the test !

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.

Re:I'd say no

[MobyDisk]

This is the only correct answer I have seen so far here. The article is like asking if software development is the same thing as working in IT. To a lay person not in the field, yes they might seem the same. To anyone in those fields it is very different.

Re:I'd say no

[KingMotley]

I have to agree that this is the only answer I've seen so far that is actually right.

Agile is often at odds with Lean. Agile wastes a lot of time and effort in rewrites that you wouldn't have with waterfall. DevOps (CI/Unit Tests/automated security scans/CD) becomes vastly more important with Agile because you are making so many more builds than you would with waterfall. In order to change from say monthly or quarterly builds to weekly/daily (or multiple per day) builds, you simply can't have a QA team that keeps up if they are doing it all manually.

Re:I'd say no

[mapkinase]

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

Wrong. Not very wrong, but substantially wrong.

Waterfall model was gone long before Agile. People understood iterative nature ("back to design because only during implementation we discovered this design flaw") long before Agile.

Agile is about communication, about process of collective work on software packages.

Who cares? Just choose what works, dump the rest

[Anonymous Coward]

'Agile' (etc) is all a bag of crap. I've seen places employ the 'philosophy', turn into a bag of crap, and then others blame not implementing it properly.

Just take the *ideas* that work for your team, use them, and dump the crud that fails. All this crap about agile, devops, etc, should simply be treated as seperate, segmented ideas on how to run things and you should choose the *bits* that work for you. Nothing is going to fully be how you should work, no one-size-fits-all, everywhere is different.

And Jesus H don't buy/read a book on it. Everything you need is on the internet already!

(and the sooner the terms devops, agile, lean get dropped, the better) BUZZWORD BINGO!

DevOps, Agile, and Lean IT

[Anonymous Coward]

Sounds like a trio of black women.

Featuring Lil' Scrum on their hit single "Waterfalls"

Same as...

[aleck7]

... dentist, ophthalmologist and surgeon. Just subtle differences.

This all goes back a long way in project

[bobstreo]

management.

basically "Fast, Cheap, Easy, Pick 2"

You can also study "The Mythical Man-Month" Fred Brooks, 1982

Re:This all goes back a long way in project

[jrumney]

Around here we insert "quality" in place of "easy". I guess it works either way, except that PHB doesn't care whether something is easy or not, so the former is a no-brainer to him - fast and cheap every time.

Re:This all goes back a long way in project

[Anonymous Coward]

we always say good/fast/cheap

Re:This all goes back a long way in project

[Junta]

Every time, obvious observations are made and held up in hopes of driving a mindset change and every time the inconvenient ones are discarded.

The common thread is each time it's suggested you need good people and that is guaranteed to be the one thing discarded as it becomes a fad in the industry.

Re: This all goes back a long way in project

[Anonymous Coward]

At work the focus over the last two years have been speed, cost, quality. This was introduced by a senior manager that is not an engineer.

Parts of the Same

[Anonymous Coward]

You implement and practice DevOps to be more Agile. You're need to be Agile to be Lean enough that it matters.

X6Delta

[baker_tony]

All of these are shit, compared to the X6Delta way of sculpting the future in ways unforseen to achieve greatness!

Re:X6Delta

[Narcocide]

Go on...

Re:X6Delta

[Junta]

And now many companies have begun the search on how to get certified X6Delta.

Re:X6Delta

[raftpeople]

Anyone who is paying attention knows that X6Delta has been superseded by Extreme-CEO-As-Dev (TM) for instantaneous ROI and complete company adaptability.

Re: X6Delta

[Anonymous Coward]

We switched from Agile to X6Delta and saw a 371 percent improvement in peak project velocity.

Re:IT vs. Proper Engineering

[Anonymous Coward]

Proper Engineering fields have professional exams & liscensing which unregulated I.T. does not. Any regulated field has fewer, hopefully more competent, workers, and therefore commands higher wages.

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.

Re:Yes, of course

[Tablizer]

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

They'll merge into one giant dripping Dilbertian blob with its own YouTube channel; and start eating cars, bars, guitars, and Debbie Harry.

?Why Old when You Want New?

[Anonymous Coward]

What you are looking for in your 5-yr exp. candidates are, Neo-Agile, Neo-LanIT, and Neo-DevOps. Anyone not onboard the Neos is already far too damaged to be useful. Mark my neo-wisdom in neo-yellow highlighter and you will be mightily rewarded ... by the press.

They're all ways to kid management

[AntisocialNetworker]

Software development managers like to appear to be in control. All methodologies are merely a way for them to give themselves that appearance. Developers come, as is well-known, in two sorts - those who can, and therefore don't need any of this stuff, and those who can't. Those who can't won't be any better for any of these techniques, but it gives them something to hide under. The big benefit of these techniques is they stop your boss playing with critical path/PERT tools. That really screws development.

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.

Re:No. (explaination below)

[gtall]

You lost me at the use of "nown" for "noun".

Re:No. (explaination below)

[Anonymous Coward]

I'd wager that it was intentional. You've seen the trend in naming projects/products, right? "Kode With Klossy" and the like...

Re:No. (explaination below)

[skovnymfe]

"Agile" - Bullshit term

"DevOps" - Bullshit term

"Lean IT" - Bullshit term

It's all just management-speak, and if there's one truth that underlies all management-speak is that it's utter bullshit.

If you are successful in IT, you are lean/agile/devops. If you are not successful, then you are not lean/agile/devops, and should immediately transition. See what I did there? I gave you absolutely nothing of value, and no sense of direction. Management-speak. Bullshit.

Re: No. (explaination below)

[Qbertino]

Whoops. ... Well, since English isn't my first language, maybe you can let this one slide.

Re:No. (explaination below)

[Anonymous Coward]

> My 2 eurocents
ugh..

Re: IT vs. Proper Engineering

[Anonymous Coward]

Lol somebody just realised his degree is worthless

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

Re:They are not the same at all

[Anonymous Coward]

Experience with SAFe so far seems to be used as a way to ram through fewer large projects, while ignoring business and IT Operations side. This might be necessary in order to implement DevOps and reduce technical complexity, but is being sold as "Agile for all", while it clearly excludes 70% of the organization. A big concern is the extent of cultural damage over time and the divisive heavy-handed tactics being used in order to do Scrum, Scrum of Scums, and all the rest of the religious practices "just right".

Also, SAFe was built for software development and releases, saying nothing about IT Operations. So they're trying to sell SAFe+ITSM (ITIL) with "agile handover" processes, which of course fails miserably and reinforces old silos to the extreme. SAFe is more suited to pure software development companies sharing releases externally, but fails addressing in-house competence, cooperation and flow, the foundation for most other businesses.

There are some plus sides of SAFe, namely, democratization of ordering new stuff. If you truly need something, it's handled and processes, just need to wait a bit and hope results come out good. However, fixing defects in production is IT Operations in SAFe, so supposed to happen "magically by itself". Hint: It doesn't and queue up, to be inspected whenever, if ever, by any team, not the team responsible.

Re:They are not the same at all

[angel'o'sphere]

If you don't know anything about agile and Scrum, I wonder why you rant about them?

The rest of the Agile community will come under a single umbrella very willingly.
There is no one fits it all agile approach. So there is no such umbrella.

BTW: a Scrum Certificate is probably the most cheapest certificate in the industry, calling it a certification mill is just bollocks.

Re:They are not the same at all

[cjonslashdot]

LOL - I have written books and blogs about these things; my own company (I was CTO) adopted XP in 2000. I have been an Agile/DevOps coach for a decade. I am sure I know more about it than you do ;-) But I agree with your other points. You would do well to avoid making a personal attack against someone who you don't know. It shows immaturity.

Re:They are not the same at all

[angel'o'sphere]

I did not make a personal attack on you.

And writing a book is not a qualification. Strange that I hear that so often lately (mostly in martial arts, though).

I have been an Agile/DevOps coach for a decade. Nice. Sad we never met.
As I do this far longer than a decade, long before the terms even where coined: I am sure I know more about it than you do ;-)
I respectfully disagree ...

Re:They are not the same at all

[cjonslashdot]

Sorry angel'o'sphere. Your post started with something about a rant. I might have misunderstood the intent. So many posters on slashdot are immature, rude and nasty - like they surely would not be if they were talking to someone face to face.

Let's not debate our quals please. I am sure you are competent - most people here are. Please know that I am as well. I don't just coach - I code - have been for 40 years, many languages, written compilers, web apps, a relativistic 3D simulator, deep learning apps, container image scanner and other tools. Am current - latest tools, many languages. Know devops well enough that I am generally ahead of the teams that I coach, even in forward organizations.

About the qual of a book: you are right, it does not prove that one has practical experience, and I have read books that proved to me that the author did not know what they were talking about. But writing a technical book is an immense undertaking. Immense. (My books average ~800 pages each of all original content, with design patterns and code.) And if you _do_ know what you are talking about, writing a book forces you to organize everything you know, to think it through, to connect the dots, for refactor your knowledge and identify patterns and practices, to reflect on the causes of the causes. Each time I have written a book, when I was done, I felt like I understood the subject much better than before I started the book. A book is significant - or at least, it can be.

Re:They are not the same at all

[angel'o'sphere]

And if you _do_ know what you are talking about, writing a book forces you to organize everything you know, to think it through, to connect the dots, for refactor your knowledge and identify patterns and practices, to reflect on the causes of the causes. Each time I have written a book, when I was done, I felt like I understood the subject much better than before I started the book. A book is significant - or at least, it can be.
True, but I can not get my arse up to finally start writing. I'm refining several books in my mind since years ...
What books did you write, link one please.

Re:They are not the same at all

[cjonslashdot]

Today it is hard to get a technical book published because the docs for everything is online and free.

I wrote the enterprise Java book for Prentice Hall and Sun Microsystems. The first edition did spectacularly well: https://www.amazon.com/Advance... . The second edition not as well: https://www.pearson.com/us/hig...

The book I am most proud of was a commercial failure, even though it got great reviews and IMO had better content than competing books. It was High-Assurance Design: https://www.amazon.com/High-As... . All these are out of print although you can still get them due to on-demand printing. The High-Assurance Design I collaborated with Peter Neumann, an author of Multics and the author of the ACM Communications Risk column. I learned from that experience that programmers have almost zero interest in building reliable and secure systems - they are interested in "how to" books that enable them to hack something together as quickly as possible. My first book was that kind of book; but High-Assurance Design was a thoughtful book, full of design patterns but no code and no APIs, and people were not interested in that.

Re:They are not the same at all

[angel'o'sphere]

Amazon has the last one still on stock.

Yeah, enterprise java books that are over 10 years old are not selling good. The environment is changing to fast. If you ever want to write again in that area perhaps try to make it language/environment agnostic.

I liked this one e.g. https://www.amazon.com/exec/ob... still have it at my fathers place. Gosh, I should make an inventory of all my books ...

Re:They are not the same at all

[cjonslashdot]

Well, I did - I had that very thought! My book High-Assurance Design is all patterns and principles - all original content. I was first to tabulate a set of secure design principles before NIST did. But it sold really poorly. In contrast, my Java books with code in them sold really well. Perhaps it was the topic. I think that programmers are generally not interested in security or reliability.

Re:They are not the same at all

[angel'o'sphere]

I think that programmers are generally not interested in security or reliability.
Not sure about that.

But partly you are right. E.g. reliability ... what does it mean? That the software does not crash? Or hang up? Just kill the process after 5mins and restart it ... (was not my idea).

But that is exactly what in modern cloud environments is happening. You have some VMs running some Docker "sub VMs" spinning up when a request comes in, getting killed after serving it, or after serving a set number of requests.

I bought a few Java Books ... all were a waste of money, the "man pages" or "Java Doc" explained enough. But on the other hand, you can read them with sun glasses in bright sun shine in a park or at the beach :D

I remember "Java in a Nutshell" ... it was helpful to get an overview about the broad topic (that time I only did C++ ... and the idea that the language has multithreading built in and a GUI (PORTABLE!!!) library, too, was ground shaking. The only other language, affordable but nevertheless expensive, that was portable and delivered that, was Eiffel. Eiffel failed badly because of its price barrier.

Re:Who cares? Just choose what works, dump the res

[garethjrowlands]

Your advice to do what works for your team is great. But your advice not to read books... not so much. Reading books is one of the best ways to learn and grow. The underlying theory that explains _why_ things work for your team is not at all obvious and deserves concentrated study.

Yes.

[Anonymous Coward]

They're all stupid; imposed by busybody management types that don't have a clue what they're doing.

Re:IT vs. Proper Engineering

[gweihir]

True. And with the abysmal state IT is in these days, I do not really see a way around that regulation.

Re: IT vs. Proper Engineering

[gweihir]

Indeed.

Yes

[AncalagonTotof]

Buzz words !

Re:IT vs. Proper Engineering

[Anonymous Coward]

IT is like healthcare. Similar knowledge is required, but the pay is much less than that.

Now, lets see how good the doctors are at what they do. After all, they have to pass specific schools, training in hospital, tests etc.

"20 percent of patients with serious conditions are first misdiagnosed"

That is all I had to say.

Re:Who cares? Just choose what works, dump the res

[cshark]

I've worked in a dozen agile houses at this point, and it's been my assessment that agile does have its advantages. It's good for things where there's feedback coming and running a constant qa process. When done right, a good way to squeeze a little more creativity in the process. When done badly, it's little more than project managers yelling at their developers who have no idea what to do next. Honestly, most of the time, agile is an elaborate cover to hide the simple fact that there simply isn't any kind of process going on at all.

No!

[angel'o'sphere]

But when you think about Agile, Lean IT and Agile, aren't these all the same thing, essentially?
Pizza is made from grain.
Pasta is made from grain.

Both have basically originated in Italy, main ingredience are tomato and cheese. Both have the same goal: to be tasty and make you full, therefor: they are the same thing!

The same

[Anonymous Coward]

They are all ways for other non-programmers to exert more control over the code creation process. Iâ(TM)ve been a professional programmer for 30 years and can say unequivocally that none of those âoeprocessesâ create better code. They all add needless complexity and transfer important decision making to non-technical people. Thankfully I work in a very technical, mathematical field where programmers donâ(TM)t have to deal with that bs. I blame the current state of programming on Java, OOP, and design patterns not to mention all the unsufferable millennials that would rather do something âoeelegantlyâ then correct. Ugh....

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:Empty buzz words..

[Anonymous Coward]

The reality no one wants to acknowledge is that success requires a *small* team of *really good* folks at the core.

Sorry, but any formula that only works for "a *small* team" is simply no help to lots of people, who need a much larger team.

I know some small teams that are great at what they do, but there's only so much work they can handle. Because small.

There comes a point where a small team can't hack it any more and needs to grow. Then what happens? If you can answer that with an answer that doesn't end with "... and then everything goes to shit", then congratulations, you've got a methodology.

Re:Empty buzz words..

[Junta]

Ok, at some point for some things, large teams are required.

However to the extent a call must be made in personnel decisions, quality is better than quantity. Laying off one developer because they are expensive and back-filling with two of the cheapest in the world won't work the way a business would want to.

I would also say generally teams can mess things up by imagining the problem at hand suggests a large volume of people, when a small team can do the work with less inefficiency. I have worked on two very similar projects at two different companies. One fluctuated between 3-5 developers but everyone knew every one else's code and could competently cover and make great strides in functionality and fantastic support coverage even as people worked sane hours and took reasonable vacation. The other had 30 developers, had less functionality, and never did I see a customer have an issue that any one developer fully understood the relevant code, every one was incompetent outside a very narrow scope. No feature or fix could be developed without a great deal of coordination, that would inevitably have a misunderstanding and require redoing the work. Revenue for the 3-5 developer project was about 10 fold the revenue of the 30 developer project. Management's solution to that 30 person team not pulling in nearly enough revenue to cover the cost of the project? Lay off 15 and bring in 20 more from a cheaper geography from an outsourcing company no one had ever heard of. To their surprise, that did *not* in fact improve their fortunes or their user reviews.

So while there are big software projects out there that do require a big team, I would say probability is that the team doesn't have to be as big as most managers thing it would have to be.

Human wave.

[funky_vibes]

Those three are all continuations of the failed human wave ideology. Where bean counters and managers love to hear that they can toss more bodies on a problem to solve it in time. Regardless of skill, competence, concentration, ramp up time and work-motivation.
Of course this doesn't work, but complex work methodologies always leave ample opportunity for the real culprits to hide and find a scapegoat.
In real life, nothing can replace a good plan, a good developer or enough time to do things properly. Nothing.

You should actively avoid methodology buzz words.

[funky_vibes]

If a company uses any of these in work advertisement, just move along. Else you will waste a lot of time on useless endeavors.

No

[Misagon]

DevOps is a portmanteau.
Agile is an adjective.
Lean IT are two words.

Agile Is A Scam

[NicknameUnavailable]

It was designed by talentless hacks who got sick of being code monkeys to "manage" more competent developers who were younger then them because they "put in their time" and damnit, they've been shit on for being talentless hacks for so long they deserve to do some shitting of their own.

Re:Who cares? Just choose what works, dump the res

[Junta]

I'd say you described the reality of any team, regardless of 'Agile' or not.

I've seen shops that said 'sorry, we can't take on this urgent requirement because we've planned out the next 2 *years* of sprints, strangled by process but they call it Agile so they think they are good.

I've seen shops that are as you imply, are aimless and don't really have any structure and when pressed say 'uhh.. Agile'.

The common thread is: if a methodology is a buzzword, it will lose any hint of meaning as it gets adopted by companies desperate to use buzz to fix real problems.

Re:Who cares? Just choose what works, dump the res

[Junta]

The underlying theory that explains _why_ things work for your team is not at all obvious and deserves concentrated study.

The problem is that this is mostly understood if we are being honest with ourselves, but the money train of management consultancy is running on the illusion that you can extract the essence of a quality team and inject it into a poor team and have that work. As such books with branding aligned to the buzz word of the day will minimize the awkward reality to encourage people that they can throw some money at the peddler of the methodology instead of having to pay more for people or that perhaps the people they need to succeed don't even exist.

Re:Who cares? Just choose what works, dump the res

[angel'o'sphere]

Honestly, most of the time, agile is an elaborate cover to hide the simple fact that there simply isn't any kind of process going on at all.

"Agile" is a meta process. Except for Extreme Programming most Agile "Methods" don't tell you what process to run, look e.g. at Kanban or Scrum.

If you don't have automatic tests, a version control system, and an issue tracker ... you can be as agile as you want. You simply fail the same way you would fail with water fall or other processes.

And is exactly the reason why Scrum is dogmatic: you define your process and use Scrum as an overall framework. If you change the framework: it is not Scrum. That does not mean it does not work or is not agile ... it simply should be not called Scrum then. And I would go so far: if you do Extrem Programming, do everything of it. If you drop one aspect, it is not XP.

Well... yes.

[Opportunist]

They all belong into the same box. The one where a consultant gets a lot of money to teach you something that makes you more productive if you don't use it.

Re:Well... yes.

[Junta]

I would say that in theory you can be perfectly productive when using (or at least claim to use) any of those things, but almost certainly not if a consultant teaches you how.

Re: IT vs. Proper Engineering

[Anonymous Coward]

Yeah, sure, buddy. Of course, by mis diagnosed, you mean that very common case where treatment is part of diagnosis. And you, like most "developers" don't know fiscal nest add much as you think you do.

In a way... Yes

[Anonymous Coward]

If you mean, are they a mess when implemented poorly, then Yes, they are the same.

Re: IT vs. Proper Engineering

[Anonymous Coward]

The halting problem applies to "computers" with infinite storage. As we don't have ACTUAL computers with infinite storage (though admittedly a huge cloud system with ever increasing storage COULD be considered such, MAYBE), it is purely an interesting theoretical observation. It has 0 relevance to real-world programming, and the idiotic "OMG halting problem" shouts may well be one of the many things that needlessly have held back computer science.
Imagine all the architects would have shouted "but we can't built a bridge that can withstand a meteor!" and as a result everyone had started to acceot bridges that get blown over by the next big storm.... That's the world of programming.

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:Agile is NOT supposed to increase quality

[nw_rad]

Agile is supposed to support making continuous changes to the requirements. When users and developers have something to look at and try out, requirements always change. Agile encourages responding to change requests as opportunities rather than problems. There is nothing to stop Agile developers from deploying properly tested software.

Re:Agile is NOT supposed to increase quality

[Anonymous Coward]

Most statements misrepresent scrum.

Scrum doesn't chose to sacrifice quality. It makes quality decidable. If you don't reach consensus with other developers on quality you never would have reached the quality anyway, with or without scrum. Check your definition of done.

Scrum aims to work around that requirements in complex projects aren't decidable up front, so don't waste time on what you can't determine. If you can determine all requirements, then maybe it's not a complex adaptive problem you are trying to solve.

Scrum aims to have potentially shippable products. That doesn't mean they have to be shipped. There are loads of ways to get feedback on it, from user tests in beta's, to running in a shadow mode/simulation, or partially replacing a legacy system. The feedback helps to improve quality, because it gives insights otherwise wouldn't have

Re:Agile is NOT supposed to increase quality

[bsolar]

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

An agile team is *still* supposed to determine and document requirements. The main difference in agile is the assumption that these requirements are going to change. In my experience in many fields it's a very wise assumption to do no matter whether you are implementing with agile or not.

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

An agile team is *not* supposed to push out code before it's done either: it's supposed to factor the requirements in smaller modules which can be pushed out when done before starting with the next. This "done" should include satisfying quality requirements... Note that this factoring is usually the hardest part to do well and the key factor in the success of agile. The difficulty of this step is usually overlooked.

Re:Agile is NOT supposed to increase quality

[Anonymous Coward]

Also, getting half-finished software done is the only way to get the customer to actually start trying to say what they wanted instead of just waving the question away.
Getting to that point before you spent the entire developing budget makes everyone happier.

Re:Agile is NOT supposed to increase quality

[HornWumpus]

Scrum is 'cargo cult' Agile.

It uses the words, but gets everything wrong.

Agile is a manifesto that sounds good enough to PHBs they pasted onto their micromanaging bullshit.

Agile explicitly says: 'People before process'. Scrum is the opposite.

Re:Agile is NOT supposed to increase quality

[Anonymous Coward]

I see Scrum more as an agile 'starter kit'.

Many people see and read about agile and like the idea, but have no idea how to start implementing it. Scrum gives you a beginners set where you can start doing it.

Keep in mind: If you start doing Scrum and a year later, you're still doing Scrum, you didn't understand Scrum.

Oblig. Car analogy

[Anonymous Coward]

Are Ford, Chevy, and Dodge the same thing?

Three?

[diethelm]

There have been three great movements shaping the information technology landscape.

I stopped reading there.

Re:Three?

[fibonacci8]

There have been three great movements shaping the information technology landscape.

I stopped reading there.

There have certainly been at least three, these aren't among them.

Re:Three?

[PPH]

Our three weapons are fear, and surprise, and ruthless efficiency...and an almost fanatical devotion to the Pope....

Fad IT

[Anonymous Coward]

Yes they are all the same thing; they are the fad diets of IT. Designed to give you a list of things to do and suddenly you have better IT; the problem is just like a fad diet they don't work long term (honestly short term is iffy as well) and often have massive negative side effects.

The secret to good IT, is the same as all other professions. Get and retain the best people you can. I have seen many business fail because they want to treat IT as a sunk cost; IT is an investment in your business and if you treat it like that it empowers all of your employees and has lasting positive effects throughout your whole organization. /endrant

Of course

[OneHundredAndTen]

They are three different fads.

"about Agile, Lean IT and Agile"

[Anonymous Coward]

Well, at least agile is the same thing as agile. So, at least two are the same thing.

Re:No -- correct qnswer is YES

[Anonymous Coward]

All signs that crap is being produced, with no design or controls.

Appreciate

[pcsoftsfull]

Best Info Share !

DevOps = Do two jobs for 1 salary

[Proudrooster]

DevOps is a job description that merges development and system/database/cloud administration into one job. This is why we have security holes galore in modern software and web applications. One person can't learn it all, code it all, and secure it all.

Re:DevOps = Do two jobs for 1 salary

[Junta]

Eh, one person *can* (and I would argue that security has to be pervasive, not bolting on a security team). Of course having good generalists is expensive, and businesses chasing DevOps are usually doing so to reduce staff expense, so it is correlated with reduced skills too.

In practice though, I think the bigger issue is the rush to cloud hosting. It has caused teams that suck at security to expose their services to the global internet, when formerly they were limited to private networks on premise (not a good intentional security strategy, but it does at least mitigate the risk).

Re:DevOps = Do two jobs for 1 salary

[sad_]

That is not what devops is about at all.
If anything, your code should be more secure by implementing devops, because the security part gets integration in the delivery flow.

Re:DevOps = Do two jobs for 1 salary

[strikethree]

One person can't learn it all, code it all, and secure it all.

I disagree... but, you won't find the person who actually can do it all for the prices they are willing to pay. Not even close. :)

Not at all

[nospam007]

First, obviously because of Betteridge's law of headlines, second, because 'lean IT' is when all the IT stuff is done by the bosses teenage son on the weekends.

Probably yes

[Anonymous Coward]

I haven't been involved with Lean IT or DevOps really ( I have read a little about them), only a couple of workplaces that advertise "we are Agile!" as if its the new veganism.

My practical experience with Agile in such places leads me to believe it's something concocted by some people having a very narrow understanding of software development, but dismiss decades of development of software development best practices with a simple all-inclusive invective "Waterfall!!" and think that you can use the same principles for developing a 4-page website and a mission critical central banking system. Managers that have never programmed themselves love the concept of quickly delivering something working, then go and buy vaguely worded books and consultancy on the matter.

That sounds very similar to the OP article where 3 widely separate concepts are described in such broad and vague strokes that from the lofty distances of management levels they all look like the same thing ("moar moneeee!!!!")

Fact of the matter is, if you are in some position of authority to implement really any way of how the developers are going to do their job, you need to understand more than just for-loops and if-conditionals. You have to have a broader picture of how information and work products flow, what the bottlenecks and hindrances are, and put measures in place to alleviate that. The Agile Manifesto won't tell you that, it won't even know the issues particular to your organization let alone suggest solutions.

Document writing was put in place for a reason (higher levels of abstraction of information). True, many organizations have done it just because that is the way it's done. One actually has to understand why it's done then tailor it for max benefit. Fred Brooks described the pitfalls of "collaboration" in The Mythical Man Month decades ago (i.e. exponential rise in communication with linear rise in complexity) and suggested solutions - which seem to be thrown out again with Agile. If people don't learn from history, they will continue to repeat the same mistakes.

I did them all for 15/24 yrs... apk

[Anonymous Coward]

See subject: I challenge YOU to find bugs or security flaws in a program I give away freely vs. your statement APK Hosts File Engine 2.0++ 64-bit for Linux/BSD h t t p : / / a p k . i t - m a t e . c o . u k / A P K H o s t s F i l e E n g i n e F o r L i n u x . z i p

* All this "new hotness" (agile bullshit etc.) LEADS to TOO MANY cooks in the kitchen & "modern wares" problems. Look @ it out there nowadays in general & tell me different.

(Why do you THINK Linus Torvalds STILL governs what goes into OR out of his Linux kernel? (last I knew of it spanned 15++ million lines of code (far smaller than NT-based OS @ iirc, 30-40 million) & something of that SIZE might need specialization & division of labor, but the core of it?? He built, himself...))

APK

P.S.=> When you have 1 guy that directs & DESIGNS information systems & the networks they ride on HE has the overall understanding to MAKE THEM WORK & WORK RIGHT (Linux kernel IS a prime example & improving almost daily) minus too many cooks in the kitchen - & I don't have to say anything other than LOOK @ THE MESS OUT THERE NOW in wares galore full of bugs etc. ... apk

Re:Who cares? Just choose what works, dump the res

[cshark]

I don't know about that. Waterfall can really leave a mark on the production process. The cold, top down order of the thing. If you're working in waterfall, or reverse waterfall, you know it. It may not be the most efficient system there is, but it's implemented consistently, and it gives you something to fall back on. Agile on the other hand is 12 simple ideas that together, are impossible to implement the same way twice. You always get the feeling that the team you're on is "learning" Agile, no matter how long they've been working with it, and that can drive you nuts. Personally, I've always been driven by order and efficiency. To that end, Agile's a crapshoot. And it all depends on the managers and the stakeholders. Either they get it, or they don't. My feeling is that most of the time, we as developers would be served better by simply taking the basics out of agile. Sprints, retrospectives, and just use those, without trying to focus on the pieces everybody always gets wrong.

Re:Who cares? Just choose what works, dump the res

[cshark]

If you don't have automatic tests, a version control system, and an issue tracker ... you can be as agile as you want. You simply fail the same way you would fail with water fall or other processes.

Well, that could be interesting. I wonder what agile might look like if you're not using a tool like JIRA or Redmine to track the items in your sprint. How would you do it without version control or issue tracking?

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

[HanzoSpam]

As in "management fads that will all be forgotten within the next 10 years"?

Yes. Yes they are!

Nope, just cost cutting from management

[Anonymous Coward]

It also stems from a management ideal, of squeezing assets. Ops people are expensive, so might as well have DevOps who know the full stack. Agile is a great, broken system, like Total Quality Management, and other fads, which helps the PHBs optimize their synergies.

In reality, when you get tired daily of four hour SCRUM meetings which are like kangaroo courts where the SCRUM master calls out every dev and asks them why they don't have everything done in their swim lane, and where the place is in a permanent sprint, where not much get done other than name calling and good people bailing for work at less shitty places.

Then, there are the "Agile" settings, the open air workplaces where you have to wear earphones all day otherwise you won't get any work done. The open air workspace saves square footage, which makes the bean counters happy, but is a worthless environment for the people who have to work trying not to pay attention to the co-worker on the phone talking about his hysterectomy, the other co- worker chowing down on chips or popping popcorn.

Then there is the "lean IT" or NoOps. Again, management. They want to brag about having zero IT staff, all the while offshoring or putting stuff on the cloud. Great for lowering those pesky CAPEX numbers, while pushing OPEX through the roof... but hey, it looks great next quarter.

I worked in Agile environments for years. It is no wonder why we get the shitty, failed, insecure products we do with this methodology.

Re: Who cares? Just choose what works, dump the re

[garethjrowlands]

Just use a kanban board on the wall to practice agile without jira. Works great if everyone is in the same room. You absolutely need source control though. You don't need branching necessarily.

Not even close

[Anonymous Coward]

How can you compare a job role (DevOps) , and methodology (Agile / Lean IT).
It's not even 'apples' and 'oranges'.

Re:Who cares? Just choose what works, dump the res

[angel'o'sphere]

Items in your sprint are classically tracked on cardboards half the size of US legal or European DIN A4 paper.
The best scrum team I was in actually only used cardboards ... the issue tracker was not used by developers.

My point however was: using a version control system correctly and efficiently is an important point for success. And that has nothing to do with being agile or not. Many teams don't use version control right (e.g. not including the issue number of the issue tracker in the commit, not having a commit hook that rejects such commits, etc.)

Re:IT vs. Proper Engineering

[Anonymous Coward]

Programming is a world unbound by physical rules, only logic and reason dictate what works. There is a large "art" aspect to making quality programming. Many projects fail not due to a lack of following rules, but a lack of creativity. They can't think of the many ways their design can fail, they can't figure out which methodology works best, they don't know when to break the rules. In programming, rules aren't written in stone like civil engineering, but rules are "more like guidelines". Those who follow the rules are mediocre at best. I don't know if you've seen the state of programming, but mediocre is crap.

It does get worse...

[Anonymous Coward]

I've worked in IT for about as long, before Linux was even something that was available, and if you wanted to run UNIX, you had to use Mt. Xinu, or BSD/386, and pay for it.

In those times, you had the massive physical book to search for something. There were no usable search engines, even with Archie and Veronica. Gopher was useless. At best, you had man pages and USENET groups, but at best, unless you were 95% of the way there, you would be laughed at out of town. If you wanted a software package, you built it from source, and you rewrote the code so the package built on your flavor of UNIX, be it AIX, Ultrix, BSD, Dell SVR4, IRIX, Minix, XENIX, A/UX, NeXTStep, UNICOS, or whatever you were using. If it didn't compile, it was on your shoulders to get the application going.

You had to be competent then. As a UNIX admin, you had to be a network admin, a storage admin, and many other roles that are separate today. You give the wrong person the root password, or physical access to your Suns or SGI boxes, and thousands of people would be fucked. You made DAMN sure your backups were working, because there wasn't a cloud provider that you could click Next on a few steps and be done.

Fast forward to today. You don't have to know anywhere near as much. For Windows, you can get by in a lot of cases with Google and clicking "next". For UNIX stuff, it can be harder, but there is something out there. You really don't have to know much about computer science, but just watch some YouTube vids.

I have worked with DBAs who didn't even know how to CD to the Oracle directory in Linux. It is very easy to become a "DevOps guy" and get hired in not knowing a damn thing. When fired, bounce to the next thing, saying that they had layoffs.

SunOS 4.1.4, AIX 3.2.5 and IRIX 4.x did not suffer fools gladly.

Re:It does get worse...

[Anonymous Coward]

They knew how, you click on the 'Oracle' branch.

Yes,

[RuiFRibeiro]

They are all bullshit. Next?

yes. they all suck.

[Anonymous Coward]

=p

buzzword disqualifier

[Anonymous Coward]

The referenced article uses the phrase "laser-focus", which means it's marketing fluff.
Lasers aren't focused, they are collimated. If you do not know the difference, you are not smart enough to talk about process and development

Means to an end

[Anonymous Coward]

I think they are all methods of convincing management to let developers do their job.

Yes, of course! Mostly.

[internet-redstar]

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

Especially the former and the latter are absolutely positive the same thing :-D

The only way some people were taught

[raymorris]

> half-finished software done is the only way to get the customer to actually start trying to say what they wanted instead of just waving the question away.

If that's the only way you've been taught, that's the only way you know. It's not the only way!

Largely that misconception comes from starting with the idea that you can only determine requirements based on "rhe customer saying what they wanted", or more commonly, the customers' boss's boss saying what they think.

You CAN document, in detail, the exact requirements for a complex $15 million project, without building anything first. Proof is most every civil engineering project ever. My mentor routinely did that with software projects. But you can't do it if you haven't been taught how.

Re:The only way some people were taught

[epine]

You CAN document, in detail, the exact requirements for a complex $15 million project, without building anything first. Proof is most every civil engineering project ever. My mentor routinely did that with software projects. But you can't do it if you haven't been taught how.

Was your mentor a civil engineer? That preconditions the kinds of software projects he might have taken on to those with tighter boundary conditions in the real world, that being a huge advantage in building requirements/specifications top down.

Are they all complete wastes of time?

[Anonymous Coward]

Yes. Yes they are.

Don't waste your time.

Perfect world versus reality...

[Anonymous Coward]

In a perfect world, Scrum would be useful. However, in a real world, the Scrum master position is abused and becomes a bully pulpit. Stand-up meetings become daily floggings on the devs, forcing devs to use any out they have, even if the outs are unethical, unscrupulous, or even illegal (as in hacking root access in production to get their code artifacts pushed out, because their code doesn't past a unit test and "ops" refuses to allow the request to complete until it does.)

Scrum just ensures shitty code and shitty developer morale. Combine that with the open spaces, the fact that devs are pretty much fungible, especially with offshore dev houses and H-1Bs costing pennies on the dollar (or rupee), and it is no wonder why code is such garbage in general.

Nope, she was just taught different than fad

[raymorris]

It wasn't civil engineering projects that she did.

A couple of her projects included:

Building Dell's innovative customer order to inventory to manufacturing system. With this system, when a customer orders a custom-confugured computer via Dell.com, it immediately checks the inventory of parts and orders new parts from the suppliers as needed. Based on parts availability and all of the computers scheduled to be built, it then schedules that particular computer to be built on the assembly line. The assembly line scheduling optimizes for several factors to make it more efficient - orders using similar parts are batched together. Shipping is scheduled similarly. Within a few seconds after the customer places the order, the system knows when it will be assembled and placed into the box, within a margin of a few minutes.

Designing an integrated information system for Martin Marietta, an enterprise consisting of many companies in different fields, including mining and aerospace.

Her method for determining requirements was NOT asking the users' boss what they think they need.

Her methods also did NOT involve throwing shit and the wall and see what sticks (Agile, as often practiced).

The entire system was designed, in detail, based on *actual* requirements, not what some manager thought of when asked "what do you want?"

Three major parts of determining requirements included:
1. *Watching* the assembly line workers build the computers and taking detailed notes of what users *do*. (Not asking their boss's manager what they do, actually watching).

2. Documenting business inputs and outputs. Inputs include customer orders and vendor shipments. The key output is computers shipped to customers. (Note there are no integers or floats af the top level - these are business inputs, not data formats).

3. Analyzing the legacy systems, computer based and paper based, that did the same operations less well. Especially the databases were analyzed. If you understand the databases that run an enterprise, you will understand the operations of the enterprise better than any C suite executive does.

All three are scams for consultants to bill.

[Anonymous Coward]

All three are scams for consultants to bill.

Desk

[dohzer]

Doesn't an "agile workplace" just mean less desk space for all employees?

Lean IT, which promotes delivering software faster

[mapkinase]

> Lean IT, which promotes delivering software faster, better and cheaper

This just sounds like marketing bullshit. The other two were described more ... descriptively

articulate it sufficiently

[mapkinase]

> articulate it sufficiently

That's the key word in Agile.

Forcing the use of Agile on non-development

[Anonymous Coward]

There may a place for Agile, but imposing it's used on an O&M organization "just because" is extremely poor management and a HUGE waste of O&M staff time

Re: IT vs. Proper Engineering

[presidenteloco]

The number of possible states of a program operating in a memory of 1 Gigabyte is approximately 2 ^ 8,000,000,000.
To determine if the program is going to halt, you need to wait til the program has explored all of those states.
Practically, as in, in the life of the universe, that is not decidable, even though theoretically it may be.