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?
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?
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.
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.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.