Q&A: Agile Vs. Formal Methodologies

carnival of the agilists, 18-may-06

silk and spinach — Sat, 03 Jun 2006 20:23:37 GMT

Welcome to the May 18th edition of the Carnival of Agilists - providing you with a commented digest on what's been said in the agile blogsphere during the last two weeks

re: Q&A: Agile Vs. Formal Methodologies

Scott Ambler — Fri, 19 May 2006 02:17:00 GMT

At http://www.agiledata.org/essays/differentStrategies.html I compare and contrast a collection of agile and traditional/formal methods. Too many people look for the one best answer to their question, in this case "What is the best approach to software development?" Unfortunately, the answer is "It depends on the situation". That's why I wrote the article comparing the various methods, so that people not only know that they have a choice but that they get some direction as to the differences between them. The article isn't perfect, none are, but it's pretty good IMHO.

Hope some of you like it.

- Scott

re: Q&A: Agile Vs. Formal Methodologies

Arnon Rotem-Gal-Oz — Tue, 16 May 2006 10:55:00 GMT

Matan,
The problem with fixed priced projects is that the customer usually requires a detailed plan as part of Terms and conditions of the bid.
More so, they (usually) want detailed documentation, only allow partial access to end-users etc. etc.
The (unfortunate) end result is that it is next to imposible to have a pure agile project.

Also regarding VSTS - MS claims that even MSF for CMMI improvement is an agile methodogy - this is what Ken Schwaber (SCRUM) had to say about about MSF
Agile:"
Dear CrossTalk Editor,

In the December 2005 issue, the article “Agile Software Development for the Entire Project” by Granville Miller, Microsoft, describes how the agile process in MSF can make the agile described in the Agile Manifesto <www.agile manifesto.org> much easier to implement without all of those difficult changes that many others have experienced. He describes how these reflect the fine engineering practices at Microsoft that have led the MSF version of agile to already be a year late.

It has taken more than 20 years for parts of the American manufacturing industry to adopt lean thinking. Agile, which has many parallels to lean manufacturing, will also take a lot of effort and time. Change is always an effort, and only the dramatic benefits of agile make it worthwhile. Efforts by people like Granville Miller to water down agile by redefining the intent do not help. Efforts that add more process miss the point; process is defined by self-managing teams within frameworks. Decisions are made by these teams working closely with customers to maximize benefit and optimize results.

At the start of the agile movement, we were warned that the larger commercial interests would attempt to water it down to fit their existing tools. We should expect to see other similar fits such as from IBM (through RUP in the Eclipse Foundation) and others. The refinements suggested by Granville Miller do a disservice to everyone working on agile.

Ken Schwaber

Signatory to the Agile Manifesto
Founder of the Agile Alliance
Co-Author of the Scrum Agile process
ken.schwaber@controlchaos.com " (http://www.stsc.hill.af.mil/crosstalk/2006/02/0602LetterToEditor.html)

re: Q&A: Agile Vs. Formal Methodologies

Matan Holtzer — Tue, 16 May 2006 08:30:00 GMT

"Unless you are working on a project with Fixed Price, Scope and Time, Agile is a good way to go." -
Every VSTS presentation I've been to starts with defining the "problems" that VSTS, by employing Agile methodologies, is adressing. These problems are, quite simply, never being able to end a project while keeping it On Time, On Budget and On Scope.
I thought that these are the problems that arise naturally when working on a project with "Fixed Price, Scope and Time"...

How can these two notions coexist?

re: Q&A: Agile Vs. Formal Methodologies

Arnon Rotem-Gal-Oz — Tue, 16 May 2006 07:59:00 GMT

You also need Hybrid methods when the circumstances force you to use formal methods (but you know you can benefit from agile practices) - e.g. the example you gave of fixed price/time project (fixed scope is a fiction :) ), when the organization has formal culture/certificate (like CMMI or ISO certification) or when the customer demands detailed plans and documentation etc.

Arnon

re: Q&A: Agile Vs. Formal Methodologies

Bob — Mon, 15 May 2006 15:01:00 GMT

I think a death march is more about unrealistic expectation than methodololgy.

I think the bigger competition is Agile or Formal Methodologies vs. cutting corners and putting out a less then quality product. At least in in-house projects. Its hard to convince developers to switch to unit testing from hardly any testing because there is no time. And I think its hard to get managers to switch because its easier to blame one of the programmers when the project fails than to adknowledge they over promissed or even worse they're boss over promissed.

re: Q&A: Agile Vs. Formal Methodologies

AndrewSeven — Mon, 15 May 2006 13:04:00 GMT

I wonder if its time to start using a different term for non-agile project types.

The agile methods have an informal feel to their activities, but they are still formal about what activities should (must) be undertaken.

Planned, formal plan, death march ;)

re: Q&A: Agile Vs. Formal Methodologies

Pawel Pabich — Mon, 15 May 2006 12:14:00 GMT

Great questions, I'm looking forward to all answers.