Choose the Right Way of Working (WoW)/Method for the Job

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

1. The Need for Flexibility

To succeed at software development you need to be flexible in your choice of software development method, to choose the right one for the job. There are several reasons why it is important to do so:

1. Different technologies require different techniques. Object-oriented methods are best-suited for teams 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 teams must conform to government regulations. Other teams 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. Initiative categories vary. Different types of initiatives, 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.

An organization gets the process that it deserves.

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 ways of thinking (WoT) and ways of working (WoW). 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 team that is clamoring to it.

Repeatable processes have nothing to do with successful software development,

repeatable results have everything to do with 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 team, 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.

Table 1. Comparing software development methods.

Figure 1. Comparing leading software processes.

4. Categories of Initiatives

It isn’t enough to recognize that you have a selection of software process methods to chose from. Nor is advice presented in Table 1 sufficient to determine whether a given method is a good candidate for your team because you must also take the type of initiative into account. Table 2 summarizes the various categories in which an initiative may fall, categories that are not mutually exclusive (e.g. it is possible to have an outsourced data warehousing team). Once again this table is meant to be representative but not exhaustive. It is important to understand that:

• Any given initiative 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 team you want to “Apply the Right Methods”.

Table 2. Comparing initiative categories.

5. You May Need Several Methods

So what’s the point? For the Agile Data method to work within an organization everyone needs to be flexible when it comes to leveraging a development method. One size clearly does not fit all, particularly when the types of initiatives vary widely. Everyone involved with software development needs to have an open mind, especially when working with different methods than they are used to. For traditional data developers the implication is that many initiatives may not have conceptual or logical data models, instead they may use Class Responsibility Collaborator (CRC) cards or UML class models. For application developers with a strong background in object-oriented development the implication is that sometimes they may work from traditional requirements artifacts such as shall statements or conceptual data models instead of the use cases or user stories that they may be accustomed to. Different teams will work with different artifacts, choosing the best options for their situation.

It is possible to easily adopt and support several methods within your organization if you choose to do so. To succeed you should:

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 initiative 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 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 team 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 stakeholders come to an agreement with the 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 streamlined artifacts produced by an agile 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.

The take-home point from this article is simple: It may be completely unrealistic to expect every single team within your organization to follow the same software development process. Different teams will create different types of artifacts, in different manners, and in different orders. Software development is complex and varied and as a result you need to have several processes in your intellectual toolbox if you wish to succeed. Yes, this makes your job as an IT professional harder than you would likely prefer. Life’s tough that way.