The root problem seems to be that "we have to respond to inputs much faster now". Where did this rationale come from? Did the big companies grow terrified of small startups taking all their market share? Did the small startups grow terrified of each other? When did we trade our confidence in knowing our problem domains to fear that anyone could just waltz in with less knowledge and dethrone us? I remember companies built great stuff in good time by just focusing on their core competencies. But now everyone seems determined to keep competitors at bay using superficial "we're more agile" means. Is no one confident in their abilities anymore?
Loved it. I think it's one of the most sobering presentations about agile and methodology adoption in general that I've heard in the past 10 years. Everyone is histerical about "being agile" at an organization level, in all teams, even where it just doesn't make sense to have agile to begin with. And the Culture part of the equation is so easily and so often forgotten (or pretended that it doesn't matter, 'cause it's easier that way), and I also believe that it's at the core of any transformation or evolution. Culture fosters the right change from within, instead of it being pushed and shoved down people's throats without any thought. The copy-paste model of scrum or even the spotify model is the way I've seen fail again and again, but the consultants keep getting hired and churning pass organizations with the same powerpoint slides. Thank you so much for putting it all together.
Same for all religion, sadly. Replace the word "agile" with "religion" and everything is still true. Especially for top-down control religions like the Abrahamic ones.
I was a scrum master for a couple of years. This absolutely matches a lot of my experience in the field. But not the worst of it. On nearly every contract the one thing I expressed repeatedly to product owners and stakeholders and management - who were usually “self-trained” in Agile by skimming Death March and attending a luncheon/seminar, and who were energized by the prospect of no longer “wasting” FTEs with documentation, or on testing or deployment, which would now be magically automated - was that my team members MUST be assured they have job security for a minimum of at least a few quarters under Scrum, which always reveals immediately all the rot that was intentionally hidden in the prior SDLC approach and will now be replaced with cooperative team effort, which will reveal it. Teammates MUST NOT be ranked by management by their velocity against their other teammates’ velocity or there is only reinforcement to NOT cooperate with your teammates, because they are now “the competition”. Ideally velocity ratings are determined by me to see how strong members can help weaker members and are not to be sent upstairs. I would act as the buffer to keep the heat off the team. But: Business would tell me unequivocally that I was naive and business can’t abdicate their fiduciary responsibility to shareholders to “separate the wheat from the chaff” at every level to be effective and efficient. They also told me it was MY job as Scrum Master to make my untrained team work together effectively and accept that downsizing happens sometimes and we all need to accept that and their individual velocity is the best way to stay off the hit list. Basically, I had to put my team members back on that lonely toxic treadmill to the unemployment office. So I quit Scrum. On my final Scrum contract the client’s Scrum approach failed right out of the gate and they were probably glad to see me leave. They instead searched for “the RIGHT Scrum expertise” since I obviously was the problem and had not even trained the team in my first weeks there. (I was not a certified Scrum Trainer and was never hired as such.) The team was dissolved in a reorg not long after and my teammates were given the bum’s rush because they were blamed for costing managers their bonuses that year.
Great presentation, I couldn't agree more. Buying into one particular framework is not agile. Agile is a mindset, not a framework. The organization must have the mindset to always change, and adapt as necessary... even if this includes moving to a waterfall approach. Not all problems are the same, and not all teams are the same. Do what is best for the team, environment and organization as a whole. Find your way and always reflect on what is working and what is not. Be ready to pivot if necessary.
As I see waterfall will never die, there is a waterfall in every iteration, just the scale is getting smaller and smaller. Scaled Agile doesn't work because it operates on a bigger scale so it converges toward the classical waterfall. I recently got into continues delivery and the main things are iterative development, small steps, fast feedback. I believe this is agile and this could work for project management as well.
It's ironic that Agile preachers always blame waterfall for things that go wrong (_"Agile never fails, YOU who did it wrong"_) but LOTS of products in the past (not just software) were created by that method and they were great, those companies managed to grow from garage startups to largest market cap corporations in the world using Waterfall approach. On th Agile side, not so much 🤔
Thank you for this. You've managed to deliver something that both shakes some of the things I'd like to be true as well as articulate some of the things I'd like to be true. Will have to re-listen and reflect :)
Very nice, this articulates thoughts i had, but could not quite put my finger on. A random thought: Maybe it is not necessary to really scale agile. Maybe just coach teams to be agile (if they are willing) and then don't stand in their way.
It definitely started around software but its application is so much more now that software is such a huge part of most products and complexity has grown
@@InspectAdaptLtd right, agile has lost its meaning amidst the mad dash for the enterprise to get in on the game. Agile is still about producing software, all the rest of the scrum/agile enterprise stuff is just a distraction from producing software.
If a triple-A game like Sea of Thieves can do it, it can be done for any project. The problem is in one of your first statements, Agile is not a 'solution' to anything. It's a way of thinking/working that can't be implemented by one person (or even a couple) onto a company. It is a team and company effort. The mere idea of imposing it on people proves that whoever tries it doesn't understand Agile. No process is 'Agile' by default and Agile looks different for different projects/teams, it's even in the word. You can try Agile suggestions, yes, but there is no 1 size fits all scheme to get there. A good start for a lot of projects is to not expect people to just: 'do it like this, shut up and go fast'. And then work out your teams own way from there. You'd be surprised if you actually gave good devs the chance to speak their mind and think about the process.
@@InspectAdaptLtd I did, I'm not attacking your video. I agree with the general message. Not so much with the title, but I guess it helps reach the right people. I just wanted to reinforce that it can be done with an example. Anyone who thinks a project is too complex or big for Agile should think twice if a triple-A can do it.
I'm in agreement that no product or project is too complex for agile. The more complex, the more suitable it is, in my opinion. However, trying to become an "agile organisation" by scaling an agile approach just doesn't make sense or work. I think we are in agreement there.@@stevendhondt771
I agree if you implement SAFe as you describe it it will not work, however I would be cautious about saying the anti- pattern is the rule and applies to all implementation of all methods of agile.
I know this probably doesn’t come across as cautious but SAFe is awful. For me, if you don’t want to do things in an agile way, that’s ok...sometimes that’s the right thing...but in those cases don’t do something that pretends to be agile.
@@rmworkemail6507 Interesting I thought Agile was about being open, being willing to try new things, clear not the case for you, all judgy and all as you are.
@@shaneharrison581 That's not Agile. Agile means self-managing and self-organizing teams, which means that middle management is redundant and unneccessary. SAFe mandates a heavy middle management presence and even buy-in from the very top of the company, and is thusly the antithesis to Agile. Several large e-commerce-heavy companies in my country are failing hard at delivering anything of value right now, and they all hopped on the SAFe bandwagon a few years back.
I don’t have first hand knowledge but I very much doubt they have scaled agile. These organisations will be much more organic and contextual I would think.
Ok, agile @ scale does not work, and motivation would? Well, actually agile does work. But, first of all. Agile for organization is chimera. Never existed, never will. Agile in SW development does work. Even at scale. Yet, there are principles which need to be followed. Just, please, don't exchange incompetence with impossibility.
Hi there. Thanks for watching and commenting although I'm not sure I understand your message. I agree that agile works and I agree that agile in SW Dev works. I have seen organisations adopt principles very much aligned with the agile manifesto at the macro level although I think we also agree that scaling agile to the organisation has not and will not work. The five principles of ORGANIC agility seem to be remarkably effective at helping organisations become more resilient and coherent which is much more valuable than becoming "agile".
A lot has indeed changed in 22 years...and I think that's the point. The rate of change requires greater agility. There's a strong argument for poor application of agile approaches but the principles of fast feedback, collaborative, cross-disciplinary learning, iterative-incremental value delivery are more relevant than ever. We just need better application IMHO
Agile is very good at prototyping software, and horrifically bad at making maintainable, scalable software. You can't go from an ambiguous set of requirements and no code, to a database, server, and UI in a week or two without making a lot of bad decisions.
It's a technical challenge alright and certainly not easy. Many organisations don't have the feedback loops, empowered and supported teams and willingness to enhance the infrastructure to make this easy. I personally think in most situations companies find themselves in today, however, that this is the necessary path despite its difficulties.
@@InspectAdaptLtd, it's the opposite. Agile is a business challenge,, not a technical one. In companies that are technically oriented, agile works perfectly fine. In companies that are business oriented, agile is just another buzzword.
The root problem seems to be that "we have to respond to inputs much faster now". Where did this rationale come from? Did the big companies grow terrified of small startups taking all their market share? Did the small startups grow terrified of each other? When did we trade our confidence in knowing our problem domains to fear that anyone could just waltz in with less knowledge and dethrone us? I remember companies built great stuff in good time by just focusing on their core competencies. But now everyone seems determined to keep competitors at bay using superficial "we're more agile" means. Is no one confident in their abilities anymore?
Loved it. I think it's one of the most sobering presentations about agile and methodology adoption in general that I've heard in the past 10 years. Everyone is histerical about "being agile" at an organization level, in all teams, even where it just doesn't make sense to have agile to begin with. And the Culture part of the equation is so easily and so often forgotten (or pretended that it doesn't matter, 'cause it's easier that way), and I also believe that it's at the core of any transformation or evolution. Culture fosters the right change from within, instead of it being pushed and shoved down people's throats without any thought. The copy-paste model of scrum or even the spotify model is the way I've seen fail again and again, but the consultants keep getting hired and churning pass organizations with the same powerpoint slides.
Thank you so much for putting it all together.
Thanks Sanaz! Culture is key
Same for all religion, sadly. Replace the word "agile" with "religion" and everything is still true. Especially for top-down control religions like the Abrahamic ones.
I was a scrum master for a couple of years. This absolutely matches a lot of my experience in the field. But not the worst of it.
On nearly every contract the one thing I expressed repeatedly to product owners and stakeholders and management - who were usually “self-trained” in Agile by skimming Death March and attending a luncheon/seminar, and who were energized by the prospect of no longer “wasting” FTEs with documentation, or on testing or deployment, which would now be magically automated - was that my team members MUST be assured they have job security for a minimum of at least a few quarters under Scrum, which always reveals immediately all the rot that was intentionally hidden in the prior SDLC approach and will now be replaced with cooperative team effort, which will reveal it. Teammates MUST NOT be ranked by management by their velocity against their other teammates’ velocity or there is only reinforcement to NOT cooperate with your teammates, because they are now “the competition”. Ideally velocity ratings are determined by me to see how strong members can help weaker members and are not to be sent upstairs. I would act as the buffer to keep the heat off the team.
But:
Business would tell me unequivocally that I was naive and business can’t abdicate their fiduciary responsibility to shareholders to “separate the wheat from the chaff” at every level to be effective and efficient. They also told me it was MY job as Scrum Master to make my untrained team work together effectively and accept that downsizing happens sometimes and we all need to accept that and their individual velocity is the best way to stay off the hit list. Basically, I had to put my team members back on that lonely toxic treadmill to the unemployment office.
So I quit Scrum. On my final Scrum contract the client’s Scrum approach failed right out of the gate and they were probably glad to see me leave. They instead searched for “the RIGHT Scrum expertise” since I obviously was the problem and had not even trained the team in my first weeks there. (I was not a certified Scrum Trainer and was never hired as such.) The team was dissolved in a reorg not long after and my teammates were given the bum’s rush because they were blamed for costing managers their bonuses that year.
Great presentation, I couldn't agree more. Buying into one particular framework is not agile. Agile is a mindset, not a framework. The organization must have the mindset to always change, and adapt as necessary... even if this includes moving to a waterfall approach. Not all problems are the same, and not all teams are the same. Do what is best for the team, environment and organization as a whole. Find your way and always reflect on what is working and what is not. Be ready to pivot if necessary.
Thank you for taking the time to comment and I agree with what you say there.
no. waterfall is never agile.
As I see waterfall will never die, there is a waterfall in every iteration, just the scale is getting smaller and smaller. Scaled Agile doesn't work because it operates on a bigger scale so it converges toward the classical waterfall. I recently got into continues delivery and the main things are iterative development, small steps, fast feedback. I believe this is agile and this could work for project management as well.
I agree. I don’t think it’s about waterfall dying. There will always be a place for that type of approach
It's ironic that Agile preachers always blame waterfall for things that go wrong (_"Agile never fails, YOU who did it wrong"_) but LOTS of products in the past (not just software) were created by that method and they were great, those companies managed to grow from garage startups to largest market cap corporations in the world using Waterfall approach.
On th Agile side, not so much 🤔
Thank you for this. You've managed to deliver something that both shakes some of the things I'd like to be true as well as articulate some of the things I'd like to be true. Will have to re-listen and reflect :)
Thank you for the thoughtful consideration. I’m glad it provoked some reflection
Lovely talk, thanks Geoff. I especially liked the pyramid of results.
Glad you enjoyed it
An interesting and thoughtful presentation.
Many thanks!
Very nice, this articulates thoughts i had, but could not quite put my finger on.
A random thought: Maybe it is not necessary to really scale agile. Maybe just coach teams to be agile (if they are willing) and then don't stand in their way.
I think that’s a very good way to look at it
Agile: "We are uncovering better ways of developing software"
Scaling framework: "... so you don't have to."
Agile was never about scaling, it was always about producing software.
It definitely started around software but its application is so much more now that software is such a huge part of most products and complexity has grown
@@InspectAdaptLtd right, agile has lost its meaning amidst the mad dash for the enterprise to get in on the game. Agile is still about producing software, all the rest of the scrum/agile enterprise stuff is just a distraction from producing software.
If a triple-A game like Sea of Thieves can do it, it can be done for any project. The problem is in one of your first statements, Agile is not a 'solution' to anything. It's a way of thinking/working that can't be implemented by one person (or even a couple) onto a company. It is a team and company effort. The mere idea of imposing it on people proves that whoever tries it doesn't understand Agile.
No process is 'Agile' by default and Agile looks different for different projects/teams, it's even in the word. You can try Agile suggestions, yes, but there is no 1 size fits all scheme to get there. A good start for a lot of projects is to not expect people to just: 'do it like this, shut up and go fast'. And then work out your teams own way from there. You'd be surprised if you actually gave good devs the chance to speak their mind and think about the process.
Just wondering. Did you watch the video?
@@InspectAdaptLtd I did, I'm not attacking your video. I agree with the general message. Not so much with the title, but I guess it helps reach the right people. I just wanted to reinforce that it can be done with an example. Anyone who thinks a project is too complex or big for Agile should think twice if a triple-A can do it.
I'm in agreement that no product or project is too complex for agile. The more complex, the more suitable it is, in my opinion. However, trying to become an "agile organisation" by scaling an agile approach just doesn't make sense or work. I think we are in agreement there.@@stevendhondt771
I agree if you implement SAFe as you describe it it will not work, however I would be cautious about saying the anti- pattern is the rule and applies to all implementation of all methods of agile.
I know this probably doesn’t come across as cautious but SAFe is awful. For me, if you don’t want to do things in an agile way, that’s ok...sometimes that’s the right thing...but in those cases don’t do something that pretends to be agile.
It's awfull, its not even Agile to begin with. Period.
@@rmworkemail6507 Interesting I thought Agile was about being open, being willing to try new things, clear not the case for you, all judgy and all as you are.
@@InspectAdaptLtd Sadly many people in the world have managed to scale it, sadly you are not one, lucky for me I have.
@@shaneharrison581 That's not Agile. Agile means self-managing and self-organizing teams, which means that middle management is redundant and unneccessary. SAFe mandates a heavy middle management presence and even buy-in from the very top of the company, and is thusly the antithesis to Agile. Several large e-commerce-heavy companies in my country are failing hard at delivering anything of value right now, and they all hopped on the SAFe bandwagon a few years back.
Google? Amazon?
I don’t have first hand knowledge but I very much doubt they have scaled agile. These organisations will be much more organic and contextual I would think.
I mean... It never worked for small teams on the first place...
Scaling a fish, yes. Scaling a shark, hell no. Same for agile ™️
"self-organize... like this:" brilliant! The confirmation bias is strong with this one.
Thanks Jamie. Or baby Yoda as going to think of you now I am
SAFe is not safe. At least that's what my therapist says.
Ok, agile @ scale does not work, and motivation would? Well, actually agile does work. But, first of all. Agile for organization is chimera. Never existed, never will. Agile in SW development does work. Even at scale. Yet, there are principles which need to be followed. Just, please, don't exchange incompetence with impossibility.
Hi there. Thanks for watching and commenting although I'm not sure I understand your message. I agree that agile works and I agree that agile in SW Dev works. I have seen organisations adopt principles very much aligned with the agile manifesto at the macro level although I think we also agree that scaling agile to the organisation has not and will not work.
The five principles of ORGANIC agility seem to be remarkably effective at helping organisations become more resilient and coherent which is much more valuable than becoming "agile".
Agile is outdated, 22 years have passed and many things have changed since then
A lot has indeed changed in 22 years...and I think that's the point. The rate of change requires greater agility. There's a strong argument for poor application of agile approaches but the principles of fast feedback, collaborative, cross-disciplinary learning, iterative-incremental value delivery are more relevant than ever. We just need better application IMHO
agile will never be outdated.
Agile is very good at prototyping software, and horrifically bad at making maintainable, scalable software. You can't go from an ambiguous set of requirements and no code, to a database, server, and UI in a week or two without making a lot of bad decisions.
It's a technical challenge alright and certainly not easy. Many organisations don't have the feedback loops, empowered and supported teams and willingness to enhance the infrastructure to make this easy. I personally think in most situations companies find themselves in today, however, that this is the necessary path despite its difficulties.
@@InspectAdaptLtd, it's the opposite. Agile is a business challenge,, not a technical one. In companies that are technically oriented, agile works perfectly fine. In companies that are business oriented, agile is just another buzzword.