Our clients regularly ask us about Agile versus Waterfall, Agile versus Business Analysis, or Agile versus Project Management. Our answers come from our perspective that system development and the management of it have a different life cycle, each with several variations, that are combined into a specific approach, e.g., for a particular project.
Agile versus Waterfall
Our view is that whenever systems are developed, or parts of systems, the System Development Life Cycle (SDLC) is relevant. Basically, the SDLC lays out the various activities that result in a system, e.g., Analysis, Design, Code, Test. Agile delivers (small) pieces of a system frequently (say, once every two weeks), and thus traverses various SDLC activities repeatedly, i.e., in each Sprint. Waterfall delivers the system in one go (“big bang”), and traverses SDLC activities one time through, one after the other.
Our version of the SDLC is depicted below:
In our perspective, we don’t see Agile versus Waterfall. Agile and Waterfall are similar in that they traverse the same SDLC activities. In our view, Agile and Waterfall differ in their frequency of delivery, and thus how often they traverse the SDLC. In certain situations, Waterfall may be more relevant; in others, Agile.
Agile versus Business Analysis
In Agile, say Scrum, the attention is focused on the Sprint. The functionality that is to be delivered is typically brought into the Sprint as stories by way of Sprint Planning or Backlog Grooming. Sprint Planning and Backlog Grooming start with stories that are (almost) ready to be worked on by the development team. Stories are, in effect, specifications for the functionality that is to be developed. The specifications should be based on Requirements. Requirements and specifications should be developed using Business Analysis.
In our perspective, we don’t see Agile versus Business Analysis. Agile is one approach to system development, which requires Business Analysis to take into account Requirements and to come up with good specifications for the functionality to be developed. However, Business Analysis takes place before the Sprint. Consequently, Business Analysis is generally not part of the Sprint, and Business Analysts are generally not part of the Sprint team. But, they are needed. So, in our perspective, it is Agile and Business Analysis.
Agile versus Project Management
With Agile, it is often not clear at the outset which exact functionalities will be delivered eventually, because requirements may shift over time, as users get more experience with the system. Therefore, it is not clear how long such functionalities would take to deliver. Consequently, it is argued that Project Management, with its focus on Scope, Schedule and Budget, is not relevant for Agile, i.e., Agile versus Project Management.
But, system development, when done with Agile or otherwise, still needs to be managed. Decisions about what kinds of functionalities should be delivered, and when, must be made, along with how many people to have on the team(s), how much money to allocate, and what risks should (not) be taken. Our view is depicted below:
In Agile environments, such decisions are made by the development team and the Product Manager (in Sprint Planning and Backlog Grooming). Scrum is often the approach that is used to manage each Sprint. Sprint Planning and Backlog Grooming generally implements decisions, types of systems needed or business strategy, that are made by executives above the development team and Product Manager. So, in our perspective, it is Agile and Project Management.
