[a-priori]

To be fair to your mates, a lot of places that claim to do 'Agile' do a shit job at it. It turns into a cargo cult where they wrap their bad practices in Agile lingo to make them sound good. I've seen that happen a lot at various companies.

If that's the only 'Agile' you've been exposed to, then it's perfectly reasonable to think 'oh man that agile thing is such shit'.

[gedrap]

I agree with you. It was somewhat reasonable basic stuff - asking for requirements (because they were intentionally ambiguous), working in sprints (rather than you have to do this, come back in 4 months), etc. I just believe it is hard to totally 'get' it in university and when your biggest previous application was ~3 days of coding lab :)

[voltagex_]

How can I tell the difference between Agile and 'Agile' then?

[a-priori]

The same way you spot other cargo cults: look at the team's processes critically. Start from the basics, with the Agile Manfiesto. It's well summarized on the Wikipedia page here: http://en.wikipedia.org/wiki/Agile_software_development#Agil....

I believe that manifesto is the only important part of Agile. Everything else is just suggestions about how to accomplish that goal. If a particular practice does not make sense for you, in your particular situation, then it's garbage. So, look at your team's processes and ask yourself this:

If you were to reverse engineer a process that would accomplish the goals of the Agile Manifesto (e.g. the developers know what needs to be built, and there's short feedback loops between developers and stakeholders), would you end up with something that looks like what they're doing? Could you drop any part of your process and have things still work?

If you discover too many red flags -- things that serve no purpose except to "look Agile" -- then you may be in a cargo cult.

[chiph]

If you see this on a slide, you'll know: "Sprint 0: Envisioning and Planning"