> I feel like this is all a big fat joke. Its not, but many companies get it wrong (sounds like your one does too). In my opinion, a big part of the problem i

> I feel like this is all a big fat joke. Its not, but many companies get it wrong (sounds like your one does too). In my opinion, a big part of the problem is that you get some manager types who thinks they're "doing agile" just by cargo culting it a bit and then wonder why it didn't work. Another big problem is when teams make up their own pseudo-agile (that is, they pick only some parts and change others saying things like "we work differently so needed to change it to suit us") and then complain that agile doesn't work when it fails. That's why I like the GROWS Method [1] -- its designed for customisation because it acknowledges that every team actually is different and has different needs, but its also split into tiers that you should progress through and customising the process is a higher tier: you need to be experienced enough in agile to know what works and what doesn't work for you before you start to change or twist it into something else, otherwise you end up with an incoherent unworkable mess that adds more overhead than the problems it solves, or you have some pretend-agile that doesn't actually achieve anything. You need to get beyond that to what agile is (in my opinion) really about: getting shit done, aligning stakeholders and team members, communication. [1] http://growsmethod.com/ http://growsmethod.com/