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?
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 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 :)
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.
Lovely talk, thanks Geoff. I especially liked the pyramid of results.
An interesting and thoughtful presentation.
Agile was never about scaling, it was always about producing software.
Agile: "We are uncovering better ways of developing software" Scaling framework: "... so you don't have to."
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.
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.
Agile is outdated, 22 years have passed and many things have changed since then
I mean... It never worked for small teams on the first place...
Scaling a fish, yes. Scaling a shark, hell no. Same for agile ™️
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.
"self-organize... like this:" brilliant! The confirmation bias is strong with this one.
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.
Google? Amazon?
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.
@sanazzadegan4086