Q&A: Agile Vs. Formal Methodologies
- Agile Vs. Formal Methodologies
- Is "Agile" just another trend that is slowly turning into a more accepted and practiced methodology?
- Is this the beginning of the end for "Formal" Methodologies?
- What role, if any, as VSTS played in the struggle of Agile methodologies to become more "mainstream"?
- When would you use Agile or Formal Methodologies?
- What about "hybrid" culture where Agile and Formal mix together rather than going the full on extreme path of "one or the other"?
Is "Agile" just another trend that is slowly turning into a more accepted and practiced methodology?
Agile Practices have long been practiced in the world of Software Development. If anything, I'd say they have always been mainstream (to a certain degree, in many companies) and just now are starting to pick up the "buzz" and become a trend. The new "Agile" word simply tries to put together a set of practices and mind set that works better for most projects than not thinking about them together. Stuff like Coding standards, unit tests and daily builds have always existed, stuff like pair programming have been done to a degree in any company (have you ever set with a colleague trying to solve a tough problem?). Agile simply tries to take those things, name them and realize that we'd be better off acknowledging their power and using them more rather than less.
Is this the beginning of the end for "Formal" Methodologies?
Hardly. There's always a place for both, but I suspect that most projects will use a mix of both over one or the other.
What role, if any, as VSTS played in the struggle of Agile methodologies to become more "mainstream"?
Team System helped bring the idea of Agile to the mainstream .NET community. That's a wonderful thing, because now we have something that the Java Developers have had for along time - the idea of Agile methodologies embedded into our tools. Unit Tests, MSF Agile, extreme programming, they are a few clicks away rather than a few downloads away. That's a big plus for Microsoft.
On the other hand, team System is not quite there yet. It's TDD Support is
less than perfect and the notion of XP and MSF Agile is still not there fully, but we are a long way from Kansas Already, and it will just get better from now on.
When would you use Agile or Formal Methodologies?
Unless you are working on a project with Fixed Price, Scope and Time, Agile is a good way to go. Even if you do Hardware & Software integration, the software part can be done in an Agile manner (so can the hardware, but that's a different topic).
What about "hybrid" culture where Agile and Formal mix together rather than going the full on extreme path of "one or the other"?
99% of the projects I've seen come from a :formal background and implement Agile practices incrementally. For example, doing daily builds, then adding unit tests, then adding TDD, then adding Rolling Wave Planning etc..
If it fits your team more than going all the way , I'd say go for it. One of the main notions of Agile is making the methodology fit your team, and not the other way around. If it can work better for your team with more documentation and more meetings, do it. But stick to your guns for at least some amount of time (an iteration or two) and then decide what to change, if at all.