Agile v Lean v DevOps sense-making


Howdy - can anybody point me to some good analysis / posts / whitepapers of the merits / challenges of concurrent Agile/Lean/DevOps models?

I’m currently working on a transformation piece that involves introducing a DevOps operating model and scaling agile / building agile maturity. There are some parts of the business that are wed to Lean.

I’d like to elevate the conversation to an appreciation of what you get out of each approach to make sense of some of the disparate practices in place at the moment and how there is actually more consistency in the fragmentation than some may think.

I know I have read some before, but just can’t find them!


Jen - Its an interesting question. I think I have found, personally, that the original intent of Agile is very closely aligned with DevOps and the humanistic process that wraps this is well suited for Lean theory. I gave a talk a few months back around putting what I just said into action if you are interested in seeing it, but have not really written a paper just yet:


shameless self promotion :grin:


I gave up shame long ago my friend, you know this.


Maybe this is too much of a ‘my 2 cents’ opinion for the discussion but here goes: I find that a lot of DevOps focuses on speed for speed’s sake, and thereby becomes another piece of buzzword hype (“we deploy 50x/day - aren’t we awesome!”). What I feel gets overlooked is what do we get with that speed? In other words, the focus is lost or diluted around the production of genuine customer benefit. DevOps is a tighter loop or cadence of PDCA, but I’m not sure the feedback loops with the customers are always in place.


I have a video for that too :grimacing:


Fab - so much appreciated, thank you. I’m on the same page eg it’s all VERY closely aligned. I’ll use this video on the company workplace to stimulate conversation.


That .04AUD is also valuable, thank you - it’s one of the objections I am hearing as we progress the conversations and that’s why I want to draw out the tensions and validate them. This needs to be a considered adoption, not a faddish “me too” adoption.


Can I have a few more videos of @ryan speaking on this thread??? Don’t have enough yet. Also, you have no right to make fun of my skinny jeans ever.




@ryan, 2 questions:

  1. Do you have a slideshare or a paper/article/blog post for this talk? (thanks in advance.)

  2. I also like the idea of a product team seeing what the customers do now/asking customers about the problems they want to solve. I’ve seen a ton of pushback from that idea from the product managers. Have you seen that? What have you said?



Sure thing Johanna:

Here is the DevOps Framework deck:

And here is the Business Agility Deck:

To the second question, yes. It’s the personification of ‘who moved my cheese’. Mike McCalla here did a nice write up on “Inviting vs. Inflicting Agile” and I think there was even a podcast we did on it. The point being, a lot of the enterprise, or even personal, change that is introduced in a lot of what practitioners do, is potentially threatening to those impacted by the change. I have not found a silver bullet to ensure that threat is eliminated, but to mitigate I invite folks to the conversation. in the framework talk I go into how starting small with lighthouse projects is extremely successful. It allows for a gradual change, and creates outside curiosity and (when done very well) excitement to be part of the new way. In the Business Agility talk, I go into creating a better interface with the business/product managers. Often, we default to Jira or slack as the interface and that is an artificial construct that gives an external appearance of invitation to the change, but is ignorant to the human side of change.

Not till we appreciate the stance of the non-technical folks impact to change, and find ways to introduce them to the change like lighthouses and interfacing better, will we ever unlock the real hyper-speed we talk about with DevOps, Cloud, Agile, Lean, etc. But the beauty is this, it works both ways :slight_smile:

Only focusing on the business operations, product management and process aspects of agility while ignoring engineering culture has the exact same outcome, just from a right angle to the one you present.