The state of agile 2022 Report
I sometimes describe myself as a 'recovering agilephobe' and you don't need to understand much about me and my views to understand why...
On an average week you will see the following sort of topics about Agile: -
‘Why SAFe will ruin your teams, and isn’t a ‘proper’ framework’
And
‘How SAFe will save your teams and is the best thing since sliced bread’
Don't forget
‘We hate SCRUM and you should to’
But also
‘Use SCRUM if you want to guarantee your teams success’
And this one
‘Why Agile is different to agile’
This is my fav
‘Blah blah blah something about agile being crap/amazing/the reason for third world hunger’
Hopefully you get my point, there is a lot of crap on the interweb today about agile, sorry Agile – because clearly there is a difference between an uppercase Agile and a lowercase agile (Although no one can really give a quantifiable answer on it)
Add in a mixture of people who’ve either be practicing real agile frameworks for 2 weeks and are now telling everyone else how to do it or people who’ve been teaching it for the last 10 years but last worked with a real team in the trenches of software development 15 years ago and you’ll see why I think we are truly screwed when it comes to delivering valuable working software to users.
And what of the ‘experts’ and original signatories of the now oft quoted and vastly misunderstood manifesto for agile software development?
Well, some of them are still going and fighting the good fight, some of them are probably sitting here wondering where it all went wrong and some of them have monetized the entire idea entirely and will now tell you that in order to succeed you need to pay them to enter their walled gardens and take 200 different certification courses just to be able to practice agile with a team.
The net result of all of this is that agile is not in rude health, it’s on life support and the prognosis looks bleak. Real people and real teams sit and stare in a mixture of bemusement and utter confusion.
Larger enterprise companies who missed the initial first few waves of agile transformations are now left with large consultancies who have no clue on real agility charging them obscene figures to give them a copy of the scrum guide, sit with their teams for 6 months and try and ‘train out’ decades worth of engineering knowledge and expertise to be replaced with PI planning and graphs for the C suite that show hockey stick growth in frequency of deployments and equate it to faster, safer releases before they sail off into the sunset with a queens ransom to consult the next shmuck/enterprise.
And everyone else is left wondering where they start.
Yes, agile today is all about how quickly you can convince others that your framework is better than everyone else’s by a mixture of bullshit, snake oil and courses on it to demonstrate adherence.
In the mix are some genuinely good people with a heap of real-world knowledge trying to push against this tidal wave of BS, but the sad reality is that maybe they’ll win the occasional battle for agiles soul, but the war? The war was lost a long time ago in my opinion.
We’re so far away from the intentions of the initial signatories of the manifesto who met at the Snowbird ski-lodge in what felt like a lifetime ago that I struggle to see how we come back from this.
Recommended by LinkedIn
Take a gander through your LinkedIn feed on an average day and you’ll read about how you need to think with ‘an agile mindset’ whatever the hell that is, but hey, mention it because it makes you sound like you know what you are talking about.
Fake profiles, fake qualifications, fake certification bodies, unnecessary courses and everyone trying to make a fast buck at the expense of the millions of teams who just want to build good software for customers.
It’s a shitshow
I could go on, trust me, I’ve got material on this that will fill a book one day, and feel free to point the finger at me and say I’m simply adding to the noise about why X is better than Y. If we’re looking for suspects holding the smoking gun standing over the slowly bleeding out body of agile then we only need look in the mirror in many cases to find the perpetrators.
So, what’s my advice for what it’s worth.
Go your own way. And remember some of this…
Apply everything with consideration
Scrum is a great framework to start with, but apply it with consideration, not everything in the Scrum guide will necessarily work for your team either immediately or ever
Its not a sprint, even if you are using them
True agile working is a journey and along the way a team will loosen some of its baggage or leave it behind entirely, the point of the game is value, not rigid application of all of the techniques of whatever framework you choose to use, the end destination should never be met if you are focused on continuous improvement, because it’s a cycle of inspecting and adapting how the team works to add in those marginal gains that help a team be slightly better today than they were the day before
Badges are for scouts not for helping a team work well
Are certifications worthwhile? Sometimes, but only ever as an introduction to a framework or practice and should never be used to re-title someone into a new role and then religiously apply all of what you have been taught at a team, question everything and work with your team(s) to understand what could work and what won’t, experimentation is key and a willingness to accept that some experiments will fail, learn from this and apply it back into the mix
Scaling is something you find on the end of your taps, not in a software team
Scaling frameworks may give a warm fuzzy feeling to senior leaders and may help a larger IT department start a journey to agile software development, but they are hardly ever the end game and continuous improvement practices are even more important in these types of environment
People beat process any day of the week
Ignore the vast majority of advice (Feel free to do the same with mine) because you are an individual in a team that is entirely different to every other team out there, the key element here is people, not practice, not frameworks, not courses, people.
People behave in sometimes unexpected ways and do things totally different to how we imagine they might, the human element is what puts agile frameworks on their backsides quicker than any other potential impediment, expect this, welcome challenge and try to understand why people may be acting the way they are, it is hardly ever because they simply want to be an arsehole and normally due to the socio/psychological factors in play for the vast majority of humans.
Whisper it, but we don’t tend to like change, despite working in a business sector that suffers vastly more of it than most, so don’t be surprised when introducing change to a team to see a variety of very natural human responses to said change including complete opposition
Keeping up with the joneses will bankrupt you
Do not compare yourself or your team to what you read on LinkedIn or any other website or from what you hear at events and conferences, you and your team are very different and running your own marathon and despite what you may hear from some about guaranteed routes to reliable and quick deliveries for users, they didn’t start that way, and chances are a lot of what they did will be totally different to what you will face, by all means use tips and advice if you think they will help and sometimes imitation is the highest form of flattery but the problems you and your team face are in most cases totally different to the problems that Spotify or Google faced.
So how do we come back from the smoking ruin that is Agile in 2022?
Some of the above suggestions may help you, experimentation will definitely help you, copying other people definitely won’t.
And hey, agile in 2022 is way over-rated at this point, going back to the basics of working with a confident and safe team who feel cool in their own skin and want to do a good job for their users regardless of what techniques they use to get there is far more valuable than trying to change the world with ScrumbanSAfe mk2 isn’t it?
And don’t forget, before we had agile, we were already working in agile ways with techniques such as extreme programming (XP)
PS – Don’t for the life of you just try and apply the ‘spotify model’, because (whisper) it doesn’t exist.
Director of Major Accounts at Computrition, Inc.
2yThis is a fantastic article!!!!
Technical Lead @ Redgate Software | ✨Former Six-Times MVP on C# | 💖 Grow Software Engineering Leaders | 💻 Trainer, Mentor and Coach @ productivecsharp.com | 🎤 Host of The Productive C# Podcast | 📚 Books Reader
2y100%. I totally agree with you on this one and I would add that this also apply to technical practices in addition to team processes. Every framework, tools, techniques are just a collection of ideas and tips you can pick and choose from to incrementally define your own processes and practices to apply in your unique business context. It’s a continuous experiment and ultimately the team “gut feeling” can go a long way when combined with a psychologically safe environment where people know and trust each others.
Recruitment Exec- Connecting enterprise software professionals with benchmark employers | Tampa, FL & Cambridge, UK
2yGreat post Ben and some of your points around expert advisors don't just apply to the world of Agile! 'People beat process any day of the week' - Never has a truer word been spoken. A happy, well supported team with freedom to think and act will consistently outperform! Then we try and replicate their processes without realising that is just one small part of their success.