It’s easy to see that you need to take a different approach developing a web page as compared to developing a space probe. Your company likely doesn’t develop both web pages and space probes, so it’s easy to stand back and recognize that there’s a difference. It would be clearly foolish to follow similar approaches on these projects – a very simple process is sufficient for the web page development effort whereas a complex and rigorous process could be appropriate for the space probe. You would put the space probe project at serious risk following the web page process and you would incur significant costs following the space probe software process to develop your web page. Clearly it is important to follow the right process. But what about developing a data warehouse as compared to an online ordering system? Your organization might do both of these things, and now suddenly it isn’t so easy for you to fairly judge the situation. Senior management might want these two projects to follow the same method to make it easier to manage, measure, and compare their entire portfolio of projects. IT support groups, such as enterprise architecture and enterprise administration, want to work with project teams in a consistent manner using a consistent set of artifacts. Similarly project stakeholders who are involved with several IT projects will want to follow a consistent approach with each team. Your human resources department doesn’t have the budget to train and educate people in every single IT method and technique. It is clear that there is significant pressure to follow a single method within your organization. 

1. The need for flexibility
2. Categories of method
3. Comparing development methods
4. Categories of projects
5. You may need several methods

1. The Need for Flexibility 

1. Different technologies require different techniques.  Object-oriented methods are best-suited for projects using object-oriented technologies whereas data-oriented methods are best-suited for data-oriented applications.
2. Every individual is unique.  People are not replaceable parts.  Each person has a different background, different preferences for the way in which they work, and different cognitive style (e.g. are they visual or textual thinkers?). An approach that works incredibly well for you might be impossible for me to grasp, and vice versa. 
3. Every team is unique.  Because teams are made up of individuals, and because individuals are unique, each team will require a unique way for them to work in order to maximize their potential. Several teams could follow DAD, but each will follow their own “flavor” of DAD tailored to meet their exact needs.
4. Your external needs vary.  Some projects must conform to government regulations.  Other projects are highly-dependent on suppliers, such as technology vendors or software development outsourcers, and therefore must tune their process to reflect the ways that their suppliers need to work..
5. Project categories vary.  Different types of projects, see below, require different approaches because each category has different priorities and goals.
6. Method categories vary.  Each category of method, for example agile and rigorous, has its strengths and weaknesses.   

2. Categories of Method

For the purpose of our discussion there are four different categories into which a method, such as DAD or Extreme Programming (XP), could fall into:

1. Code and fix. This approach is also known as “hacking”, “hack and slash”, or “no-process at all”. This approach to development is chaotic and often unplanned, or when it is planned the plan is quickly abandoned. Estimates and schedules, when made at all, are rarely met in practice. 

