When Does(n’t) Agile Modeling Make Sense?

• When will AM likely work?
• But this isn’t my situation…
• When will AM likely not work?

When Will Agile Modeling Likely Work For You?

My experience is that AM has the potential to be effective when the following factors hold true:

1. You are taking an agile approach to software development. AM isn’t a complete methodology, it is presented under the assumption that it will be applied within the scope of another process. For this to work successfully there must be a conceptual fit between AM and this other process, otherwise you will be forced to hobble one or more of AM’s techniques and therefore not truly be doing AM.
2. You are working iteratively and incrementally. Effective communication and feedback, two of AM’s practices, require an iterative and incremental approach to software development.
3. Uncertain or volatile requirements. Martin Fowler, in The New Methodology, points out that if your initiative is exploratory in nature, and many are, then it is very likely that an agile approach to development is best suited. When your requirements aren’t certain, or actively changing, then you need to follow a software process that reflects this fact. AM deals with changing requirements by embracing change, but taking an incremental approach to development, by seeking rapid feedback, and insisting on active participation of stakeholders so that the requirements may be quickly and effectively explored.
4. Your primary goal is to develop software. This is one of AM’s core principles, something that is not always the case for many teams. For example, sometimes a team’s primary goal is to make money from your customers (often the case in outsourcing situations) or simply to specify the system so it can be given to another team to implement. Even worse, some development efforts are simply a political exercise with no intention of delivering anything more than a perception that something is being done. The goal of software development should be to produce systems that meet the needs of their users in an effective manner – if you are doing anything less then AM is not for you.
5. You must have active stakeholder support and involvement. For agile software development efforts to be a success you should have the active support and involvement of your stakeholders. A stakeholder is anyone potentially affected by the development and/or deployment of a software solution. This includes direct users, indirect users, managers, senior managers, operations staff members, support (help desk) staff members, testers, developers working on other systems that integrate or interact with this one, and maintenance professionals. To be successful with AM you need to know who your stakeholders are, you must have access to stakeholders on a daily basis who are able to provide information and make decisions in a timely manner, and have full management support for your initiative.
6. The development team must be in control of its destiny. Agile software development, and Agile Modeling is particular, is new to most organizations. Adopting agile approaches will be difficult at best for many organizations because it is a significantly new way to work for most people. To be successful my experience is that teams must be given the opportunity to succeed or fail on their own merits. The must be in a position to try new techniques and be given the resources, including time, to let them run their course. Your organizational environment must have minimal politics, implying that both management and other groups within your organization need to get out of your way.
7. A true champion for AM exists. Whenever you adopt something new there will always be challenges. People don’t like to change, they are often happy working in the non-agile way that they are used to. Others see things differently than you, or simply don’t recognize the problems that you are trying to address by adopting AM. Perhaps they are promoting their own pet approaches to development, approaches that don’t fit well with AM. Perhaps AM threatens the current power structure within your organization. Regardless of the situation there will always be people who will fight change. To be successful at change someone must exist that champions the new cause, in this case adoption of AM, someone willing garner support of stakeholders and to protect and nurture AM efforts as they take root within your organization. Change takes time, and champions buy you that time.
8. You require responsible and motivated developers. Agile software development requires developers that have the discipline to work together to develop quality software, and who are often generalizing specialists. The implication is that you need a healthy team environment, one in which people trust one another and help each other to succeed. Contrary to what many of the detractors of agile development will tell you, my experience is that you don’t need people that can walk on water instead you simply need people who want to get the job done and who have the ability to work with others effectively.
9. You have adequate resources available to you. You will see that agile modeling requires people to work together closely. The implication is that you need “co-location space(s)”, such as a dedicated modeling room to work in, a public wall to display your models on, and ideally even shared workstations for pair development efforts. Furthermore you need access to modeling tools such as whiteboards, index cards, markers, and CASE tools as necessary. I’ve seen lack of basic resources such as decent chairs, tables, food, drink, and top-notch workstations dramatically hamper software development efforts. If your team is being nickel-and-dimed to death then I have to question if your initiative is important to your organization – if it isn’t cancel it now and invest your efforts on something more productive.

But This Isn’t My Situation….

So what do you do when one or more of these factors does not hold true? Try to change your situation. No champion for AM exists? Then become the champion. Not allowed to work iteratively and incrementally? Negotiate with senior management, convince them that there are better ways to work, ask them to give you a chance to prove it to them. Don’t have adequate resources? Communicate the importance of this to your management. Once you’ve changed the situation the best you can, if you’re still missing a few factors then you need to choose one of the following options:

1. Partially adopt AM. You can adopt as many of the principles and practices of AM as possible, you won’t be truly doing AM but you will likely be more productive as a developer. Once your organization discovers that there are better ways to develop software perhaps they will be more willing to change the factors required to fully adopt AM. In other words, ease into agile modeling.
2. Give up on AM within your organization. Personally, I don’t like this option but I have to admit that it’s a valid one. The reality is that AM isn’t for everyone and perhaps your organization is one where AM simply isn’t a good fit.
3. Start looking for employment elsewhere. There are a lot of organizations out there that are choosing to succeed at the software development game, organizations that are more than willing to hire motivated software developers.

When Won’t Agile Modeling Work For You?

I suspect that you are likely to run into trouble with Agile Modeling in the following situations:

1. One or more of the factors listed above isn’t there.
2. Your organizational culture is geared towards prescriptive processes. There are many organizations that simply aren’t interested in taking an agile approach to software development. These organizations are happy with the status quo and that’s fine by them. This likely includes organizations such as Government agencies, large established firms (banks, insurance companies, telecommunications firms, “¦), and consulting firms that specialize in serving these organizations. This isn’t to say that it’s impossible to adopt AM in these organizations, but it is likely that an extraordinary effort such as an off-site effort will be required to be successful.
3. You have a large and/or distributed team. Agile modeling works very well on teams that are co-located in the same work area, particularly when the developers are co-located in a shared work room (often called a “tiger team” room). You can attempt to apply AM on large or distributed teams, I discuss this very situation with respect to architectural modeling, but you will find that communication challenges quickly get in the way.

I would also be leery of applying agile modeling to develop life-critical systems, such as an air traffic control system or patient monitoring system, simply because I don’t work on such initiatives and have no insights into how well AM will work on them. Similarly, I don’t work on embedded software and therefore have never had a chance to apply AM techniques on these types of efforts. I highly suspect that AM is applicable to embedded software development but this is just speculation on my part.

See also When is a Model Agile?, What Is(n’t) Agile Modeling?, and When Are(n’t) You Agile Modeling?