I know methodologies, like Extreme Programming (XP), which specifies its own specific practices for developing software. However, unlike Scrum where it focuses more on management aspects, XP specifies software practices that are required to be followed. From reading this article, these steps eliminate the explicit modeling phase using tools such as BPMN and UML. In another article from Martin Fowler, he further explains such discouragement.
Personally, I prefer the model-driven methodologies I guess it's up to the preference of companies and people. One of Agile goal is to "free developers from document works". Methodology like XP seems to easily lead to under documentation. I think to achieve that goal, the solution is to implement the tool to help developer reduce the workload on writing document, not by writing less documents, by gathering information from existing diagrams and automatically generate reports (in RTF, PDF, HTML in the case of Enterprise Architect of Sparx System).
Some software engineers also complain about drawing diagrams consuming their time. In my opinion, the solution is not to draw diagram, but using the tool. Modeling tools today support round-trip engineering, where you can synchronize between your code and your diagrams, thus eliminates the extra effort to manually correct the diagrams if the code base changes (specifically, class diagram).
How does modeling fit into a team that is using Extreme Programming?
Best Answer
XP doesn't explicitly call for the creation of a model, but it doesn't say that one should never be produced. If developing a model helps you to build and then document your system, it should absolutely be done. The difference is that Agile Modeling has a different focus than system modeling in a plan-driven environment. In fact, the Agile Modeling site even addresses specifically how you model in an Extreme environment.
Agile environments take a more Lean (in the same sense of Lean engineering or Lean manufacturing) approach. Some of the key tenants include reducing waste, deciding late, and delivering fast. In order to eliminate waste, only the required documentation is delivered at the appropriate granularity. If you produce a work product, that work product is expected to ultimately add value to the customer - waste is considered anything that doesn't help add value to the person paying for it.
In fact, the XProgramming blog article you linked to supports this:
The Martin Fowler article that you linked to also supports this:
A central idea of the agile methods is "individuals and interactions over processes and tools". You don't follow a process or use a tool for the sake of following the process or using a tool. If the task that you are working on does not add value or if it doesn't produce something that is useful to someone (either the customer or another engineer), then you don't do it.
Martin Fowler goes on to say:
Again, same idea. The purpose of any documentation is communication. If you are producing things that don't help you communicate the system, why are you doing it? Don't focus on every little detail, but focus on communicating a message that provides useful, value-adding information to someone else.
Even later in the article, Fowler goes on to note that one of the problems with CASE tools is that they can fall out-of-sync. As soon as the code and the documentation fall out of sync, the document adds no value. I'd even take this a step further and say that it adds negative value, as it provides false and misleading information to anyone who tries to use it to make a decision. If you have a process to maintain synchronization, that's good. However, if you don't and you do let your documents fall out of sync, this brings up another question: why do you have them? They clearly aren't being used, or else they would be maintained.
Rather than some other model-driven methodologies requiring the models, even if they don't necessarily add any value, XP calls for spending time and resources on things that actually help you deliver value to the customer/client. If you can justify that certain models actually do add value to your project, then by all means you should produce them. However, you shouldn't be producing models that duplicate other information or don't add value.