Slashdot Mirror
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?
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.
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
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.