I attended a .NET user group meeting here in Albuquerque last night where the discussion was on CMMI and Agile Programming. Who out there is using Agile right now? Or even Extreme Programming? Has anyone started using CMMI to really tie in all the different processes and methodologies?

Agile seems like a lot of work up front, but as I hear and read more about it, it seems like a really smart way of developing. The idea of delivering a working product after each sprint is really neat, but I'd have to totally re-think how I develop applications, both as a manager, and a programmer.

So are you using Agile? Extreme? CMMI? Or any other methodology? What has your experience been and is it something you'd recommend?

Well from the Wikipedia page I gather that Agile Programming is basically:
* Release often
* Talk to your team members
* Adapt your plans as necessary
* Have someone in charge who knows what they're doing

Feel free to correct me if I'm wrong, but it sounds like just another buzzword to me.

The way I've seen and done agile, is get a rough idea of what the user wants, whip out some functionality, talk with user, make adjustments, continue with small functional incremental releases, that happen often.

It's a bit more than just a buzzword. I would like to try out an environment that supported agile programming as it sounds like a great way to work. With a traditional larger development team my understanding is there are large milestones and large group meetings. Agile uses small groups that meet frequently (at least once per week/sprint), for a quick session in order to go over results for that week and evaluate new tasks. I'm sure people were doing this before the term 'agile' came along, but it gives a structure and format to that sort of organization.

It is a buzzword, it doesn't tell you anything about what it is.

Not saying that the concepts aren't good ideas, but it sounds to me like it's just a name someone decided to give to something that people already do.

Saying "We should meet often and talk about the project" makes a lot more sense than saying "We should begin AGILE PROGRAMMING".

This post has been edited by Tom9729: 8 Aug, 2008 - 10:36 AM

Wait...people don't talk to their customers? WTF--you don't need a new methodology for that--you need common sense...

I like the idea of test driven development but the methodology seems over done and Agile smacks of marketing to me.

Read a great blog post from Steve Yegge over at Google. Admittedly Google is different than most companies but Netscape was the same way. Nightly builds. If you broke the build boy did you hear about. Test, Test and Test again before committing.

I love this quote though...

Scrums are the most dangerous phase in rugby, since a collapse or improper engage can lead to a front row player damaging or even breaking his neck.
— Wikipedia

JW

You know... it *sounds* like a buzzword but there is a little more to it.

At the moment I am working on a project with a very BAD implementation of Agile. The original project managers had no idea what they were doing and basically set up all up to fail.

From the level of the grunt programmer all of these project methodologies are pretty much just an aggravation. At least this is how I felt. Then I began to work on a huge project spanning several organizations and anywhere between 50-100 programmers. Each team is working on their own little part and yet in the end we all have to be able to integrate and work together in the end...

Special "Project management" expert consultants were brought in from IBM to set up and manage the project. They were idiots. I find it hard to believe that these people had EVER worked on a software project in their lives. They literally made EVERY textbook error you can possibly make. Somehow they imagined that three development teams working independently with only an outline of the business requirements would be able to come together about every two months and drop off their code which could then be shown to the business users who would refine the business requirement based upon the current code release.

So the first time anyone gets to really test their code is the day the customer is looking over their shoulders.

All of this was justified by, "We are following the Agile methodology..." which they clearly were not, but you try to tell a consultant charging the customer something just shy of a million dollars for this project plan that they are full of shit and setting everyone up for failure.

Needless to say that IBM eventually fired the lead consultant since even their own developers could not find the same crack dealer. (Well I say fired, but it was more like "reallocated to other projects"). We eventually came up with a schedule that will hopefully work, but the project was seriously hurt by the poor initial planning.

This post has been edited by NickDMax: 8 Aug, 2008 - 04:45 PM

Traditionally I follow a waterfall or in some cases a RAD methodology and have seen a lot of jobs lately asking for agile methodology experience. The idea is sound in theory but in practice it is very poor. The one inheriant flaw in the whole thing is that it heavily relies on the customer providing accurate feedback. Where is the problem? Half the time the customer doesn't know what they want or even what they need. This is even more problematic by the idea that some customers think they know what they want and won't tell you that it is a "guess". This leads to situations where you are half way through a set of iterations when suddenly they drop the bomb "Uh yeah this software is not doing anything it is suppose to do". Of course you are dumbstruck because they were the ones feeding you the specs as you released each iteration.

Second flaw is that it typically requires a "manager" to manage the project backlog (the list of tasks which will eventually make it into a sprint's backlog). Normally this would be great if the manager knew what they were doing, but most managers in charge of this backlog are not IT, they are businessmen. So they put up priority on one task not knowing that you have to do other tasks before this task (can anyone say critical path?)

At least with the old waterfall method you went into the information gathering phase with a little support from the customer but you also looked at actual paper forms, observed how people DID their job not how they SAID they did their jobs, you analyzed the project workflow and modeled the software after it.

I am going to say that Agile methodologies are more a fad than a time proven solution. I expect it to die out in the coming years.

As for CMMI, never ever heard of it. I did a little research on it and it sounds like recycled agile mixed with a few other methodologies. I will be surprised if that ever makes it into wide stream use.



This post has been edited by Martyr2: 9 Aug, 2008 - 08:03 AM

We started using the Agile methodology at the place I work at about a month ago. Scrum meetings, sprints and all that. I personally like it, since you really think out all the items in detail within the sprint and those are set in stone for that time frame. No inserting new tasks or changing stuff on the fly while working, unless there is a real emergency.

That last note was a major issue for myself, since the last two dev shops I've worked at, the boss would constantly change what I was working on while I was working on it. This would wear my mind out, since I would get 4 - 5 changes in a day. Forget getting back to the previously assigned tasks.

With all the stuff we are doing, we have been thinking about how to make it work better, coming up with coding and documentation standards all the time.

I do find that a lot of people that say they don't like it, they have had exposure to it when it was badly implemented. If implemented correctly, it will make sense and work smoothly. Also each group need to tweak it to work better for their situation.

We roll agile in my department. Sorta.

(No, I'm not dead.)

We trialled both XP and Scrum a few years back. All was going will with two week sprints (or iterations) through the project. At the end of each sprint we'd demo to the business analysts and the customer representative.

We also tried sharing the job of scrum master around on a rotating basis amongst each team member. The benefit was that I believe each team member understood more of the software than they otherwise would have, using the traditional waterfall approach, where team members just about worked in isolation from the rest of the team members, thus understood very little the big picture.

Being a company developing public safety software for the government, the biggest issue we had with both agile methodologies was the lack of project documentation outputted, something governments really like, and a neccessary part of our continuing ISO 9001 certification.

We've now gone back to the traditional waterfall SDLC, using spiral for "quick and dirty" projects.