Agile Modeling

Agile Modeling (AM) is a PracticesBasedProcess that describes how to be an effective modeler. Current modeling approaches can often prove dysfunctional. In the one extreme, modeling is non-existent, often resulting in significant rework when the software proves to be poorly thought through. The other extreme is when excessive models and documents are produced, which slows your development efforts down to a snail's pace. AM helps you find the modeling sweet spot, where you have modeled enough to explore and document your system effectively, but not so much that it becomes a burden that slows the project down.

The EinsteinPrinciple applied to modeling: A model should be as simple as possible, but no simpler.

The techniques of AM can and should be applied by project teams that wish to take an agile approach to software development, in particular those that are following an agile process such as eXtreme Programming (XP), DSDM, SCRUM, or FDD. AM can also be used to improve and often simplify your modeling efforts on projects where you don?t take a purely agile approach. &

The extreme-modeling link is no longer available.

New name for ExtremeModeling

See AgileModelingBook plans by ScottAmbler.

It's funny, I think that calling ExtremeModeling AgileModeling would probably help to sell it better. What about AgileProgramming? OK, maybe not the best, but definitely less controversial than ExtremeProgramming. (Please note that I don't actually care about these names. I'm just pointing out how changing the name sells the product... silly isn't it?)

AgileModeling is great. It is a wonderful feeling when are new to a client site, have no login, have no access to the net, no access to a copier, but after interviews and code reviews have a good chunk of their system written on CrcCards. You know that when you get the administrative nonsense done, then you will hit the ground running.

Is this one of the AgileProcesses by the AgileAlliance?

No, it is not one of the ones originally discussed at the Snowbird meeting. However, the intention of the AgileManifesto is that more than just the original authors can subscribe to the AgileProcesses concept and claim to be Agile. The key is the four values in that manifesto: individuals and interactions + working software + customer collaboration + responding to change. --AlistairCockburn

Does "AgileModeling", per se, produce working software ?

It seems to me that AgileModeling relies on a set of assumptions:

I have not seen a set of assumptions like this anywhere, so I don't know how accurate this list is. At any rate: How well does these assumptions match up with observations on real projects? -- JohannesBrodwall

The problem I usually see is that the truly complex interactions that you find in the code are not represented in the model. I find models useful in representing sections of existing code I need to understand, often relationships between classes. I do not find them useful as a planning tool for code. --WayneMack

These seem to be assumptions of modeling in general. An AgileModeling assumption would be that models are never complete, and hardly ever accurate, so it's better to stick with an incomplete model (that helps understanding the problem), than trying to create a fully detailed (and probably inaccurate model). -- GustavoSousa?

As always, the usual myth put forward that modeling is all about visualising code. Isn't this good evidence of an unhealthy FocusOnCode ?

I would also contest that it is evidence of an overly complex design or system.
see also TestDrivenAnalysisAndDesign, CleaningUpWhiteboardPictures
CategoryExtremeProgramming, CategoryAgileMethodology

EditText of this page (last edited November 8, 2009) or FindPage with title or text search