Scrum is a decent place to start, but it really isn't the be-all of agile and in many cases, one could argue, it becomes the anti-thesis of "lean". On the bright side Scrum has done much to get agile into places that probably wouldn't have considered anything without a certification and consultant-based training attached to it. The bad thing about Scrum is that has also done more to facilitate cargo-cult agile than anything else.
Iterations? We don't sell iterations around here we sell software, software features specifically. Planning releases around iterations often results in more pain than pleasure I'm afraid, but it is still usually a step up from most traditional waterfall processes (on that note, most traditional waterfall shops really have no idea how to do waterfall either).
Stand-ups? Great when there is no more than 5-8 people, more than 10 and they quickly become a way to bore the entire team for 15 minutes.
Velocity? A useful planning tool, but often seen by managers who have "drunk the Scrum kool-aid" as a way to measure team performance. It's not, and in the end planning poker is simply another euphemism for task estimation, which in turn is a euphemism for performing magic tricks.
Scrum certainly has it's place, but it's important for teams learning it to treat it as just a few steps along a much longer path.
Whenever I see people doing Agile/Scrum, I urge them to understand its limits, its purpose, and the agile Next[1][2], where, for instance, learning about products and users is more important than working code.
It is nice to see people trying to learn Agile methods, and I'm glad these guys have found something that works for them. I think they've done a great job getting started.
But to set the context for others, this is adopting circa 25% of what I'd consider a serious Agile approach. That's fine to start, and many stop there. But I hope they keep at it, as there's a lot more benefit to be gained.
Your second paragraph is the kind of wording that gives me, as a developer, the heebie-jeebies. If a development group is improving their workflow and structure with the addition of a few thoughtfully chosen changes to what they had before (a morning standup meeting, shorter iterations, tracking burndown), then that to me sounds like a very pragmatic approach. Implementing even more changes, merely for the sake of having a capital-A "Agile" designation, just sounds like cargo cultism.
Reminds me of a message I saw once on the "LuaForge Development" Google group. Literally 96 hours after the current LuaForge leadership and some people on lua-l decided to team up and create a new LuaForge, a buzzword-filled e-mail was sent to the mailing list entitled, "Request to use Agile Development Methodology." [1] Jim Whitehead responded, "You don't need agile development to have clearly defined roles, responsibilities and standards. A long time ago that used to be called 'project management' and it worked just fine =)"
I didn't say they should do it for Agile, I said they could do it for the benefits they could gain.
I agree there's a problem with cargo cult Agile. There was a problem with cargo cult design patterns, too. In both cases, you can certainly turn your back on the hyped thing on the theory that your team is already sufficiently awesome.
For the daily meeting with developers in multiple locations? What are all these other "lots of tools"? If you mean Skype, iChat, etc., wouldn't those just be variations on a theme?
Iterations? We don't sell iterations around here we sell software, software features specifically. Planning releases around iterations often results in more pain than pleasure I'm afraid, but it is still usually a step up from most traditional waterfall processes (on that note, most traditional waterfall shops really have no idea how to do waterfall either).
Stand-ups? Great when there is no more than 5-8 people, more than 10 and they quickly become a way to bore the entire team for 15 minutes.
Velocity? A useful planning tool, but often seen by managers who have "drunk the Scrum kool-aid" as a way to measure team performance. It's not, and in the end planning poker is simply another euphemism for task estimation, which in turn is a euphemism for performing magic tricks.
Scrum certainly has it's place, but it's important for teams learning it to treat it as just a few steps along a much longer path.