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]

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

[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

[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

[postbigbang]

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

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

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

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

Re:No

[ilguido]

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

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

Re: No

[ulski]

Yes. It is buzzwords on buzzwords.

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

[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

[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

[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

[Pseudonym]

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

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

[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

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

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

[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

[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

[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

[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

[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

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.

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

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]

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.

Only a Millennial would ask such a silly question.

[HotNeedleOfInquiry]

Only a Millennial would ask such a silly question.

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!

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

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

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

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)

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

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.

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

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

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

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

[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

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

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

Of course

[OneHundredAndTen]

They are three different fads.

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.

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!

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.

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

Yes,

[RuiFRibeiro]

They are all bullshit. Next?

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.

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.

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.

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.