Easing into Agile Modeling (AM)

The first published description of AM appeared in the November 2000 issue Software Development magazine under the name eXtreme Modeling (XM). I then led the evolution of the technique, for the most part via the Web although also at the XP 2001 conference held in Italy in May of that year. AM started out fairly complex and it grew a bit into its current form. In the time since I’ve been applying AM on teams, mentoring people in its techniques, teaching AM courses, and speaking about AM at a variety of conferences. The one thing that I’ve noticed is that many people struggle with its plethora of concepts – five values, eleven core principles, seven supplementary principles, thirteen core practices, and eight supplementary practices – so it shouldn’t be any surprise that some people find AM complex. Sigh.A question that I get asked is how can people get started with AM but perhaps not fully adopt it all at once. Some organizations don’t want to adopt just the core principles and practices at first, let alone some of the supplementary ones. One common situation is that the organization is very non-agile at the present moment, that adopting all the AM core is just too much to attempt at once. It is clear that many people need a way to ease into AM slowly.First, focus on improving communication between people. Modeling with others is critical as is active stakeholder participation . When you use simple tools it is much easier to model with others because there isn’t a tool learning curve to overcome, and simple tools also make it possible for your stakeholders to actively model with you.

Second, you should strive to keep things as simple as possible and to travel as light as possible. This is easy to talk about but often proves quite difficult to do in practice, at least at first. Using simple tools such as whiteboards and paper to create models is a critical first step, showing you that you don’t need sophisticated CASE tools to succeed. Simple tools also make it much less painful to discard temporary models because you haven’t invested as much effort in them.

Third, adopt techniques that enable you to work in an evolutionary (iterative and incremental) manner. Creating several models in parallel and iterating to another artifact are crucial practices, but this of course requires you to accept that you need multiple models. Keeping your models small by working on them incrementally is also important. Together, these techniques help to break you of any “big design up front” (BDUF) habits that you may have as well as any delusions that one single model is the primary artifact that drives all your development efforts. For example it is quite common for people to insist that data models or use case models drive your initiatives, and this may in fact be true for a very small minority of teams, but often this attitude is the result of political ambitions more than any thing else. Proving it with code is a critical practice that supports evolutionary development because it provides the link from modeling to implementation, once again helping you to break out of a BDUF mindset.

In short, to make this first step into AM you should consider adopting following principles and practices:

Upon adopting these concepts you’ll discover that it is quite easy to add other ideas incremental. For example, you’ll quickly discover that you’re getting rapid feedback by working in an evolutionary manner, and likewise that embracing change makes sense in such an environment. Because you’re working closely together to create models you’ll soon see that collective ownership makes things much easier for you as does displaying models publicly. As you gain more experience with the modeling techniques, something that happens quickly in an evolutionary environment, that you get much better at applying the right artifacts for the situation.

In short, I think that you can see it is possible to ease into AM over time. However, I want to make it perfectly clear that to truly be doing AM you must adopt the five values as well as all of the core principles and core practices.

This article has been excerpted from The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2.