What's your methodology?

I've been thinking a lot about methodologies lately. This is partly just because it's a subject that's always interested me. Figuring out how you design & build your software is just as interesting as actually building and designing it (to me at least). It seems like a vast field, the theoretical aspect to development, and something that is often controversial.

The other thing that's got me thinking about it is that at work I'm being asked to build a system using a methodology that's pretty foreign to me. Although, in my professional life, I've rarely used formal methodologies, I've found that I've naturally used an Agile-like approach of my own (and the companies I've worked for). After reading a lot about Scrum lately, I've found it matches pretty closely how I've always worked, as well as adding a few extra controls (such as consistent length of iteration) which make life even easier.

Basically, I find it very difficult to create systems without the following things:

A single technical owner, and a single business owner (or at least the minimal group on each side).
Extremely important is direct and constant interaction between these two, especially in regards to requirements. To me, assembling requirements is a bargaining process. If business goes off and tries to figure out their requirements, they'll miss some really important issues relating to the reality of what they're asking.
The ability to manage constantly changing requirements
An iterative process, i.e. a feedback loop. The client needs to see the system to understand what their requirements are

The methodology I'm being asked to use is based on Waterfall. With the possible exception of the first point, it has none of the above. The preferred method of communication is via documentation. Requirements are locked down as much as possible, and there is no iterative process built in to the methodology.

While I'm sure I'll find a way to work within these contraints, I can't help wondering if I've missed the point of Waterfall (or similar) approaches. Agile is suffering from a backlash at the moment, with people playing the "No Silver Bullet" card (similar to some of the reaction to OO in the 90's). I don't want to jump on the Agile bandwagon and become one of the people who in their rabid evangelism actually harm the reputation of the very thing they're trying to advocate.

So what is your methodology of choice? What methodologies have you used and what works for you? What do you like / dislike about particular methodologies? (I'm sure this is a good way of starting a Holy War :)

Comment on What's your methodology?

Replies are listed 'Best First'.
Re: What's your methodology? by philcrow (Priest) on Sep 29, 2006 at 17:02 UTC
While I'm now in a very loose shop which has pretty much whatever methodology each developer/user pair find useful, I used to work in a supposed Waterfall shop. I discovered the secret to successful waterfalls from them. In principle, a user would make a formal Service Request on the appropriate form, getting approval from management on the user and programming side, for the the change. Then a front line programming manager would assign the task to a programmer who would draft a Technical Design Document, which would again be approved all around. Finally, work would begin until the programming side was happy. Then the users would test. The above sounds like a disaster. Here was the trick. None of the documents were finalized until right before a release (sometimes hours before). This left both sides open to debate and discuss what the request was and how it would be implemented. When testing was going well, the documents would be signed on the way to release. I suspect that there are shops on the other side, where agile methods are supposed to be in place, but they aren't really used in practice. So, I don't let the terminology or stated policies affect me. What matters is how things work in practice. Is there really a rule that you can't talk to users after they deliver their request? Do you really have to tell someone in advance exactly what you are going to do? Phil	[reply]
Re^2: What's your methodology? by chromatic (Archbishop) on Sep 29, 2006 at 19:15 UTC
Ha, so the secret to successful Waterfall is "don't do Waterfall". I like that!	[reply]
Re: What's your methodology? by chromatic (Archbishop) on Sep 29, 2006 at 19:13 UTC
I can't help wondering if I've missed the point of Waterfall... The point of Waterfall is to prevent change. This is because change is expensive. It's much cheaper to make a change at the start of a project, when you're safely in an office and can type those changes into the computer (in a requirements document) than when you're actually building the software out on the field and have cranes and concrete and rebar and safety inspectors and a 200-foot hole in the ground and the customer comes out and says "Wait, I really wanted a nice two story building instead of a skyscraper!" If someday we can make it as easy to write computer programs as it is to type clear and unambiguous and testable specifications into a text editor, maybe Waterfall can go away.	[reply]
Re^2: What's your methodology? by impossiblerobot (Deacon) on Oct 03, 2006 at 15:04 UTC
I hope you were being sarcastic when you said "as easy ... as it is to type clear and unambiguous and testable specifications." Impossible Robot	[reply]
Re^3: What's your methodology? by chromatic (Archbishop) on Oct 04, 2006 at 06:09 UTC
My only serious sentence in that whole post was the first one.	[reply]
Re: What's your methodology? by poqui (Deacon) on Sep 29, 2006 at 17:41 UTC
What methodology I prefer and what methodology I am forced to abide by are very similar to yours. Our management structure is uncomfortable with the "iterative" development methodologies because the business partners are remote from the developers, and they like giving thier requirements in the form of a quasi-design. For instance, instead of asking for data for a certain purpose, like a report, we will get a SAS query and they will ask us to reproduce the same results from our Oracle Data Warehouse. In addition, developers rarely have direct access to the business partners and have to communicate through a "Single Point of Contact" or SPOC. Many times, the SPOC for the business partners will communicate the need for a new project to the SPOC for the developers; a Project Request Document will be produced, then the SPOC for the developers will solicit the requirements from the Business SPOC, and a deadline will be set; all before the actual technical people get involved with the project. Then when the technical people have questions about the requirements, the developer's SPOC is the one to answer their questions, to insulate the Business from "interruptions" and "repeating themselves". So what happens is a very Waterfall approach where we turn out what we think the Business Partners want, and it rarely meets their real requirements. Oh, and we don't ever do it fast enough. ;-)	[reply]
Re: What's your methodology? by dws (Chancellor) on Sep 30, 2006 at 05:56 UTC
I can't help wondering if I've missed the point of Waterfall (or similar) approaches. Waterfall misses the point of waterfall. Seriously. If you go back to the original paper that Waterfall derives from, and actually read beyond the first few pages, you'll see that a) the early proponents of waterfall never read past the first few pages, and b) the author actually advocates an iterative approach.	[reply]
Re^2: What's your methodology? by Mutant (Priest) on Oct 01, 2006 at 11:51 UTC
That's true. It hasn't stopped many companies using it over the last 20 - 25 years however.	[reply]
Re: What's your methodology? by Anonymous Monk on Sep 29, 2006 at 17:29 UTC
So what is your methodology of choice? For what task? In what language? For what purpose? With how many other developers? With what organizational constraints? With what time constraints? With realistic expectation of code re-use? With what other constraints? The methodology used should match the task at hand. Scripting a one line throw-away in Perl for your own personal interests is very different from working on a multi-person team doing OS development which is different from research done with taxpayer's money which is different from safety-critical software engineering which is different from military applications developed as a state secret. Each environment will have it's own requirements, it's own paperwork, it's own QA requirements, etc. Some of them will have other special requirements as well (military clearances, document handling rules, formal audit trails, signoffs, confidentiality requirements, etc, etc.) The level of paperwork and the level of quality assurance required will determine the appropriate methodology; a slapdash (but very "agile"), "fix it if it breaks" attitude works great for personal web sites, but would be a disaster for work on, say, a nuclear weapons control system. Even if you're just writing scripts in Perl, what you need to do often determines how you do it; if every release to production requires formal sign off from management in triplicate, your team will probably make fewer small changes, and spend more time testing each change than if the environment is set up for fast turnaround of development and promotion. The way I work is mostly determined by how I'm allowed to work; if the boss needs/wants something done a given way, well, it's his money...	[reply]
Re^2: What's your methodology? by Anonymous Monk on Oct 02, 2006 at 09:32 UTC
Each environment will have it's own requirements, it's own paperwork, it's own QA requirements, etc But in each environment, the possessive pronoun is spelled its.	[reply]
Re: What's your methodology? by ruoso (Curate) on Sep 30, 2006 at 22:42 UTC
I've been for some time a great fan of eXtreme Programming. Even if most of the places I know that ponders using XP almost never implements XP completely. From my experience of never implementing completely XP in some places, indeed, there's no silver bullet, but... 1. the Agile approach, in general, always argue for a constant negotiation between the customer and the developer. 2. the Agile approach, in general, argues to remove the bureaucracy implicit to the managing process. 3. the Agile approach, in general, makes the customer realize that he's paying for a limited set of resources and that he has the right to say what is more important, but he can't make a team work more than it can... So, even never being in a completely-XP environment, I realize that these three values are something that really make some difference in accepting the view-changes of the customer and making the customer accepts the limits of resources they have available for them... daniel	[reply]
Re: What's your methodology? by adrianh (Chancellor) on Oct 02, 2006 at 13:43 UTC
So what is your methodology of choice As much of Extreme Programming as I can get away with. What methodologies have you used and what works for you? What do you like / dislike about particular methodologies? See Re: On Quality :)	[reply]