Slashdot Asks: Are DevOps, Agile, and Lean IT the Same Thing? (zdnet.com) 226
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?
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?
No (Score:5, Insightful)
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: (Score:2)
Re: (Score:2)
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 (Score:4, Insightful)
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: (Score:2)
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.
Agile is NOT supposed to increase quality (Score:4, Insightful)
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: (Score:2)
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 inclu
Re: (Score:3)
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.
The only way some people were taught (Score:2)
> 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
Nope, she was just taught different than fad (Score:3)
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 li
Re: (Score:2)
Yeah, they are all very different certifications which require distinct expensive training courses. Now hand over several thousand or else.
Re:No (Score:5, Insightful)
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: (Score:3)
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 (Score:5, Insightful)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
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 meth
Re:No (Score:5, Insightful)
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 (Score:4, Insightful)
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 (Score:4, Insightful)
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: (Score:2)
Re: (Score:2)
Indeed. And for sure there are IT/CS/Coding people that can do that. They are just very rare.
Re:No (Score:5, Interesting)
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: (Score:2)
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 reaso
Re:No (Score:5, Insightful)
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: (Score:3)
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.
Re: (Score:2)
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 one
Re:No (Score:5, Interesting)
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: (Score:2)
Indeed. Somehow the most critical people are treated as the most expendable ones. It boggles the mind.
Re: (Score:2)
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 i
Re: (Score:2)
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 [urbandictionary.com].
Re: (Score:2)
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 fo
Re: (Score:2)
True. And with the abysmal state IT is in these days, I do not really see a way around that regulation.
Re: (Score:3)
Indeed.
Re: (Score:2)
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
Yes and No (Score:4, Interesting)
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 (Score:5, Insightful)
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: (Score:3)
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 con
Re:Yes and No (Score:4, Informative)
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 (Score:4, Informative)
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: (Score:2)
Re:Yes and No (Score:4, Insightful)
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: (Score:2)
I have a hard enough time finding developers that catch and log exceptions, let understand anything outside of their IDE
Re:Yes and No (Score:4, Funny)
Programming, motherfucker, do you speak it? [programmin...fucker.com]
They claim to value: Responding to change
They really value: Instability and plausible deniability
We fucking do: Programming, motherfucker!
Re:Yes and No (Score:5, Insightful)
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.
Yes and no (Score:4, Informative)
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.
Re: (Score:3)
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: (Score:3)
DevOps is not a method. It is a job description.
No idea why americans don't get that.
Re: (Score:2)
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.
Yes (Score:2, Insightful)
They are all bullshit ideas from management that do not work in reality
Re: (Score:2)
Care to share your experiences of them? I sense anger in you but there is hope.
Re: (Score:3, Insightful)
Re:Yes (Score:5, Interesting)
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.
when you think about Agile, Lean IT and Agile.. (Score:4, Funny)
from tfa..
Well, two of them are ..
Agile is like active methodology in teaching (Score:3)
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: (Score:2, Informative)
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: (Score:2)
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 (Score:3)
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.
Only a Millennial would ask such a silly question. (Score:2)
It's like a Venn diagram (Score:4, Informative)
I'd say no (Score:5, Informative)
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: (Score:2)
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: (Score:2)
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 t
This all goes back a long way in project (Score:2)
management.
basically "Fast, Cheap, Easy, Pick 2"
You can also study "The Mythical Man-Month" Fred Brooks, 1982
Re: (Score:2)
Re: (Score:2)
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.
X6Delta (Score:2)
All of these are shit, compared to the X6Delta way of sculpting the future in ways unforseen to achieve greatness!
Re: (Score:2)
And now many companies have begun the search on how to get certified X6Delta.
Re: (Score:2)
Yes, of course (Score:5, Funny)
”Are DevOps, Agile, and Lean IT the Same Thing?”
Yes, they are all the same thing. They are buzzwords.
No. (explaination below) (Score:4, Informative)
"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: (Score:2)
You lost me at the use of "nown" for "noun".
Re: No. (explaination below) (Score:2)
Whoops. ... Well, since English isn't my first language, maybe you can let this one slide.
Re: (Score:2)
"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.
They are not the same at all (Score:4, Interesting)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
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, cont
No! (Score:2)
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!
Empty buzz words.. (Score:5, Insightful)
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.
Human wave. (Score:2)
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. Nothin
No (Score:2)
DevOps is a portmanteau.
Agile is an adjective.
Lean IT are two words.
Well... yes. (Score:3, Informative)
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.
Of course (Score:2)
DevOps = Do two jobs for 1 salary (Score:3)
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.
Not at all (Score:2)
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.
Are DevOps, Agile, and Lean IT the Same Thing? (Score:2)
As in "management fads that will all be forgotten within the next 10 years"?
Yes. Yes they are!
Yes, of course! Mostly. (Score:3)
Especially the former and the latter are absolutely positive the same thing :-D
Re: (Score:2)
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.
Re: (Score:3)
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
Re: (Score:3)
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
Re: (Score:2)
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 c
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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?
Re: Who cares? Just choose what works, dump the re (Score:2)
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.
Re: (Score:2)
Items in your sprint are classically tracked on cardboards half the size of US legal or European DIN A4 paper. ... the issue tracker was not used by developers.
The best scrum team I was in actually only used cardboards
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
Re: (Score:3)
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: (Score:2)
Our three weapons are fear, and surprise, and ruthless efficiency...and an almost fanatical devotion to the Pope....