The Agile Modeling (AM) Method

What Is(n’t) Agile Modeling?

Agile Modeling (AM) is a way of thinking (WoT) and a way of working (WoW) that is tailored into your existing process to improve modeling and documentation. The following points describe the scope of AM:

  1. AM is a way of thinking (WoT), not a prescriptive process. Agile Modeling comprises a collection of values that agile modelers adhere to, principles that agile modelers believe in, and practices that agile modelers apply. AM describes a style of modeling, when used properly in agile environments, that results in better quality software and faster development while avoiding over-simplification and unrealistic expectations. AM is not cookbook approach to development – if you’re looking for detailed instructions for creating Unified Modeling Language (UML) sequence diagrams or drawing user interface flow diagrams then you need to pick up one of the many modeling books listed in the article Modeling Artifacts. In particular I highly suggest my own bookThe Object Primer 3/e (although naturally I’m biased).
  2. AM is a supplement to existing methods, it is not a complete methodology. The primary focus of AM is on modeling and its secondary focus is on documentation. That’s it. AM techniques should be used to enhance modeling efforts of teams following agile methodologies such as Kanban, SAFe, and Scrum. AM can also be used with prescriptive processes although will not be as successful the less agile the process is. Figure 1 depicts how AM practices should be tailored into existing software processes as part of defining your way of working (WoW).
  3. AM is a way to work together effectively to meet the needs of stakeholders. Agile developers work as a team with their stakeholders, who in turn take a direct and active role in the development of the system.
  4. AM is effective and is about being effective. As you read more about AM one of the things that should become poignant to you is AM’s ruthless focus on being effective. AM tells you to maximize the investment of your stakeholders, to create a model or document when you have a clear purpose and understand the needs of its audience, to apply the right artifacts to address the situation at hand, and to create simple models whenever you can.
  5. AM is something that works in practice, it isn’t an academic theory. The goal of AM is to describe techniques for modeling systems in an effective manner, one that is both efficient and sufficient for the task at hand. These techniques have been examined and discussed by several thousand modeling practitioners.
  6. AM is not a silver bullet. Agile modeling is an effective technique for improving the software development efforts of many professionals. That’s it, nothing more. It isn’t magic snake oil that will solve all of your development problems. If you work hard; stay focused; and take AM’s values, principles, and practices to heart; then you will likely improve your effectiveness as a developer.
  7. AM is for the average developer, but is not a replacement for competent people. AM’s values, principles, and practices are straightforward, many of which you have likely been following or wish you had been following for years. You don’t have to walk on water to be able to apply AM’s techniques, but you do need to have basic software development skills. The hardest thing about AM is that it prods you to learn a wide range of modeling techniques, a long and continuing activity. Learning to model can seem difficult at first, and it is, but you can do it you choose to learn a technique at a time. Having said that, the best developers are generalizing specialists.
  8. AM is not an attack on documentation. Agile modelers create documentation that maximizes their investment in its creation and maintenance. Agile documentation is as simple as possible, as minimal as possible, has a distinct purpose that is directly related to the system being developed, and has a defined audience whose needs are understood.
  9. AM is not an attack on CASE tools. Agile modelers use tools that provide positive value by helping to make then more effective as a developer. Furthermore, they always strive to use the simplest tool that gets the job done, and sometimes that’s a sophisticated CASE tool.
  10. AM is not for everyone. More on this in When Does(n’t) Agile Modeling Make Sense?.

Figure 1. Agile Modeling should be tailored into your software process.

Scope of Agile Modeling