2. Serial rigorous.  Software processes in this category are well defined and often include detailed procedures that developers are expected to follow in a more-or-less serial manner. For example requirements are identified, reviewed, and accepted.  The analysis of those requirements is performed, reviewed, and accepted. The design is defined, reviewed, and accepted. And so on. There is room for feedback between phases, although that feedback is provided via a reasonably defined procedure and the changes are then reviewed and accepted as before. Systems are typically delivered on an incremental basis where the releases are on the order of several quarters or years in length.  ISO/IEC 12207 is an example of a process which is typically instantiated in a serial and rigorous manner (to be fair, it doesn't have to be instantiated like this but it typically is). This approach is sometimes called a “waterfall process” or a “big design up front (BDUF)” process.

3. Iterative rigorous.  Software processes in this category are well defined and often include detailed procedures that developers are expected to apply in an iterative manner. For example requirements may be initially defined at a high-level with the detail later identified on an as needed basis. Small portions of your system are fleshed out, with software potentially delivered on an incremental basis following short release cycles often on the order of weeks or months.  Disciplined Agile Delivery (DAD) is an example of an iterative rigorous process.

4. Agile. Agile is an approach to software development that is people oriented, that enables people to respond effectively to change, and that results in the creation of working systems that meets the needs of its stakeholders. Software processes in this category are defined at a high-level, often presented as a collection of synergistic practices or philosophies.  Disciplined Agile Delivery (DAD) and XP are both examples of agile software processes.

Each method category appeals to a different mindset. For example, code and fix methods are attractive to maverick developers, often referred to as cowboys, that prefer to work alone with little guidance. Although great software can sometimes be created this way, the reality is that the approach doesn’t scale well to teams of people nor does it succeed very often. Serial rigorous processes often appeal to managers who are looking for an approach that is straightforward (hopefully) to understand and to manage. This is particularly true in heavily regulated industries, although my experience is that the regulations never seem to stipulate that the process be serial nor rigorous; however, people choose to interpret the regulations to mean that. Highly bureaucratic environments also seem to prefer serial rigorous processes, often because this approach enables the politicians among us to build their empires easily. Iterative rigorous processes work well in environments that are bureaucracy prone yet still able to condone “risky” practices promoted by iterative development (iterative development actually reduces most risks although it is harder for “traditionalists” to manage). Agile processes are new to most organizations and are therefore considered leading edge to many managers. It is interesting that those very same managers bemoan the fact that their developers don’t want to follow software processes yet will fight the adoption of a new agile process by a project team that is clamoring to it.

3. Comparing Development Methods

Table 1 describes and compares leading development methods.  The focus is on high-level software processes, not on detailed methods – therefore DAD is included but use case modeling is not.  This list is not meant to be exhaustive, instead it lists the development methods that appear to be in reasonably common use (in my opinion). Table 1 includes advice for when to apply the method, some of the situations overlap which reflects the fact that you have a methodological choice.  Figure 1 depicts a graph comparing the same processes.

Table 1 also indicates primary types of modeling artifacts that you are likely to create following each method. The artifacts are listed “in order” of creation although the reality is that most models are created iteratively, even when you are following so-called serial processes. There are many secondary models that are not listed, such as business rules or user interface prototypes on a DAD project, because those artifacts are not the focus of the method.  The table isn’t perfect, instead it is just barely good enough in that it shows that there are many different approaches to development, each of which has it’s own collection of primary modeling artifacts.  Each method is applicable to certain types of situations, so it is to your advantage to understand each method and to pick the one best suited for your current situation.

It is important to understand that the advice regarding when to use a method is fairly general and should be taken with a grain of salt.  For example, although XP is well suited for small teams people have been successfully applying XP on medium-sized teams between 40 and 60 people.

Figure 1. Comparing leading software processes.

4. Categories of Projects

• Any given project may fall into several categories.  You may outsource a data warehouse for example, or a new application development effort using C# and .NET technologies may involve integration with several legacy systems, integration with a new commercial off-the-shelf (COTS) package, and the retirement of an existing system that the new one replaces.
• The suggested methods reflect my experiences and opinion. I have no doubt that you could force-fit DAD to work for the development of a new COBOL application but is this really your best strategy when other well-defined and proven approaches already exist? 
• Each method is applicable in several scenarios yet no single method is applicable to all. Just like you want to follow the practice “Apply the Right Artifact(s)” when you are modeling, when you are working on a project you want to “Apply the Right Methods”.

5. You May Need Several Methods

1. Adopt a small subset of the available methods.  You don’t need to support every method listed in Table 1, but you will need a few. For example a combination of EUP, DAD, and a data-driven method should prove sufficient for most organizations. A combination of ISO/IEC 12207, EUP, and DAD could also work for many organizations. Organizations that tackle one type of project the size of the subset may in fact be one method. However, adopt ONLY ONE method if it makes sense to do so, not simply because it is convenient for management.
2. Be prepared to tailor the process to each project team. One team’s version of DAD will be slightly different than another team’s version and that’s ok. You might also decide to combine methods, for example DAD works very well with SAFe.
3. Define common goals, not common artifacts.  A common mistake that many organizations make is to insist on a common set of artifacts that every project must develop, resulting in make-work efforts that offer little actual value to the effort.  For example, don’t insist on a detailed requirements model comprised of a conceptual data model and a collection of shall statements when many methods require different requirements artifacts (such as use cases or feature statements). Instead insist that the project stakeholders come to an agreement with the project team as to what is to be built and when it is to be built – How the team and stakeholders come to that agreement is their business. 
4. Define common terminology.   Using the same terminology and concepts will make it easier to support several methods. One source of common terminology is the Software Process Engineering Metamodel (SPEM) specification.  The SPEM is something that your enterprise administrators may want to consider adopting to form the conceptual foundation for their software process support efforts.  Having said this, I wouldn't want to force fit an existing process into an unreasonable "standard" set of terms nor would I want to invest a lot of time in an effort to standardize terminology. If you can easily come to a terminology agreement then do it, otherwise move on to more important things.
5. Be flexible.  Everyone involved with software development needs to recognize that it is a complex endeavor and that there are many ways to succeed at it.
6. Prioritize.  A serious problem with supporting several methods is that many people need to be prepared to work with different types of artifacts.  For example, quality assurance professionals who facilitate requirements reviews will need to work with light-weight artifacts produced by a DAD team to a collection of acceptance tests written by an XP or DAD team to a 200-page system requirement specification (SRS) written by a ISO/IEC 12207 team.