I think this gives me a glimpse. To me, agile is about adjusting your planning so you can get customer feedback and adjust your project accordingly. Without that, much of what I value from agile goes out the window.
The problem is the brand has been captured by consultants selling something that doesn't jive with the original ethos.
You were supposed to talk to the customers. Now you have dedicated POs that determine what the team will work on, but they're also too junior to talk to the customers. It's okay though, you have dedicated PMs that'll talk to the customers, right? Only they're typically to busy pushing a personal agenda to climb the corporate ladder to actually care.
It's cool though, we're agile so we can just change the process? Nah, there's now there's extremely prescriptive processes. Heaven forbid you don't find the hour long retrospectives, that you can't action anything from, useful.
So basically it boils down to the daily status report which ensures you a) show up on time and b) report on your commitments, and generally being forced to overcommit by committe on really short deadlines, so you can be pressured to work free overtime because apparently its your commitment?
Of course, not everyone abuses agile like this. But they don't typically advertise, sell, or even really talk about agile all that much.
In general - I consider "agile/scrum master training" on a resume as a pretty serious black mark, for basically the same reason: The training is all from consultants who preach bs to sell courses and products to management - very rarely does the training encourage simple acts like "talk to your customers" or "let your devs shadow a user" or even "treat your team like people". It's all process over people - the opposite of the intent.
- followed as a religion, especially when it doesn’t make sense (daily stand up for a team working in the same room and collaborating all day long? One day lost every 2 week for planning and review? Trying to do a stand up with too many people?)
- using it as an excuse to not prepare the project and without clear objective
- trying to fit agile in a fixed schedule (like trying to sync with a big marketing release, complete with pre reserved tv spot 1 year in advance)
- not listening to the final customer - heck, not even making sure he’s interested - trying to complexity it by adding a lot of metrics (financial is a big one)
- making estimate as the law
This allows everyone to project their own desires on to it - from CEO to PM to programmer to consultant.
I get why this happened - the original consultants probably felt that defining it in a way that would alienate people (especially leaders with the budget to hire them) wouldnt be good business.
Nonetheless it led to all this. Scrum was almost worse - an attempt to be specific and regimented about process without being alienating which is how I ended up working on a project for BigBank where they asked for N story points to be delivered per month in the contract.
Ideally Id like to see some new sort of movement X that follows the heart of what agile is and isnt afraid to get specific in a way that would alienate a CEO/pm with waterfall/controlling tendencies. This way I could ask in a job interview if the companies does X or agile and get a clearer answer about wtf they do.
You can easily uncover in an job interview if they honor those preferences.
* How is the customer involved in shaping the software? Give specific examples.
* Who decides what will be developed? Where does my role fit in?
* Will I be able to ship production code my first week? (Why not?)
Et cetera.
Even better: come up with your own manifesto of preferences for ways of working.
And then score potential employers and your teams against them.
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
and
"Individuals and interactions over processes and tools"
to argue that writing code comments, tests and documentation wasnt worth investing in when we can all just talk.
This was after a series of disasters that code comments, tests and documentation would all have helped with. It's perhaps hard to imagine that this would be controversial but it was - the fact it was 10 years ago and we were under pressure to deliver can perhaps partly explain why.
Try as I might I couldnt argue that his interpretation was wrong. I stared at the words and was shocked when I realized that it was actually perfectly valid.
I have my own understanding of "good agile" and no doubt a lot of developers share it after many decades of good experiences and bad experiences and it arguably means putting processes and tools over individuals and interactions some of the time - like using a linter/autoformatter over arguing about formatting.
I dont know what we need but probably it looks a lot more like an updated version of the joel score than the vague soft focus angel tinged* crap that is the agile manifesto.
For what it's worth, I think your list is also a bit vague.
* I swear that the of the agile manifesto web design was also stolen from a baptist church.
So your colleagues view was a pretty extreme one compared to the moderation shown there. But like any philosophy you end up with fundamentalists taking things too far even in the face of reality being more complex. It’s terrifyingly dogmatic to argue from scripture rather than pragmatics.
I agree that arguing from scripture is awful. I havent tried to do it since. I would like to see some other sort of anti-waterfall set of principles that I could get behind though.
No real engineering team exists in a vacuum, so more often than not, all Agile processes degrade into waterfall.
If you're lucky and you live in a pure software world with no 3rd parties imposing deadline dates on you, great. In my experience, those worlds are few and far between.
There will always be major events that are locked to fixed dates, like conferences, launches and many things that are impacted by launches (like hiring new teams to be using the new systems that we were supposed to be building). This does not mean this company sucks, or working at this company sucks, it usually means this company is profitable.
"Waterfall" is starting to get twisted into some sort of virtue signaling for folks that like to complain about deadlines.
Managing this tension is what we all need to be good at - there's definitely no silver bullet or perfect methodology to manage this, because it is always evolving.
So-called capital-A “Agile” - including the thing that people call Scrum, SaFE, all the other hard coded nonsense - are just turnkey processes, churned out by authors who got lucky, that tend to be implemented as silver bullets, with almost no regard for the actual principles and value of the manifesto from which they draw their name.
https://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-s...
> Keep the values, keep the principles, think for yourself. A core premise of agile is that the people doing the work are the people who can best figure out how to do it.
Brilliant.
It fails (and therefore is loathed) when the people who need time, focus, room, safety to achieve the outcomes are forced into working with particular processes, procedures or tools in order to satisfy someone other than the team or the customer.