My own experience with (lack of) Agile development: - Water Epic Fall. An obvious symptom of Cargo Cult Agile. This happens when the phases of a waterfall proj

My own experience with (lack of) Agile development: - Water Epic Fall. An obvious symptom of Cargo Cult Agile. This happens when the phases of a waterfall project are disguised as epics that represent a huge fraction of the development. In my own experience this is caused when the MBAs try to force Scrum from top to bottom so they can pretend that they're doing agile on paper and thus "fulfill the values(tm) of the company". This is even worse than usual waterfall because it places an artificial limitation on making multiple components of the project live and evolve together and so "world collides" when each time an epic "is closed" and the new one has to find a place to fit, somehow. Proposition: epics are a way to breakdown work and work is done by a the team and so leave it to the team doing the work. Rule of thumb: stories are defined by time while epics are defined by stories with a common concrete idea. - Daily meetings are mostly reports to the boss. Proof of that was when the boss wasn't there meetings that normally endured for 30 minutes and more would only take 10 minutes. In none of these meetings the boss helped to resolve the blockers; other devs did. Proposition: no boss in daily standup; DSMs are a tool for and by the dev team. - Devs are blamed for not finishing stories in time. This is usually due to a bad backlog grooming where definition of ready is left as an exercise to the reader. It is also a symptom of the Water Epic Fall described above. Devs has to deal with the fact that the code isn't simply ready to integrate the new feature but the exercise to check if it was was never done in the first place. This is made worse when it is the dev who estimated the story and is now "responsible" for it. Also made even worse when "architects" with veto power decides what is ready or not and what the stories are. Proposition: again, let the devs have the final words on the backlog and its stories. - Asking for permission to fix problems and remove friction. This is usually a problem caused by survivor biased MBAs who think of the heroics they did 20 years ago as war medals and a good development methodology because after all "this is why we could afford our new building". This problem often forms a symbiotic relationship with a culture of fear lead by barons aka "team leads". Proposition: revolt. Seriously. "We can't work this way anymore" during the quarterly report mega-meeting in front of the C*Os has its impact. Otherwise change jobs and make sure to let HR know by naming names. It's sad to see this kind of situation but if you don't it will poison every aspect of your life. - Nobody RTFM. Seriously. Who can say they have read at least one book on Lean/Agile/Scrum/DevOps from cover to cover? I would say most MBAs didn't because there's an entire industry based on giving very expensive courses and on agile consulting just to repeat verbatim what are on these books. And even then most of the time you will never heard of concepts such as "lead time", "feed back", "release often", "no wip", etc. Some devs do tho, but they usually quit when they realize that their conversion efforts go to waste and provoke the wrath of the MBAs and the Teams Leads(tm) because either "we're not a startup" or "we can't be like Google" - Large teams. Scrum doesn't really say much about how to work with multiple teams. Even less so where you're dealing with hardware and firmware development.