[wheaties]

You're still a student? The first year at a full time gig is going to feel a bit overwhelming. You'll have so much you have to catch up on, either technology wise, development practices with a larger team-wise, or just design-wise. This type of thing will sink in once you've been somewhere at least 2 years. Then you'll understand.

[gedrap]

I know what you mean :)

For the last nearly 2 years I make living from doing part-time gigs. At one gig I was lucky to have a rather experienced manager and he taught me about OOP design, a bit on Agile practices and testing. That was an eye opener and put me on the right track for other gigs.

When my class mates talk 'oh man that agile thing is such shit, I just wanna write some code' I tried to convince them at first, now I just smile :)

[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"