Process methodologies

At some level, all development process methodologies are variations on the theme of managing development within the boundaries of some common realities:

• There are only so many useful working hours per person per day that can be devoted to a project
• There is a limit to the available resources, whether in terms of people, equipment, or money, available to a project
• There is a minimum acceptable quality standard for the project when it's complete

This is sometimes expressed as the Iron Triangle of project management:

The primary concern with respect to the Speed point is time—the most common focus is probably on a project needing to be complete by a specific deadline, or there is some other time constraint that may only be surmountable by adding developers to the team (an increase in Cost), or by cutting corners (a decrease in Quality).
 Budget variations are a common theme for the Cost point—anything that costs money, whether in the form of additional developers, newer/faster/better tools, and so on.
Reducing the available resources/staff decreases the Speed of project completion and/or the final Quality.

The Quality point is, obviously, concerned with quality measures—which might include specific internal or external standards—but could easily include less obvious items such as longer-term maintainability and support for new features and functionality. Prioritizing Quality, at a minimum, requires more developer hours, decreasing Speed, and increasing Cost.

Often, significant priority (whatever value for significant might apply) can only be given to two out of the three points of the triangle at most, yielding three priority possibilities:

• Fast, inexpensive development, at the cost of quality
• Fast, high-quality development, but at greater cost
• High-quality, inexpensive development that takes a longer time to complete

There are three specific development process methodologies that are worth an in-depth examination in the context of this book. The first, Waterfall, will be examined in order to provide a frame of reference for two Agile methodologies, Scrum and Kanban, and a few others will be looked at as well, at least briefly. A full discussion of any of them is well beyond the scope of this book, but the intention is to provide enough detail on each of them to illustrate what their focuses and priorities are, as well as their advantages and drawbacks. At a minimum, this should provide a baseline of what to expect while working in any of them, tying the phases of each methodology back to the phases of the model SDLC from Chapter 3, System Modeling, to show what happens, when, and how.